We had interesting discussion about one of commits, which changed way for delivering stubbed server responses in our test suite. In short: we have jasmine-based acceptance tests for client-side, which uses jQuery .click and other event triggers to simulate interaction with user. All requests to server-side are stubbed, so we have to produce some JSON-like data structures to respond with them. Almost every test use the same data, but sometimes we need to change something to test specific scenario.

1st solution

It was based on global object ServerResponses with few fields for each type of request. That fields contained objects, which were stub responses for specific request. Take a look at the code (CoffeeScript):

OK, not bad, but what if I want to change something in player attributes, for examples his points?

Now you see where the problem is – if we want to change inner object we have to clone it. It sucks.

2nd solution

Here’s the point, where the discussion begins – I replaced initialData object with initialData object factory. In CoffeeScript the change is syntactically small:

So as you see each response is represented by new object, instead of shared one. We can pollute these responses with everything we need, we don’t have to think about global state. But there is one problem – it’s a function, so we have to remember about “()”. That’s sad, awful and too complicated.

Is there any chance to get this as beautiful as furry bunnies on green grass?

3rd solution

So let’s design perfect solution for this problem. Let’s have a function “merge”, which would create new object from object given as first parameter, and new values in second one. “Perfect code”:

It looks nice. If we assume, that every object can only update its fields or extend with additional fields – it seems doable. We can live with this assumption, but let’s think how it can be implemented… First of all – for each field of second parameter object we must create clone of corresponing object in first parameter. It has to be deep clone of object sometimes, so it isn’t easy to implement. Please, remember the context – we want it as tests helper. So to get “perfect code” we would have to implement helper, which also needs to be tested. But ok, we can do it in 1 hour – because we love “perfect code”.

What’s the biggest problem with that solution? That it doesn’t protect us from affecting global state of tests. We still can do ServerResponses.initialData.player.points = 10.

Summary

Object factory:

• has ugly “()” in every use (eeeew, worst thing ever)
• always use new object, without reference to global state
• has ugly name – factory
• has simple implementation

Merge function:

• syntactically beautiful
• has complex implementation (we are awesome, so we’ll write it with full test suite)
• doesn’t protect global state

tl;dr

Handlebars > other JS templating libs/tools (ps. maybe except dust.js)

Here’s the story

I work for startup GameBoxed.com. My job is to implement new game scenarios, improve old ones and few other things. All games are written in JavaScript/CoffeeScript, all of them are one screen only – every view change is made by JS. For few months we used to render all views on server-side (statically and dynamically), sometimes updating old static templates with new values with jQuery. It was quite clear to us we should change the way we render views – we should only use static, not prefilled templates with easy way to fill them with data. First try was Mustache, next is Handlebars. We’re also thinking about Pure.js, but this blog will show you, that Pure.js is hard.

Templating trash

• EJS – too easy to add logic to template
• jquery-tmpl – collection support is too poor
• underscore.js template – also oto easy to add logic
• Mustache – too simple

Pros and cons of Handlebars

compilable

You don’t have to process same template on one runtime – Handlebars.compile simply creates function, which can be applied to context to render HTML.

extendable

Nice API to extend template logic, but with little pain, that makes you to think twice about putting logic into template.

simple

Create template with holes, fill them with JSON data, add to DOM with third-party tool.

only for render

It’s created for one thing only – rendering templates. There is no support for updating existing components. There is also no support for DOM management.

Why I like Handlebars.js over Pure.js

First of all it’s too complicated. You can pass your data (context) as crappy JSON with matchers as field names, or leave translating matchers in directives. Matchers seems to be hard to manage – for each piece of data you must define one, so your templates are not so friendly to get filled. Of course you can use conventions, so it can be easier, but than you have to use ugly css class-based convention. It is also too complicated to render template for collections.

Pure.js is much bigger than handlebars – in sense of functionality. It can manage DOM, update easily rendered view. Maybe it’s worth it to write matchers to get this ease of updating? I’m almost 100% sure, that it is easier to render template with Handlebars and than update it with jQuery – it’ll need some conventions, but much more flexible than those from pure.js. In next blog I will show how to write Handlebars templates that are easy to update.

Ps. While I was about to finish this blog post, Andrzej tweeted about dust.js in LinkedIn. Fuuuu…