Parcel v2(parceljs.org)
parceljs.org
Parcel v2
https://parceljs.org/blog/v2/
102 comments
My experience with the “Webpage tax” is every couple of weeks when I upgrade build tooling around one of my Webpack Workspaces, something somewhere silently breaks in the system outputs an exit 0 but with fundamental mistakes. Last week and experimental flag was implicitly enabled with a Webpage version upgrade that broke MiniCSSExtraPlugin (which why at v5 is this still a thing to output CSS as not JS?) and all of a sudden I had no styles. It's in the CHANGELOG for a minor version bump but running NPM/Yarn upgrade gave me a broken build, and trying to tweak my build scripts to find the problem, I got styles outputting but no JavaScript was built. And this has happened on multiple occasions every couple of weeks/months where minor version upgrades to plugins gave me an exit 0 broken build.
Parcel’s implicit plugin loading with node-gyp and randomly-dowloading-from-the-internet binaries system (rightfully) does not play well with Nix.
Considering I’m not even leveraging code splitting or many of Webpack’s advanced features, I’m now investigating the cost of switching to something built on esbuild to lessen my Webpack burden and get much better build performance. Honestly makes me miss Tup and Make as front-end tooling exploded with complexity.
Parcel’s implicit plugin loading with node-gyp and randomly-dowloading-from-the-internet binaries system (rightfully) does not play well with Nix.
Considering I’m not even leveraging code splitting or many of Webpack’s advanced features, I’m now investigating the cost of switching to something built on esbuild to lessen my Webpack burden and get much better build performance. Honestly makes me miss Tup and Make as front-end tooling exploded with complexity.
Note that Parcel’s plugin system is completely different in v2 and the implicit loading is gone.
That wasn't my experience, but it's been several months since I tested v2. I may have had to specify which plugins to use, but downloading of random binaries was an issues -- albeit this is a larger NPM ecosystem issue assuming read-write capabilities, glibc, x86_64 arch, etc. I've even made some small contributions to Parcel, its blog, and wrote a plugin, but this was before I started using Nix for a lot of things and node-gyp does not like to play well.
That said, I very much preferred Parcel to Webpack as the JSON5 config was declarative and simpler and the HTML entry point.
That said, I very much preferred Parcel to Webpack as the JSON5 config was declarative and simpler and the HTML entry point.
Note that Devon Govett, who you replied to, is the main driving force behind Parcel.
And? I just looked up my old package.json and see the NPM script use `parcel build --no-autoinstall ...` and a pinned version `2.0.0-beta.3.1` which to me says there some genuine autoinstall going on, which is what I meant by "implicit plugin loading", loading/installing some plugins from the ether. Perhaps my wording wasn't clear, but it still was an issue for me.
Parcel in my experience still came with less issues than Webpack to be clear (and talking about the woes from Webpack was the main reason I commented). Now esbuild is on the front page and we can see some users saying it was a smart switch away from Webpack (https://news.ycombinator.com/item?id=28861732)
Parcel in my experience still came with less issues than Webpack to be clear (and talking about the woes from Webpack was the main reason I commented). Now esbuild is on the front page and we can see some users saying it was a smart switch away from Webpack (https://news.ycombinator.com/item?id=28861732)
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.
This has been my experience, too. Great for getting started quickly on straight-forward projects or prototyping, but even simple projects hit snags.
If you're certain it covers all of your requirements out of the box, it's a great option. Otherwise...you're probably better off configuring Webpack from the start. I've never hit an issue with Webpack that can't be solved (an likely it has already been solved by someone else).
If you're certain it covers all of your requirements out of the box, it's a great option. Otherwise...you're probably better off configuring Webpack from the start. I've never hit an issue with Webpack that can't be solved (an likely it has already been solved by someone else).
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.
In v2, there is no transpilation unless you add a browserslist config.
This echoes my experience as well.
> 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 core.
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 core.
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 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."
> …
[1]: https://news.ycombinator.com/item?id=15853907
> 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."
> …
[1]: https://news.ycombinator.com/item?id=15853907
I guess the whiggish interpretation is that if each step is an improvement then the cycle represents steady progress, if not arrived at as directly as could be hoped. Maybe a cynic says that the extensions are negative-sum, or the rewrite is (either to adopting teams, or to a fragmented wider community.)
I'm an optimist, though admittedly entirely ignorant of this project. I think some capacity is sometimes lost when new projects are started with new technologies that don't live up to their predecessors, but that accusations of tool choice being fashion-driven are mostly misplaced. There are real, tangible, frequent improvements, and disruption is probably the price of innovation. And it's a price you can mostly avoid paying if you want to keep using what you're using.
I'm an optimist, though admittedly entirely ignorant of this project. I think some capacity is sometimes lost when new projects are started with new technologies that don't live up to their predecessors, but that accusations of tool choice being fashion-driven are mostly misplaced. There are real, tangible, frequent improvements, and disruption is probably the price of innovation. And it's a price you can mostly avoid paying if you want to keep using what you're using.
The other day I was playing around with parcel V2 and I ended up having to write a config file for something that I believe was included in v1... The whole point of parcel for me was avoiding config files... I feel like this release is missing the point
I think they discovered that if a library tries to provide "zero config", users quickly end up needing to configure something, or reconfigure something else.
I still don't think that Parcel is right for me given how comfortable I am with Webpack, but I welcome a "simpler config" option. Provide language support, but don't assume I want to use Babel, or PostCSS, or any other build tool.
I still don't think that Parcel is right for me given how comfortable I am with Webpack, but I welcome a "simpler config" option. Provide language support, but don't assume I want to use Babel, or PostCSS, or any other build tool.
I could be wrong, but I don't think webpack ever "just worked" right out of the box to the extent that parceljs does. I was in the middle of all kinds of gulp and webpack configuration when I discovered parcel a few years ago. A single command "parcel watch *.html" just worked. It detected that I was using react, followed the js includes and all the other dependencies and handled hot reloading and typescript and all the included css and sass and everything else. It was magic. It even did yarn add for any new dependency imports that weren't already in the packages.json.
My understanding is that webpack can do all of this, you just need a few weeks and a PhD in webpack.
My understanding is that webpack can do all of this, you just need a few weeks and a PhD in webpack.
And also go to a vacation at every release, because your config uses plugins that a) can’t keep up, b) can’t help but break previous version compat, and now it’s snafu for few months. And for beginners, good luck finding out the correct set of versions that support what you need simultaneously. One LARGE upside of all-in-one include-all packages is that you can’t find yourself in that sort of a gridlock.
> My understanding is that webpack can do all of this, you just need a few weeks and a PhD in webpack.
Uff, really hits the nail on the head from my experience with setting projects in the early webpack days.
Uff, really hits the nail on the head from my experience with setting projects in the early webpack days.
> Everything old is new again! Parcel embarks on the path that Webpack did
And Webpack embarked on the path that it’s forefathers did.. gulp, babel, browserify, grunt, and others. But that didn’t stop Webpack from improving on what was there.
The core thing Parcel does (or at least did when Parcel was started) that is/was a fundamental improvement over Webpack is parse your index.html (or whatever you name it, of course) to figure out what to do. I always thought Webpack was silly for asking a human to re-describe it’s html dependencies. I haven’t used Webpack in the last year, so I’m unaware if Webpack has fixed this shortcoming.
And Webpack embarked on the path that it’s forefathers did.. gulp, babel, browserify, grunt, and others. But that didn’t stop Webpack from improving on what was there.
The core thing Parcel does (or at least did when Parcel was started) that is/was a fundamental improvement over Webpack is parse your index.html (or whatever you name it, of course) to figure out what to do. I always thought Webpack was silly for asking a human to re-describe it’s html dependencies. I haven’t used Webpack in the last year, so I’m unaware if Webpack has fixed this shortcoming.
At least the core gets better with each new system :-) I joke, but only somewhat.
Who cares? As long as the tools are improving, this shouldn't matter.
That sounds...good!
izelnakri(2)
Previous thread:
Parcel 2 Beta 3 – improved build performance - https://news.ycombinator.com/item?id=27222460 - May 2021 (69 comments)
Also related:
Parcel – Fast, zero-configuration web application bundler - https://news.ycombinator.com/item?id=21961963 - Jan 2020 (201 comments)
Parcel: Fast, zero configuration web application bundler - https://news.ycombinator.com/item?id=17547433 - July 2018 (91 comments)
Parcel – A fast, zero configuration web application bundler - https://news.ycombinator.com/item?id=15853149 - Dec 2017 (163 comments)
Parcel 2 Beta 3 – improved build performance - https://news.ycombinator.com/item?id=27222460 - May 2021 (69 comments)
Also related:
Parcel – Fast, zero-configuration web application bundler - https://news.ycombinator.com/item?id=21961963 - Jan 2020 (201 comments)
Parcel: Fast, zero configuration web application bundler - https://news.ycombinator.com/item?id=17547433 - July 2018 (91 comments)
Parcel – A fast, zero configuration web application bundler - https://news.ycombinator.com/item?id=15853149 - Dec 2017 (163 comments)
Currently on HN's first page (and related):
Esbuild – An extremely fast JavaScript bundler
https://news.ycombinator.com/item?id=28860713
Esbuild – An extremely fast JavaScript bundler
https://news.ycombinator.com/item?id=28860713
For a while now, I've been using esbuild (swc is an option too) and a few basic shell scripts. I don't miss anything, other than being able to take a break while build happens.
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 module repalcement, and pretty error pages when you cause a RuntimeError.
In the ideal world, you would use esbuild only, but you still need the other features for development: hot reload, hot module repalcement, and pretty error pages when you cause a RuntimeError.
vite uses Rollup, and I think it's probably better too. When I see zero configuration I become less interested in a project, because I like being able to configure things.
Edit: I found this on Vite's website: "Vite plugins extends Rollup's well-designed plugin interface with a few extra Vite-specific options. As a result, you can write a Vite plugin once and have it work for both dev and build." https://vitejs.dev/guide/api-plugin.html
Edit: I found this on Vite's website: "Vite plugins extends Rollup's well-designed plugin interface with a few extra Vite-specific options. As a result, you can write a Vite plugin once and have it work for both dev and build." https://vitejs.dev/guide/api-plugin.html
Parcel 2 does both: it is useful out of the box, and many projects will never need to configure it, but v2 adds a complete plugin system that lets you override and configure everything too. :)
Good to hear! I'll give it a look.
I don’t think zero configuration is mutually exclusive with full configuration control. Zero config is often just a design exercise in setting reasonable defaults on top of a configurable system.
It could be argued that Vite is zero config because it allows you to go without a configuration file, but it says "zero config" nowhere on the site. It isn't because I want there to always be some configuration that I avoid zero config, it's because I've seen some projects like Next.js reject requests for a configuration setting that I thought were good and it has turned me off to the idea of "zero config". https://github.com/vercel/next.js/issues/7315 https://github.com/vercel/next.js/issues/1109 https://github.com/vercel/next.js/issues/13268
I get that. Curious, what do you think of prettier, which appears to philosophically align with next.js based on the issues you linked? Personally, prettier is more palatable specifically because it does one thing.
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? Who knows.
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? Who knows.
> 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.
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.
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.
What do you mean by "dev/validation iteration"?
Say you're developing a big form with lots of different inputs. When you're iterating on the form you don't want to lose all your form state because you edited some code.
When you make the change you want to see what that change does to your form in its current state.
When you make the change you want to see what that change does to your form in its current state.
That's very true. I think the most frustrating thing (that I regularly see) is people trying to do a minor fix in a wizard (let's say on the 5th step) and going through every step again just to see if the bug was fixed. Things like HMR can help here.
That's why things like mock-service-worker or having prefilled Redux stores (or whatever state management you use that allows something similar) are a real time saver.
Of course fixing the bug based on test is always better, but often you have to fix something visual which is a little bit harder to do with tests.
That's why things like mock-service-worker or having prefilled Redux stores (or whatever state management you use that allows something similar) are a real time saver.
Of course fixing the bug based on test is always better, but often you have to fix something visual which is a little bit harder to do with tests.
In those situations I usually just write some throw away code so the application loads up in the desired state
Sounds like you have auto save on.
I moved from Parcel (v1) to ViteJS because it felt a bit faster. Is there a performance or other type comparison between Parcel and some of the newer bundlers? (I.e, vite, snowpack, etc..)
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 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.
> It's possible that the Parcel 2 version they used is not the released one, so maybe it improved.
I'd guess so because of timing and because the Parcel 2 beta 3 announcement [1] says "10x faster JavaScript compiler written in Rust [...] on top of the SWC compiler". Likely the esbuild folks benchmarked against beta 2 or earlier.
[1] https://parceljs.org/blog/beta3/
I'd guess so because of timing and because the Parcel 2 beta 3 announcement [1] says "10x faster JavaScript compiler written in Rust [...] on top of the SWC compiler". Likely the esbuild folks benchmarked against beta 2 or earlier.
[1] https://parceljs.org/blog/beta3/
Probably should add https://bun.sh/ to the list as well, it's early but has some potential.
Doesn't seem to be open source, only has a macOS binary, you need to request "early access" by joining their Discord... what's their target audience here? Certainly not web developers.
Is there any information other than this home page? like an announcement somewhere, a demo video, or anything similar?
to be fair, that's without Parcel 2's cache, which surely improves build times considerably
the benchmark looks brutal to other bundler
Note that this benchmark is dominated by Terser for minification. All tools aside from ESBuild use it.
Why not minify with esbuild instead by default?
esbuild tends to produce larger bundles due to https://github.com/evanw/esbuild/issues/639. Looks like there was recent activity though, so we need to re-test. Anyway, there's a plugin available for now: https://www.npmjs.com/package/@parcel/optimizer-esbuild. We're also excited about the SWC minifier project, which is basically a port of Terser to Rust.
This link https://github.com/privatenumber/minification-benchmarks shows swc is still a work in progress.
I really don't understand vite. They use esbuild under the hood for some of the tasks, but they still ultimately use rollup. I tried to use it for a project I'm working on and it was more than 50 times slower than esbuild. (esbuild took half a second, vite took 30 seconds).
It uses esbuild for unbundled dev builds and Rollup for bundled production builds.
https://vitejs.dev/guide/why.html#why-bundle-for-production
https://vitejs.dev/guide/why.html#why-bundle-for-production
Vite's goal is a mixture of speed and flexibility. Rollup's plugin system provides the flexibility in exchange for slower build times, but that doesn't affect development speed, because Vite doesn't bundle anything in development (apart from CommonJS dependencies, which are pre-bundled with esbuild).
Vite's main focus is on a fast dev server and provide ultra fast hmr.
However, it needs source (user code and npm packages) to be in ESM modules, so it uses esbuild for pre bundling npm packages.
And vite uses roll-up to create a production build with some parts done by esbuild
However, it needs source (user code and npm packages) to be in ESM modules, so it uses esbuild for pre bundling npm packages.
And vite uses roll-up to create a production build with some parts done by esbuild
As other comments have mentioned, they use Roll-up under the hood.
I was put onto the incredibly fast esbuild[1] by a colleague and have used it here and there for open source packages. I'd been keen to understand which release of Parcel v2 they benchmarked against as they claim 0.37s to 39.28s on their home page?
[1] https://esbuild.github.io/
[1] https://esbuild.github.io/
I commented elsewhere in this thread but that benchmark is really measuring the performance of Terser, which is used by all of the other tools listed there. Parcel has improved somewhat since that benchmark was last updated but until terser is replaced there’s no competition.
Those are some really impressive numbers.
I was really impressed with the speed of Vite, which uses Rollup under the hood. I never had any real complains about Webpack's speed until I tried Vite out. In my experience with Vue apps, the difference between Vite (Rollup) and Webpack was much greater than esbuild's data shows.
I was really impressed with the speed of Vite, which uses Rollup under the hood. I never had any real complains about Webpack's speed until I tried Vite out. In my experience with Vue apps, the difference between Vite (Rollup) and Webpack was much greater than esbuild's data shows.
Vite only uses Rollup for the production build step. During development it uses ESBuild for pre-bundling, and then serves everything as native ESM, that's why it's so fast. They might get rid of Rollup in the future if ESBuild gains more features.
oh, cool! I didn't realize that. Then yea, I am very impressed by esbuild's performance.
Vite uses esbuild too.
https://vitejs.dev/guide/features.html#jsx
https://vitejs.dev/guide/features.html#jsx
My team’s been using parcel for Wordpress dev of all things. The switch to v2 has been interesting.. overall very happy with parcel v2 though, it magically fixed a bunch of issues that we just kind of lived with in v1.
> The zero configuration build tool for the web.JavaScript.CSS.HTML.TypeScript.React.images.SASS.SVG.Vue.libraries.Less.CoffeeScript.Node.Stylus.Pug.Electron.Elm.WebGL.extensions.GraphQL.MDX.XML.
Parcel combines a great out-of-the-box development experience with a scalable architecture that can take your project from just getting started to massive production application.
Very unclear what it does, until I tried to copy/paste the title. That changing word should just be a list.
Very unclear what it does, until I tried to copy/paste the title. That changing word should just be a list.
It’s a web build tool, which does basically the same thing as every other web build tool — it takes a bunch of developer-friendly inputs (multiple files, typescript, JSX, scss, raw images) and turns them into browser-friendly outputs (single-file, vanilla JS, vanilla CSS, optimised images)
The selling point for parcel is that it does the above with zero configuration (you point it at your input directory and it automatically figures out which compilers / optimisers to use -- other builders typically require hours of googling for / installing / configuring / debugging plugins)
The selling point for parcel is that it does the above with zero configuration (you point it at your input directory and it automatically figures out which compilers / optimisers to use -- other builders typically require hours of googling for / installing / configuring / debugging plugins)
It’s worth noting that Parcel v2 still needs work to support some basic use cases. For instance, it does not correctly build a Sass file that pulls in Bootstrap imports from NPM: https://github.com/parcel-bundler/parcel/issues/6002#issueco....
We tried switching to Parcel v2 but we had to downgrade back to v1.
We tried switching to Parcel v2 but we had to downgrade back to v1.
I also ran into issues like this while trying to migrate to Parcel 2.
Used v1 mainly for quick prototyping and playing around with new tech (had rust and fable which I was interested in at the time). Look like they've been removed from official support so at least it's no longer zero config to play with.
Having said if this turns out to be a low hassle tool to build library then I might use it. My pain point is the boilerplates involved in building libraries. For apps, I'm pretty happy with nextjs default.
Having said if this turns out to be a low hassle tool to build library then I might use it. My pain point is the boilerplates involved in building libraries. For apps, I'm pretty happy with nextjs default.
So what exactly is Parcel? The website says it has "a new JavaScript compiler written in Rust" but I thought JavaScript was an interpreted language?
The JavaScript ecosystem is so dang confusing. I'm glad I'm not a frontend dev who has to deal with that hot mess.
The JavaScript ecosystem is so dang confusing. I'm glad I'm not a frontend dev who has to deal with that hot mess.
Calling it a compiler is not great IMO, but it is a js bundler/transpiler.
You set it up, and write your js code, and parcel spits out the final, ready to embed in your html file, js and css assets.
That's oversimplified, but the basics all the same.
You set it up, and write your js code, and parcel spits out the final, ready to embed in your html file, js and css assets.
That's oversimplified, but the basics all the same.
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 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 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
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.
esbuild is not really configuration based like webpack. It takes some config options but you either specify them via the command line or write your own script to build up the config object. (they have a js and go api).
It's so much nicer to use than all the other bundlers.
EDIT:
To clarify, the dev experience is:
- You start with just the basic bundler with simple options you specify on the command line or maybe in a shell script.
- Then you want to do a few more things, so you turn the shell script into a nodejs script (or a Go program).
- You get to make the build script as simple or complex as you want. To your own discretion and to fit your use case.
It's so much nicer to use than all the other bundlers.
EDIT:
To clarify, the dev experience is:
- You start with just the basic bundler with simple options you specify on the command line or maybe in a shell script.
- Then you want to do a few more things, so you turn the shell script into a nodejs script (or a Go program).
- You get to make the build script as simple or complex as you want. To your own discretion and to fit your use case.
The documentation is top notch. I was able to learn it and switch over to it in about an hour or two for a moderately complex codebase targeting both Node and the web, and using Workers and some code splitting.
ESBuild is very unopinionated and mostly just does the right thing. Some config is available for mundane stuff. The rest it defers to plugins, rather than config. That’s where you have N+1 problems however.
If you and your team know Webpack and the ecosystem of plugins well already, then stick with that. Setting up a new project does not take a lot of time for you I guess. Someone mentioned "webpack tax" when using Parcel, it is real. Parcel is nice, I like it, but you get more control with Webpack.
This was true in Parcel 1, but v2’s plugin system is just as powerful as webpack’s. v2 is all about adding extensibility and control.
I also switched to Parcel. My use case was such that Parcel was a faster and simpler choice. That being said, I am starting to look at esbuild, in the hopes of making builds even simpler.
Parcel definitely looks simpler than Webpack. Of course Webpack tries to advertise itself that way, but it's never the case.
Moved from webpack to esbuild + postcss. Forced us to reduce our dependencies, and it also improved our iteration speed. Of course that comes with dropping the need for core-js and focusing on evergreen browsers that esbuild targets.
I switched to Snowpack for a small project (TS+Preact), reasonably straightforward and strong recommendation. Would not consider Parcel, seems like a step backwards in performance.
I am just using parcel for my small projects because it is simple. It is actually zero configuration. Setting it up takes about 1 minute.
So, with most of this discussion leaning towards esbuild/vite because it's simpler and much faster. What are the reasons one would use parcel instead of esbuild?
I would like to see a comprehensive benchmark of parcel v2 and vite.
Hopefully this situation improves as more competitors (like Parcel and Esbuild) mature, but at the moment I'd be pretty hesitant to build on anything that's not webpack or webpack based unless you're a lot more confident figuring out build tool setup from first principles than I am.
* V2, about a year ago, since my options were between the non-production-ready v2 and the explicitly unsupported v1.