Hacker News Reader

Comment by ericingram | Hacker News Reader

I don't understand this argument. The way I use server side templates is much simpler and more powerful than any demo of client side templating I've seen. I think you're reading a little too much into the hype, otherwise maybe you can share an example of superior Javascript templating patterns because I can't find them.

View on HN

It depends what you are trying to do. If you are only targeting browsers, and especially if you don't need a lot of responsiveness, it's much simpler to just render views on the server side and optimize your server for speed. It takes a lot of effort to write a thick client.

But if you are targeting a browser and a native iPhone app, the view logic lives on the iPhone app. It used to be that you could just serve up a web page and assume that your client was a browser. Not anymore, and that's my point. And my point is that the trend will continue: I think we will have more variety of non-browser clients in the future, not less. Your car, refrigerator, geranium, etc. will all be hooked up to the web.

Keep in mind that I'm not talking about whether you should create your web app in Backbone.js today, but I'm looking years into the future, anticipating trends.

I think I see what you're talking about: more non-browser clients exist so the web servers need to be able to expose an API. I agree with that.

Besides that, the ability to "template" output on the server is still my ideal way to transform the business API to something the client can read. In the case of a browser, I'm templating for HTML. For a mobile app, we may just pass through in JSON and let the native mobile app handle the views, even output HTML5 for mobile in addition.

In all of these cases, server side templating of output plays a role I think. For browser targeted output, server side templates are still simpler in the implementations I've seen.

Well said. I think this is the best way of putting it. I temper my original position of saying that server-side view rendering is "on its way out".

I don't think the necessity of writing your app so that it exposes APIs has any correlation to whether or not the traditional web server interface to your app can still serve HTML from the server. It's just as easy to wrap API methods on the server and feed that data into a server side template as it is to call the API from a client side method (well, it's actually much easier, no need to manually futz with the browser URL/history and all that).

That's exactly what I intended to say but you said it better :)

Reply on news.ycombinator.com