Postcss is not necessary for custom properties. IE isn’t a thing anymore, and using css custom properties directly without a transpilation step is fine. The same thing applies to the for … of issue. Babel is not necessary anymore, all browsers support ES8. JSX is the only thing babel still does that offers real value, but that can be replaced by the runtime alternative developit/htm. We can just stop using babel and sidestep this whole issue.
I see a lot of energy going into making faster build tools, and I feel this energy is misdirected. We need to dramatically strip down the build tools as most of them have become largely redundant since the death of IE.
I share your opinion, but recently got very disappointed to find out that safari still needs lots of -webkit- prefixes; even for stuff seemingly available for ages now. So we’re not fully out of the pit yet, at least until the most valuable company in the world finally cares to fix their fucking browser (yes, dear Apple engineer, I’m talking to you!)
I don’t know what you’re using but most developers most likely don’t need “lots of -webkit- prefixes”.
In the link posted by the sibling commenter, I see 2-3 properties that could be useful to the general public. The rest is esoteric, never-ratified, or straight up user hostile (font-smooth)
It's like user agent strings. Developers didn't fix their user agents, so other browsers just lied about what they were so the website would run properly. Only now they were stuck with the lie as long as devs depended on the user agent string for stuff leading to abominations like this one from Chrome on Android where it basically claims to be every single browser out there.
Mozilla/5.0 (Linux; Android 12; Pixel 6 Build/SD1A.210817.023; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/94.0.4606.71 Mobile Safari/537.36
Devs were NOT supposed to use prefixes in production, but they did anyway (best viewed in Chrome). Unfortunately they then proceeded to NEVER UPDATE these as other browsers added support. Non-webkit browsers had the choice of interpreting the CSS or leaving their users with a broken experience.
Major browsers moved away from vendor prefixes between 2012 and 2016 (when webkit finally stopped), but it was too late. Browsers 50 years from now will still be supporting this garbage because of what devs did.
The key takeaway: Never give devs a tool you don't want to be stuck with forever. Also, can we please not do this yet again in the future?
Firefox added support for -webkit prefixes several years ago now... I think mostly to capture things written for mobile Safari but also Chrome I imagine.
I don't know if anybody really does other directions of that, though. There was probably no percentage in working with -moz prefixes for other browsers by the time this became an idea to do.
You still need postcss or something like it to use css modules. The alternative of CSS-in-JS requires a build step to extract either a CSS file or inline critical styles for server rendering. The browser-native alternative of CSS Module Scripts doesn't work in Safari.
You still need babel, tsc, or swc to transform typescript to JS.
And then there are imports of files that aren't JS (images, fonts, stylesheets, etc).
The best approach for a no build CSS approach I've found is using BEM notation to scope the CSS of each component, and then @import'ing the separate CSS files into a master stylesheet. When hosted over HTTP/2 those @imports are downloaded pretty efficiently. However, when doing that the lighthouse score is impacted and it doesn't scale for large websites.
Typescript is indeed a given. There's no good way to do that without build tools. The question is whether typescript's benefits are worth the overhead of the build tooling. I tend to prefer it for libraries with strict API's, but I don't experience as much of a benefit for web applications. I think libraries also benefit a lot from bundling/minifying, so there I would choose a full build tools approach. For small web applications the overhead of the build tooling is not worth the benefit IMHO.
And then when it comes to direct imports of images, fonts, svg, I don't think people should do that at all, even when using heavy build tools. YMMV.
@imports are invisible to the browser's preparser as the stylesheet that contains them must be downloaded and parses before the browser can discover them
This will lead to slower FCP etc times particularly if the stylesheets aren't in cache
Funny that you mention htm, because developit is Jason, who build Preact, and the author of the article is Marvin, also working on Preact. So I'm pretty sure the author know about what is needed and the alternatives and still sees use cases and just wants faster builds. Just look at the article before about unit tests in 1s. That's where he is coming from.
> I see a lot of energy going into making faster build tools, and I feel this energy is misdirected. We need to dramatically strip down the build tools as most of them have become largely redundant since the death of IE.
what if we standardize browsers ? Like if it happens, we get easily all of the power from browser itself. It's same story like ES6 and later versions did to underscore and lodash (long live lodash).
The Babel example problem in the article is a fascinating one because that's someone's metaprogramming that's just lost in the ether of time and the labyrinthine tower of a Babel install someone's too afraid to break to just tear down. Not only is it an unnecessary downlevel transform in 2022, but it doesn't look like any of the official transforms that common Babel transforms produced, so who knows what metaprogramming thought might be a good idea that delivers that from that configured stack?
As others have pointed out: JSX transforms have non-Babel options (also including Vite, esbuild, and Typescript).
As for other metaprogramming commonly done in Babel: I would point out that the Stage 0 Decorators that Angular was built on (not to be confused with the Stage 3 Decorators that might actually come to JS) have relied on very specific Typescript build options anyway and the double-up that Angulars tools by default do of also feeding that Babel is kind of silly.
One of those parentheticals also slightly buries the lede that there is a Decorators proposal at Stage 3 and likely to get added to Browsers "in the near future" for those that desperately want to do metaprogramming in JS to have metaprogramming in JS proper, no Babel needed. (There are Stage 1 proposals to offer even more meta- and reflection tools beyond that directly in the language.)
In 2022 though, it is worth asking what in JS needs metaprogramming? A lot of applications get by without it just fine.
How would I remove all console.log from my code automatically during a build?
How would I add syntactically nice things to JS?
How would I get my environment variable values set for the build into the code, which is to be run in a browser?
JS being JS, there seem to be no good facilities in the language itself to do that inside the language. My understanding is, that babel was created to do these things outside of the running script. Maybe there is another way that I am not aware of?
> How would I remove all console.log from my code automatically during a build?
Make it a lint warning?
Add a higher-level logging abstraction and/or library?
I know Webpack and Esbuild both have ways to define symbols like `console` at build time and get dead code elimination. No Babel needed.
> How would I add syntactically nice things to JS?
What do you need in 2022?
I definitely understand that in 2014 there were a lot of nice polyfills and prollyfills to be found in the Babel ecosystem for syntax that made the language a lot nicer to work in, but in the last eight years, most of them are in the language itself now and supported in nearly every browser. ES2015+ has so much of that goodness baked in and every browser generally supports ES2015+ well (and so does Node, mostly). Most caniuse statistics says browsers are caught up to at least ES2020.
We are over and on the side of the hump that Babel helped collectively prepare us for.
Yes, there's still a usefulness there in testing future ideas and it will probably still always be a collaborative tool for helping with TC39 early stage testing of proposals. But at this point, should your Production builds really rely on anything before Stage 3 with TC-39?
For stuff in Stage 3+ there's always Typescript as an alternative to Babel.
> How would I get my environment variable values set for the build into the code, which is to be run in a browser?
You do that in Babel? I've never heard of anyone doing that Babel. I've seen all sorts of dynamic import strategies in Webpack and other builders. I've done some neat things with JSON files and sometimes builder imports and sometimes just good old fetch().
Postcss is not necessary for custom properties. IE isn’t a thing anymore, and using css custom properties directly without a transpilation step is fine. The same thing applies to the for … of issue. Babel is not necessary anymore, all browsers support ES8. JSX is the only thing babel still does that offers real value, but that can be replaced by the runtime alternative developit/htm. We can just stop using babel and sidestep this whole issue.
I see a lot of energy going into making faster build tools, and I feel this energy is misdirected. We need to dramatically strip down the build tools as most of them have become largely redundant since the death of IE.