
Ask HN: Is server-side HTML rendering dying? - jeswin
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.<p>1. Processors are going to be fast enough to offset the rendering disadvantage that exists on the client now<p>2. Getting JSON data is just another request (or you could bootstrap on the page itself). In any case, you&#x27;d need to bring other files like CSS before the user can interact.<p>3. All crawlers will soon do AJAX, some are already doing this.
======
bdcravens
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.

~~~
jeswin
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.

------
nostrademons
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).

~~~
jebblue
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](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.

------
chipsy
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.

------
joeclark77
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.

------
ttepasse
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.

------
bpicolo
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.

------
Spoom
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.

------
silentinteract
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?

------
webmaven
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.

