test.ical.ly | getting the web by the balls

Jun/12

28

First thoughts on Hogan.js – javascript templating from twitter

4 Comments · Posted by Christian in The right tool

Yesterday I was introduced to Hogan.js the templating library from twitter. It was new to me so I had a look at the documentation and I think I know when I would use it.

And when I would not.

The javascript templating engine of my choice so far has been ICanHaz.js. It’s implements mustache syntax for the templates which can be described as a kind of standard and it’s small and fast and jQuery/zepto.js compatible.

If I was to work on a Symfony or Silex I would try out twig.js instead as it features the same template syntax as the name giving PHP templating engine feature in the before mentioned frameworks.

So what can I read from the Hogan.js documentation?

It is of similar size as ICanHaz.js (about 2.3-2.5kb) and it uses the mustache syntax as well. Judged from that alone they seem almost identical.

But they’re not.

Hogan.js compiles its templates into javascript before use. Which probably accelerates the client-side execution. But it also means that the compilation has to take place on the server to make sense and as the compilation is taken care of by Hogan.js as well we are talking about server-side javascript execution like node.js.

This is perfectly fine of course if you’re working with node.js or similar anyway but I wouldn’t recommend it for use with other languages like PHP, Ruby or Java as it would increase your complexity a lot and you would probably have to introduce a lot of business logic duplication.

But if you’re working in an all javascript environment I reckon Hogan.js would be perfect fit.



  • Eric Herrmann

    You mean ”
    but I would[n't] recommend it for use with other languages”, right?

  • caefer

    @google-fdbc20fa977a2ac731b83c634b1104fa:disqus yep, typo. fixed it. thanks!

  • Mortimer

    I love(d) ICanHaz.js, but it has been slowing down my app quite a bit. I have to say that I have hundreds of elements that come from a single template with some partials.

    ICanHaz.js stores the html template string in memory and calls mustache to_html every time you call your template function to render an element. So in the use case I describe, it’s parsing the template string again and again, which doesn’t make much sense if you think of it. That’s where compiling comes in.

    I am using php, so as you said, it’s not simple to use hoganjs server side. But if you think of it, compiling the template once, even on the client side, to then execute it many times makes sense.

    Now, if you look at it again, templates are quite static once you deploy your app, so you can do the compilation on your machine, at deploy time, store the javascript in its own file and just import that instead of importing raw templates in script tags.

    So it’s a question of making a deploy script (using nodejs on the cli for instance) to compile the templates with hogan and store them in normal javascript files.

    In both these use cases, it’s not so hard to use hogan with projects in php (or java, or ruby, or…).

  • caefer

    @4333827eb5eb02dfbdf477f9c310bd68:disqus thank you for these interesting insights! I would have clearly expected a compile cache instead of recompiling over and over again. Still it’s a bliss to write ICanHaz templates. :)

<<

>>

Find it!

Theme Design by devolux.nh2.me
To top