4 ms·
> We're not rendering html client-side for fun. It makes the UI more responsive, while keeping the overall architecture more simple. There's a cleaner separatio
by Isofarro 14y ago
> We're not rendering html client-side for fun. It makes the UI more responsive, while keeping the overall architecture more simple. There's a cleaner separation between the client and the server.
Except the time to first user activity is delayed. Speed is an important criteria to responsiveness.
The architecture problems can be solved without pushing it all to the client. It's a standard service-oriented architecture. Where the processing happens is mostly irrelevant.
- the_gipsy 14y ago> Except the time to first user activity is delayed. Speed is an important criteria to responsiveness. Not if the client receives the requested page pre-rendered. The client should then render subsequent pages.
- Isofarro 14y agoThat would jeopardise the "overall architecture more simpler" which is the selling point of the article.
- sopooneo 14y agoIf there is a way to describe a conversion of data (json, whatever) to particular html that will work both client and server side, then sure. Prerender the initial page server side, and then do updates on the client. But if there is no integrated way, you end up failing DRY. Can Node do this?