dom-monster

updated to use the standard rows, datamodel and a better FPS/memory counter

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 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 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 ? 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 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 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 loop, then do it in a better way. 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 attribute and a bug You are not setting the row attribute as the original benchmark does. This 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 to actually wrap a which is already a row. Do you feel better now that you have an method through a wrapper, instead of an 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

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.