|
|
|
|
|
|
by valuegram
4110 days ago
|
|
|
As someone who is considering using a JavaScript framework for client-side rendering on a new application, this strikes me as an anecdotal over-simplification. We can find terrible uses of any technology. I'm not sure that is a reason not to use that technology. I believe the theory is that your application may take a little longer to load initially, but subsequent interactions should be much faster, since all rendering is happening on the client, and the server is only delivering API interaction. There is also the potential for even the initial render to be faster depending on what server-side rendering logic is being transferred to the client. |
|
|
It depends on what you are actually doing and how much you cache client side, but for most cases that isn't going to make things faster for the end user.
Take the example of a theoretical blog post that takes 10ms to get from the database and 50ms to render on the server. You could potentially save server capacity by shifting that 50ms of rendering* from the server to client, but in actual fact the client (a low powered mobile device) probably renders it slower than the server.
The main thing though is this doesn't take into account the 2500ms round trip time it takes the mobile device to make a HTTP request. This is going to be the same whether you render on the client or server.
Now I agree it makes sense in some cases, if you cache the data on the client (ie an email client could cache the 100 most recent emails) then it will be faster, but the most services that use client side rendering aren't doing this, so there is no real benefit to the end user.
(Apologies if I'm just repeating the article, but it's down for me)
*Serialising into whatever format you API uses is still rendering, so you aren't actually saving 50ms.