3 ms·

Sorry, I'm calling bullshit on his argument for server-side rendering for increased performance. Consider a typical SPA: === In my SPA I load one large html

Sorry, I'm calling bullshit on his argument for server-side rendering for increased performance. Consider a typical SPA: === In my SPA I load one large html document and javascript file in. The html document contains the 30-or-so templates my system needs to use. The script contains logic and localization data for the user. This is all cached. As my users use app, Angular makes calls to my REST/JSON services, transferring just the data it requires with a very efficient encoding. Some of the data is even cached in local storage. Now, imagine that I've moved the rendering to the server. Instead of transferring a couple of KB of JSON data when a user filters a grid, I have to transfer 30k of HTML markup. My HTML could be smaller, but my designers really like to have class names on all elements. Plus the German text I see is really long. === In this rather common scenario the SPA vastly outperforms the traditional server-side render-as-markup sites I was making three/four years ago. Network dominates, especially on mobile. It's not your CPU killing your battery, it's the screen and radios. If you're making a simple informational site - a newspaper, blog, marketing site - then sure your performance will suffer, but that isn't the problem. The problem is that you're using a excavator to plant a daffodil. You shouldn't even need to use a server-side framework, let alone Javascript.

syllogism 12y ago
Agreed. Server-side templates only make sense if you assume that every user action will end up needing the DB. If what you're building is really an _app_, and not just a webpage, you can't expect to compute its UI on the server, making the user wait for a network round-trip for every action. If your app is built around server-side templates, but your UI doesn't need the server, then you end up with a royal mess. The client has to do DOM manipulation over the rendered page, so now the templates have to include convenient hooks for the jQuery selectors your client will need. There ends up being no clear separation between the server's responsibilities and the client's. In this situation it's much better to just let the client own the UI entirely.

syllogism 12y ago

Agreed. Server-side templates only make sense if you assume that every user action will end up needing the DB. If what you're building is really an _app_, and not just a webpage, you can't expect to compute its UI on the server, making the user wait for a network round-trip for every action. If your app is built around server-side templates, but your UI doesn't need the server, then you end up with a royal mess. The client has to do DOM manipulation over the rendered page, so now the templates have to include convenient hooks for the jQuery selectors your client will need. There ends up being no clear separation between the server's responsibilities and the client's. In this situation it's much better to just let the client own the UI entirely.