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

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 :)

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..."

    $ 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: chunked

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.

Also, follower notification emails appear to be broken.

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.

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.

Yeah very "clean" from a search engine perspective: http://www.google.com/search?q=site:nodeup.com

http://code.google.com/web/ajaxcrawling/docs/getting-started...

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. :(

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

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

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 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?

http://knockoutjs.com/

I used it a fair bit last year and quite enjoyed it.

Does binding and a LOT more.

http://angularjs.org/

Very fast and well documented.

http://github.com/shinetech/jazz

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

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?

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).

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?

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.

http://www.borismoore.com/2011/10/jquery-templates-and-jsvie...

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

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

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.

It is just easy to create an html template with inserted values an minimal control flow using the <%...%> style.