> I don't know, there's definitely some merit in separating your front end from your back end
This is 100% true and the biggest loss in web development in my opinion.
SPAs actually end up making this worse in the long run though. The major SPA frameworks are all moving to an RPC model of all things, entirely coupling your frontend and back end together. The original SPA approach did offer the ability to separate frontend and backend, but the frontend scaled poorly and brought in too many complex considerations like routing, caching, error handling and recovery, etc. The new approach is basically abandoning the benefits of an isolated back end in favor of tight coupling simply because the existing frameworks are too far down the wrong path.
If your goal is ever to isolate the frontend and backend you'll want to consider three environments - backend, web server, and frontend. Ironically that's exactly where we were when SPAs broke out onto the scene
> The major SPA frameworks are all moving to an RPC model of all things, entirely coupling your frontend and back end together.
I'm not familiar with this development. Do you mean that for example React has grown a backend running on a server, querying the database, etc?
I know that backend frameworks like Rails and basically all the major ones added a JS layer running inside the browser and obeying to the backend. It listens to messages from the backend with changes to the UI elements and that saves full page reloads.
I'm thinking mainly about about SPA frameworks (metaframeworks?) like NextJS, SvelteKit, Remix, and I think NuxtJS as well though I'm less familiar.
They're all adding features where code is marshalled back to the server either through useServer() hooks, pragmas, or magic $ signs and imports.
They all create RPC calls as part of the build and bundle step. Depending on the specific implementation, that usually means taking code that otherwise looks like client code, moving it to the server bundle with a unique API signature, and swapping the RPC API call into the client code.
Rails has been a full stack framework since the start, with the JS component changing frequently over the decades, but with template helpers that generate JS being a fundamental component since the beginning.
This is 100% true and the biggest loss in web development in my opinion.
SPAs actually end up making this worse in the long run though. The major SPA frameworks are all moving to an RPC model of all things, entirely coupling your frontend and back end together. The original SPA approach did offer the ability to separate frontend and backend, but the frontend scaled poorly and brought in too many complex considerations like routing, caching, error handling and recovery, etc. The new approach is basically abandoning the benefits of an isolated back end in favor of tight coupling simply because the existing frameworks are too far down the wrong path.
If your goal is ever to isolate the frontend and backend you'll want to consider three environments - backend, web server, and frontend. Ironically that's exactly where we were when SPAs broke out onto the scene