Server-side or client-side {{mustache}}?

Question

{{mustache}} is, in my opinion, a great template library. The question I face is whether to use it in the client-side, or in the server-side.

I am developing an online magazine that will have a main page with one big article and the the rest of its articles in smaller size underneath.

E.g.

+-------------------------------------------------+
|                                                 |
|             Big Article Image                   |
|                                                 |
|                                                 |
+-------------------------------------------------+
     Title
     Author

+------------+     +------------+     +-----------+
|   Image    |     |   Image    |     |   Image   |
+------------+     +------------+     +-----------+
  Title               Title              Title
  Author              Author             Author
...

---

Server-side option

Using {{mustache}} in the server-side, as a PHP library: when the browser asks for the page, the server will complete the template and send it back.
pros:

• Loading times will be better. The browser, once it has received the html code will know which other resources it has to ask the server for.

cons:

• It will be difficult to integrate with client-side {{mustache}} because when the template is parsed, all the "mustache-tags" that were not matched are removed (I do not know if this can be easily and cleanly avoided).
• I do not like to modify the interface from the server-side, I rather do it from the client-side, thus the 3-tier architecture seems more clear (you might differ with this).
• I do not have previous experience with server-side {{mustache}}.

Client-side option

Instead of plain {{mustache}} I usually use ICanHas.js, which wraps {{mustache}} and makes it incredibly easy and comfortable: when the browser asks for the page, the HTML is sent, containing all th js code to ask the server for the JSON which contains the title, author, and filename of the image.
pros:

• Enhances 3-tier architecture.
• Things like infinite scrolling (an other ajax stuff) are super-simple to add.

cons:

• Load time is worsen. The browser will need to receive the code, make a request for the JSON, and then ask the server for the resources discovered in that JSON (like the image filename).

---

Question

Which one do you think, from your experience, is the best solution? Why?

Answer 1

I'd like to add a couple of points to your pros & cons.

Client side templating is more error-prone than server side

With all kind of browsers, versions, devices and security settings, things can quickly get messed up. The more javascript and client-side templating you have on the page, the more likely you'll have some users getting a screwed up page. Think of IE default compatibility settings for instance, a pain. With server side templating, you just have to check it once and be happy.

Client side templating is typically harder to debug than server side

First, you typically don't notice it when a client gets an error in the browser, except if you have some reporting system. Then, you get some cryptic one-liner error message. On server side, on the other hand, you can automatically monitor errors and have nice stack traces where it happen. Sweet ...saves a lot of time.

Probably better SEO with server side templating

It is straightforward for bots to accurately parse static or server generated pages. For pages full of client side templating, I don't really know what you'd get, hence the indexing might suffer.

Loading time is quicker with server side templating

Especially for mobile with low end phones, client side templating might make a noticeable difference. Especially if you have to fetch the data in a second step after page load. Ajax + rendering on these small devices adds a small delay. On server side with caching on the other side, you're pretty swift.

---

That said, despite all disadvantages, client side templating has its purpose

Client side templating rules with interactivity and two way data bindings

Typically for RIA (rich internet applications) where you read/edit/browse data in a very interactive fashion, client side templating can be very handy. It becomes a single page app, where the page is stateful and the adequate portions of the page is updated with corresponding data. The downside is of course that such sites are harder to develop, maintain and more error-prone.