Hacker News Reader

There's many reasons to have a JS compilation step:

- Still targeting legacy browsers like IE11

- Using React / JSX syntax

- Using TypeScript

- Using other brand-new JS syntax that hasn't trickled out to wider support yet

- Using custom JS transforms for libraries like `styled-components` (see this Next.js discussion thread for examples of the many different non-standard Babel transformations that people are using: https://github.com/vercel/next.js/discussions/30174 )

That said, the ideal target language version _is_ getting better. Jason Miller ( creator of Preact) has done a lot of research on both browser support for ES2017, as well as tooling to reverse-compile ES5-targeted published libraries upwards to ES2017 syntax again for improved bundle size:

- https://jasonformat.com/enabling-modern-js-on-npm/

- https://web.dev/publish-modern-javascript/

Excellent summary. Thank you!

The important part is to know your target. I'm currently working on a project that has a complex webpack/babel setup. The reason for the complicated toolchain? I have no idea. Our target (Electron) supports ES6+ syntax yet we're still compiling down to ES5. The only other reason I can think is that the developers wanted ES2020+ features, but this, in my mind, is a bad tradeoff. The toolchain has broken more than once for me. Realistically, all we need is `tsc` and `esbuild`.

I've been a JS developer for almost 10 years. I'm convinced young hip developers are just addicted to tooling.

> Realistically, all we need is `tsc` and `esbuild`.

esbuild and babel/webpack do basically the same thing. esbuild can also target older versions of JavaScript (just not es5).

Which is great! And it even takes care of JSX/TS transpilation.

I'm confused about what your point is then since either way you are using some system in between your code and the browser or Node.

You'd likely still need a bundler for vendor packages. esbuild ships as a static binary, is a single dependency, and is one of the fastest bundlers around. It's also pretty much zero-config. That other stuff is just icing on top. I don't know why someone would pick webpack + babel + the endless plugins and config involved over that.

Electron uses node and node support for es6 modules is new, and electron itself is just putting its toes in the water. Same with Typescript. Are you using .mts .mtsx files?

Node support for ES6 modules has been out for years...

Es modules are one of hundreds of features that have been added to javascript since es5. Others include typed arrays, promises, async/await, and so on. Babel configured to recompile code to es5 will polyfill all of those JS features. So the highly efficient V8 implementation of Uint8Array is replaced with slow javascript. Code using async await will be rewritten to use a promise polyfill and callbacks. And so on. The resulting code will be bigger and slower. Sometimes much slower depending on what it’s doing.

List of features in each version of JS: https://kangax.github.io/compat-table/es2016plus/ (also check the ES6 tab)

The answer is usually that whoever set up webpack grabbed the configuration from another project, and nobody wanted to touch it since then because it worked and it looks scary.

Young developers don’t know what they don’t know. If they don’t see editing the webpack configuration as part of their job, they’ll probably just never touch it.

And that means it’s your job to go fix it! Compiling down to es5 can have terrible performance implications for the resulting application - particularly if any of the bundled code touches typed arrays. There’s some free performance wins sitting on the table. If your coworkers are too junior, it falls to you to fix the build.

The best way to drive a wedge between young and old developers is to negatively attribute something to a specific age group.

So keep going, you're on the right track.

Point taken.

There might be one reason: compiling from ES6+ to ES5 transforms for of loops in regular for loops, which are faster.

In a perfect world, things would be like you describe.

Unfortunately we live in a diverse landscape of browsers and devices, many of which have not been updated in quite some time. Factors ranging from IT policy at older companies, to geographical limitations, may prevent many users from upgrading to the latest and greatest.

Some companies choose to cut their losses, and support only certain browsers - these can get away with less compilation and polyfills. Other companies may be targeting these specific segments (such as B2B), and can't get away with such a luxury.

But we are so close - the wound has almost healed, and instead of taking off the band aid, we are putting on another band aid.

How are we 'so close' though? Browser fragmentation hasn't really decreased at all, perhaps even the opposite.

You have to realize that it is not at all in the interest of most commercial web applications to be transparently delivered as ES modules, all neatly split up and perhaps lightly minified. No, the fact that your 1000+ constantly version churning NPM dependencies and your proprietary business code are all bundled up in a big undecipherable blob is seen as a feature. The only thing that I can see that is going to replace it, is probably going to be WASM or a binary format blob, or the application code executing entirely on the backend and the frontend streamed like Netflix.

While a compiler-free world sounds ideal, my take is there will always be different, newer, syntax developers will want to write that isn't natively supported by the browser. For example, JavaScript language proposals that are maybe in stage 1 instead of the later stages.

Overall, browsers have gotten a lot better at implementing and supporting a common set of web APIs. There's still work to be done, but we're in a far better place than we were five years ago (in my opinion).

100% agree with your sentiment though.

It's more of an issue on the end user's side. All the main browsers have had support for ES6 and newer features for years. But that doesn't mean end users are running the latest versions of those browsers. So when you transpile/polyfill a feature, you're aiming to support that small number of users who haven't updated their browser in 5+ years. If you don't care about those people, you have no need for that intermediate step. Or if you want to be really sophisticated, you can look at the user agent for an incoming request and serve a response that's transpiled/polyfilled exactly as much as is needed.

Let's say we had no need for babel or similar level transpilers.

There would still be benefit to webpack-like bundlers, if for no other reason then for performance/obfuscation reasons we would probably want the number of modules as seen by the broswer to be smaller than the number of modules that developers like to use for development purposes.

Many would still want minification for both performance and obfuscation reasons.

Many would still want to tree shake out any unused code from the libraries used (again for performance reasons).

Once one have all of that tooling, adding a babel like transpiler to the stack is not that big a deal.

At this point, if you are only targeting modern browsers, it's more for the bundler than the transpiler. The module loader standard is still a mess, mostly because there is little incentive to fix it. Unless you are using HTTP/2 or another streaming connection, loading the hundreds of project files and thousands of dependencies, is just not feasible. The compilers also do a bunch of tree shaking to remove dead code from your dependency graph.

It will be interesting to see a tool that does dead code elimination (tree shaking) and minimization, then writing back individual es6 module files for http2. Maybe one of tools can be configured to do so now?

The Rollup tool supports that in conjunction with the `preserveModules` option. I've never used it outside of playing around, so can't vouch for it from experience, but yeah it exists. It can also do more of course, like convert to older module formats or the like, but obviously you don't need to use that.

The biggest downside is that even in http2 or http3, bundles can still perform better in terms of lower overall loading times, since individual modules you need to download the first one, and perform at least a bit of parsing to find the other modules statically imported before you can start downloading those, repeat.

Right, though you could use HTTP2 push, but to do that right… you would need a tool to know which files are bundled and their order and… it looks like today.

With one exception though… cache invalidation of a single source file would not invalidate an entire bundle or chunk.

It seems to me the future is rather in gradually replacing JS engines with a WASM back-end. The whole webpack/babel ecosystem could be replaced by a toolchain which targets WASM, and browsers could ship with a JS engine which just translates es5 to WASM for legacy support.

I guess the WASM api is lacking a lot of features which would be required to make this work, but I don't see why it shouldn't be the goal.

JS is too complex for that. But you can have a look at AssemblyScript.

Because there are old computers and phones with old browsers that are still running today and will not be upgraded. Many companies cannot risk upgrading and many consumers have not upgraded or bought a newer device.

The old browsers are on ES5.

Also, if we are going through a compile step anyway, why not a future for more support for WebAssembly and then we can use other languages instead of JavaScript.

You don't need Babel anymore. I recently updated a project of mine to only use Babel on jsx files only for jsx transform. webpack handles everything

Browser competition is one that sparks inovation. Each vendor wants to be the leader. So they compete.

And also anyone want to browse web using any browser they have at the time, it may be outdated.