{{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
...
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:
{{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).{{mustache}}
.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:
JSON
(like the image filename).Which one do you think, from your experience, is the best solution? Why?
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.