webarchitecturemustachemustache.php

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


{{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:

cons:

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:

cons:


Question

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


Solution

  • 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.