6 ms·

After years of configuring webpack for various projects I have finally decided to migrate all my projects to Parcel[1] manly because I got tired of creating and

After years of configuring webpack for various projects I have finally decided to migrate all my projects to Parcel[1] manly because I got tired of creating and maintaining hundreds of lines of webpack.config.js files, I wanted something that just works. I am really happy with that decision. Parcel is plenty fast and is pretty much zero config, I can use it to build libraries[2] as well as applications[3] for the browser and node. I am manly building client side react applications, so your mileage may vary. [1] https://parceljs.org/ https://parceljs.org/ [2] https://parceljs.org/getting-started/library/ https://parceljs.org/getting-started/library/ [3] https://parceljs.org/getting-started/webapp/ https://parceljs.org/getting-started/webapp/

chillfox 4y ago
I just spent an entire evening a few days ago trying to make Parcel work for a new project and I just couldn't get it to spit out working js and css. The project is just a small server rendered web app (using Crystal) that I wanted to add papercss, trix, hotwire/stimulus and hotwire/turbo to (using yarn). Anyway, I never got it to output the css for papercss or the js for trix. Webpack on the other hand, I had working in about 20min. Yeah, the config is verbose and tedious, but at least there are a lot of great docs/tutorials for just about everything for it.
- fragile_frogs 4y ago
  IMO where Parcel shines is when you are building client side single page apps or JS/TS libraries. I could see that it won't be the right tool for a multi page server rendered app.
phplovesong 4y ago
Same here. I got dead tired and fatigued of all the JS ecosystem bundles and over engineered solutions. Today i mainly use a Makefile and esbuild. No config files at all! It has been a blessing!
VoidWhisperer 4y ago
This has been a huge frustration of mine with webpack - you end up with relatively complicated configs and it sometimes feels like even if you copy and paste your config over, you end up still having to spend a ton of time fighting with webpack to actually get it to work
- fragile_frogs 4y ago
  And when you try to upgrade just one plugin everything breaks and you have to upgrade everything.
  - POPOSYS 4y ago
    This should be the universal byline for all JS projects. Make a T-Shirt with this and get rich.
threatofrain 4y ago
I kind of don't understand pure bundlers for the individual dev level; I feel that they are made for other ecosystem authors to package into a "meta-framework", such as NextJS (which used to use webpack). The devs at Vite said something similar, that although they provide a great developer experience with no/low configuration, they're really meant for other ecosystem authors.
wruza 4y ago
Parcel felt really fast, zero-conf and “opinionated” in a good way. But I’m still searching for a zero-conf full-stack pipeline which could manage both frontend and backend in a single project under a single watch command, with modules shared across sides. This frontend/backend separation is too alien to my idea of development (coming from desktop programming), and it feels like some artificial border. Thankfully, Node and browsers slowly converge, so isomorphic code is less and less of an issue. Btw, how does HN develop solo-dev apps? Do you switch between two projects? Run two separate webpack configs simultaneously? How do you share code/typedefs/dtos between them? Do you use or want to use backend HMR? Backend webpack-like import extensions? got tired of creating and maintaining hundreds of lines of webpack.config.js files, I wanted something that just works When I finally built my perfect set of webpack configs, I deleted them after a couple of months. This complexity is “fun” to set up, but maintaining it is not something I want not working as a “devops” full time. Achievement unlocked, so to the trash it goes.
- pas 4y ago
  Rust :) https://m.youtube.com/watch?v=oCiGjrpGk4A https://m.youtube.com/watch?v=oCiGjrpGk4A but more importantly, I recommend embracing the frontend-backend separation. it's important in desktop contexts too. after all, you don't want to block the UI thread with waiting for I/O, right? of course the last ~2 decades were about coming up with various hacks, workarounds, solutions to make the whole threshold easier to pass (from Java applets to Ajax/XHR, comet/long-poll, websockets, server sent events, localstorage, WebSQL, WASM, service workers, and so on), but the basic architectural separation of concerns remains. ... regarding sharing things between frontend and backend: OpenAPI + openapi-generator; monorepo works okay in VSCode, etc. many people opt for RoR-like frameworks where they don't have to write frontend JS if they can avoid it (see also htmx)
  - wruza 4y ago
    I think your comment is mixing two kinds of separation together: process/thread separation and project separation. To me, a project is a single concern, monorepo or not, and dividing it along a particular api border seems unnatural. Anyway, I’m looking for a tool that could make this part of development simpler by joining all these efforts in a “project and process manager” way instead of maintaining multiple toolkits/configs or generators. The latter I know how to do. Been there, done that, fed up.
crummy 4y ago
Parcel seemed to fail when I had multiple entrypoints into my app that shared code. Is this such an unusual scenario? https://github.com/parcel-bundler/parcel/issues/6310 https://github.com/parcel-bundler/parcel/issues/6310
- simooooo 4y ago
  I think this is the exact thing that caused me to leave parcel for webpack
  - zamalek 4y ago
    If you want configurability+sanity then Rollup is a good bet. It generally does what you expect it too, and has far fewer footguns.

chillfox 4y ago

I just spent an entire evening a few days ago trying to make Parcel work for a new project and I just couldn't get it to spit out working js and css. The project is just a small server rendered web app (using Crystal) that I wanted to add papercss, trix, hotwire/stimulus and hotwire/turbo to (using yarn). Anyway, I never got it to output the css for papercss or the js for trix. Webpack on the other hand, I had working in about 20min. Yeah, the config is verbose and tedious, but at least there are a lot of great docs/tutorials for just about everything for it.

fragile_frogs 4y ago
IMO where Parcel shines is when you are building client side single page apps or JS/TS libraries. I could see that it won't be the right tool for a multi page server rendered app.

phplovesong 4y ago

Same here. I got dead tired and fatigued of all the JS ecosystem bundles and over engineered solutions. Today i mainly use a Makefile and esbuild. No config files at all! It has been a blessing!

VoidWhisperer 4y ago

This has been a huge frustration of mine with webpack - you end up with relatively complicated configs and it sometimes feels like even if you copy and paste your config over, you end up still having to spend a ton of time fighting with webpack to actually get it to work

fragile_frogs 4y ago
And when you try to upgrade just one plugin everything breaks and you have to upgrade everything.
- POPOSYS 4y ago
  This should be the universal byline for all JS projects. Make a T-Shirt with this and get rich.

threatofrain 4y ago

I kind of don't understand pure bundlers for the individual dev level; I feel that they are made for other ecosystem authors to package into a "meta-framework", such as NextJS (which used to use webpack). The devs at Vite said something similar, that although they provide a great developer experience with no/low configuration, they're really meant for other ecosystem authors.

wruza 4y ago

Parcel felt really fast, zero-conf and “opinionated” in a good way. But I’m still searching for a zero-conf full-stack pipeline which could manage both frontend and backend in a single project under a single watch command, with modules shared across sides. This frontend/backend separation is too alien to my idea of development (coming from desktop programming), and it feels like some artificial border. Thankfully, Node and browsers slowly converge, so isomorphic code is less and less of an issue. Btw, how does HN develop solo-dev apps? Do you switch between two projects? Run two separate webpack configs simultaneously? How do you share code/typedefs/dtos between them? Do you use or want to use backend HMR? Backend webpack-like import extensions? got tired of creating and maintaining hundreds of lines of webpack.config.js files, I wanted something that just works When I finally built my perfect set of webpack configs, I deleted them after a couple of months. This complexity is “fun” to set up, but maintaining it is not something I want not working as a “devops” full time. Achievement unlocked, so to the trash it goes.

pas 4y ago
Rust :) https://m.youtube.com/watch?v=oCiGjrpGk4A https://m.youtube.com/watch?v=oCiGjrpGk4A but more importantly, I recommend embracing the frontend-backend separation. it's important in desktop contexts too. after all, you don't want to block the UI thread with waiting for I/O, right? of course the last ~2 decades were about coming up with various hacks, workarounds, solutions to make the whole threshold easier to pass (from Java applets to Ajax/XHR, comet/long-poll, websockets, server sent events, localstorage, WebSQL, WASM, service workers, and so on), but the basic architectural separation of concerns remains. ... regarding sharing things between frontend and backend: OpenAPI + openapi-generator; monorepo works okay in VSCode, etc. many people opt for RoR-like frameworks where they don't have to write frontend JS if they can avoid it (see also htmx)
- wruza 4y ago
  I think your comment is mixing two kinds of separation together: process/thread separation and project separation. To me, a project is a single concern, monorepo or not, and dividing it along a particular api border seems unnatural. Anyway, I’m looking for a tool that could make this part of development simpler by joining all these efforts in a “project and process manager” way instead of maintaining multiple toolkits/configs or generators. The latter I know how to do. Been there, done that, fed up.

crummy 4y ago

Parcel seemed to fail when I had multiple entrypoints into my app that shared code. Is this such an unusual scenario? https://github.com/parcel-bundler/parcel/issues/6310 https://github.com/parcel-bundler/parcel/issues/6310

simooooo 4y ago
I think this is the exact thing that caused me to leave parcel for webpack
- zamalek 4y ago
  If you want configurability+sanity then Rollup is a good bet. It generally does what you expect it too, and has far fewer footguns.