Ask HN: Is server-side HTML rendering dying? | Hacker News Reader

Ask HN: Is server-side HTML rendering dying?

13 pointsjeswin13 comments

I am putting considerable energy into building a framework that renders on the client and the server. However, I am unable to think about strong reasons why server-side rendering will be a must-have in future.

1. Processors are going to be fast enough to offset the rendering disadvantage that exists on the client now

2. Getting JSON data is just another request (or you could bootstrap on the page itself). In any case, you'd need to bring other files like CSS before the user can interact.

3. All crawlers will soon do AJAX, some are already doing this.

View on HN

Serious question: can anyone name a site that has abandoned server-side HTML rendering in favor of client-side? Usually it's a matter of progressive enhancement.

I know you're wanting to avoid doing unnecessary work, but I'd surmise the future you think is coming is far enough away that your site will be rewritten at least once between now and then.

There aren't many, but that's because crawlers hadn't caught up until recently. On the other hand, there are advantages to having a data API available even on content-only sites like Wikipedia, as would be the case with client-side rendering.

Latency. Server-side rendered pages can display immediately; client-side ones need to wait for the JS to download before they show anything. This can be a significant advantage for sites that are transactional or content-based in nature (eg. Google, weather, news, or Wikipedia).

My view changed a few months ago. I think SPI (Single Page Application) is here to stay and is fast subsuming the web landscape:

http://en.wikipedia.org/wiki/Single-page_application

My tool of choice is jQuery Mobile. If it weren't for that I'd probably do AngularJS; whatever it takes to shift the processing to the client and make my life easier by not having to muck around in too much JavaScript code.

The point being that this approach works just fine for document centric sites.

Exactly. Server-side vs. client-side rendering of HTML is just another optimization choice.

Is it more important to shorten the time to display the current request, or to shorten the time for new pages to be rendered? Single-page apps marginally increase the current request's time-to-render in exchange for improving navigation between pages. For some purposes that provides a significant benefit, other times it doesn't.

You can achieve weather, news, wiki levels of performance with client-side rendering. Although, today it depends on the device you're using.

There's still a huge place for rendering on the server, but the Wheel of Reincarnation has been turning towards browsers being a thick-client app platform for some time now. But the underlying stack is still really bad for it. The high-performance path hasn't changed, even though we can see where we want it to go, and unless that changes it'd be hard to recommend making the shift.

Remember that 99.9% of dynamic websites are not Amazon or Ebay. Not every site needs to be "optimized" for massive amounts of traffic and massive server clusters. For most purposes, PHP is good enough, and Ruby or Python frameworks are fun to work with. We are fortunate to be blessed with an abundance of choices when it comes to tools.

Not all crawler have advertising giants with billions of dollars worth of resources behind them. Some are just curl or similar things.

If you want to participate in low-level crawling like for microformats/indieweb or similar things there is an advantage for static pages: you participate in a more democratic web not in one which just works for the big stacks.

I don't think processors are as close to offsetting the rendering disadvantage as you think. Servers get more powerful at the same time, so I suspect the faster strategy will continue to be server-side.

Is there potential that clients will become 'close-enough'? Maybe, but I doubt the gap will ever be fully bridged.

The primary benefit to rendering the HTML on the first request (as opposed to a subsequent request through AJAX etc.) is that you don't have to wait for another round trip of latency. Note that this is not improved by additional CPU speed, and even additional bandwidth will not completely eliminate this bottleneck.

As I understand it, Twitter tried full client-side rendering for a while and went back to a progressive enhancement model, because they noticed that an extra round trip of latency is enough additional load time to be noticed by the user.

HTTP/2 will shrink the benefit of first-load rendering further, but it's currently still an important consideration to make if load time is a primary concern.

This is an interesting topic. Could it be we're at that stage where older browsers no longer matter/actually support one page/JSON based websites?

Server-side rendering is here to stay, but in a rather odd form:

Basically, you build your SPA in such a way that most major application entry point states are reflected in the URL (or at least URL+headers), use PhantomJS or something similar to capture and cache that page, and whenever the opportunity presents itself, serve up the cached version to the user so the SPA starts from that point very quickly.

Reply on news.ycombinator.com