
Twitter releases new JS template engine: hogan.js - tednaleid
http://twitter.github.com/hogan.js/
======
decklin

       <script src="//goo.gl/OCK7V"></script>
    

Really?

~~~
kylek
This irked me on a few levels too.

~~~
Skywing
I don't understand the problem. What is wrong with the example they've given?

~~~
tednaleid
It's because they're using an url shortener in a non-twitter/character limited
situation. Makes the browser need to go through a couple of jumps to load
something that the user will want to load fast.

~~~
jasonkostempski
Is it possible using goo.gl might get you something like a poor mans CDN? I'm
thinking it may possibly respond immediately with cached results.

~~~
rhubarbquid
No, it responds with a redirect:

    
    
        $ curl http://goo.gl/OCK7V
        <HTML>
        <HEAD>
        <TITLE>Moved Permanently</TITLE>
        </HEAD>
        <BODY BGCOLOR="#FFFFFF" TEXT="#000000">
        <H1>Moved Permanently</H1>
        The document has moved <A HREF="http://twitter.github.com/hogan.js/1.0.0/hogan.js">here    </A>.
        </BODY>
        </HTML>
    

Edit: I suppose the headers are more important:

    
    
        $ curl -I http://goo.gl/OCK7V
        HTTP/1.1 301 Moved Permanently
        Content-Type: text/html; charset=UTF-8
        Expires: Thu, 22 Dec 2011 18:18:46 GMT
        Date: Thu, 22 Dec 2011 18:18:46 GMT
        Cache-Control: private, max-age=86400
        Location: http://twitter.github.com/hogan.js/1.0.0/hogan.js
        X-Content-Type-Options: nosniff
        X-Frame-Options: SAMEORIGIN
        X-XSS-Protection: 1; mode=block
        Server: GSE
        Transfer-Encoding: chunked

------
krmmalik
I was dubious when Twitter released Bootstrap.css, but i have to say, not
being a UI expert i found it quite easy to work with. Concisely documented and
the right set of tools that i need, for the most part at least. Some more on
typography would have been nice.

I have yet to understand how templating engines work, and what advantages they
provide, but knowing this comes from twitter piques my interest for the
future.

~~~
tednaleid
One place that it really clicked for me in a real world situation was by
looking at the source for NodeUp, a node.js podcast. <http://nodeup.com/>

It's a beautiful website, and I was curious what their HTML looked like. If
you look at the source for the page, all you see is the mustache template that
they then populate with the information for all of the podcasts that they've
done. You then can start to see the power that templating gives you. Serve up
a template in your html, request some JSON to populate it with on page load
and have it replicated.

Makes your initial page very cacheable and clean. Much better than assembling
html by hand with "foo" + "bar" or .append semantics.

~~~
krmmalik
Thanks for a detailed response. I checked out the link and saw Mustache in the
source. I still dont see (if im correct in thinking) how this de-duplicates
effort?

They still have to do the work to construct the JSON, no?

PS. Not trying to be inflammatory, i'm just trying to understand this better
but struggling to get my head around it. I just watched a templating video by
the YUI team for Node.js and am still none the wiser. :(

~~~
tednaleid
It really decouples the model (the data that's served in the json) from the
view (the mustache template). This lets frameworks like ember and backbone do
MVC on the client side where the server is really just there to serve up a
model (in the same way that a database does for most current apps).

Making an http request is then equivalent to making a sql query.

~~~
bricestacey
I've been working with Backbone and mustache and unfortunately I have to munge
my models a lot to get the right results - like passing the cid or converting
dates, etc. How do you work around this? I have thought of initializing many
of these, but then I'd need to bind on changes... I guess you could save
lambdas as attributes?

------
equark
I'm surprised that no JS template engines ever implement binding. It seems
like everybody just ports some server-side ideas, even though there's a lot
more that is possible client-side. Why do I need to rerender the entire
template when my data changes?

Sproutcore2 is an example of this, but it's pitched as a full framework rather
than a binding aware template engine.

~~~
stephen
I agree, just rendering is a server-side notion that obviously can work on the
client-side, but I don't think is ideal.

Web 1.0/server-side templates had to render and sling strings of HTML around
because that's all you could do (Rails's RJS was a cool Web 1.5 hack in that
regard).

But once you're on the client-side, and have state, I think binding/mutating
the DOM in-place is better than trying to explicitly maintain all the state
needed to re-render-from-a-string-on-change all the time. And having a
template engine/view layer that supports as a first-class notion is a good
thing.

I used to (naively) think all JS template engines worked that way (merely re-
rendering), but as the other comment says, Knockout at least does not, and I'm
sure there are others that don't as well; I'm not an expert on all (or any) of
them.

I wrote up some of this render vs. binding differences in a post describing my
port of the todomvc sample app to my backbone-ish GWT framework:

[http://draconianoverlord.com/2011/12/10/todomvc-in-gwt-
mpv.h...](http://draconianoverlord.com/2011/12/10/todomvc-in-gwt-mpv.html)

(Not that GWT is a terribly popular technology in these circles, and it's not
perfect, but I enjoy it.)

Another interesting assertion I make is that selectors are another Web 1.0/1.5
hack that can go away now that we have state and aren't forced into "the
server gave us a huge blob of HTML, now do stuff with it!". IMHO of course.

~~~
rhizome
I have to think of the difference between rendering and assembly.

------
stdbrouw
Compiling is nice. Not a big fan of Mustache though, the tags look like
Brainfuck to me.

~~~
thomaslee
If you're into compiled templates & more traditional syntax, you could try
jazz:

<http://github.com/shinetech/jazz>

(Shameless self-plug. I wrote the initial implementation.)

------
micheljansen
Currently using Underscore, but I would almost switch to Hogan for the name. I
am assuming Mr. Hogan's mustache was used for inspiration?

~~~
leftnode
And it looks to be based off of mustache.js, another JavaScript templating
library.

~~~
micheljansen
Hence the pun ;)

------
donbronson
Nice to see Twitter has a sense of humor. "Lovingly crafted by bros" in the
footer is a nice touch.

~~~
reinhardt
Quick, someone remove this before the sexism police sees it and we end up with
yet another ZOMG-wont-someone-think-of-the-women 100+ comment thread.

~~~
mundizzle
That's a regrettable comment. Are you feeling victimized yourself? Self
reflection may help you figure out why.

------
saturdayplace
Could someone perhaps help me out re: the difference between Compiling and
Rendering JS templates? What it feels like is this:

Compiling a JS template on the server gives you a template object that has a
render() method. On the client side, you create an instance of the object and
pass its render() method a context? Am I missing anything?

If anything, this looks like what I've been looking for to get my templates
off my page and into a separate JS file. Makes things cleaner. And
_apparently_ faster?

~~~
tjholowaychuk
It's usually two separate steps anyway. Populating HTML via the object passed
in _while_ parsing is a sloppy way to go about it. This lib (and most template
engines) compile down to an executable Function, that you then pass this
object to. This means you can re-invoke it several times with less overhead

------
Void_
My biggest question is: Is rendering faster too?

Because rendering is pretty much just string concatenation. So my guess is
it's not. Is it?

If rendering is not faster then this is no use to me, since I'm a very happy
user of haml-coffee (<https://github.com/9elements/haml-coffee>).

~~~
rhizome
Since it happens on the client, it will be faster for Twitter this way. Not so
much for the user, though.

------
asktell
Nice to see that the hogan.js site itself is using Skeleton (
<http://getskeleton.com/> ) for its responsive layout. I've been enjoying
using it quite a bit.

------
turtle4
Resembles handlebars.js. Can someone point out the difference?

~~~
devinus
Right now Hogan seems to be slower and appears to have less features than
Handlebars: <http://jsperf.com/t-bench2/6>

~~~
jarin
I may be misunderstanding this, but that benchmark appears to be based on an
in-browser compilation, while Hogan's advantage is the ability to precompile
templates.

~~~
devinus
Handlebars is also capable of precompiling AFAIK.

------
dmix
This looks just like Dust.js: <http://akdubya.github.com/dustjs/>

------
Lazare
So let's recap: This is a new Javascript template engine that uses Mustache
syntax and allows you to pre-compile template syntax. Sound's good...

But...why didn't they just use Handlebars? Or if you aren't wedded to Mustache
syntax, one of the twenty other template engines out there that support pre-
compiling?

~~~
tjholowaychuk
handlebars is a pretty inelegant lib, a parser generator for a grammar as
simple as mustache is just silly, even this current twitter implementation
could be significantly smaller. For large deployments like Twitter I imagine
these savings are quite important

~~~
wycats
The Handlebars grammar is more complex than Mustache's grammar. It supports
helpers (normal and block), paths, strings, numbers and booleans.

My initial implementation of Handlebars did not include a proper compilation
flow, but optimizing its output became very complicated. The new approach (the
one used for the past year or so in Handlebars) makes it easier to reason
about how the input gets compiled into JavaScript, and each stage in the
compilation process provides ways to perform certain kinds of optimizations.

One of the major goals of Handlebars is for users to avoid paying for features
they are not using. For instance, the ".." feature, which allows a template to
reference a parent context, only impacts the compiled code if it's used.

Finally, for performance-sensitive deployments, Handlebars provides a
precompiler that eliminates the need to compile the template on the client.
This eliminates the compiler requirement on the client, and only requires a
small (1k'ish) library at runtime.

------
nbclark
Looks a lot like jquery tmpl -- the syntax at least

~~~
Maascamp
I was wondering if anyone was going to mention that. If you're already working
with jQuery I would think the tmpl extension would be a much better choice.

~~~
bentlegen
The jQuery tmpl plugin has been deprecated / put "on hold":

[http://www.borismoore.com/2011/10/jquery-templates-and-
jsvie...](http://www.borismoore.com/2011/10/jquery-templates-and-jsviews-
roadmap.html)

------
drewblaisdell

      npm ERR! 404 'hogan' is not in the npm registry.

------
ascendant
Oh sweet. I was just saying to my coworkers that what we REALLY need is
another javascript templating engine.

~~~
intranation
It's not another JS template engine - it's a pure JS implementation of
Mustache that's apparently significantly faster than Mustache.js.

They also support compiling of templates for deployment purposes, which is
nice.

------
wavephorm
I have yet to see a template engine that has any practical advantages over
conventional <%= stuff %> scriptlet style. Moving format logic out of your
template into your controller always results an unmaintainable mess.

~~~
LeafStorm
Jinja2? <http://jinja.pocoo.org/>

A lot of template engines seem to either go for "FULL PROGRAMMING LANGUAGE
POWER!" or "NO LOGIC! LOGIC IS EVIL!", but I've found that the sweet spot lies
somewhere in the middle - you have enough power in the templates to do cool
stuff without polluting your controllers, but it uses a language designed for
templating and not a general purpose language shoehorned into HTML tags, and
doesn't give you features you'll definitely never need.

~~~
greghinch
Here here, the Django/Jinja model for templating is so much nicer than dealing
with partials in every template

