4 ms·

Alas, there's such a massive ecosystem at this point around Webpack and Babel and family (extra features like tree-shaking, loaders support for different things

by _bxg1 7y ago

Alas, there's such a massive ecosystem at this point around Webpack and Babel and family (extra features like tree-shaking, loaders support for different things, project configurations, etc.), that I think you'd be hard-pressed to make an outright replacement take off. What you could do (and I'm surprised this hasn't been done yet) is lower some of the hot paths of Webpack itself into a lower-level language. Possibly even moreso than Webpack, Babel seems like a natural target since it has much simpler input/output. Although one barrier I can see with that (unless it's C/C++) is requiring people to install a whole other build system just for it to be used in an npm install. C/C++ compilers generally come with the system, but Go/Rust ones do not. Edit: further info https://stackoverflow.com/questions/20728255/could-one-write-a-native-node-js-extension-in-go-as-opposed-to-c#39262638 https://stackoverflow.com/questions/20728255/could-one-write...

wildpeaks 7y ago
I suspect the supposed sluggishness attributed to Webpack actually comes from Babel instead because it's been fast ever since I removed Babel from my pipelines (because Typescript already covers what I was using Babel for).
nitsky 7y ago
Check out this project that is an attempt to rewrite Babel in Rust. It includes a Webpack plugin and their benchmarks show a major speedup. https://github.com/swc-project/swc https://github.com/swc-project/swc
- _bxg1 7y ago
  Very cool. Gotta say though, that logo is impossible to read...
catlifeonmars 7y ago
I think that’s a good observation. Babel is probably a perfect place to start. Two things: (1) In Go you can trivially distribute pre built binaries for <num arch> * <num os> targets. Just building with GOOS set to windows, darwin, and linux (with GOARCH set to amd64 and arm64) would cover 99% of all users. (2) Depending on where bottlenecks are, RPC/HTTP/WS can be just as effective as dynamic linking. So maybe even the need for a C/C++ toolchain could be avoided.
- _bxg1 7y ago
  I didn't know that about Go, that's pretty cool! I assumed it was like Rust, where the compiler/toolchain makes builds on arbitrary specific platforms really easy to do, but where you still have to actually do those very narrow builds.
  - pcwalton 7y ago
    > I assumed it was like Rust, where the compiler/toolchain makes builds on arbitrary specific platforms really easy to do, but where you still have to actually do those very narrow builds. What's the difference?
  - boulos 7y ago
    I think you may have misunderstood: each “go build” incantation lets you produce a single OS/arch binary, not a “fat binary”. So you make a build per OS/arch pair and distribute it.
- zbentley 7y ago
  You're right about cross-compilation, but > Depending on where bottlenecks are, RPC/HTTP/WS can be just as effective as dynamic linking. ...is just wrong. Even when performance doesn't matter at all (and it matters significantly: replacing even a low constant number dynamic library calls with optimized host-local RPCs using a fast transport can be enough to transition latency from "unnoticeable" to "a human can feel the lag"), the complexity undertaken when orchestrating any sort of RPC or webservice/webhook is substantial--absent LD_LIBRARY_PATH hacks and getting libraries installed, you don't have to think about any of that stuff when (dynamically or statically) linking.
morelisp 7y ago
Most teams I know using Webpack would love to spend the 1-2 "upgrade bullshit" days annually they already have to spend on Webpack porting to something else instead, if it actually had some longevity and advantage (and Parcel does not, if you already have a working Webpack config - still slow, still accretes config bullshit at the same rate, it just has a more mature 0 epoch).
- earthboundkid 7y ago
  The problem with Webpack is that it is not a JavaScript bundler. It is a JavaScript bundler creation toolkit. That’s great if you want to write a bundler. But it’s a huge waste of time if you just want to bundle your damn JavaScript.
- _bxg1 7y ago
  It's not just the up-front config change, it's the constellation of loaders and such around it. I assume this new project doesn't have a TypeScript loader, or an Elm loader, or a Polymer-specific loader. https://webpack.js.org/loaders/ https://webpack.js.org/loaders/
phlakaton 7y ago
https://what-problem-does-it-solve.com/webpack/interoperability.html https://what-problem-does-it-solve.com/webpack/interoperabil... nailed head-on what I detest about Webpack and many Javascript build solutions for that matter: the burning desire to shove the kitchen sink of operations into a single tool with its own, incompatible-with-everyone-else, plugin framework and an ungodly configuration language. Where all I really wanted was a somewhat more ergonomic Make and a bunch of well-written, decoupled tools to use with it. This is on my back burner of ideas to run with one day, but as a back-end engineer working in other langs, it hasn't quite bubbled up to the surface yet.
- zdragnar 7y ago
  Several of these exist and predate webpack. Webpack became popular precisely because it wasn't grunt, gulp or npm run scripts.
  - phlakaton 7y ago
    And yet, look what it has become.
- IshKebab 7y ago
  Agreed. A decent build system language and separate tools would be a lot easier to understand than one megatool that does everything in a magic way with plugins and a mega-config file that's impossible to understand.
shados 7y ago
The biggest bottleneck in the JS ecosystem is the minified, and that is already kind of decoupled from the other tools. Webpack plays with Terser pretty closely, but it's not particularly hard to do the minification as a separate step, or even write a Webpack plugin to replace the existing ones. On large builds, minification is often as much as 80%+ of the build time, sometimes even if you include the unit tests! Most projects aren't particularly opinionated about their minification solution, either, so you can just swap it in. That makes it a very good place to start. For development where minification isn't needed, Webpack is still slow, but it doesn't matter nearly as much. Even very large projects rebuild fairly quickly in dev server mode (assuming they're setup right), and if Webpack 5's persistent cache delivers, startup shouldn't be too bad either. It would still be great if the community made changes as you suggest to speed things up, but minification is really where efforts should start, IMO.

by _bxg1 7y ago

wildpeaks 7y ago

I suspect the supposed sluggishness attributed to Webpack actually comes from Babel instead because it's been fast ever since I removed Babel from my pipelines (because Typescript already covers what I was using Babel for).

nitsky 7y ago

Check out this project that is an attempt to rewrite Babel in Rust. It includes a Webpack plugin and their benchmarks show a major speedup. https://github.com/swc-project/swc https://github.com/swc-project/swc

_bxg1 7y ago
Very cool. Gotta say though, that logo is impossible to read...

catlifeonmars 7y ago

I think that’s a good observation. Babel is probably a perfect place to start. Two things: (1) In Go you can trivially distribute pre built binaries for <num arch> * <num os> targets. Just building with GOOS set to windows, darwin, and linux (with GOARCH set to amd64 and arm64) would cover 99% of all users. (2) Depending on where bottlenecks are, RPC/HTTP/WS can be just as effective as dynamic linking. So maybe even the need for a C/C++ toolchain could be avoided.

_bxg1 7y ago
I didn't know that about Go, that's pretty cool! I assumed it was like Rust, where the compiler/toolchain makes builds on arbitrary specific platforms really easy to do, but where you still have to actually do those very narrow builds.
- pcwalton 7y ago
  > I assumed it was like Rust, where the compiler/toolchain makes builds on arbitrary specific platforms really easy to do, but where you still have to actually do those very narrow builds. What's the difference?
- boulos 7y ago
  I think you may have misunderstood: each “go build” incantation lets you produce a single OS/arch binary, not a “fat binary”. So you make a build per OS/arch pair and distribute it.
zbentley 7y ago
You're right about cross-compilation, but > Depending on where bottlenecks are, RPC/HTTP/WS can be just as effective as dynamic linking. ...is just wrong. Even when performance doesn't matter at all (and it matters significantly: replacing even a low constant number dynamic library calls with optimized host-local RPCs using a fast transport can be enough to transition latency from "unnoticeable" to "a human can feel the lag"), the complexity undertaken when orchestrating any sort of RPC or webservice/webhook is substantial--absent LD_LIBRARY_PATH hacks and getting libraries installed, you don't have to think about any of that stuff when (dynamically or statically) linking.

morelisp 7y ago

Most teams I know using Webpack would love to spend the 1-2 "upgrade bullshit" days annually they already have to spend on Webpack porting to something else instead, if it actually had some longevity and advantage (and Parcel does not, if you already have a working Webpack config - still slow, still accretes config bullshit at the same rate, it just has a more mature 0 epoch).

earthboundkid 7y ago
The problem with Webpack is that it is not a JavaScript bundler. It is a JavaScript bundler creation toolkit. That’s great if you want to write a bundler. But it’s a huge waste of time if you just want to bundle your damn JavaScript.
_bxg1 7y ago
It's not just the up-front config change, it's the constellation of loaders and such around it. I assume this new project doesn't have a TypeScript loader, or an Elm loader, or a Polymer-specific loader. https://webpack.js.org/loaders/ https://webpack.js.org/loaders/

phlakaton 7y ago

https://what-problem-does-it-solve.com/webpack/interoperability.html https://what-problem-does-it-solve.com/webpack/interoperabil... nailed head-on what I detest about Webpack and many Javascript build solutions for that matter: the burning desire to shove the kitchen sink of operations into a single tool with its own, incompatible-with-everyone-else, plugin framework and an ungodly configuration language. Where all I really wanted was a somewhat more ergonomic Make and a bunch of well-written, decoupled tools to use with it. This is on my back burner of ideas to run with one day, but as a back-end engineer working in other langs, it hasn't quite bubbled up to the surface yet.

zdragnar 7y ago
Several of these exist and predate webpack. Webpack became popular precisely because it wasn't grunt, gulp or npm run scripts.
- phlakaton 7y ago
  And yet, look what it has become.
IshKebab 7y ago
Agreed. A decent build system language and separate tools would be a lot easier to understand than one megatool that does everything in a magic way with plugins and a mega-config file that's impossible to understand.

shados 7y ago

The biggest bottleneck in the JS ecosystem is the minified, and that is already kind of decoupled from the other tools. Webpack plays with Terser pretty closely, but it's not particularly hard to do the minification as a separate step, or even write a Webpack plugin to replace the existing ones. On large builds, minification is often as much as 80%+ of the build time, sometimes even if you include the unit tests! Most projects aren't particularly opinionated about their minification solution, either, so you can just swap it in. That makes it a very good place to start. For development where minification isn't needed, Webpack is still slow, but it doesn't matter nearly as much. Even very large projects rebuild fairly quickly in dev server mode (assuming they're setup right), and if Webpack 5's persistent cache delivers, startup shouldn't be too bad either. It would still be great if the community made changes as you suggest to speed things up, but minification is really where efforts should start, IMO.