Configuring it is a giant time suck. Particularly if you want to do hot reloading and all that kind of stuff.
I'm a big fan of Parcel for 90% of the things I do. It just works.
I'm a big fan of Parcel for 90% of the things I do. It just works.
Like having the most popular front end framework be unusable for at least 6 months: https://github.com/parcel-bundler/parcel/issues/645
Often you'll need to hope some third party made a plugin or make one yourself, which isn't really any different than using webpack, but the webpack ecosystem is much larger.
I struggled through parcel for a long time before I switched to Webpack 4 and had all of my existing build system and some additional niceties working in <45 minutes (probably 30 min of that was just reading the docs).
Yes, after being open for 6 months.
> Also, anybody who considered that feature important enough could have fixed it. It's not rocket science.
First off, maybe- but I was responding to the comment of 'it just works', so that's not relevant. My entire commentary was on 'it just works'. It doesn't really 'just work' if users have to implement their own plugins and fix their own bugs on super popular JS integrations.
Second off, a user did fix it, and it took the devs a month to respond to the PR- so you're still at the mercy of the core devs.
> Certainly 10x easier than when that magical something in the webpack build chain breaks.
And this I'd just have to disagree with you on. Webpack has way more eyes and as a result I have had one issue (bug) with it which had already been fixed. I had many issues using Parcel beyond the one I linked of the most popular front-end framework not working.
But Webpack is such a time saver once configured.
Same goes on when you have to setup a Docker and some chef/puppet/ansible scripts.
The nice part is you can do advanced stuff with it if you so choose.