Twitter releases new JS template engine: hogan.js(twitter.github.com)
twitter.github.com
Twitter releases new JS template engine: hogan.js
http://twitter.github.com/hogan.js/
88 comments
Compiling is nice. Not a big fan of Mustache though, the tags look like Brainfuck to me.
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.)
http://github.com/shinetech/jazz
(Shameless self-plug. I wrote the initial implementation.)
You can change the delimiter if that helps.
npm ERR! 404 'hogan' is not in the npm registry. <script src="//goo.gl/OCK7V"></script>
Even worse, goo.gl doesn't actually support HTTPS. So, on HTTPS pages, that will just fail. (It actually just loads google.com)
What's more is it redirects to a GitHub-hosted URL. Maybe it's just me, but it seems cheap that twitter would advocate hotlinking off a GitHub server when they have so much capacity of their own.
lol sorry, i'll take the blame for that.
The link was originally just a placeholder for our awesome designer @dhg (who rocked the site in like an hour).
I missed the link before it got pushed, and forgot to swap it out.
When first published it didn't even point to an actual js page. :(
Anyways, I've fixed the redirect, but should have just removed the link all together. I've updated it now to point directly to github.
The main reason that we're using github to host this (and bootstrap) rather than a proper cdn is because it makes publishing new versions super fast and easy.
Of course we don't recommend that you hotlink from github for any serious application. You should bundling these with your other assets :)
The link was originally just a placeholder for our awesome designer @dhg (who rocked the site in like an hour).
I missed the link before it got pushed, and forgot to swap it out.
When first published it didn't even point to an actual js page. :(
Anyways, I've fixed the redirect, but should have just removed the link all together. I've updated it now to point directly to github.
The main reason that we're using github to host this (and bootstrap) rather than a proper cdn is because it makes publishing new versions super fast and easy.
Of course we don't recommend that you hotlink from github for any serious application. You should bundling these with your other assets :)
This irked me on a few levels too.
I don't understand the problem. What is wrong with the example they've given?
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.
Also, it's bad practice to obfuscate the urls to scripts (outside of an automatic concat/compress process), especially external ones.
Oh, I understand. Whenever I read the Hogan site, initially, I didn't realize that they were suggesting that people actually use that URL in production.
Of course they aren't advocating that. They're just saying you can try it out by dropping that script tag on your page.
Their first suggestion, and the one they are definitely implicitly recommending, is: "Use it as a part of your asset packager to compile templates ahead of time..."
Their first suggestion, and the one they are definitely implicitly recommending, is: "Use it as a part of your asset packager to compile templates ahead of time..."
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.
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>
$ 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: chunkedNo. Regardless, a second DNS query will have to be performed by the client when Google responds with the permanent redirect.
> I'm thinking it may possibly respond immediately with cached results.
Just because nobody explicitly said it - a 301 redirect is actually cacheable per §10.3.2 of RFC 2616. But google doesn't set a long cache duration - another one of your responders posted the response headers, it was 86400s which is 1 day.
Just because nobody explicitly said it - a 301 redirect is actually cacheable per §10.3.2 of RFC 2616. But google doesn't set a long cache duration - another one of your responders posted the response headers, it was 86400s which is 1 day.
It's almost as if they think RTTs are free.
Is that why I just got a menu-bar failure message 20sec after the page nominally loads? Terrible.
Also, follower notification emails appear to be broken.
Also, follower notification emails appear to be broken.
I would have expected //t.co
Oh sweet. I was just saying to my coworkers that what we REALLY need is another javascript templating engine.
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.
They also support compiling of templates for deployment purposes, which is nice.
And then twitter released one! Awesome timing! Now you don't need to write your own.
yeah we felt the same way, but we're trying to move off of mustache.js for performance reasons (also for size in our new tweet embeds projects).
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.
Sproutcore2 is an example of this, but it's pitched as a full framework rather than a binding aware template engine.
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...
(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.
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...
(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.
I have to think of the difference between rendering and assembly.
This is the approach that we took with the Derby framework (http://derbyjs.com/): we use a template engine that parses Mustache-like templates and infers bindings at the same time. You don't have to write any additional bindings declarations, and everything updates in realtime among different windows and users as well.
I've looked at Derby and it seems like a fantastic idea. I was considering giving it a shot for my next side project, but I'm a little confused as to whether it supports any form of persistence or not?
I see you have an open issue on github (https://github.com/codeparty/derby/issues/9) about initial persistence with MongoDB which is still marked "open", but the documentation implies it's already working?
I see you have an open issue on github (https://github.com/codeparty/derby/issues/9) about initial persistence with MongoDB which is still marked "open", but the documentation implies it's already working?
Assuming I understand your use case correctly, I think Knockout is what you're looking for:
http://knockoutjs.com/
I used it a fair bit last year and quite enjoyed it.
http://knockoutjs.com/
I used it a fair bit last year and quite enjoyed it.
Yeah, I love knockout. And honestly with version 2, they've implemented native templates, which basically means you can write your templates in HTML instead of strings (gasp!). I much prefer this concept. Templates in strings never made sense to me when we already have a DOM to take advantage of, but only recently have I seen some of the great work out there to make this possible, like this, Lift's CSS selector transforms (http://simply.liftweb.net/index-7.10.html ), Nodejitsu's weld (https://github.com/hij1nx/weld ), etc.
You should really check out AngularJS.
Does binding and a LOT more.
http://angularjs.org/
Very fast and well documented.
Does binding and a LOT more.
http://angularjs.org/
Very fast and well documented.
You should check out http://www.batmanjs.org
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?
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?
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
Nice to see Twitter has a sense of humor. "Lovingly crafted by bros" in the footer is a nice touch.
this was switched up a bit today. That said - for the ladies out there - girls can be bros. total bros.
Resembles handlebars.js. Can someone point out the difference?
Right now Hogan seems to be slower and appears to have less features than Handlebars: http://jsperf.com/t-bench2/6
Couple hours later, Hogan is faster than Handlebars:
http://jsperf.com/t-bench2/7
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.
handlebars is based on mustache
So is Hogan, apparently.
Not based, it just does the same thing.
Actually, “hogan.js is a compiler for the Mustache templating language” –from https://github.com/twitter/hogan.js
It is compiler for Mustache, it does the same thing, it passes the same tests, but they didn't take Mustache code and improve it -- which is in my opinion what being based on means, they instead started from scratch and wrote a brand new parser.
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.
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.
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.
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.
> If you look at the source for the page, all you see is the mustache template... Makes your initial page very cacheable and clean.
Yeah very "clean" from a search engine perspective: http://www.google.com/search?q=site:nodeup.com
Yeah very "clean" from a search engine perspective: http://www.google.com/search?q=site:nodeup.com
Only if you don't implement the AJAX crawling scheme:
http://code.google.com/web/ajaxcrawling/docs/getting-started...
http://code.google.com/web/ajaxcrawling/docs/getting-started...
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. :(
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. :(
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.
Making an http request is then equivalent to making a sql query.
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?
Probably closer to a stored procedure or prepared statement :)
Yeah, you'll still need to jump through some hoops to get the data ready. Templates are useful when you have a JSON data source and a rather complex HTML UI that is built off the data on the fly after the page loads. You could totally build the HTML manually inside Javascript as well, but it gets time consuming for the developer, especially with Javascript's lack of long-format strings """like these in Python""".
Thanks for the detailed responses all. Im starting to understand this a little better ;-)
If they're using Node (and I assume they are, based on the fact that it's a Node.js podcast), I don't really understand why they wouldn't render the HTML server side (I may be showing my age by asking this) instead of relying on the client to render it.
Shifts computational work to the client.
Also forces you to build your server-side stuff as an api, which makes it much easier for others to consume.
Since there's nothing preventing the building of the API otherwise, this is really disabling everything but API access.
In practice there is usually a world of difference between apis that are used to build a service's main website and apis that are written outside of it. Forcing yourself to use your own apis is one of the absolute best ways to ensure you improve it.
Not necessarily a good thing.
Yeah you have to wonder about client-side performance with work being offloaded to it to render.
Sounds like it doesn't really matter. They could do either. They might have done it on the client specifically for those people that want to see the code.
Currently using Underscore, but I would almost switch to Hogan for the name. I am assuming Mr. Hogan's mustache was used for inspiration?
And it looks to be based off of mustache.js, another JavaScript templating library.
Hence the pun ;)
This looks just like Dust.js: http://akdubya.github.com/dustjs/
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.
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.
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.
Here here, the Django/Jinja model for templating is so much nicer than dealing with partials in every template
If you want to see a template engine that doesn't treat HTML as a dumb string, take a look at DRYML: http://cookbook.hobocentral.net/manual/dryml-guide
Yep, that is why I use EJS myself. Coming from a PHP background probably biases me though.
It is just easy to create an html template with inserted values an minimal control flow using the <%...%> style.
It is just easy to create an html template with inserted values an minimal control flow using the <%...%> style.
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).
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).
Since it happens on the client, it will be faster for Twitter this way. Not so much for the user, though.
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.
Looks a lot like jquery tmpl -- the syntax at least
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.
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-jsvie...
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?
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?
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
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.
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.