I suspect that OP is indirectly if not casually admitting that react core is bad or terrible DX. Can we discuss technicalities of our decisions and not just shill react frameworks?
That thread is just a niagra of nonsense. The most impressive thing is how much OP mentions the most obvious things with such great profundity. "Gib ssr, gib routing..." thanks man. We can't read docs or landing pages it seems.
A lot depends on the complexity of your application.
There are some simple React applications where you can keep the state near the top of the application and let it percolate into the components via props. (Like my app for controlling my smart speakers.) In a case like that framework can be part of the problem as much as a solution.
When you've got complex state all over the place and an update to component A's data can cause component B and C to update and particularly if the app is dynamic so you don't know when you're writing it exactly what will cause what to update than you really need a framework.
Is there any real content here? Its just "they're better" half a dozen times?
Personally, I can't go with this advice. We're on 2.5 years rolling our own, and it's been really clear that we made the right choice in not going with next.js, which was the only such framework at the time.
Given that the remix author complete broke react-router for our use case (to the point where we can't upgrade to v6), I wouldn't trust that remix could meet our needs, either.
(There is a temptation to fork react-router v5 and maintain it independently. But, we're good just pinning the version for now.)
But React is a framework, itself built upon HTML, CSS and JavaScript. Recommending to use a framework on top of a framework is madness. If React doesn't do what's needed, just make another new framework instead.
I don't know a ton about Andrew Clark; I've gathered he's an author of React, but what is his experience using React to actually build frontends?
Nah. The beauty of React is in how small and focused it has remained. This leaves developer choice to add (or not) as much complexity as your app needs. Framework lock-in is the nightmare route that Angular went down, and Next.js in particular is a bloated mess I wouldn't touch with a ten foot pole. The promise of these frameworks is to solve every problem for you, but the reality is that each one is half-way solved poorly.
What works best for JS is the "meta" framework approach. That is, collections of really well done libraries that solve one single problem extremely well and play together nicely without any actual knowledge of each other.
Can someone tell me exactly why I would need Next.js? SSR seems pointless for most apps and routing is trivial with react-router. What am I missing?
I'm having a hard time understanding why. You need like 3 or 4 libraries to have a pretty featureful experience with React (routing lib, some kind of HTTP client library most likely, state if you don't want to do that in React proper... probably some kind of form library unless React has stopped sucking at that since last time I used it) and one of those is React itself. You can add more if you want but you probably don't need them. When one of those libraries falls out of favor and goes stale, it's easier to replace one of them than to migrate to a new framework.
There's just not enough to do on the client-side to justify a framework. The browser handles so much already.
The React framework has a framework called framework?
I feel like this is very much a political tweet more than a technical one, there's incredibly valid cases (as seen throughout this thread) for not using a framework, and it's a pretty broad generalization to make.
I just use vanilla React and Redux, but mostly for lack of knowledge. What would people recommend for:
- chrome extension
- simple app that is a small step above Retool/AppSmith
Are there frameworks people recommend that don’t require JavaScript on the backend?
I maintain that React is the single worst thing to happen to front end development. Certainly for the poor end user.
For another point of view, the Solid.js author prefers advocating for better modular tooling (like Vite) rather than comprehensive monolithic frameworks.
https://twitter.com/RyanCarniato/status/1617623647803539456
It appears he considers SolidStart to be a concession to the current ecosystem reality, rather than the idealized version of how things should be done.