4 ms·
esbuild any day. JS tooling doesn't need to be written in JS, and when it's not, it's properly blazing fast.
by TheRealPomax 3y ago
esbuild any day. JS tooling doesn't need to be written in JS, and when it's not, it's properly blazing fast.
- thangngoc89 3y agoVite uses esbuild under the hood. Providing much nicer DX
- IggleSniggle 3y agoDepends on what you need, tbh. I looked into Vite briefly but esbuild seemed more obvious/ direct for hooking into the build system.
- dgb23 3y agoAt this point in my life I think "DX" - if you mean things like performance, reliability, simplicity and maintainability - is inversely proportional to the amount of (transitive) dependencies, layers of abstraction and (only half jokingly) also the percentage of JS that something includes. I've encountered a pretty back breaking memory leak in vite that has been unresolved for about 2y now. The project I work on that uses vite doesn't need the flexibility, feature set and plugin system that vite offers. It just needs a fast bundler.
- WorldMaker 3y agoesbuild has a decent DX and for some projects (especially libraries) the extra bells and whistles of Vite can be YAGNI.
- no_wizard 3y agoMy complaint with esbuild is it doesn't use `tslib` nor does it have its own sharable helpers like it that can be shared across builds, so you have all this repeated code that doesn't treeshake away. If it did, I'd use esbuild in a heartbeat for libraries. It also uses generic polling for watchmode, I'd like to see something more robust
- TheRealPomax 3y agoCan't say I've every used esbuild for watching, mostly because if I'm running in dev mode, I'm going to load "my files", not a bundle. The bundle is only for final delivery, so it needs to pass tests, but that's a precommit step, not a continuous development process.
- no_wizard 3y agomonorepo setups is where you will likely find this to be more of an issue, especially if you spin up watch mode on several libraries that may be undergoing changes