Hacker News new | ask | show | jobs
by seanconaty 4665 days ago
The thing that always bugged me about rendering things in the client was...

1) supporting 2 templating systems (server & client) 2) no graceful degradation (or "progressive enhancement" depending on your opinion) (i.e. being able to get a page's content with a simple wget)

In any case, since it hasn't been mentioned in this discussion, I'd like to direct people's attention to PJAX (http://pjax.heroku.com/).

I've found this to be a nice, simple solution to have pages work identically with and without javascript. The initial page load is rendered by the server and the HTML of the subsequent sections of the page are rendered on the server but loaded via ajax and updated with one jQuery .html() call. The app URLs and the ajax URLs are the same but they return the page's full contents (<html>...</html>) when requested regularly and the page's partial contents (<div id="#content">...</div>) when requested asynchronously.

Check it out if you haven't.

2 comments

That technique is exceedingly inefficient (download-wise) though, at least if your markup is anything but trivial.
We used to live with "exceedingly inefficient" full page reloads when we had dial-up, single-core computers and slow servers. And it worked. Now we have multicore computers, mufti-megabit DSL connections, cloud-based hosting and yet you present it as if a difference of couple kilobytes (which can be reduced to nearly zero by proper design) makes a life-or-death difference in website performance.
> yet you present it as if a difference of couple kilobytes (which can be reduced to nearly zero by proper design) makes a life-or-death difference in website performance.

That's quite the stretch, given what I wrote. I only said it was inefficient.

There's also something to be said for the fact that rendering templates on the server will make any meaningful client-side caching almost impossible. And mobile is the new dial-up; while some are fortunate to have mobile broadband, it's certainly not ubiquitous, and multi-core phones certainly aren't the norm either unless you only want to consider the HN readership for your sample.

This is a pretty good way of doing things, although I'd give older versions of IE the server-refresh version and get rid of jQuery, or at least use a cut-down build of jQuery 2.

If you're gzipping your responses (and you should if they're over a couple of k) the overhead compared to JSON is minimal.