[fragile_frogs]

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/

[2] https://parceljs.org/getting-started/library/

[3] https://parceljs.org/getting-started/webapp/

[crummy]

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

[simooooo]

I think this is the exact thing that caused me to leave parcel for webpack

[zamalek]

If you want configurability+sanity then Rollup is a good bet. It generally does what you expect it too, and has far fewer footguns.

[VoidWhisperer]

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]

And when you try to upgrade just one plugin everything breaks and you have to upgrade everything.

[POPOSYS]

This should be the universal byline for all JS projects.

Make a T-Shirt with this and get rich.

[wruza]

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.

[fragile_frogs]

> 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

I did create a proof of concept how this could be done in parcel https://github.com/mochicode/parcel-fullstack-poc.

The /src folder contains:

1. /api => backend

2. /app => react frontend

3. /shared => shared code

Once everything is installed, just run "npm start" and it will:

1. build and watch your src folder

2. react hmr/fast-refresh works

3. nodemon will reload your node server when things change

4. serve your react app on localhost:8000/frontend, currently hard coded, but I could also load this from the package.json file.

Not zero-config, but it almost gets you there.

[trinovantes]

You can cut down the duplicate config with webpack-merge package. I start with a common config object that defines loaders, aliases, etc. and it gets imported by my frontend/backend/cronjob/worker targets that simply describe the entry/outputs

I also recommend installing ts-node and writing your configs in Typescript to avoid typos

Here's an old side project of mine that has 3 targets [1]. I personally don't think it's that complex but it does have hundreds of lines altogether.

[1] https://github.com/Trinovantes/MAL-Cover-CSS/tree/master/bui...

[Aeolun]

I use Next.js, which does both front and backend in one command. It may not be powerful enough if you need truly large API’s, but for anything I build it’s more than enough.

[pas]

Rust :)

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]

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.

[pas]

> [...], and dividing it along a particular api border seems unnatural.

this boundary is inherent in client-server software/systems/applications, there's just no avoiding it. every other API is basically unimportant and arbitrary.

the whole Web paradigm, the fact of "you need to download the site and run it" and the consequences and trade offs that it implies are basically unavoidable.

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

completely understandable, and we're in total agreement. I also think that this is an underserved problem.

It's ridiculous that we still don't have near-perfect abstractions for these.

[wruza]

every other API is basically unimportant and arbitrary

Well, frontend-to-backend api is also unimportant and arbitrary, unless it’s designed for public use. Since for a user the page is always in sync with its server, this api is an implementation detail as much as any other internal api (e.g. between service processes or between async-threads)

Why do you think that the project separation is unavoidable in this case? E.g. some of my sites are simple express apps serving scripts and resources. I don’t have integrated build pipelines there because… well, that is exactly my concern. There seems to be no reason that we couldn’t have an ~isomorphic project with multiple entry points on multiple “ends” and a single build system for all of them.

[pas]

I don't think it's unavoidable, but in practice it is two separate components with markedly different concerns and trade offs.

For example if we don't use any client side JS, use only a templating system, it becomes easy to keep it one project.

Eg. there's NextJS, which is a bundle of React and a NodeJS backed in one project. (And while it provides a getStaticProps and other gimmicks it doesn't really do much to make client-server state sync seamless. I still have to manually write the /api stuff.)

[random_kris]

https://github.com/t3-oss/create-t3-app + Pnpm monorepo

[threatofrain]

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.

[chillfox]

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]

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]

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!