> esbuild is not featureful enough for a lot of production use cases
What makes you say that? I keep hearing people say this, but I haven't run into any problem that make esbuild not ready for production.
If you're using any ES6 features - default params, template literals, arrow functions, let/const, spread, etc, your cut-off for browser support will be ~2017 (= no support for IE 11).
swc (https://swc.rs) does transpilation and it's as fast as esbuild. Setup is slightly more complex. I'm hoping esbuild will add ES5 transforms at some point, would much rather have a Go tool underneath.
Regarding #2, I assume that things are set up so that type errors are caught in some other way, such as in CI or in a precommit hook.
My code editor catches 90% of the errors, but it’s definitely nice to have tsc catch the rest earlier than the CI process.
With or without strict mode enabled?
Then when you put in prod, you build once. 30s once a day doesn't matter.
I mean, notepad.exe is arguably a better text editor for most people compared to anything else most of us are using.
I'll happily take some minor overhead in build configuration over adding 30s+ to every automated build if it's not a personal or small-scale community project.
It hardly matters because it's very rare that you need to run build during development. Use dev.
> I keep hearing people say this, but I haven't run into any problem that make esbuild not ready for production.
https://vitejs.dev/guide/why.html#why-not-bundle-with-esbuil...
For the hundredth time: it does matter.
Stop wasting people's time with slow tools and telling them it doesn't matter. That's not a way to treat your users.
Your fancy hot module reloading is not what I want. What I want is to reload the page and see my changes.
I've never seen a "hot reload" that works properly. The one some of co workers are using right now works like this:
- You edit a file
- You wait 5 seconds for the "instant" rebuild
- The browser reloads the page 5 times
- After a total of over 10 seconds, you can finally see the effects of your changes.
Maybe vite's HMR is better, I will never know because I don't care.
The link you sent has the following to answer why not esbuild:
> some of the important features needed for bundling applications are still work in progress - in particular code-splitting and CSS handling.
But this is not true. It handles css and does code splitting. Now, you have to be very explicit about code splitting: you have to define other entry points that share the same libraries as the main program so that it forces those shared libraries into separate chunks. To have more chunks you have more entry points where each entry point uses just one or two libraries. Yes, it's not perfect, but it's not a blocker for getting to production.
Where as the 30 seconds build is a total blocker for development iteration.
And what other people want is to not having to reload everything, lose all state on the page and make API requests all over when they add a 2px margin.
> I've never seen a "hot reload" that works properly.
Yeah, you've never seen a hot reload that works properly means someone else can't develop something new that works. And whatever crappy workflow that you enjoy must be great for everyone else.
Anyway, talking to close minded individuals is pointless, so this is it.
That's the difference.
I don't make API request in local development mode.
If I do, the response is instant.
> Yeah, you've never seen a hot reload that works properly means someone else can't develop something new that works.
It might work, but if the cost is increasing build time from 1 second to 30 seconds, it's not worth it.
The JS ecosystem is riddled with such pests, and (as with webpack) eradication from our workflows always proves by far the best policy.