Yes but they obsess over making everything perfectly ssr to the point of both delivering slow and half the time making client side navigations slow as hell after the user is already past the pay walled/marketing material part of your app.
Honestly except for the marketing page and blogs and stuff, most apps are fine without server rendering. In fact I'd say many that avoid server rendering actually feel better simply because next.js makes it really easy to screw up your performance doing it.
Some site have dual pages these days. I guess I should explain… they have a large footprint seo and those pages are static… unless you are logged in, then they are completely different!
I see this happening in finance data sites. Say a page about Apple, has stock price, etc. when logged in, same stuff but 10x data so they layout and everything is different.
That seems to be the only big plus with NextJS and SSR. But a big reason behind that was how Vercel made NextJS accessible to so many newbie devs right during Covid season. I was one of those new learners picking up React through it. Out of all the frameworks, Next was the most well-documented and more straightforward. The extras such as the straightforward routing and the availability of templates by vercel made things all the more easier for many to pick up. Meanwhile React was languishing and most of the other alternatives were just all over the place.
That being said, I'm waiting in the back stage, like many other folks, for tanstack to get production-ready, because of the all the weird crap being pulled by Vercel on NextJS.
Reading comments here, Reddit or other places my guess is lots of people don’t know the difference between just a website and an app. Even ones that seem experienced.
Lots of newcomers are struggling and not understanding what are the options and which approach is best for their case.
Business people don’t help as they rightfully don’t care. But they want „do everything” - „pay once” approach so people bolt on static pages ona apps or other way around.
I have over ten years experience and the distinction isn't always clear to me.
Example: This logistics SPA I was building I realized could just be single pages with some data for most of the stuff (tracking, inventory, etc...) but for admins they wanted a whole dashboard. This was a conditional on some value of the stored session user. So it ended up being kinda a website for parts of it and an SPA admin panel if the user conditionally matched some privileges. Probably should have been separate stacks but they used the same data so early on they made it the same Next app.
I don't think the whole website vs app thing is always as simple as static blog pages vs full fledged JS-heavy app. There is a spectrum and overlap even within a single "application" because of various requirements.
Your last sentence is the most accurate. I don't think its primarily ignorance, its just trying to meet all the requirements while retaining some level of organization in the codebase.
I mean the docs of most of the frameworks are written in that framework even though its just static pages. Didn't even need the framework but not using your own framework for docs feels ... bad I guess?
Isn't it mainly about playing nice with crawlers? SEO and the like?
(that was my understanding but I'm a backend dev).