Hacker News Reader

Comment by rcsorensen | Hacker News Reader

Sending the framework of a page to your users and expecting them to do all the heavy lifting and slow loading of constructing the page and fetching the data is still rather unfriendly if you can afford a server to construct it.

If you love your users, give them HTML and let the Javascript enhance it.

Projects like Facebook's React ( http://facebook.github.io/react/docs/top-level-api.html#reac... ) and Rendr (https://github.com/rendrjs/rendr/) let you use server rendering as well as the single page technologies on the client side.

View on HN

Clientside rendering doesn't need to be heavy at all. In fact, you could do it with just $.getJSON('/api/users', function(data) { $('#users').text(data.content) }.

Sure, that requires jQuery, but most "normal" sites require jQuery, too.

Sure!

And now your poor little mobile user has to wait for the page to download, then to execute javascript, then to wait for the API response, then wait for the DOM to update.

Or you could put it in the HTML, and then they just have to wait for the page to download.

For each new page on your site that your user loads, the benefit of single page apps becomes greater: Now she only has to load a bit of JSON, not a full page. So essentially single page apps are a tiny bit slower on the first page load, but much quicker on subsequent page loads.

I'm suggesting the hybrid approach here, exemplified by the Rendr and React.

Give the full html of the first page, load the JS necessary. You get the best of both worlds.

On the first request, the client receives a rendered html page, gets to read the page, then JS functionality is attached.

On any subsequent pages, you do a simple JSON request and update the DOM.

The approaches come together without sacrificing anything. You get to write a single code base using JS (with a node.js backend doing string manipulation so it doesn't even need a DOM), the user gets a page without having to wait for external resource loads, and all page transitions past that are a simple data-fetch away.

The lifting ain't that heavy. And besides, wouldn't you want your server spending its precious cycles on things the clients absolutely cannot handle?

The lifting can be heavy for mobile devices with slow CPUs and limited battery life unlike the servers running your site. Also if your server renders the site and some of the pages are public, the server can cache the HTML and let the web server serve cached HTML rather than render the page in the web framework for each request.

It doesn't have to be heavy, even for mobile devices. Decrease your dependency on large libraries, minify and cache everything, and only load what they need. Once they load it the first time and cache it then all they ever need is a bit of JSON here and there.

> The lifting can be heavy for mobile devices with slow CPUs and limited battery life unlike the servers running your site.

The reverse is also frequently true: if client rendering can improve cacheability or reduce the data going over the wire the radio savings will pay for a LOT of text updates. Similarly, if you can transfer a large listing without creating thousands of DOM nodes the results can be a wash depending on exactly how much data, the browser, etc.

There isn't a single right answer here - it really depends on the application and good analysis.

Like `ssorallen says, slow CPUs and limited battery life is an issue. In addition, latency on mobile networks is rough and should be avoided for your users whenever possible.

You have two choices when taking an SPA approach:

1) Give your users a webpage that is usable, readable, and navigable as soon as they get it.

2) Give your users the skeleton of a webpage that they then have to accept the latency of javascript parsing and execution, and then the latency of data fetches.

we have the ability to do #1.

SPAs reduce the latency of data fetches because each new resource is a few bytes of JSON rather than some kb of HTML.

Of subsequent data fetches. Not the first page load. Using JSON fetches to update documents also gives you the ability to not throw away the DOM/CSS and maintain the execution context.

If you use the right technology, you can give a usable application out of the gate without waiting and use JSON data fetches for every subsequent request.

Reply on news.ycombinator.com