”By the time the browser has downloaded, parsed and compiled your smart compiler, my dumb parser is done rendering the template.“
Your dumb parser may be quick the first time, but when you have to render a template 100 or 1,000 or 1,000,000 times the cracks will start to show. One main benefit of parsing and compiling templates is that you can cache the result of that stage on the server.
If you want to be really smart about it, the client shouldn’t even be downloading a .mustache template — it should download a .js file containing a pre-generated function which can be called with the context, returning the rendered template. Parsing the template on the client side makes about as much sense as parsing JSON or XML with a hand-written pure-JavaScript parser.
In the browser you will not render thousand times a template. And the tens milliseconds you will save if you pre-compile the template is irrelevant compared to the hundreds milliseconds of network latency and page & js load time.
I wrote http://beebole.com/pure another template engine.
With the version-2 we dropped the pre-compilation. The small performance gain wasn't worth the complexity.
"And the tens milliseconds you will save if you pre-compile the template"
Ten milliseconds here, ten milliseconds there, pretty soon you're talking about real time. Especially if I can manage to browser-cache away the page & js load time you mention.
On repeated compilations: Of course, hence the “Compiled Templates” requested feature.
On being "really smart": These are design goals different from mustache[.js] and can be freely implemented in any other templating library if people want it.
> the client shouldn’t even be downloading a .mustache template — it should download a .js file containing a pre-generated function which can be called with the context, returning the rendered template
This would render browser-side mustache as moot. Now the server side implementations must render javascript functions. handlebars.rb, handlebars.py, handlebars.php, handlebars.cs anybody?
Why would it be moot? I do something similar to this technique with haml-js and underscore templates (though i wear a full beard, i'm not really into mustache.js)
This lets me use the same views on the server and the client, with the same $templates.render("item", context); where "item.html.haml" is the name of the source file. I pre-compile the source of all the .haml files to functions and add them to the $templates object (boo, globals, yadda yadda yadda) and then write this out to a file for serving to the browser (./public/templates.js by default.)
Then, when I make a json call or whatever and need to re-render a partial, i just call the same template rendering.
Note that this works for Node.js but you could easily make it work with ruby through redcar or use a similar technique for precompiling your mustache templates for the browser while still using your language-native implementation on the server.
Because the server generates the javascript template methods. Thus the browser does not need to parse the mustache templates. It only needs to call the compiled functions. This means the browser would not need to have an implementation of mustache running on it, since the template building is contained within the compiled javascript functions.
Ah, ok. I thought you meant that using the mustache template on the client side would be moot, not that having a mustache compiler on the client side would be moot. It was a little confusing because I'd still say that you are "using the mustache template" on the client side even though you are actually just running the precompiled function derived from that template.
Your dumb parser may be quick the first time, but when you have to render a template 100 or 1,000 or 1,000,000 times the cracks will start to show. One main benefit of parsing and compiling templates is that you can cache the result of that stage on the server.
If you want to be really smart about it, the client shouldn’t even be downloading a .mustache template — it should download a .js file containing a pre-generated function which can be called with the context, returning the rendered template. Parsing the template on the client side makes about as much sense as parsing JSON or XML with a hand-written pure-JavaScript parser.