Hacker News new | past | comments | ask | show | jobs | submit login

Are they competitors? I thought SWC is a transpiler and ESBuild is a buildtool. I think any tree-shaking or code splitting that Parcel has is being done somewhere else.



esbuild does transpiling too, for example it can pull out typescript annotations or handle JSX transforms. It doesn't support transpiling down to ES5 though like swc. In general both tools are pretty similar, when you get down to it they're just a class of tool to take JS code, produce a AST, and then perform various transformations to the AST and write it back out as JS.


True, but how many projects will use either one directly and not as a part of a larger toolkit like vitejs and now parcel?


esbuild is perfect for adding to a go server app that needs to do some basic bundling. Just add it as a go module dependency, add a few go generate comments to use it to bundle your JS code, and you're done--you don't need nodejs or anything else installed.


I use just esbuild for prod compilation. For dev we still use webpack (with webpack-esbuild since it’s much faster than babel).


Is it a good idea to use a completely different compiler toolchain for dev vs prod? I don't know enough about their internals but that seems like a recipe for weird behavior in production.


It's a tradeoff. Given that you have a staging environment that behaves like production, you want dev to be the fastest environment as possible, so that you can iterate quickly to develop features and fix bugs, and validate them later on staging. Of course, the closer you are to prod the better, but when you have to chose for dev between speed vs reliability and the difference is high, speed is better (higher morale, more features deployed, the occasional bugs related to the different environments that were not catched by staging (why? need one more test) can be quickly fixed - most of the time)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: