While Vercel acqui-hired many developers behind SvelteKit and Nuxt.js, I was under the impression that they weren't interested in running these projects hands-on, or even making them similar to each other. Can anyone correct me here or explain what their long-term game seems to be?
Seems Svelte is still mostly managed as an independent open source project.
I am wondering about giving Remix a whirl for an upcoming forum/CMS rewrite with custom auth. Anybody else have experiences with Remix?
Stick with a single version and you'd probably be happy though.
FWIW, I've been doing webdev-related work for a living since 1998, and React since 2016.
New devs coming in and expecting the framework to be with "batteries included", which it absolutely is not, will also have a bad time. Node apis, ALS/context, handling app version changes on deploys, running the server app itself (if in cluster mode, e.g. with pm2, what that means in terms of a "stateless" app, wiring up all the connnections and pool and events and graceful reloads and whatnot...), hell even basic logging (instead of console.xxx) ... all of that is up to you to handle. But the framework gives you space.
People new to React and/or Node will be confused as hell for quite a bit... in such a cases I would add like 3 months of personal dev time and learning to just wrapping your head around everything... React docs themselves say that you should use a framework if you're using React in 2025 - but it's not that easy. There is a cost, especially if you go the full stack route (client + server + hydration) of having everything under one "typescript roof". The payoff is big, but definitely not immediate.
Having to know node (or other supported server) and needing to implement your server business logic from scratch (models, db access, caching layer with redis or something, etc. etc.) is not a weakness, it's a strength.
The thing that .net tried to do for like a decade and failed to (one stack for both the server and the client), see Blazor bullshit etc. is handled here. Imagine you need a modern web app or a shop or whatever and that means React. It just does. Your backend stack is PHP or Rails or Go or whatever. Now you have to somehow square the hydration circle which you can't do without it being a massive pita (as PHP renders a page on the backend in.. well.. PHP) so you end up passing the data manually in some blobs of jsons or whatever with each request (or even worse, side to it in some fetches) that then React initializes from on the client and it's a total mess. Not to mention that unless you render the page in both php and react (try to keep both outputs the same lmao), you'll only see the full app "on the client" meaning crawlers/bots/google have to run JS on all your pages or see nonsense ... yikes.
SSR with hydration is there for this reason. You render the same React tree both on the server and on the client. The hydration process itself is made much easier by RR and its infrastructure (automatic passing of data to the client). Hell, thanks to SSR you don't even have to have JS enabled on the client if you're using just basic web standarts (see RRv7 docs on progressive enhancement and state management) and the site will work. This means even crawlers without JS runtimes will be able to index your site.
I have always developed backend apis in nodejs with express and used Nextjs for frontend only and just when I needed SSR.
Developing projects this way had always been a joy.
App router did change everything and destroyed the good reputation of Nextjs: it is hard to learn, to manage and does offer few concrete advantages
I’ve run into this myself. I tried middleware, AsyncLocalStorage, even wrapping layouts and pages in HOCs. After plenty of research, it still feels over-engineered for such a trivial task. Ironically, my understanding is that Next.js on Vercel already provides a requestId by default.
Another recurring issue is the documentation. The moment you hit anything even slightly advanced, it becomes too simplified to be useful, and the only guidance you find is a handful of open GitHub issues.
Imho next attempts to do too much, moves too fast, every few months the wheel gets reinvented and never perfected.
I've wrote previously about nextjs: https://omarabid.com/nextjs-vercel My opinion remains the same: Most of the issues in Nextjs are not a bug but a feature. A feature that only functions and locks you in Vercel platform.
Since their routing/SEO/content features are also now less functional, there is really very little reason to use Nextjs especially with React Server Components.
These days I do my best to stay in Rails land, far away from Next.js. It just looks like a cluster.
Wait, if you have issues with logging, why don’t you set up opentelemetry? It’s really easy to add into a project [1], and if you don’t want to manage it, you can easily find some cost efficient solutions like Grafana Labs [2].
[1]: https://nextjs.org/docs/app/guides/open-telemetry
[2]: https://grafana.com/
There are a lot of gotchas and considerations with Nextjs, but it is a framework and it is not unexpected that unless it is developed by yourself, frameworks require some getting used to.
There are some things that could be better, especially in non-Vercel-hosted scenarios, and if the backend for frontend part becomes too complicated, I would switch to Nest.js, but overall I am satisfied with Next.