41–50 of 103 posts
Earlier quoted context omitted.
https://esbuild.github.io/faq/#benchmark-details has Parcel 2 benchmarks. The summary is that you should use esbuild (or swc/spack when ready) for new projects and probably switch existing ones as well if feasible. It's possible that the Parcel 2 version they used is not the released one, so maybe it improved.
the benchmark looks brutal to other bundler
I think https://vitejs.dev/ is better. It pulls in a much smaller set of packages for a hello-world non-CRA react app. I think it was something like 1.3k lines of yarn.lock for Vite vs 6k lines for Parcel v2. JS projects shouldn't be bloated, even if this would get optimized-out for production. In the ideal world, you would use esbuild only, but you still need the other features for development: hot reload, hot modul…
In the real world, you can use esbuild only. You actually don't need hot reload or hot module replacement. esbuild is so fast you can just reload the page and it reloads instantly. hot reload is really bad with slow bundlers. One of the projects I have to maintain at work has this hot reload feature. Here's how it goes: I edit a sass file, it recompiles in the background for 5 seconds, then reloads 4 or 5 times. Why?…
You don’t actually need any of these tools. But HMR is useful not because build time is slow (even if it often is), but because dev/validation iteration is slow too. TDD can improve some of that, but when you’re iterating on something interactive and want to validate the experience of it (or any number of other circumstances where manual validation provides value), having your setup state preserved can mean the difference between split second validation (with fast tooling) and completely breaking flow.
Earlier quoted context omitted.
I switched from Parcel (v1; had trouble upgrading) to esbuild for my web game, and it's been much simpler. And faster, obviously. If you don't care about having a large plug-in ecosystem, or things like image optimization being handled directly by your bundler (and other stuff, from scanning the linked article), I'd say just go with esbuild
esbuild definitely caught my eye. I'm now noticing they support CSS and static files, which I guess I didn't realize. Is it easy to setup and configure? Because that is the one part of Webpack I cannot stand.
Anyone here switch from Webpack to Parcel? Or, look into switching and decided not to? I recently upgraded Webpack from 4 to 5 and briefly looked for alternatives, but ultimately just decided to stick with Webpack since it works for us.
I set up a new project on Parcel*. It was amazing at first for getting going quickly with minimal config, but became increasingly expensive to deal with. Every week or so I'd run into what I'm calling the "webpack tax" where I'd spend twice as long having to figure out how to do something as the price for not using webpack. Every tool out there has a 95% chance of having docs (or at least a blogpost or StackOverflow…
What things are you trying to do that’s not supported with parcel? I think sometimes we make super complex front end build configurations that don’t yield much benefit over something more simple.
Earlier quoted context omitted.
What things are you trying to do that’s not supported with parcel? I think sometimes we make super complex front end build configurations that don’t yield much benefit over something more simple.
In my case I actually want it even more simple: not using babel. Parcel silently use babel, which cause problems with other tool in my case and there wasn't any way to turn it off, at least at the time.
> An all new plugin system, which makes Parcel fully extensible. This allows Parcel to scale from small side projects to massive production applications with complex build requirements. Everything old is new again! Parcel embarks on the path that Webpack did, and it's only a matter of time before the plugins are doing more and more core work, and Parcel's successor will again rewrite them and bring those in to the co…
> The eternal cycle of developer tool bullshit:
> 1. "Ugh, OldTool™ v3.0.0 is overcomplicated, bloated, slow and unnecessarily configurable!"
> 2. "Introducing SuperTool™ v1.0.0, which just does the stuff you really need. No bloated configuration. No huge ecosystem of extensions. Simple, straightforward and fast."
> 3. "SuperTool™ v1.0.0 is great! But our setup really needs it to do something a bit different, so we've hacked in this extension."
> ...repeat for a while...
> 10. "Introducing SuperTool™ v2.0.0, which now has a more flexible API and configuration , allowing many former hacks to be done in a straightforward way."
> …
> An all new plugin system, which makes Parcel fully extensible. This allows Parcel to scale from small side projects to massive production applications with complex build requirements. Everything old is new again! Parcel embarks on the path that Webpack did, and it's only a matter of time before the plugins are doing more and more core work, and Parcel's successor will again rewrite them and bring those in to the co…
My understanding is that webpack can do all of this, you just need a few weeks and a PhD in webpack.
> An all new plugin system, which makes Parcel fully extensible. This allows Parcel to scale from small side projects to massive production applications with complex build requirements. Everything old is new again! Parcel embarks on the path that Webpack did, and it's only a matter of time before the plugins are doing more and more core work, and Parcel's successor will again rewrite them and bring those in to the co…
This comment by @stupidcar (December 5, 2017) [1] from the first Parceljs post seems pertinent. I’m not pasting the entire comment; visit the link below to read it: > The eternal cycle of developer tool bullshit: > 1. "Ugh, OldTool™ v3.0.0 is overcomplicated, bloated, slow and unnecessarily configurable!" > 2. "Introducing SuperTool™ v1.0.0, which just does the stuff you really need. No bloated configuration. No huge…