Swap out Mustache rendering engines

[sizzlemctwizzle]

I wrote my own Mustache template rendering engine for Node.js awhile back. It is much faster and more memory efficient than Mu. Instead of building a parse tree in memory and then evaluating it to render (waking the parse tree and figuring out context.. ew), my engine transforms a template into a node module and then requires it. To render, it just passes the options to the module. The code is much simpler (so easier to optimize) and because it's a module, V8 can actually preform optimizations on the rendering code. I still need to implement Mustache partial syntax before it becomes a drop-in replacement for us. Template rendering speed and efficiency is important for us because we do it for essentially every request, and templates are just going to get more large and complex going forward.

[jerone]

Without looking detailed at it, my concern is stability and documentation. Mustache has been around a bit longer and tested throughout. Also examples and documentation can be found on the Internet.

When (not if) openuserjs becomes popular performance will be a big issue, so if you think this will help...

[sizzlemctwizzle]

my concern is stability and documentation.

I wouldn't say that Mu has stellar documentation. It's pretty sparse. As far as stability is concerned, my implementation is much simpler and therefore easier to debug. I still need to fill it with comments. It was just an experiment on a theory I had of building a faster rendering engine.

Also examples and documentation can be found on the Internet.

Mustache documentation can be found on the internet. We're talking about the rendering engine. There are already two implementations written in JavaScript: Mustache and Mu. The first is written in pure JS and can run in the browser. The second is written for Node.js. I wrote a third, also for node.

Mustache has been around a bit longer

Mu has been around for three years, but most of its commits are in the last year.

tested throughout

I'll give them that.

so if you think this will help...

I do, but I agree that it needs more testing if we decide to use it.

[eneko89]

Don't know if it helps, but there are a lot of Mustache implementations in javascript, not just Mustache.js and Mu.

• Hogan ( https://github.com/twitter/hogan.js ): Twitter's implementation of Mustache. They claim it to be fast, and is faster than Mustache.js indeed, but not the fastest one. Fully compliant with the Mustache spec.
• Handlebars ( https://github.com/wycats/handlebars.js ): The most popular one by now. It's even faster than Hogan and provides a lot of extra features, but it's not fully compliant with the spec (helpers vs lambda functions amongst others, really annoying to me).
• Templayed ( https://github.com/archan937/templayed.js ): This Mustache implementation is focused in being performant and small. It is, and is fully compliant with the Mustache "required" features, but lacks partials, and although it is an "optional" feature in the spec, is essential to me.
• LT ( https://github.com/rhyzx/lt ): "Little Template" engine, really fast, but like Templayed, it does not implement some of the "optional" features of the spec. It does not support partials nor lambdas.
• Mote ( https://github.com/satchmorun/mote ): Blazing fast (probably the fastest, see benchmarks in their website) and fully compliant Mustache implementation.

And they are probably more out there. Be aware that some of them are not being actively supported/developed. Mustache.js and Handlebars are the most active projects (the last one specially). Think it twice before reinventing the wheel.

[sizzlemctwizzle]

not just Mustache.js and Mu.

I know. I looked into them before rolling out my own version. I took a different approach than any of the others in my implementation. A template transformed into pure js will always be faster than evaluation. Apparently Mote does something similar but the advantage of keeping it in-house and not having to rely on someone else outweighs any benefits of using it imo.

Think it twice before reinventing the wheel.

I already did, so this advice is too late. I just need to finish it off by implementing support for partials.

[Martii]

@sizzlemctwizzle

When the time comes for node @ 6 LTS mu2 will have to be swapped out, whether forked or actual replaced, unless that maintainer/author (@raycmorgan) comes alive.

See also:

• https://nodejs.org/api/buffer.html#buffer_buf_write_string_offset_length_encoding
• Planning for v6 nodejs/node#5766 (comment)
• .write( string, encoding, offset, length is deprecated notice raycmorgan/Mu#70
• Buffer.write is deprecated. raycmorgan/Mu#71 -0, or Replace deprecated call to Buffer.write. raycmorgan/Mu#74 +0, or Updated depreciated methods. raycmorgan/Mu#77 -0
• https://github.com/nodejs/Release