Hacker News Reader

Comment by choxi | Hacker News Reader

Parcel is great, 99% of the time I'm doing frontend development I just want my build tool to convert Sass/Less/JSX/Babel code to whatever browsers support. It's nice to just source a .sass or .js file and have Parcel figure out the rest.

Has anyone used Parcel and Webpack and still prefers Webpack?

View on HN

I switched from Parcel to Webpack after lots of bugs and issues. Parcel 1 had lots of tiny things that annoyed me (source maps never worked, it broke a lot when pulling from git), and the team is no longer fixing Parcel 1 issues. However, Parcel 2 literally didn't work for me:

https://github.com/parcel-bundler/parcel/issues/3690 https://github.com/parcel-bundler/parcel/issues/3691 https://github.com/parcel-bundler/parcel/issues/3696

So I switched to webpack. The configuration was miserable, but after I got it working, it seems to be OK. It's actually faster than Parcel, and a lot more stable.

https://github.com/magcius/noclip.website/blob/master/webpac...

Not to mention that I had a few issues with Parcel trying to be "too smart" for me. It would automatically try to hot reload, but my app wasn't designed for that, so it would break hard rather. The workaround was throwing an Error in the hot reload handler.

I'm hesitant to try parcel, and generally use webpack w/ laravel-mix, even in node projects simply because it's a pretty decent 'starting' point for webpack config, and I can override the config anyway I want when I need to which isn't too often.

Zero configuration is great until your project requires something that doesn’t fit into the parcel model, at which point it’s simply out of the question, but webpack with its myriad configuration options can be bent to your will. I was in that position once, but I can’t recall the details now.

As a comment on Parcel, this is kind of a counter productive one. What's the utility of a comment that says "it can't do something, but I don't know what"? If you have the details, those are super valuable to comment with, but if you don't... why comment?

Because "there exist situations that parcel cannot handle because it doesn't allow configuration". That's a useful thing to know. The fact that the OP can't recall what the situation was also provides a useful piece of information; that it's likely something that is not run into often.

From what I read one of the developers wrote on here, Parcel does allow for configuration. It just doesn’t require it.

It’s actually convention over configuration taken to an extreme where it’ll start adding entries to packages.json for you, or wrapping rust code in WASM for you on import.

Except that it allows tons of configuration, but is zero-conf by default.

Not every project will get there. I’m building a Firefox extension and I just need to turn ES6 and imports into a bundle.

Sometimes that’s all you need

Parcel 2 should help with this a lot. It has a much improved plugin system that allows pretty much everything to be extended and overridden, while still keeping things easy to use by default.

rollup is a good option if you need more config than parcel allows. It takes about 10 minutes to configure rollup correctly, and it's far more sane than webpack.

I see this all the time with build systems for various languages and projects (as well as for other classes of tools, frameworks, etc). Most of the time you don’t need the more complex tool. Ride out the simpler tool for as long as you can, and only when your product is mature (the time finding market fit is tremendously valuable—don’t waste it on integrating/building the perfect, most future-proof build system) and successful and you have a backlog of features that really do depend on the more complicated solution do you migrate. Ruthlessly trim that backlog for fade dependencies (most of the time the simpler tool really meets the actual requirements, but proponents of the more complex tool will stock the backlog with items that only appear at first blush to depend on the more complex tool). Consider the one-time cost of moving to the more complex tool and the ongoing increased cost of maintaining the more complex tool (and multiply both by 10) and compare those costs to the value of the items in your backlog, making sure to account for opportunity costs (I.e., what else could my team be working on instead of spending time porting and maintaining the more complex tool?).

A sign of engineering maturity is knowing the right time frame to plan for relative to your project’s lifecycle. Don’t worry about how your solution will scale when your product is hugely successful and you have Google-scale concerns; focus on getting to next week or next year or whatever timeframe is appropriate for your product’s current level of maturity.

I use both.

Parcel has some bugs that webpack doesn't since the latter has much better funding and corporate support from Facebook.

Can you edit in some links to those bug's issues on the parcel repo?

Yeah, I actually was very excited to use Parcel until I ran into a tree-shaking bug on my project that broke the generated bundle. I ended up switching to rollup instead, since although you still had to configure it, there were many less times than webpack where things misbehaved for some non-obvious reason.

Still, I dig what the project is going for, and intend to try out Parcel 2 when it becomes stable.

> and corporate support from Facebook

Huh? Aren’t you confusing webpack with prepack?

I’ve found that every time I start a project with parcel, I eventually want to change something about the Babel config and end up switching to webpack: once I was familiar with it, configuring webpack wasn’t all that bad

Parcel works with normal .babelrc configs the same way as webpack or other tools. Curious what you couldn't change.

I use Parcel for very small projects but vastly prefer Webpack for my "day job". On large projects it's so useful to have full control over your build pipeline. I've written a few custom loaders and plugins that we use for things like managing legacy code and dealing with oddities of our deployment system. I spent two days learning Webpack a few years ago and that has paid dividends ever since. It really is a beautiful tool but most people just want to start writing code and don't really care about the minutiae.

Switched to Rollup.

Can you elaborate why?

I tried it in the past (maybe a year ago) and just 2 weeks ago, too. The experience I had was aweful. Pretty much nothing was working. Maybe I am too biased from Parcel and I got disappointed when even simple things such as starting with an HTML file as root module does not work, or when importing CSS does not work, or when using TypeScript does not work.

What I particularly disliked is that it cannot even cope with the standard stuff that I throw at it. CommonJS modules (only the standard...)? You need a plugin. Not only that: I had to specify what modules I wanted to include and what they export. Do you know a way around all these wholes or is your solution always pretty much self-contained?

I used wepback before, and on every project it horrible to configre Webpack. A waste of time for me.

Tried some other packager and ended with Parcel and Rollup. I like Rollup, i can not say why i prefer it over parcel. Both are better, easier, faster then webpack.

Thanks - yeah I fully agree!

The one killer feature of rollup (which parcel also gets right) is sensible and usable sourcemaps. Webpack does not deal with using Vue SFCs and TS very well, you end up with 4-5 [almost empty] files in the browser per file on-disk and often the file with the actual source is missing. You have to hunt down the correct file and pray that it is their every time you wish to set a breakpoint. I've burned days in the past trying to figure out a workaround for the unusability of sourcemaps in Webpack. Webpack has tons of knobs and levers to configure sourcemaps, but none that do what I assume most people want (a single sourcemapped file in the browser).

Parcel and Rollup do the right thing 90% of the time (requiring only tweaking the path for the 10% remainder) with a single boolean configuration value.

Reply on news.ycombinator.com