I’m at an agency, work with lots of different tech depending on the client, and am the local Angular expert on staff. We build most of our new products in Next. It’s lightweight, flexible, easily deployable, the Vercel ecosystem is great and when you need to introduce a specific thing, there is a package available. Angular has the most divisive opinions of any FE tech imo. It’s feature richness is great, if you plan on using those features. If you don’t, then you’re left with a ton of unnecessary boilerplate that slows down development. We are firm believers in picking the technology for the problem, not sticking to a certain tech because we know it. My advice would be to learn new tech and stay flexible to what you’re using.

There is also Analog - The fullstack Angular meta-framework Similar to other meta-frameworks such as Next.JS, Nuxt, SvelteKit, Qwik City, and others, Analog provides a similar experience, building on top of Angular. https://analogjs.org/

The problem is once you've built the html on the server and sent it to the client, how do you make it interactive? Before SSR React, you'd need an entirely different framework to make the client interactive like jQuery. The code you'd use to render the page on the server (php, asp, etc..) would be different from the Javascript code on the client you use to re-render/update html on the client. Even with node templates, once you render them - how are you going to update them? not with node templates again, but with some other library on the client - extra work. This is the secret sauce of Next and other React SSR frameworks. You can render html on the server, send it to the client, and continue running the app on the client, just as you did on the server - seamlessly. Next sends the app state you left off rendering on server, down to the client, and you don't skip a beat. It's like you're building one app where before with php/asp/rails it felt like you built a server renderer, and then a client updater, both with redundant code to pull data and build/update html. Using the same language on the server and client is essential for this to work. You can also use the same utilities and dtos on the server and client which is huge for productivity. Other similar solutions like WebForms, Livewire, Motion,and Blazor tried to do this but with major compromises because the languages client/server were different. Edit: I should also mention Next is going to code split and build your pages with only the parts of the scripts your app needs to run - php/asp won’t do that. Also with Next bundling you get for free, in pho/asp it’s configured and still suboptimal compared to Next. Also hot code reloading. You can update the code (client or server all the same), hit save and see the update immediately on the page with the state of the page maintained - no refresh. An incredible dx for fast iteration. There’s a million tools and frameworks out there with bits and pieces of all these features, but Next really it all in one cohesive package. And they’re still iterating, like one pain point was API interaction, which really is loose and not static typed. tRPC is one solution but requires a lot of configuration. React server actions it looks like will make talking to the backend as seamless as calling a tagged function. Another one is the app folder that should allow a site built with Next to feel more intuitive with pages, APIs, and components co-located.

does next.js still make any server requests after the initial one, or does it act like a typical SPA with CRA from now on?

You got it right. The first (initial) request is handled by the server and after that the frontend handles the routing (at least in the case of Next.js).

If you want to see an example OpenCollective is built with Next.js. Try playing around with it and see the Network tab in the DevTools.

I am simply trying to understand why its called SSR since it seems to work different than the traditional SSR which I described on the beginning.

It is called SSR because the app is effectively being rendered on the server. The fact that frontend routing takes over after the initial render doesn't remove the fact that the server did the work of rendering the app as oppose to the user machine.