> it is really annoying to stitch together a bunch of tools and libraries that are slightly incompatible with each other

This is my job. We're a small team and my job is to keep things up to date. Insanely time consuming. Packages with hard dependencies and packages that stopped being supported 5 years ago.

▲

DanielHB 5 days ago | parent [-]

Yep, been there. It is a lot better these days for React SPAs but it is still a pain.

Fact is the only way around this in the frontend without a monolitic "batteries-included" all-encompassing all-knowing all-mighty framework is through standardization which can only be pushed by the browsers. Like if browsers themselves decided how bundlers should work and not have them be extensible.

And this tooling-hell is not only a browser frontend problem only either, it is also quite common in game development. Where you also have these monstrosities like Unreal Engine that "includes batteries" but makes it really hard to troubleshoot problems because it is so massively big and complex. A game engine is basically a bundler too that combines assets and code into a runnable system to be run on top of a platform.

▲

wild_egg 5 days ago | parent [-]

Advances in the browser standards are slowly removing the need for most client side JS altogether so standardizing on some concept of bundlers would be a step backwards.

Vast majority of web dev projects have zero need for an SPA framework these days and all this pain is self inflicted for little benefit.

Those tools do have good use cases still but the chances that your project is one of them I'd shrinking all the time.

Browser standards have come a long way in filling the holes that caused react to be written in the first place.

▲

DanielHB 5 days ago | parent [-]

I don't think we will ever be able to get away from bundlers because there is no way to solve the waterfall request problem of using modules (one module imports requires another module). Maybe some kind of standard manifest spec that tells the browser which parts of the code to load upfront and which parts of the code to lazy-load, but to generate that manifest in an efficient manner you would need at least part of what the bundlers do today.

Minifying is also somewhat of a hurdle, I guess it could be done at the CDN level on-the-fly+cache, but that is also its own nest of complexity.

SPA frameworks have a place, if anything I think they will become more prevalent, but I can foresee WASM opening the door for non-JS language stacks. However they will need bundlers as well and some languages are just not built around giving ways to minimize binary size and lazy-load code. Just try to compile some C++ to wasm, you end up with 10+mb .wasm files.

	▲	wild_egg 5 days ago \| parent [-]
		> Advances in the browser standards are slowly removing the need for most client side JS altogether I probably wasn't clear enough when I said this. If you're talking about waterfall requests in module loading, you've missed what I said and are likely sending orders of magnitude more JS to clients than you need to. It's really worthwhile looking at all the new features in browsers over the last 5-10 years and asking yourself if you really can't do what you need just with vanilla HTML and CSS at this point. You can always sprinkle in a bit of JS to fill in some gaps if needed. My team usually has a 2-300 line JS file in each project. No bundlers or modules ever required at that scale.