Accessibility First DevRel. I focus on ensuring content created, events held and company assets are as accessible as possible, for as many people as possible.
Could be me misreading it but it seems like they deliberately made the vanilla JS test dumb so that it keeps overwriting the HTML (copy existing, add new item, then replace all the HTML with the new HTML) instead of adding to the HTML.
That isn’t how anyone would do things in the real world. (Or if they did they wouldn’t be adding 1000000 DOM elements)
For the benchmarks, there is a distinction between the "baseline" (or most optimized imperative score) and "vanilla" (or what developers naively do often when using vanilla.)
It can be easily argued that benchmarks generally have no basis in real world instances - and this is very true! Generally, you should take benchmarks with a grain of salt, which is why I provided some points where optimizations were performed. In my opinion, providing benchmarks is better than making an unsubstantiated claim of "it's just fast," whether you take the benchmarks as 100% accurate for your use case or not.
Accessibility First DevRel. I focus on ensuring content created, events held and company assets are as accessible as possible, for as many people as possible.
Good point, well made! It just always feels a little disingenuous when in a graph form as it leads to the misnomer “the virtual DOM is faster” and that gets touted about all the time! 😜
Thanks! Yeah, this may be my fault, I tried to bring as much nuance into the article as possible to communicate that there is more to it, but it's often difficult to get readers to understand. Generally, readers will just skim over and get the big ideas, which is an issue and proliferates the misnomer you brought up. Context always matters!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Did you look at how they set up the tests?
Could be me misreading it but it seems like they deliberately made the vanilla JS test dumb so that it keeps overwriting the HTML (copy existing, add new item, then replace all the HTML with the new HTML) instead of adding to the HTML.
That isn’t how anyone would do things in the real world. (Or if they did they wouldn’t be adding 1000000 DOM elements)
For the benchmarks, there is a distinction between the "baseline" (or most optimized imperative score) and "vanilla" (or what developers naively do often when using vanilla.)
It can be easily argued that benchmarks generally have no basis in real world instances - and this is very true! Generally, you should take benchmarks with a grain of salt, which is why I provided some points where optimizations were performed. In my opinion, providing benchmarks is better than making an unsubstantiated claim of "it's just fast," whether you take the benchmarks as 100% accurate for your use case or not.
Good point, well made! It just always feels a little disingenuous when in a graph form as it leads to the misnomer “the virtual DOM is faster” and that gets touted about all the time! 😜
Thanks! Yeah, this may be my fault, I tried to bring as much nuance into the article as possible to communicate that there is more to it, but it's often difficult to get readers to understand. Generally, readers will just skim over and get the big ideas, which is an issue and proliferates the misnomer you brought up. Context always matters!