Hacker News Reader

Comment by rty32 | Hacker News Reader

Every bundler these days boasts "Rust" and "fast". What people really want is webpack feature parity. For a large enough organization with complex use cases and resource management, I yet need to see a real webpack equivalent.

(Meanwhile, swc parser can't yet pass all tests in test262 according to their website: https://docs.rs/swc_ecma_parser/latest/swc_ecma_parser/ )

View on HN

Isn't rspack[0] trying to handle full feature parity? I've just come across it earlier today so I'm not an expert but I'm looking forward to the full 1.0 release

[0] https://www.rspack.dev/

What features do they want? In my experience people always welcome webpack alternatives and not having CPU starvation issues or having to wait for minutes to webpack to work.

The problem is that we have already n-thousands alternatives, so it's a slightly different setup everytime - but generally as long as it's not webpack, it's all good.

Recently someone disabled turbopack on a next.js project because one new dependency wasn't supported and the developers started complaining right away the app was unbearably slow. The team couldn't work on latest for a week, they were just reverting the latest changes breaking turbopack support, working and then pushing.

how’s esbuild? I’ve yet to hit something I had in webpack that isn’t a couple line plugin away from being present in esbuild

Intrestingly esbuild isn't included in their benchmarks.

Esbuild is the only current build-tool that keeps one sane. The serve-mode is excellent and elegant with no brittle constantly breaking hacks like HMR or file watching.

Sadly configuring especially the serve-mode is a bit badly documented, and not usable via CLI flags if one needs plugins.

> Intrestingly esbuild isn't included in their benchmarks.

i noticed, and was very surprised by that. surely esbuild is the "standard" fast bundler these days; everyone knows webpack is slow so doing better, even significantly better, than it isn't a very large claim.

To each their own. I can't imagine doing UI development without HMR anymore. Makes it so much faster to iterate.

That's what Vite is for: all the zip of esbuild plus HMR that works. Usually works anyway... looking at one project where I never have to reload, and another that I'm doing that every ten saves or so. Much sloppier legacy sources in the second tho, Vite really pays off when you write more modern code from the start.

I rather hit Ctrl-R on each iteration than worry about whether I've hit the 1/10 buggy state on every change. With esbuild the reload is practically instant.

It was pretty infuriating wondering why my changes weren't taking effect, but like I said, it only hit me for that one project, and now I'm ready for it (I had to manually refresh every time beforehand anyway). It's a legacy codebase, I'm already used to intermittent nonsense like that. HMR never fails on the other project -- but now I've jinxed it for sure!

I don't find hitting Ctrl-R or F5 to be much of a hinderance for iteration. Especially when you don't have to worry whether the system has been left to some incorrect state by HMR.

You mustn't be working on forms then. Or anything state heavy.

no one mentions rolldown by the author of vue and vitejs?

Reply on news.ycombinator.com