js-framework-benchmark - variations of the ideal solution to the mathematical problem of speed or why it is standard

Hey everyone! I spent 2.5 years solving the speed problem in the

Some of the results:

https://krausest.github.io/js-framework-benchmark/2024/table_chrome_130.0.6723.58.html

We have results for different key actions with the table that can occur when the state changes. We can measure the speed of work and compare which code works faster and which slower. This is very convenient, because it creates a level playing field for all frameworks and libraries. But it would be fine if only the speed were the problem, but the standard of the structure itself is also set, because it must be correct. The component approach, key implementation, state and other terms are included in all this. Without such a standard, this is simply not a working topic.

So, the standard has long been set by the creators of frameworks and libraries - it is obvious and understandable to those who do it. The question is that now we need to somehow adapt all this for fast work, so that the UI is quickly rendered.

So, a cool idea to gather all the creators of "large" and not so large frameworks and libraries, and just enthusiasts who also want to try their hand. All this is important, because, like in sports, we have a community, and there is a board of "leaders" where different solutions to problems are published. This is not a very good comparison in terms of programming, because it is just mathematics, but the idea itself is interesting, because it pushes people to do beautifully and quickly and, most importantly, it is correctly.

Well, such a community has generated many cool solutions in recent years that can be used today by all current and future creators. You don't have to reinvent the wheel, because the basic algorithm is already written. This understanding can save a lot of years.

Many developers have already written examples of implementing ideal code, it is quite easy to base it on this, so the best thing is that this did not happen before and it happened, among other things, because of this repository. No matter what anyone says, it is cool.

If we consider the ideal algorithm by components, we can highlight - the algorithm of the key implementation (using Longest increasing subsequence or another variation of it), template cloning, reactivity directly (textContent, addEventListener, classList.add), or using the useless VDOM today, although in terms of templates it is necessary, as well as working with the state and import between components, the last 2 are debatable. But this is the basis, nothing else can be invented here.

This article will not contain any code as such, because there is a lot of it in the benchmark repositories.

Anyway, I hope people will soon understand that today we already have the ideal code for displaying data, it is just worth taking it into account and doing something new based on it, without reinventing the wheel. Many libraries and frameworks today can work much faster and much more efficiently, it is just that legacy code does not allow this, because there can be a lot of work and it is not a fact that it is generally possible without redoing everything.