Hacker News Reader

Comment by ryankshaw | Hacker News Reader

as I read that I kept wanting to say "No, we're so past that! i need client-side everything w/ json apis" (as I'm sure a lot of people and the mindshare of the interwebs are going) but then I read the last part:

  > If your web application is all high-fidelity UI, it’s completely legit to go this route all the way. You’re paying a high price to buy yourself something fancy. No sweat. But if your application is more like Basecamp or Github or the majority of applications on the web that are proud of their document-based roots, then you really should embrace SJR

and I realized that he's completely right, the majority of the web is still document oriented "pages". If that's your case, don't try to be an "app" and the 37signals way works just fine for you. in other words, it would not be a good idea to make a blog be a Single Page App (I'm looking at you blogger).

View on HN

I'm sure there will eventually be a happy medium where a page/app is rendered on the server, but upgraded asynchronously to be as dynamic as it needs to be, so we'll see the convergence of apps and pages. The return of progressive enhancement, I suppose - but even better because of pushState, indexeddb, etc.

That's if there's truly some benefit. Server-side rendering has its place, but probably isn't important for apps on the very "app" side of the content-app spectrum. What makes me want very easy to use server-side rendering, even for apps, is the fact that so many of those apps have embedded content - say an email in Gmail - that it'd be great to reuse the same templating if it's later deemed important to have a link to a static version of the content "outside" of the app.

So ... let's deliver our HTML templates pre-filled with HTML data. Sounds like the best of both worlds to me, and less duplication of work if the string concat is already done for you ;-)

I find the best approach is to render the initial view server-side and then render any future requests client-side with data from your API. That way your site will be super fast and can be indexed by search engines.

If you're using node.js then you can even use the exact same template rendering code.

You can even use the same templates on the server and client with python server side using Jinja2 and Nunjucks.

Did you read the article? They specifically address this:

This means it might well be faster from an end-to-end perspective to send JavaScript+HTML than JSON with client-side templates, depending on the complexity of those templates and the computational power of the client. This is double so because the server-generated templates can often be cached and shared amongst many users (see Russian Doll caching).

If you're just looking at a web page then maybe sometimes server side rendering is a good way. But as soon as you're having a mobile app and a tablet app, and partners that want to read your data, you realize that what you need is an api. And once everybody except your website uses this API, then you start to wonder.

Can't your web server also consume your API? If SJR can improve performance that seems like the best option.

I've had exactly the same realization. Too often I am working with different embeddable widgets with dynamic functionality forgetting that a lot of the webapps out there still work with the old CRUD app model where you list items in a table, select one item, edit, repeat.

Reply on news.ycombinator.com