Next.js App Router Update

Also have a look at https://vite-plugin-ssr.com/ (author here).

VPS is slightly lower level which gives you a lot more control: integrate with your existing Node.js backend (use any backend framework you want), deploy anywhere, use any React alternative (Solid, Preact, ...) and any data fetching tool (e.g. Relay can't really be used with Next.js).

The flip side is that you've to write a little bit more glue code. Although this will be alleviated by a lot with projects such as Bati[0], Stem[1], and vike-react (see Vike Rebranding[2]).

VPS also cares a ton about details, such as hooks for full control over i18n (use any i18n strategy you want), better Base URL support (VPS supports setting a different base for your server and your CDN), automatic deploy synchronisation, domain-driven file structure, polished and helpful error messages (especially the next upcoming release), ...

Detailed comparison with Next.js: [3].

If you run into any blocker then it's quickly fixed (or at least a workaround is proposed).

It supports not only SSR and pre-rendering, but also SPA in case you don't need SSR. It's going to support RSC but doesn't yet (RSC isn't ready for production).

Because it's lower level and because it's decoupled from React everything is designed in an agnostic way and with meticulous care. In other words: vite-plugin-ssr is becoming a robust foundation. There are breaking changes coming for the v1 release but beyond that chances are that there won't be any breaking changes for years in a row.

In a nutshell: vite-plugin-ssr takes care of the frontend and only the frontend. You keep control over your architecture. (Whereas frameworks tend to put themselves right in the middle of your architecture restricting you in fundamental ways.)

Last but not least: it's powered by Vite which means blazing fast HMR.

[0] https://batijs.github.io

[1] https://stemjs.com/

[2] https://github.com/brillout/vite-plugin-ssr/issues/736

[3] https://vite-plugin-ssr.com/nextjs-comparison

Yeah, it's a good point, and I'll continue to do that on my stable projects. But for a new project I'd like to try Vue, because I don't like the direction React is moving. In five years the "React I like" might not be available or widely practiced.

You're right that Vue will be a novelty - that's what I'm saying: React has jumped the shark to the point that it's now worth trying something for its novelty, because it just might be better.

At my current gig we support two Next apps (both on the pages router) and are currently in the very early stages of building a new Next app using the app router. While we are very excited about the technology, adoption has been slowed by a few things.

1. Server components have poor support for certain (non tailwind) css solutions. We had hoped to use vanilla-extract as its syntacticly similar to other css-in-js solutions, but ran into issues with HMR completely falling apart locally if the page contained a NextImage. We ended up falling back to good ol’ fashion sass modules.

2. As some other commenters mentioned googling for support somewhat consistently lands you on the opposite routers docs and while it’s somewhat obvious to tell where you are its still missable if you are moving quick.

All that to say I’m personally, _sorta_ burnt on Next and have found a ton of joy using svelte + sveltekit for my personal/hobby projects.

Agreed, nextJS feels incredibly overloaded with lots of terms that seem to conflate.

I tried to use the new app router, but it felt infuriatingly opaque to me, so I just went back to pages. Fortunately you can use the newest nextJS v13 and still have access to the old Pages system.

Naming things is hard. On the one hand, I prefer descriptive names like app router. On the other, idiosyncratic names like, idk, Pinecone are more googleable but opaque and hard to remember sometimes.

I used the CSS toolkit called Less and that name took the worst out of each hand. That was just terrible re: searching for things.