dbmonsater example

[chiefjester]

Question on the dbmonster example https://webreflection.github.io/hyperHTML/test/dbmonster.html

Is this the latest example? I'm only getting 30fps roughly? Shouldn't we aim for 60fps at least?

[WebReflection]

This is what the dbmonster demo here is all about

---

You need to compare it with raw DOM with manual updates, the fastest dbmonster out there, which has pretty much exact same performance. 700 cells and classes updates at 30fps is already as fast, usually faster, than any competitor.

edit cells are now 350 instead, which is why current demo is as fast, if not faster, than others. Before it was doing double the job, yet with good performance.

[chiefjester]

@WebReflection I don't mean to be rude, but there are a lot of dbmonster implementation that's beyond 30fps.

Here's vanilla manual updates (60~70fps) on my machine http://mathieuancelin.github.io/js-repaint-perfs/vanilla-optimized/

There's also this at 60fps: http://leeoniya.github.io/domvm/test/bench/dbmonster/

Here's Svelte's: http://svelte-dbmonster.surge.sh/

I do hope you won't dismiss my comment and see its a valid question. ✌️

[WebReflection]

This is what the dbmonster demo here is all about

---

The current demo code aim is to show hyperHTML simplicity delivering meaningful performance. There is a benchmark version of the same code that is faster but I don't care cause that's not the point of this library: it's the best compromise between simplicity, lightness, and performance.

Use any alternative you like if 60 fps on a fake-world demo is important for your projects.

[WebReflection]

This is what the dbmonster demo here is all about

---

P.S. you also completely misread benchmark results.

All your demo use 50% mutations, of course these go faster.

hyperHTML uses 100% mutations in all demos, and indeed it's as fast if not faster than competitors, like I've said.

Raise the bar to 100% in other links and compare again.

The hyperHTML demo doesn't even care about that value, it's just there for fun, it won't even change anything if you chose different mutations but it clearly starts at 100% mutations and that's what it does.

Please read carefully benchmarks before demanding more performance, thank you.

[chiefjester]

@WebReflection I'm getting 120fps on 50% mutations. I get 60fps on 100% mutations. The benchmark is not wrong, I just had no way in linking them at 100% mutations.

Please read carefully benchmarks before demanding more performance, thank you.

Sorry if it came that way. I am not demanding anything. Its just a friendly advice on aiming for 60fps and nothing more.

Here's the vanila JS implementation at 100% mutations (its at 79fps on that screenshot). http://take.ms/IufY8

And everything else is at roughly 60fps at 100% mutations.

[WebReflection]

This is what the dbmonster demo here is all about

---

You've skipped the first reply.

I will not answer more.

When you'll have a real world issue please file a bug, thanks.

[WebReflection]

https://github.com/WebReflection/hyperHTML/issues/31#issuecomment-294247049

[WebReflection]

P.S. just FYI 120 FPS when requestAnimationFrame goes max 60fps doesn't help your claims (it's impossible, nobody buys it) . If I were you I would use the same FPS technique other demos are using if you want to provide meaningful results.

[WebReflection]

Where is ember or react faster demo?

[ghost]

Svelte's (repo), Inferno's (repo) and Dio's (repo) seem to be the fastest around at 100% mutations.

[WebReflection]

@flagello https://github.com/WebReflection/hyperHTML/issues/31#issuecomment-294247049

[WebReflection]

http://webreflection.blogspot.co.uk/2015/04/the-dom-is-not-slow-your-abstraction-is.html

http://webreflection.blogspot.co.uk/2015/04/is-anyone-testing-on-mobile.html

http://webreflection.blogspot.co.uk/2014/06/on-meaningful-performance.html

[WebReflection]

Unlocking this conversation since I've rarely had such a big laugh.

You've all compared tomatoes with apples, blindly looking for the best without putting minimal effort reading what was going on.

Not only the initial complain was comparing benchmarks with 50% mutations while here also the range was created via hyperHTML and it was always 100%, the amount of rows in other benchmarks was 50 compared to 100 here.

I'm going to update both the dbmonster.js file and the demo to reflect last changes.

Please read carefully benchmarks before demanding more performance, thank you.

[ghost]

I perceived the exchange as an attempt to explore an observation rather than a complaint or a shallow request.

I'm pleased to see it led to a positive outcome. Despite having overlooked the differences between the benchmarks, I welcome the “alignment.”

I appreciate and value the thought and work gone into hyperHTML, and thank you for your OSS efforts — in fact I've also had the opportunity to appreciate common-js and your inputs to the dynamic import proposal.

[leeoniya]

i'm the author of domvm (mentioned above). let me chime in with my $0.02.

dbmonster is a poor benchmark that's fairly easy to "game". the only dom mutations it tests is className and nodeValue/textContent. it does test some things which are useful, like framework overhead. i use it @ 0% mutations & @localvoid's perf-monitor [1] to ensure domvm does not regress during refactors, micro-optimizations and feature additions.

i would recommend implementing js-framework-benchmark [2] instead (both keyed and non-keyed) to better assess the performance [3] of any client vdom lib; it is highly stable, reliable and impossible to cheat since the measurements are taken directly via Chrome's api/timeline.

[1] https://github.com/localvoid/perf-monitor [2] https://github.com/krausest/js-framework-benchmark [3] https://rawgit.com/krausest/js-framework-benchmark/master/webdriver-ts/table.html

[chiefjester]

Well my point, which @WebReflection deleted is aiming for 60fps rather than 30fps. That's the main take away.

If you would include a pseudo benchmark, as you describe, then better to show people your best foot forward. Instead of showing sub par performance over other view libraries which I enumerated above. (I haven't looked at the latest dbmonster implementation @WebReflection did).

I would also agree with @leeoniya js-framework-benchmark being better overall. This comment came out of genuine concern and not trying to anger the library author. I love the use of template literals as an abstraction. I would probably experimented that way if I were to write a an abstraction for DOM node creation / update.

Like I said, its just a suggestion. 🤷‍♂️ Take it easy man.

[WebReflection]

@leeoniya thanks for the links but gosh that's quite some work to do and I don't have much time these days.

The thing is, these don't look like real-world requirements and while I'm sure hyperHTML will score decently, 'cause if one understands how hyperHTML works would understand it's fast on DOM updates by default, it doesn't claim to be fastest out there, it never did!

---

hyperHTML aim, together with viperHTML on NodeJS side, is to be the best compromise between simplicity, inspired by old innerHTML but capable of delivering partial <tr> or <td> too, lightness, still under 2KB "minzipped", and performance, delegating entirely to the native DOM the visual "diffing" part.

This is what hyperHTML is all about

On the backend, viperHTML is also capable of partial chunks via asynchronous wires, a features mostly every other frameworks dreams about, keeping it simple, light, fast, and quite elegant, thanks to template literals.

---

As summary, and this is specially for @thisguychris, if you understand what is hyperHTML, what it solves and how, these "competitions" would look just overrated: of course it's fast + it does something different!

Last, but not least, this whole ticket was based on this:

I haven't looked at the latest dbmonster implementation @WebReflection did

which is annoying, because it was obvious that hyperHTML was doing more than others, with more rows (the file was called dbmonster100.js and I've stated about 700 cells updates at the first reply.

If you're looking for the best of the best in terms of micro-benchmarks, feel free to ignore hyperHTML simplicity and readability and use something like mithril.

Yeah, maybe it's slightly faster but I don't care and never will, I have better things to do.

hyperHTML is as "close to metal" as it can go, preserving template literals simplicity using them as facade for its native DOM operations.

I hope now it's clear why this ticket bothered me.

Best Regards.

[chiefjester]

Thanks for explaining @WebReflection . Before jumping the gun and being annoyed. You might have missed these comments from me:

The benchmark is not wrong, I just had no way in linking them at 100% mutations.

Here's the vanila JS implementation at 100% mutations (its at 79fps on that screenshot). http://take.ms/IufY8

And everything else is at roughly 60fps at 100% mutations.

---

I believe you are misquoting me because this comment is really out of context:

I haven't looked at the latest dbmonster implementation @WebReflection did

(Context is everything, someone might tell you "I hate it", and you ask why do you hate this library so much? Only to find what he hates is actually the ending of the TV series he is following).

This comment is meant for the recent commit you did https://github.com/WebReflection/hyperHTML/commit/694dcf15ad3c1ff1499ec20653519be8190a8b85

After I pointed the fact that other similar view abstraction libraries are at double the rendering speed of your original implementation.

At the end of the day, the main take away here is aiming for 60fps rather than 30fps. Which most view libraries are capable of nowadays. Regardless of benchmark you use, it would be wise to aim for that. But telling people that this library is not meant for that kind of poor benchmark after showing / adding an example, just actually confuses people.

[WebReflection]

its at 79fps on that screenshot

you still don't understand rAF goes max 60FPS so anything higher is likely misleading / irrelevant.

here is aiming for 60fps rather than 30fps.

It was rendering twice as much, of course it was slower. Have you realized I haven't changed a single byte to the actual library?

telling people that this library is not meant for that kind of poor benchmark after showing / adding an example, just actually confuses people.

I am telling people those benchmarks are meaningless but regardless hyperHTML there is as fast as, if not faster than competitors.

[WebReflection]

At least have the decency to actually see the updated demo.

https://webreflection.github.io/hyperHTML/test/dbmonster.html

Closing again 'cause I really really have better things to do.