4 ms·

Remember when all of these points applied to webpack, when it was the “single simple fast tool” to replace everyone’s grunt scripts? It seems there’s a feature

Remember when all of these points applied to webpack, when it was the “single simple fast tool” to replace everyone’s grunt scripts? It seems there’s a feature treadmill at work here where projects inexorably bloat as they get popular. But we tried “compose tools in the Unix way” with grunt too, and that led to spaghetti scripts, unique to each project, that were hard to reason about. I wonder if there is a middle way that can prevent the tool from giving in to the pressure to add features.

shakezula 5y ago
The Convention Over Configuration crowd has their arguments.
Epskampie 5y ago
I really don’t, webpack config was was a cluster&€@ from day 1. Also, webpacks goal always was to do everything and the kitchen sink, much different from esbuild.
- josteink 5y ago
  Seconding that. It’s the one reason I never started using webpack in the first place, at least not from scratch. Angular ships with a working config out of the box, and I hope I never, ever will have to tweak that to fix a build.
eyelidlessness 5y ago
ESBuild’s author and docs[1] are quite clear about its future scope: > [… a list of features that are already done…] > After that point, I will consider esbuild to be relatively complete. I'm planning for esbuild to reach a mostly stable state and then stop accumulating more features. This will involve saying "no" to requests for adding major features to esbuild itself. I don't think esbuild should become an all-in-one solution for all frontend needs. In particular, I want to avoid the pain and problems of the "webpack config" model where the underlying tool is too flexible and usability suffers. That said, now quoting you… > But we tried “compose tools in the Unix way” with grunt too, and that led to spaghetti scripts, unique to each project, that were hard to reason about. In this respect, ESBuild’s firm stance has a major strength, and a major weakness: - Strength: the Unix philosophy is easy to achieve, with esbuild-plugin-pipe[2]. There’s just one, simple plugin API, everything follows that same format - Weakness: since ESBuild doesn’t expose its AST, plugins are often slow which can undermine the benefits of the tool 1: https://esbuild.github.io/faq/#upcoming-roadmap https://esbuild.github.io/faq/#upcoming-roadmap 2: https://github.com/nativew/esbuild-plugin-pipe https://github.com/nativew/esbuild-plugin-pipe
- spartanatreyu 5y ago
  "Weakness: since ESBuild doesn’t expose its AST, plugins are often slow which can undermine the benefits of the tool" I think by the time we even care about the performance of a plugin being "golang" fast, we will have rome built in rust. Rome will be the full kit and caboodle at native speeds (bundler, tree shaking compiler, linter, type checker, etc...), whereas esbuild will be the rome-lite for when you just want to bundle some code and have it done.
  - eyelidlessness 5y ago
    > I think by the time we even care about the performance of a plugin being "golang" fast I certainly care about it being faster than estree-*/babel. There are a lot of static analysis and optimization things I’d like to do that are slow enough in JS to negate a lot of ESBuild’s advantage. > we will have rome built in rust. > Rome will be the full kit and caboodle at native speeds (bundler, tree shaking compiler, linter, type checker, etc...), whereas esbuild will be the rome-lite for when you just want to bundle some code and have it done. Is Rome-Rust doing something special to optimize arbitrary AST-based plugins written in JS? I hadn’t heard that but I’d be interested if it is.
imbnwa 5y ago
> Remember when all of these points applied to webpack, when it was the “single simple fast tool” to replace everyone’s grunt scripts? Don't recall perf being the win with Webpack, Webpack was "Web-Pack" because it allowed you to use CommonJS to co-locate external assets (SVGs, CSS, etc) with code, and then being able to produce distinct bundles from that dependency graph. Grunt had no clue what your source dep graph looked like, you had to build your own pipeline (specifying dependent tasks for each task). Of course, now everybody has their own Webpack config that alters some input or output, but it's a considerably more powerful tool than Grunt ever was.
brundolf 5y ago
Something a lot of people don’t appreciate is that the past ten years have been an anomaly for JavaScript. They’ve been very tumultuous because there was a ton of evolving that suddenly needed to happen. And I think we’re nearing the end. Babel was necessary because core syntaxes were changing so fast. Webpack’s sprawling nature was needed because there were so many alternate dialects, module systems to support, etc. Esbuild is only possible because we’ve generally converged on TypeScript, JSX, ES modules, etc. It knows what you probably were going to configure webpack to do anyway, so it can just do it. So I wouldn’t call it a “treadmill”, I’d call it growing pains
- dgritsko 5y ago
  This is a great point. A "Cambrian explosion" the likes of which the JS ecosystem experienced over the last 10-15 years will slow down eventually. Curious to hear whether other folks agree or not.
  - jscambrian 5y ago
    I survived the JavaScript Cambrian explosion and all I got was a disenchantment with computer programming
    - mpd 5y ago
      To me, it feels like the same effect as Ruby ~15-10 years ago. Lots of chaos as good (subsequently winnowed down to preferred), patterns were discovered, and then things stabilized. It isn't sexy anymore, but to this day I've yet to discover a better tool, that lets me blast out features and make changes at rapid pace, than Ruby (and Rails on the web side).
  - asimpletune 5y ago
    Yeah, it’s a great point. I always assumed that there was so much tool churning just because of the nature of the front-end itself as a target for building software. However I think the “Cambrian explosion” point here makes a lot of sense.
- 5y ago
tengbretson 5y ago
> Remember when all of these points applied to webpack, when it was the “single simple fast tool” to replace everyone’s grunt scripts? You're forgetting the 6 months where everyone rewrote everything with Gulp.

shakezula 5y ago

The Convention Over Configuration crowd has their arguments.

Epskampie 5y ago

I really don’t, webpack config was was a cluster&€@ from day 1. Also, webpacks goal always was to do everything and the kitchen sink, much different from esbuild.

josteink 5y ago
Seconding that. It’s the one reason I never started using webpack in the first place, at least not from scratch. Angular ships with a working config out of the box, and I hope I never, ever will have to tweak that to fix a build.

eyelidlessness 5y ago

ESBuild’s author and docs[1] are quite clear about its future scope: > [… a list of features that are already done…] > After that point, I will consider esbuild to be relatively complete. I'm planning for esbuild to reach a mostly stable state and then stop accumulating more features. This will involve saying "no" to requests for adding major features to esbuild itself. I don't think esbuild should become an all-in-one solution for all frontend needs. In particular, I want to avoid the pain and problems of the "webpack config" model where the underlying tool is too flexible and usability suffers. That said, now quoting you… > But we tried “compose tools in the Unix way” with grunt too, and that led to spaghetti scripts, unique to each project, that were hard to reason about. In this respect, ESBuild’s firm stance has a major strength, and a major weakness: - Strength: the Unix philosophy is easy to achieve, with esbuild-plugin-pipe[2]. There’s just one, simple plugin API, everything follows that same format - Weakness: since ESBuild doesn’t expose its AST, plugins are often slow which can undermine the benefits of the tool 1: https://esbuild.github.io/faq/#upcoming-roadmap https://esbuild.github.io/faq/#upcoming-roadmap 2: https://github.com/nativew/esbuild-plugin-pipe https://github.com/nativew/esbuild-plugin-pipe

spartanatreyu 5y ago
"Weakness: since ESBuild doesn’t expose its AST, plugins are often slow which can undermine the benefits of the tool" I think by the time we even care about the performance of a plugin being "golang" fast, we will have rome built in rust. Rome will be the full kit and caboodle at native speeds (bundler, tree shaking compiler, linter, type checker, etc...), whereas esbuild will be the rome-lite for when you just want to bundle some code and have it done.
- eyelidlessness 5y ago
  > I think by the time we even care about the performance of a plugin being "golang" fast I certainly care about it being faster than estree-*/babel. There are a lot of static analysis and optimization things I’d like to do that are slow enough in JS to negate a lot of ESBuild’s advantage. > we will have rome built in rust. > Rome will be the full kit and caboodle at native speeds (bundler, tree shaking compiler, linter, type checker, etc...), whereas esbuild will be the rome-lite for when you just want to bundle some code and have it done. Is Rome-Rust doing something special to optimize arbitrary AST-based plugins written in JS? I hadn’t heard that but I’d be interested if it is.

imbnwa 5y ago

> Remember when all of these points applied to webpack, when it was the “single simple fast tool” to replace everyone’s grunt scripts? Don't recall perf being the win with Webpack, Webpack was "Web-Pack" because it allowed you to use CommonJS to co-locate external assets (SVGs, CSS, etc) with code, and then being able to produce distinct bundles from that dependency graph. Grunt had no clue what your source dep graph looked like, you had to build your own pipeline (specifying dependent tasks for each task). Of course, now everybody has their own Webpack config that alters some input or output, but it's a considerably more powerful tool than Grunt ever was.

brundolf 5y ago

Something a lot of people don’t appreciate is that the past ten years have been an anomaly for JavaScript. They’ve been very tumultuous because there was a ton of evolving that suddenly needed to happen. And I think we’re nearing the end. Babel was necessary because core syntaxes were changing so fast. Webpack’s sprawling nature was needed because there were so many alternate dialects, module systems to support, etc. Esbuild is only possible because we’ve generally converged on TypeScript, JSX, ES modules, etc. It knows what you probably were going to configure webpack to do anyway, so it can just do it. So I wouldn’t call it a “treadmill”, I’d call it growing pains

dgritsko 5y ago
This is a great point. A "Cambrian explosion" the likes of which the JS ecosystem experienced over the last 10-15 years will slow down eventually. Curious to hear whether other folks agree or not.
- jscambrian 5y ago
  I survived the JavaScript Cambrian explosion and all I got was a disenchantment with computer programming
  - mpd 5y ago
    To me, it feels like the same effect as Ruby ~15-10 years ago. Lots of chaos as good (subsequently winnowed down to preferred), patterns were discovered, and then things stabilized. It isn't sexy anymore, but to this day I've yet to discover a better tool, that lets me blast out features and make changes at rapid pace, than Ruby (and Rails on the web side).
- asimpletune 5y ago
  Yeah, it’s a great point. I always assumed that there was so much tool churning just because of the nature of the front-end itself as a target for building software. However I think the “Cambrian explosion” point here makes a lot of sense.
5y ago

tengbretson 5y ago

> Remember when all of these points applied to webpack, when it was the “single simple fast tool” to replace everyone’s grunt scripts? You're forgetting the 6 months where everyone rewrote everything with Gulp.