Comment by fishtoaster | Hacker News Reader

Comment by fishtoaster | Hacker News Reader

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.

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.

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)

Just thought the additional context could help the conversation :)

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.

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 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).

This echoes my experience as well.

Reply on news.ycombinator.com