Performance: Giant speed up of Riot templating language

[eviltrout]

I was fascinated by your benchmarks on your blog post about riot.js.

In particular I really enjoyed this chart, which compared riot.js to handlebars, especially how 7ms in two places has two totally different lengths!

Anyway after being inspired by that chart I thought surely there is a way to make riot.js' templating language even faster than handlebars.

The current riot.js templating language is a simple regexp:

$.trim(template).replace(/\n/g, "").replace(/\{([^\}]+)\}/g, "'+_.$1+'") + "'")

So the "secret" to having the world's fastest templating language for the world's "most powerful client side framework"(tm) is to just throw away useless features like data binding, conditional statements and loops. Who needs those right?

I think you can even take it further! Why even do variable substitutions? Why even bother returning strings?

This patch is 100,000x faster than riot's current implementation. You're welcome!

[bcardarella]

charting... how does it work?

[danveloper]

👍 Looks good!

[merthurturk]

"Riot views are as dummy as possible. No conditional statements, loops, or data binding. No custom attributes or custom elements. These should be absent from the view. Views are something you can expect from any HTML developer."

"This kind of "logicless HTML" has no weak spots or testable surface. It's faster and passes W3C validator."

"The actual logic is inside the presenter."

The main goal is not performance, from which I understand reading the blog post (https://moot.it/blog/technology/riotjs-the-1kb-mvp-framework.html). Performance boost is the side benefit.

-- Though the chart issue is really interesting! :)

[ghost]

Can you upload a graph to represent this method being 1000x faster? I'm having some trouble visualising it and some brightly coloured bars would definitely help.

[Supermathie]

Holy crap! He must have this patch halfway applied, look at THESE SPEEDS!

[bcardarella]

@courtneycouch no merge?

[eviltrout]

😢 😢 😢 😢 😢 😢 😢 😢 😢 😢 😢 😢

[tipiirai]

Yeah. The "secret" to performance improvement is to remove unnecessary stuff from the template language. Indeed, it's implemented as simple RegEx. It's simple and performs faster than others. Why not?

The charts compare apples to apples. So 200x in Riot compared to 200x to Handlebars. It would not make sense to compare 200x to 500x, right?

If you have a patch to make it even faster, I'm obviously interested. But I can see that this pull request is just a trolling response.

[eviltrout]

I am done trolling for today, so here is a serious response. (I should say that in no way do I represent the Ember community and this patch has nothing to do with them though.)

This patch was inspired by this old but great article from Charles Nutter about MagLev, a then-upcoming Ruby interpreter that was supposedly faster than other implementations.

In the article, he shows that by simply turning off edgy behaviours of JRuby, he could get a 3x speed improvement. However, those changes made it incompatible, and he felt that compatibility was more important than "magic performance" numbers.

Your article about Riot.js begins with "magic performance" numbers.

1. The point of this PR is to show that you have made a major tradeoff in functionality before you compared the other template languages.

2. I think any novice programmer knows that if you take out a lot of functionality, it's easier to be faster.

3. You might personally think conditional statements and loops are unnecessary in templates, but plenty of developers find them amazing and great for productivity. Why do you think every template language you tested has those yet yours doesn't?

Additionally, I think that you have ignored some of the optimizations that frameworks like EmberJs make when updating single values. For example, in EmberJs values are surrounded by metamorphs so that when they change only the value is updated in the DOM. In your template "language", the entire DOM has to be replaced. Have you tested this in a large document?

[courtneycouch]

Before @tipiirai responds I wanted to jump in and thank you sincerely for a serious non trolling response. We just pushed the blog post up and the text used to describe riot will definitely improve and change.

It's meant to make an argument for our view of front end JS development, and any interpretation of our intention to troll or be inflammatory is accidental. We'll change out the "est" adjectives as well, and really do welcome serious concerns about the points we make.

[tipiirai]

Thanks @eviltrout! Your points are valid and the performance improvement is indeed caused by the lack of functionality. I personally prefer to keep the views dumb without any logic so stripping out loops makes perfect sense for me and I want to promote that pattern on Riot. I should probably point that out more clearly on the blog entry.

Templating performance is just a small angle of Riot though. In fact - it's not relevant at all. The whole point is on the MVP pattern and the fact that you don't need any framework to write modular code.

[courtneycouch]

@tipiirai It's understandable the critiques focus on the mentions of performance since the benchmarks are so prominently displayed at the top of the blog post.

[eviltrout]

Thanks guys for the nice responses. Sorry for the troll, but some of the text caused me to blow a gaskett.

[courtneycouch]

The text has been improved a bit on the blog post:

"An incredibly fast, powerful yet tiny client side framework for building large scale web applications." hopefully less gasket rupture inducing.