4 ms·

You have to deal with multiple languages in any case: Java/C#/etc for the server logic, HTML for rendering and CSS for styling. You also have to deal with whate

You have to deal with multiple languages in any case: Java/C#/etc for the server logic, HTML for rendering and CSS for styling. You also have to deal with whatever syntax you are using to embed expressions in the template. If you use SPA there is one additional language (unless you use Nodejs for server logic) that's true. And you also have two different build chains. But the advantage is that the server logic becomes much simpler because you don't need session state or rendering logic. Your server can focus on being a stateless REST service which is more scalable (since you don't have session state clients can connect to a different server on each request). Your server is also more future-proof because it won't need to be rewritten to support native mobile clients.

fyfy18 8y ago
> Your server can focus on being a stateless REST service which is more scalable You can do exactly the same with server side rendering. In all the applications I've built over the past decade, the only state I've had is an encrypted session cookie to say which user you are logged in as - but that's send by the browser on each request, so it doesn't matter which server handles it. The urls I've built are basically the same as you would for a REST API, to view a widget you do a GET /widgets/1, to view the form to edit you do GET /widgets/1/edit, to save the update you to PATCH /widgets/1, which redirects you to the list of widgets at GET /widgets. I admit that trying to fit multi-step workflows into this scheme doesn't always fit so nicely, but with good API design (that's what you are building, an API for the browser to call directly without JavaScript) you can make it perfectly stateless.