React was originally meant to be the 'V' in MVC. You can still use it that way and React becomes very simple when you only use it for UI. Why do data fetching in a React component?
I find the best DX with Adonis/nodejs and typescript.
I too have been very frustrated by this, and I made an "Astro for dynamic sites" TypeScript framework called Hyperspan ( https://www.hyperspan.dev ) that aims to fill the gap in the JS ecosystem for a modern fully dynamic option that, similar to Astro, makes dynamic islands easy. I have enjoyed using it in all my own projects. Check it out if you want.
The pool size is less, but the pay is more (depending on your demographics, experience, etc) in my personal experience.
But, honestly I chose it not for the market, it's just a better programming language to build stuff, period.
Every time I run into an issue that Rails had a standardized solution for a decade ago just proves that most of the JS world spends their days metaphorically digging holes with sharp sticks, rather than using the appropriate tool.
But the industry values overpaying stick-diggers over results, therefore I gotta play along…
At this point, I'm convinced there's a secret global conspiracy to prank JS developers. For example 1 person maintaining 3 similar-but-distinct decimal libraries for Javascript, or the top 3 PDF processing libraries silently producing blank outputs.
Someone go make an AI rewrite of Apache+Mod-PHP and sell it to zoomers as the hip new thing already please
React, if you are judicious about what additional packages you use on top of it.
> I dropped out of the front end years ago, and it seems to just get worse every year with a profusion of confusion.
This has actually gotten somewhat better in recent years starting with esbuild which made it possible to use a simple single-binary tool for bundling.
If the similarity is "they are both open source projects" then so are about a million others. 99.99% of them don't get any traction beyond the first week.
> You think you'll get better long-term support from an experiment that a single engineer did in his spare time?
Linus started it as an experiment. That's a single engineer doing it on his spare time.
Do you think Linux doesn't do long-term support right?
The one changing the goal post is you.
https://github.com/cloudflare/vinext It is MIT licensed. It can be used and maintained by anyone.
If it'll get adoption like Linux did, that's different. But the base is there.
So entertain me if you disagree.
also why do you need support? agents are the support
If you're relying on webpack plugins heavily, I'd consider that a liability either way. It's going to seriously hamper your portability to other frameworks and build tools and even new versions of the current ones.
You can easily run turbopack for development / preview environments and webpack for production(-like) ones btw. as long as you don't rely on custom magic.
Everything just becomes a plugin.
I just wrote an open letter to fix Next.js. The goal is to compile a list of needs for whoever decides to fix those in any way possible...
This gives someone like me everything we want. Better performance is something the Next community has been begging for for years: the Next team ignored them, but not the Cloudflare team. Meanwhile Vite is a better core layer than the garbage the Next people use, but you still get the full Next functionality.
I wish Cloudflare the best of luck with this fork: I hope it succeeds and gets proven so I can use it at my company!