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 answer somewhere) showing how to set it up in webpack. Then there's a 50% chance there'll be docs for how to set it up if you're using CRA. And if you're using anything else (eg Parcel), you've got a 30% chance at best to have docs on how to make it work.
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.
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.
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.
> 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.
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."
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.
> 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.
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.
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
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.
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..)
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).
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?
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.
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.
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.
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)
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.
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 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.
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.
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.
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?
[+] [-] fishtoaster|4 years ago|reply
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.
[+] [-] toastal|4 years ago|reply
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.
[+] [-] meowtimemania|4 years ago|reply
[+] [-] sk55|4 years ago|reply
[+] [-] AaronFriel|4 years ago|reply
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.
[+] [-] AnonHP|4 years ago|reply
> 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
[+] [-] jjeaff|4 years ago|reply
My understanding is that webpack can do all of this, you just need a few weeks and a PhD in webpack.
[+] [-] dahart|4 years ago|reply
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.
[+] [-] foota|4 years ago|reply
[+] [-] nextaccountic|4 years ago|reply
[+] [-] tshaddox|4 years ago|reply
[+] [-] izelnakri|4 years ago|reply
[deleted]
[+] [-] dang|4 years ago|reply
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)
[+] [-] cies|4 years ago|reply
Esbuild – An extremely fast JavaScript bundler
https://news.ycombinator.com/item?id=28860713
[+] [-] jeswin|4 years ago|reply
[+] [-] herpderperator|4 years ago|reply
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.
[+] [-] benatkin|4 years ago|reply
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
[+] [-] hsn915|4 years ago|reply
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.
[+] [-] cetra3|4 years ago|reply
[+] [-] devit|4 years ago|reply
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.
[+] [-] hsn915|4 years ago|reply
[+] [-] taitems|4 years ago|reply
[1] https://esbuild.github.io/
[+] [-] devongovett|4 years ago|reply
[+] [-] FinalBriefing|4 years ago|reply
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.
[+] [-] willio58|4 years ago|reply
[+] [-] jbverschoor|4 years ago|reply
Very unclear what it does, until I tried to copy/paste the title. That changing word should just be a list.
[+] [-] Shish2k|4 years ago|reply
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)
[+] [-] clmcleod|4 years ago|reply
We tried switching to Parcel v2 but we had to downgrade back to v1.
[+] [-] russelg|4 years ago|reply
[+] [-] nsonha|4 years ago|reply
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.
[+] [-] csense|4 years ago|reply
The JavaScript ecosystem is so dang confusing. I'm glad I'm not a frontend dev who has to deal with that hot mess.
[+] [-] igreulich|4 years ago|reply
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.
[+] [-] mrgalaxy|4 years ago|reply
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.
[+] [-] hoten|4 years ago|reply
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
[+] [-] 1ark|4 years ago|reply
[+] [-] diskzero|4 years ago|reply
[+] [-] joshxyz|4 years ago|reply
[+] [-] akdor1154|4 years ago|reply
[+] [-] SCLeo|4 years ago|reply
[+] [-] kabes|4 years ago|reply
[+] [-] jkrubin|4 years ago|reply