Client-side vs. server-side templating (which one?)

Question

I've been reading some very interesting articles about the whole client vs. server rendering lately.

http://www.onebigfluke.com/2015/01/experimentally-verified-why-client-side.html

http://www.quirksmode.org/blog/archives/2015/01/angular_and_tem.html

http://tomdale.net/2015/02/youre-missing-the-point-of-server-side-rendered-javascript-apps/

Now I've been a bit of a fan boy when it comes to client side but after I read these articles some points started to show up in favor of the server side rendering, to my surprise... The main points were:

• 1) You can upgrade your server, but not your users device - This means, well, yes... you are in control of the server, so if it's under performing you may opt to upgrade/scale. You can't force users to upgrade their devices.

• 2) First paint vs. last paint - Now on the experimentally verified... link above it shows when the users first see the page (first paint) and when the users may use the page 100% (last paint). Now from what I can think of when the user sees the page, it takes their brain some time to process the signals from the visual cortex to the frontal cortex and then to the premoter cortex where the user actually starts clicking his/her finger, that is of course if the html is rendered first so the brain has something to process while loading is happening in the background (js files, binding etc.).

What really got me was the bit were twitter reported people of having up to 10 seconds of loading time for client side rendering, no one should ever experience that! It's kind of saying, "Well if you don't have a good enough device, sorry, you'll just have to wait.".

I've been thinking, isn't there a good way of using both client-side and server-side templating engines and which both client and server use the same template engine and code. In that case it's only to figure out if it's benefactor to supply the client with the rendered page or let the client render it themselves.

In any case, share your thoughts on my sayings and the articles if you want. I'm all ears!

Wanting

As curious as I am about what people answer, and as fascinating a debate as this is, it is not in line with the purpose of SO. This is meant as a "I am stuck, here is what I tried, here is what I expected, why didn't it work?" kind of site. What you are asking is for opinions, and is perhaps better suited for a blog post where you post some opinions of your own and ask for reader's opinions. – Koodoo

Answer 1

UPD: do it only if you really need it

(4 years and 2 isomorphic enterprise apps later)

If you're required to do SSR, fine. If you can go with a simple SPA - go with it.

Why so? SPAs are easier to develop, easier to debug and cheaper and easier to run.

The development and debugging complications are evident. What do I mean by "cheaper and easier to run", though? Well, guess what, if 10K users try to open your app at the same time your static HTML website (i.e. a built SPA) you won't even feel it. If you're running an isomorphic webapp though, the TTFB will go up, RAM usage will go up and eventually you'll have to run a cluster of those.

So, unless you are required to show some super-low TTFB times (which will likely come through aggressive caching), don't overcomplicate your life.

Original answer from 2015:

Basically you're looking for an isomorphic web app that shares the same code for frontend and backend.

Isomorphic JavaScript

JavaScript applications which run both client-side and server-side. Isomorphic JavaScript frameworks are the next step in the evolution of JavaScript frameworks. These new libraries and frameworks are solving the problems associated with traditional JavaScript frameworks.

I bet this guy explains that much better that me.

So, when a user comes to the page, the server renders the full page with contents. So it loads faster and requires no extra ajax requests to load data, etc. Then, when a user navigates to another page, the usual techniques for single page applications are used.

So, WHY WOULD I CARE?

• Old browsers / Weak devices / Disabled Javascript
• SEO
• Some page load improvements

Old browsers / Weak devices / Disabled Javascript

For example, IE9 does not support History API. So, for old browsers (and if user disables javascript too), they would just navigate through pages just like they did it it in good old days.

SEO

Google says it supports SPA's but SPA's aren't likely to appear in the top results of google search, are they?

Page speed

As it was stated, the first page loads with one HTTP request, and that's all.

OK, so

There are lots of articles on that:

• http://nerds.airbnb.com/isomorphic-javascript-future-web-apps/
• http://www.sitepoint.com/isomorphic-javascript-applications/
• https://www.lullabot.com/articles/what-is-an-isomorphic-application

But SHOULD I CARE?

It's up to you, of course.

Yeah, that's cool, but it takes much work to rewrite/adapt the existing app. And if your backend is in PHP/Ruby/Python/Java/Whatever, I've got bad news for you (it's not necessarily impossible, but close to that).

It depends on the website, you can try to collect some stats and if the percentage of users with old devices is small, it's not worth the trouble, so why not...

LET THEM SUFFER

If you care only about users with old devices, then c'mon, it 2015, and it's your user's problem if he's using IE8 of browsing websites with a iPod Touch 2. For example, Angular dropped IE8 support in 1.3 approximately a year ago, so why wouldn't you just alert the users that they need to upgrade ;)

Cheers!

Iatrics

It's 2017 now. Webpack is ruling the world. Tree shaking and bundling code in chunks are essential parts of building the UI. Plus Ahead-of-time (AOT) compilation. Server-side compilation becomes less compelling. IMHO, SEO is the main argument. Is it the only argument?... – Guadalcanal

Answer 2

All of the conversations on this topic miss one point. Bytes sent to the client. Pages rendered as HTML on the server are a lot smaller. Less bytes transmitted is better for everyone, both server and client. I've seen the bandwidth costs on cloud sites and even a 10% reduction can be a huge saving. Client side JS pages are always fat.

Deborahdeborath

This is untrue. Literally the first link in the question shows a bar chart comparison as the data needed to render the page increases. Think about it. What is smaller, a complete table definition or the JSON data that goes inside the table? Obviously the latter... docs.google.com/spreadsheets/d/… – And

For clarity, the template library it self will obviously force you to incur some overhead, but there are some very lightweight template libraries and even in the worst case, it is only increasing the size complexity by O(1) – And

I'm pretty sure rendered HTML sent from server to client is bigger than raw data sent from server to client and rendered client-side. I'm not advocating for or against client-side, but your argument is invalid. – Charge