Adding a (huge) abstraction on top of another (huge) abstraction to solve a problem introduced by the first abstraction is rubbish software engineering. It's one of the oldest anti-patterns in the book.
I get that these libraries provide some utility beyond their core purpose, and that it's a bit more nuanced than A -> B -> A, but I'm highly suspicious of people that recommend these libraries without giving much context behind it.
The industry norm for SPA seems to be moving towards SSR along with code-splitting and offline workers. The main SSR framework for React is NextJS. Vue and others have their equivalents.
Honestly I don't see a reason not to use it. I could write a traditional website using Next/react at the same speed as someone using Django/rails/etc.
Next.js is a front-end framework, right? So how can you build a traditional website using only a front-end framework at the same speed as someone using Django or Rails?
I previously visited nexjs.org and read the docs, and it wasn't clear that Next.js is a full-stack framework. The term "full stack" isn't used anywhere at nextjs.org[1], unlike rubyonrails.org[2].
Furthermore, there are numerous references on the web to Next.js being a front-end framework, including statements made by Next.js maintainers[3]. Do these statements not reflect the current state of Next.js?
If Next.js is a full-stack framework, then this seems to be another instance of JavaScript tools having inadequate documentation. Speaking of which, if Next.js is a full-stack framework that's comparable to Rails and Django, why is the documentation just one page (!) and there's no mention of database migrations or other basic features that are included with every full-stack framework?
Next.js is not really a fullstack framework. It provides a server for static websites but as soon as you want dynamic content you can use any js api framework of your choice.
Apologies for the tone. RoR website does not describe itself as 'full stack', neither is it a full-stack framework in the modern sense since there is no client-side library other than the ajax helpers.
Next.js is not a 'client side framework' in the usual sense, as it encompasses server side rendering, but it doesn't mean you'll be writing your backend logic in it (unless you want to) or that it will include an ORM.
Adding a (huge) abstraction on top of another (huge) abstraction to solve a problem introduced by the first abstraction is rubbish software engineering. It's one of the oldest anti-patterns in the book.
I get that these libraries provide some utility beyond their core purpose, and that it's a bit more nuanced than A -> B -> A, but I'm highly suspicious of people that recommend these libraries without giving much context behind it.