6 ms·

Front end engineer, here. Not very experienced, less than 10 years exp. Dumb question - why do we still need compilers like Babel and SWC to compile our es6 (e

Front end engineer, here. Not very experienced, less than 10 years exp. Dumb question - why do we still need compilers like Babel and SWC to compile our es6 (excluding TS) to...whatever version of js the compiler is targeting? Are browsers still so out of sync with each other that we still need to compile to es5? If yes, wouldn't it be more worthwhile for the front end community, including TC39 and every major browser engine developer (google, apple, mozilla, etc), to focus on the base implementation (engine) so they are no longer so out of sync? The most popular browser are based on open source engines anyway. Don't get me wrong, I am sure there is a good reason for all this rust tooling - faster compilation does not hurt, but it seems inefficient to have an intermediate compiler (Babel / swc/ TS/ etc) that creates deployable code that will eventually be interpreted by the user's JS engine (V8 / webkit / gecko) anyway. A standardized engine seems the way to go and it seems like we are going in that direction with only a handful of JS engines in use today.

skohan 5y ago
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.
- sroussey 5y ago
  JS is too complex for that. But you can have a look at AssemblyScript.
RcouF1uZ4gsC 5y ago
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.
totaldex 5y ago
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.
- game_the0ry 5y ago
  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.
  - WJW 5y ago
    How are we 'so close' though? Browser fragmentation hasn't really decreased at all, perhaps even the opposite.
rizky05 5y ago
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.
leerob 5y ago
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.
winterplace 5y ago
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.
acemarke 5y ago
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 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://jasonformat.com/enabling-modern-js-on-npm/ - https://web.dev/publish-modern-javascript/ https://web.dev/publish-modern-javascript/
- leerob 5y ago
  Excellent summary. Thank you!
- Buttersite 5y ago
  None of those are good reasons. If you need a JS transpiler you are overusing/misusing JS, probably to an extreme degree.
kag0 5y ago
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.
dexwiz 5y ago
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.
- sroussey 5y ago
  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?
  - jsmith45 5y ago
    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.
    - sroussey 5y ago
      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.
toastercat 5y ago
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.
- eatonphil 5y ago
  > 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).
  - toastercat 5y ago
    Which is great! And it even takes care of JSX/TS transpilation.
    - eatonphil 5y ago
      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.
      - toastercat 5y ago
        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.
- sroussey 5y ago
  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?
Androider 5y ago
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.
__s 5y ago
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
jsmith45 5y ago
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.

skohan 5y ago

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.

sroussey 5y ago
JS is too complex for that. But you can have a look at AssemblyScript.

RcouF1uZ4gsC 5y ago

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.

totaldex 5y ago

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.

game_the0ry 5y ago
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.
- WJW 5y ago
  How are we 'so close' though? Browser fragmentation hasn't really decreased at all, perhaps even the opposite.

rizky05 5y ago

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.

leerob 5y ago

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.

winterplace 5y ago

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.

acemarke 5y ago

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 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://jasonformat.com/enabling-modern-js-on-npm/ - https://web.dev/publish-modern-javascript/ https://web.dev/publish-modern-javascript/

leerob 5y ago
Excellent summary. Thank you!
Buttersite 5y ago
None of those are good reasons. If you need a JS transpiler you are overusing/misusing JS, probably to an extreme degree.

kag0 5y ago

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.

dexwiz 5y ago

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.

sroussey 5y ago
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?
- jsmith45 5y ago
  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.
  - sroussey 5y ago
    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.

toastercat 5y ago

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.

eatonphil 5y ago
> 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).
- toastercat 5y ago
  Which is great! And it even takes care of JSX/TS transpilation.
  - eatonphil 5y ago
    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.
    - toastercat 5y ago
      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.
sroussey 5y ago
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?

Androider 5y ago

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.

__s 5y ago

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

jsmith45 5y ago

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.