The program is pretty simple.
It is a good sample of Mustache rendering principles.

It renders a recursive template taken from a well known web site:

<h2>Example 6 : Recursively binding data to templates</h2>

<h3>Organization Structure</h3> {{> person}}
{{<person}} <div> <b>{{name}}</b> ({{title}}) <div style='padding-left: 15px; padding-top: 5px;'> {{#manages}} {{>person}} {{/manages}} </div> </div> {{/person}}

This template is executed on the following context data:

 { title : "President", name : "Perry President", manages : [
{ title : "CTO", name : "Janet TechOff", manages : [
{ title : "Web Architect", name : "Hari Archie", manages : [
{ title : "Senior Developer", name : "Brenda Senior", manages : []},
{ title : "Developer", name : "Roger Develo", manages : []},
{ title : "Junior Developer", name : "Jerry Junior", manages : []}
{ title : "HRO", name : "Harold HarOff", manages : [
{ title : "HR Officer", name : "Susan McHorror", manages : []},
{ title : "HR Auditor", name : "Audrey O'Fae", manages : []}
It will render it in loop, and then we compare the speed...
For SynMustache, we got:

For mustache.js over SpiderMonkey, we got:

The native Delphi version, included within our mORMot framework, is 10 times faster than the JavaScript optimized library.
And if you look at the process explorer during the run, SynMustache does not have any memory increase, whereas the JavaScript engine will continuously increase/decrease its memory usage, due to the garbage collector...

I always prefer such benchmarks, pretty close to real world process, in comparison to optimistic and unrealistic benchmarks like a Mandelbrot computation.
Who is calculating a fractal for its business? Unless you write a video game (but who may use a JIT and a GC for it?), your software will very likely process data and strings in memory, just as with this benchmark.

In fact, JavaScript runs pretty well on latest SpiderMonkey, with more than 10,000 recursive blocks rendered per second.
The SynMustache performance (around 120,000 recursive blocks rendered per second) sounds so high it may not be worth it...

Just remember: 10 times faster, on a server, means 10 times more clients served in the same time...
So 10 times more Return On Investment (ROI) for the same hardware, and probably a more integrated (cheaper) solution, since you won't need to spread the server software on several pieces of hardware!

If your managers begin to have doubts about JIT/GC/Java/C# speed and ROI - which is pretty much likely after years running J2EE servers around the globe - you can show them this sample.

Today, managers may be confident that JavaScript (and mono-threaded node.js) is the answer.
At least, they are told so.
But, even if they are far away from the technical stuff today, they know that such solutions consume a lot of computer resources: each tab in Chrome or FireFox exhausts their notebook or smartphone computing power!
JavaScript may be good enough on client side, but may reduces the ROI on servers.
RAM on servers do cost money...

Imagine how your business may benefit from a multi-threaded engine like mORMot, when compared to a mono-threaded node.js server...
And, in mORMot, every single thread is able to process 10 times more data than its JavaScript version!
So 10 times more clients on the same server, 10 time less money to invest, 10 times more money to win, with the stability of native code and tuned memory process...
I'm quite sure they will perhaps start to be moon-eyed again on Delphi.

Especially if the company has still Delphi skilled people in its teams.
Do not let your critical software be written by young developers who do not know about algorithms and data structures.
Delphi has the strengths of C/C++, but easier to work with thanks to a cleaner approach, and all modern design concept at hand.

OK... I stopped trolling, but it is not far away from my own experiment...

Feedback is welcome on our web site, as usual.