31–40 of 229 posts
Frankly, I would pass. The switchover of build tools in JS land is insane. I get that this has concrete performance improvements over alternatives, but I wonder if the same effort put towards improving an existing toolchain wouldn't get you a lot of similar efforts without breaking everything yet again.
Some stats not mentioned in the post. Create React App (webpack) vs Vite (esbuild) on Replit containers: - 1 second start up time on Vite vs 15 seconds for CRA - React.js hello world project is 234mb on CRA and only 34mb on Vite - 1GB RAM for Vite dev server vs 3GB+ for CRA This is a perfect example of how fast and efficient tools can be, and I think we can do even better! Super excited about the future of JavaScript…
As the "webpack" guy on my team, these numbers look extremely compelling, but I also know Webpack does a lot for us (e.g., through Webpack v4, it includes browserfied node libs as needed). Beyond node libs, there's a long tail of niche things that need to be taken of... am I trading coverage of that long tail for speed?
Earlier quoted context omitted.
Ooh next uses webpack right? Might be some free speed. Thanks.
Yes but there are some difficulties you may run into when replacing the default loader nextjs uses, because it includes some custom babel plugins that get blown away when you replace the loader with esbuild-loader.
It's always impressive to me that, the co-founder of Figma ( https://twitter.com/evanwallace ) who essentially built a browser in a browser (figma.com) built esbuild. Could honestly be the Woz of our generation.
Need to handle non-js assets in your bundle? Need to integrate into both node and browser environments?
You should stick with webpack. Any time you lose waiting for webpack to run you will get back 10x over by not fighting with your tooling because it doesn't handle a set of use cases you have.
I'm sure the next generation of build tools and bundlers will mature over time and we'll all get to enjoy the benefits of es modules, but right now webpack's mature plugin ecosystem, documentation, and stability makes it my default choice.
Earlier quoted context omitted.
I’d like to see non-CRA numbers: I’ve found that a simple React + Webpack 5 project is not as bad to get off the ground as it used to be.
I'm sure it's less disk space because it has less deps but the most of the RAM and CPU usage in CRA is Webpack so I'd be surprised if that changed much.
Webdev truly is one of a kind. Not only do you have your source code, you also have your build code, oddly dictating the organization of your source code. For extra fun, some libraries don't build with build system a, others require build system b, when you're lucky enough to have a working mix, changing build systems is better to be avoided. Of course periodically the officially blessed build system for your used li…
It... really doesn't? You generally have an entry point file - which can be any file, you just have to specify it to your build system - and import statements are followed from there on. If anything you could argue the JS build ecosystem is too flexible (which is one of the things esbuild is pushing back against). I've never heard someone criticize it for being too opinionated.
> For extra fun, some libraries don't build with build system a, others require build system b
I've literally never encountered this problem. Library authors virtually always ship least-common-denominator JS that will work without using a build system at all, and then build systems know how to handle lots of different variations of JS and converge them into a single representation. Compatibility is not an issue that exists in my experience.
> The webdev ecosystem is so broken, it's no wonder so many websites deliver assets that are extremely suboptimally optimised, big unused blobs of assets /scripts slowing page load, optimising it all is actually made harder than coding it all.
Now you're just airing your own personal beef which doesn't actually have anything to do with the original topic.
I wonder how this compares to a proper manual Webpack configuration. Comparing it to CRA isn't really helpful to me, as CRA is already known to be very slow. I would consider trying it if it has significant performance benefits over a manual Webpack config, especially one making use of esbuild-loader ( https://github.com/privatenumber/esbuild-loader )
What is a "proper webpack config".
It's such a complex and arcane beast, that I doubt anyone could really figure out a "proper" way to do anything with it.
I tried out both snowpack and esbuild recently, and while the approach of using es modules was neat, these tools are still wildly immature compared to webpack. Need to handle non-js assets in your bundle? Need to integrate into both node and browser environments? You should stick with webpack. Any time you lose waiting for webpack to run you will get back 10x over by not fighting with your tooling because it doesn't…
Generally I think this is good advice for tools--stick with the mature thing. But my former company's webpack builds were 30+ minutes for a relatively simple site. No doubt something was misconfigured, but you really have to be a webpack expert to get any sort of insight into where the time is going, and even then it may not be especially actionable (or at least not obviously so). In our case, we were using a monorepo and we didn't have something like Bazel, so this was painful for backend engineers, data scientists, etc--not just frontend engineers.
Maybe our case was pathological, but we would have saved a ton of time moving to esbuild and building whatever additional features we needed from scratch.
Webdev truly is one of a kind. Not only do you have your source code, you also have your build code, oddly dictating the organization of your source code. For extra fun, some libraries don't build with build system a, others require build system b, when you're lucky enough to have a working mix, changing build systems is better to be avoided. Of course periodically the officially blessed build system for your used li…