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.
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.
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)
Also as the esbuild thread alluded, Phoenix (Elixir) and Rails alpha are switching to esbuild because of how many issues were raised in their projects related to things breaking in the Webpack tooling.
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).
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 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 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.
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 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.
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.
> 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.
Webpack is a pain to use I agree, I've never liked webpack. My comment is on the behavior of trying to look smart/funny(meme-y) while lacking actual substance.
>A free open source tool exists for you to use if it suits your needs.
I do not believe that webpack suits my needs, it is in my opinion incredibly inferior to Gulp. So Gulp suits my needs.
Nonetheless I have had to basically use nothing but webpack for the last 5-6 years unless I do something for myself! Why is that?
Well it turns out that when I go to work at some place they have set up everything with webpack, why? Well that's what everybody else does, nothing we can do about it now. Hardly anyone in the real world only uses tools because they suit their needs, they use the tools that have been chosen by someone else.
Ok, so then something goes wrong with webpack build, anyone at the place know the depths of webpack and how every different plugin/module is screwed together - nope, we use webpack here but have no webpack experts - so they spend some days fixing things. Or even worse we want something that there is no webpack solution for that we can find - either we need to fix it ourselves with a plugin / module / fork of plugin module we want to extend (after asking fruitlessly on StackOverflow if someone knows) or we have to do a horrible hack to fix it.
I am sure there are some webpack experts out there who take minutes to fix problems they encounter in webpack, but my experience is that a webpack problem any more complex than we don't have a plugin for that file extension seems to require a developer day to fix (not just me as the developer, other developers always seem to take the same amount of time).
now before someone jumps in and cleverly changes my complaints to use Gulp instead of webpack (if you weren't thinking of doing this you can stop reading now) - can you point out to having a similar experience with gulp? Because I can't, and if I wanted to write a gulp plugin (which I have done twice) it was insanely easy because all you have to do is to understand vinyl streams and that's it; everything in Gulp has the same model of how things work - that really speeds up problem solving time.
Choosing tools based on what other people are doing instead of based on understanding your needs is so endemic in the industry it's not even funny. It's not even the juniors that do it. People labeled "senior software engineers" do this.
I'm still not understanding the problem. If webpack doesn't suit your needs then don't use it. If your employer's technical leadership picks technologies based on fashion rather than suitability for the problem that's not a failure of the technology, that same problem surrounds literally every popular technology irrespective of its technical properties.
My poop is on the street. If you like it, you can use it. If you don't like, don't use it. What's your problem? If someone shoves my poop down your throat and you don't like it, that's not a failure of my poop. That's a failure of human relationships.
Your analogy is laughably absurd. Poop on the street is a public health hazard, someone shoving poop down your throat is assault. Comparing such things to free open-source software is borderline trolling.
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
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. :)
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/7315https://github.com/vercel/next.js/issues/1109https://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.
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.
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.
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.
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..)
> 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.
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.
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).
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).
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.
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.
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
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.
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.
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?
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.