2 ms·
Funny thing, had related talk today with my co-worker... Anyway, so problem currently is that client devices are slow and HTTP requests are expensive/slow. If
by hippich 13y ago
Funny thing, had related talk today with my co-worker...
Anyway, so problem currently is that client devices are slow and HTTP requests are expensive/slow. If these were not issues - I guess rendering on a client would be just fine?
If above is correct, I do not see good reason for smallish websites/apps/whateverucallit fallback on server rendering, as it looks like every single year mobile devices getting faster and faster. And we have SPDY on a way to mainstream.
Do I want to wait 3 seconds to get HTML or wait 100ms to get bootstrap code and see pieces rendering as data comes in? Probably doesn't matter, since it will take roughly same 3 seconds to render it on client side.
Ultimately, perceived responsiveness of webapp depends a lot on particular implementation. If you wait for all data required for page to render - yes, it will be slow. If you render pieces of page as data comes in - user sees that something going on and this is good enough. Why it should matter where data will be converted to presentation, on server or on a client? It is still waiting. And if client is not happy with it? Buy beefier hardware!
- babby 13y ago> 3 second to get HTML No server should take more than 100ms-500ms on a sufficiently cached page to process and to begin transferring, in non-edge cases. The only thing that could take that long is a shitty datacenter/vps, and as such, transfer speed/latency limits will encumber all types of requests. In the end, you still have to transfer data from databases, so ignoring that, client-side template rendering seems like a non-issue to me. Surely it's never the latency issue unless you're serving at ~100+ requests per second, which translates to many millions of requests a day, and I don't believe 99% of websites are doing this.