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 js-framework-benchmark repository, and I don't regret it, because there is a super interesting observation that I recently noticed.

Basically, all framework and library developers faced the issue of speed in the early stages of web development. This is the main thing, because the faster people see data changes on the UI, the less time they spend. Imagine if sites worked 10% faster, then billions of people could save a lot of years of life.

Something had to be done, so, and maybe for other reasons, many repositories with benchmarks of modern frameworks and libraries were created. One of such repositories is js-framework-benchmark. It contains almost all popular frameworks and libraries for creating UI.

The main task is to draw a table that depends on the data. It would seem like a simple task, but in fact, it is very, very indicative, because it draws attention to the main thing that the application can look like anything, but the components, their sequence in the DOM, work with the browser and other things - imitate the behavior of a regular site. Because a line in a table, a header on a page - it's all in general, just one component of the general.

Since the application is working normally with code and time as a dependency (we don't take into account the display, colors, because it can be said 0 and 1 on the wire, so there are only 2 such dependencies), then at least 1 component, at least a million of differently intertwined ones - there is no particular meaning, because everything rests on one engine. Therefore, simplicity here even suits, because it is clarity.

So, we have a task, but we need to solve it somehow. Programming is good because we can solve one mathematical problem in a million different ways, but we come to the main thing, the basic ideal algorithm is the same for everyone. This is a theorem, and what and how is implemented is a matter of taste and the need for convenience.

Let's take the interface now, what does it look like:

Test app:

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.

The above is the detailed content of js-framework-benchmark - variations of the ideal solution to the mathematical problem of speed or why it is standard. For more information, please follow other related articles on the PHP Chinese website!