Note 2: I do want to be fair in saying that I understand the desire for this for a rich interactive application interface that has a lot more moving parts that don't need to communicate with a back end. Such as where you would build an offline application
I'm not sure I'd go that far even. I'd stop at "interactive application interface". Even communicating with the backend this client approach can still be preferable. To me it comes down to something should be keeping track of user state. Hopefully it's not the server as that scales worse. Complexity of client apps comes in that they manage state and transitions. When you go to the next page they still remember everything since you didn't reload the whole page. Sure you can encode information back and forth on request/url but that can get ugly quick. So you can regularly be communicating with the server and still have this persistence beneficial. Not to mention if you are serving multiple clients(mobile, different products) anyway it's possible a JSON API is more re-usable than an HTML one.
So while it matters very little if your backend is writing JSON or HTML for performance, it makes all the difference for what the client does with it. Now it's possible to use AJAX to insert server-rendered HTML but at the point these updates are distributed it's no more beneficial than client rendering. In fact the client could do more granular change with data in the right format. If the JS is loaded(cached) for updates the client rendering after initial load is just better.
So really the main argument for server templates is initial load. I'm not going to deny the solution here is not complicated. Classic server rendering is just insufficient for many scenarios. So we instead attack the issue of client rendering on the server, and have been researching improvements to JS code splitting, client rehydration and streaming async on initial request to overcome the classic shortcomings here.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I'm not sure I'd go that far even. I'd stop at "interactive application interface". Even communicating with the backend this client approach can still be preferable. To me it comes down to something should be keeping track of user state. Hopefully it's not the server as that scales worse. Complexity of client apps comes in that they manage state and transitions. When you go to the next page they still remember everything since you didn't reload the whole page. Sure you can encode information back and forth on request/url but that can get ugly quick. So you can regularly be communicating with the server and still have this persistence beneficial. Not to mention if you are serving multiple clients(mobile, different products) anyway it's possible a JSON API is more re-usable than an HTML one.
So while it matters very little if your backend is writing JSON or HTML for performance, it makes all the difference for what the client does with it. Now it's possible to use AJAX to insert server-rendered HTML but at the point these updates are distributed it's no more beneficial than client rendering. In fact the client could do more granular change with data in the right format. If the JS is loaded(cached) for updates the client rendering after initial load is just better.
So really the main argument for server templates is initial load. I'm not going to deny the solution here is not complicated. Classic server rendering is just insufficient for many scenarios. So we instead attack the issue of client rendering on the server, and have been researching improvements to JS code splitting, client rehydration and streaming async on initial request to overcome the classic shortcomings here.