5 ms·

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?

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?
- vorpalhex 5y ago
  Node support for ES6 modules has been out for years...
  - josephg 5y ago
    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/ https://kangax.github.io/compat-table/es2016plus/ (also check the ES6 tab)
josephg 5y ago
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.
cuddlecake 5y ago
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.
- toastercat 5y ago
  Point taken.
Zababa 5y ago
There might be one reason: compiling from ES6+ to ES5 transforms for of loops in regular for loops, which are faster.

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?

vorpalhex 5y ago
Node support for ES6 modules has been out for years...
- josephg 5y ago
  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/ https://kangax.github.io/compat-table/es2016plus/ (also check the ES6 tab)

josephg 5y ago

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.

cuddlecake 5y ago

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.

toastercat 5y ago
Point taken.

Zababa 5y ago

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