Hacker News Reader

Comment by swyx | Hacker News Reader

the prevailing consensus esp in the JS world is that 1 tool should do 1 thing. This is fine under the Unix philosophy, but challenges arise due to the combinatorial explosion of config needs, bad errors, and overhead from crossing module boundaries. There are a number of attempts at challenging this status quo:

- ESbuild (100x faster than webpack in part due to focus on doing a single parse (but also shipping a Go binary))

- Deno

- Rome

As we consolidate on the jobs to be done we expect out of modern tooling, it makes sense to do all these in a single pass with coherent tooling. It will not make sense for a large swathe of legacy setups, but once these tools are battle tested, they would be my clear choice for greenfield projects.

recommended related reads:

- https://medium.com/@Rich_Harris/small-modules-it-s-not-quite...

- (mine) https://www.swyx.io/writing/js-third-age/

View on HN

After spending way too much time debugging issues with frontend tooling, I am all on board for this glorious monotool future. We’ve definitely gotten some progress out of the massively micropackage approach that Webpack/Babel/etc use, but these days it really feels like we’re passing a complexity limit and we need a new approach. The fact that CRA will refuse to startup if you have another version of Babel installed anywhere in the tree, is a pretty good clue that the current approach isn’t scaling.

Yes, time spent on tooling is time not spent solving real problems. The ability to make unpopular decisions necessary to move a product forward is what separates an expert from an expert beginner.

I wrote about something related as well: Disintegrated Development Environments — How Did We Get Here?

https://amasad.me/disintegrated

Wow! I've been trying to put my thoughts about this into a blog post, but it would have ended up (or will end up) almost exactly like yours (except I didn't know about "Worse is Better"). Great to see someone with such similar ideas!

Don't forget https://github.com/swc-project/swc

Man, the performance benchmarks that esbuild publishes are pretty remarkable. I know it's common to cherry-pick favorable benchmarks, but even if these are misleading by two orders of magnitude esbuild would be best in class.

I also found them unbelievable so I did some quick tests with a couple of large projects that I'm working on, currently using Rollup. From these, I'd say their benchmarks are completely accurate.

Agree. I went as far as regressing to `watchexec` to re-run esbuild and cargo build on any changes. Esbuild is near instant compared to anything else.

I think maybe what's missing is one tool which the "one thing" it does well is put all the other tools together seamlessly and make sure they work right. My guess is that's what an IDE is supposed to do (I say "my guess" because I've always done my development in Vim).

I just know that every time I revisit any JS front-end stuff, I end up punting and just manually adding script/stylesheet includes for Vue and Bootstrap or whatever so I don't need to deal with half that crap. As an outsider it's always so daunting, and I feel like whatever I learned 6-12 months ago last time I needed to do something doesn't necessarily apply anymore.

There are some claims to this thrown recently:

* create-react-app serves as a very basic frontend template for a React project. It eliminates worrying about Babel, webpack, polyfills, etc

* next.js / nuxt.js solve both front-end and backend for React / Vue. Likewise they package webpack, Babel, typescript, etc, and also help with bundle splitting, routing, and server-side rendering that used to take 30 different packages and 6 think-piece blog posts. It’s good stuff (I can speak for Next, dunno about Nuxt)

> create-react-app serves as a very basic frontend template for a React project. It eliminates worrying about [...]

Until you need to do something that CRA doesn't do. Then you have to learn about babel/webpack/whatever AND how to do get CRA to play ball with it. I'm still on the fence on whether CRA and its leaky abstractions is better than a boilerplate with working config files exposed

But, CRA comes with a button that turns it into a boilerplate with working config files.

Reply on news.ycombinator.com