rich-harris / dom-monster

The fastest possible dbmonster implementation?

dom-monster

The dbmonster benchmark has been widely used to compare various front-end frameworks and libraries. Andrew Giammarchi aka @WebReflection argues, in this post, that those tools are often unnecessary and often cause performance problems.

Personally, I wouldn't want to build an app without a suitable abstraction (cough Ractive cough), because your code becomes hellaciously complex surprisingly quickly if you try to rely on vanilla DOM. But Andrea makes a reasonable point that a vanilla DOM implementation serves as a useful benchmark against which to evaluate frameworks.

On Chrome on the machine I'm writing this on, his vanilla DOM implementation is actually slower than the Ractive implementation (though that's not true on every device or every browser). That's because Ractive implements various optimisations that no sane developer would bother with themselves. (Yep, abstractions can be faster than the thing they're abstracting, when the underlying primitives are sufficiently complex that we don't use them correctly.)

But what would the fastest possible vanilla DOM implementation look like?

Something like this, presumably

dom-monster is a fork of the Ractive implementation, without Ractive. It's really bad code, with lots of hardcoded assumptions (e.g. about the number of rows staying constant), and anyone who produced code like this would receive some stern words if they were working on the same team as me. But because the code doesn't make any attempt to be non-brittle, it's pretty fast.

This is the standard that those of us authoring tools should be aiming for. (I have to hand it to paperclip, which is within spitting distance of dom-monster.) Besides raw update performance, we should be aiming for the same degree of compatibility, initialisation speed, and memory footprint.

Theoretically, that's pretty much impossible, but it's still a useful target.

(Incidentally, Ractive is undergoing some changes for the upcoming 0.8 version that improve its update performance significantly - even beyond its current React/Underscore/Ember-beating performance. Yay!)

I bet I can make dom-monster faster

Please send me a PR!

License

MIT.

dom-monster's Issues

What is the achievement? + Code review

Once clarified that this benchmark was about performance and not style, what are you trying to achieve here?

Your code style looks more prolix for no concrete reason, it creates instances of Rows without any benefit, coupling nodes with objects which is as memory leaks prone as my closures, if these objects are never freed. You are using more RAM, and you constantly access properties so you do a lot of extra lookup.

This is a benchmark, not a code-style lesson, but since you apparently think it was ... and since you wasted time to write that down, here my review:

Leaking globals

You use a closure, which is good, but you leak globals regardless.
Using capitalized variable names does not grant you automatically the privilege to leak globally.

Why is there a TIMEOUT = 0 ?

You are using requestAnimationFrame right here ... in case you didn't know, that's DOM, not underscore or any other framework. Why are you leaking a TIMEOUT variable to use a misleading setTimeout(fn, 0) at the end of the function?
Did you know that intervals never goes under 4ms in recent browsers, and used to never go under 10 before? What kind of good practice is a globally leaking TIMER variable to use a timer instead of requestAnimationFrame ?

Why is there a ROWS = 100 ?

You were planning to use a static length or something? That's completely unused, you forgot to lint your code. Any linter would have found that unused variable.

IFI => "use strict"

Since you put an IFI in place, where is the guarding "use strict" that grants we are not leaking globals in that closure too? https://github.com/Rich-Harris/dom-monster/blob/gh-pages/index.html#L40

DRY

You are repeating countlessly the same operation over and over. I hope you don't consider this a good coding style or pattern. As shown in my code

  function append(where, what) {
    return where.appendChild(
      (where.ownerDocument || document).createElement(what)
    );
  }

This would minify much better and make you write much less code ... it's too late, you already wrote that code but I would not encourage such style. There is a closure? Use it for what its good at.

Hoisted multiple variable declarations

It's usually considered a bad practice to declare variables down the road, but if you do that because you have a for loop, then do it in a better way.

// yak!
var cell;
for ( var i = 0; i < 5; i += 1 ) {


// ... oh, much better
for ( var cell, i = 0; i < 5; i += 1 ) {

You have one place where you need those two variables: inside that for loop.
( there's no problem with leaking globals, there is only if you forget use strict and a linter before deploying ... but then you have a bigger problem than just a leak )

Same stuff repeated here

missing key attribute and a bug

You are not setting the row key attribute as the original benchmark does.
This if statement is always true
I guess that's the result of premature optimizations pattern you used.

As Summary

I cared only about the benchmark in my code, and I wrote that in minutes.

I've explained few used patterns, and I've created the smaller memory footprint needed on JS land for that benchmark.

I've clearly stated I didn't even care about the style, only about quickly bringing the benchmark in DOM land so ...

If you want to make it a life lesson about coding, there's a lot to improve here too, and so many unnecessary extra objects I don't know where to start dropping stuff.

You are coding a benchmark, the used RAM and the amount of code for startup should be more important if you want to shine in this competition.

And this is also a problem I've implicitly discussed in my blog post: developers tend to over engineer even the most simple task.

You created a class called Row to actually wrap a tr which is already a row. Do you feel better now that you have an update method through a wrapper, instead of an update function?

Good for you, but please don't tell the world that's how everyone should code, specially how everyone should code a benchmark.

Best Regards

Misleading statement

His vanilla DOM implementation is actually slower

That's just your opinion, 'cause your library performed always worst than DOM and paperclip in all tested devices. Maybe your Chrome goes 60FPS with Reactive, but it does not matter if everything else goes slow.

Please drop that sentence or modify it, thank you.