How to measure DOM performance in Chrome DevTools?

Question

JavaScript

Hello, it’s the end of 2016, new standards and features are being sawed with might and main in JS, and many people still haven’t learned how to write a normal front-end. In fact, many people still use jQuery, and this is not a bad thing, it all depends on where we spend more time: deploying a front-end environment or writing a simple slider on a freelance exchange for a customer on pure JS or jQuery without any Gulp /Webpack/MV* stray goodies (since 2009). However, in complex projects, even if we now write our application in ElectronJS, we cannot do without a virtual DOM or other technology under the hood of some library or framework that independently manipulates the DOM in accordance with the data model. However, I do not understand one thing, different tests show different results, some framework works well with that, some just know how to quickly update the DOM, but do something else wrong. And here, as it were, the question arises, is there a problem in the framework, or did I just write the code incorrectly, because of which the framework does not work correctly? After all, we still understand that additional libs and frameworks also work with the DOM, it's just that it's all automated on timers, listeners, and other signal-slots.
Therefore, I'm wondering how to measure the DOM in my project and understand where just the browser goes wrong, where the framework is, and where specifically I am. Tell me something about this topic?
Why I said about the browser, because it’s easy to notice when you start reading the history of your messages in VK, when you open more and more old messages, they are also loaded into the DOM and everything starts to lag, and you don’t understand that the browser stack overflows and recalculations become long. But damn it, when we open the native Excel desktop application, we can easily scroll 64,000 lines there and nothing will slow down, the fault is in the browser and the DOM, or is it that JS is just so single-threaded and forever interpreted!?

Answer 1

Excel implements the so-called "virtual scroll", the essence of which is that it does not render all 64,000 rows, but only those that are currently visible. When the scroll position is changed, hidden rows are removed, and the resources freed from them can be reused to create new rows. On the web, this technique can also be applied, gaining independence of responsiveness from the position of the scroll. For example: eigenmethod.github.io/mol/#demo=mol_grider_demo
Unfortunately, this technique has limitations due to which it cannot be built into the framework - line heights must be fixed in order to understand which lines are visible at a certain scroll position. So if the number of elements in the DOM is constantly growing, then you need something in the algorithm of your application.
However, there are some poorly written frameworks that are basically slow and the only way to write a fast application on them is to access the framework functions as little as possible. The difference can be several tens of times: eigenmethod.github.io/mol/app/bench/#sample=sapui5~mol