Forem: antonmak1

[Boost]

antonmak1 — Tue, 06 May 2025 21:19:01 +0000

Anthony Max

May 6 '25

The concept of a temporary View state in JavaScript

#webdev #javascript #programming #opensource

Comments 5

5 min read

How the new concepts of JSSugar and JS0 are able to slow down websites

antonmak1 — Thu, 19 Dec 2024 19:02:42 +0000

Hello everyone! Today, I would like to share my thoughts on the topic of the much talked about JS0 and JSSugar. In my opinion, there is a certain danger in this, which is hidden potentially for billions of website users. Now I will try to explain what I mean.

You may not like my point of view, please, there are comments on dev.to, I will try to answer everything.

Description of JS0 concept and JSSugar in my understanding

Perhaps I misunderstood something or made a mistake somewhere, but I will explain as best I can.

In short, today in javascript instead of expanding the functionality with more and more functions we need to focus on making it more acceptable for the user. Like, today all developers write code that goes through typescript, webpack and a bunch of other layers, so why not apply this logic of simplification, when the developer writes less code, in future versions of ecmascript. Like, set such a vision as a standard, that we need to create functions (forEach for example) just like lodash or jQuery, and not expand, because it is already complicated.

Like, there is JS0, it will be for this environment where everything is compiled, and let ordinary developers use forEach instead of for, conditionally.

So, now here is where the serious problem with this approach arises. It seems to be written that "not for the sake of speed", but in fact, everyone who has ever compared the speed of JavaScript code in benchmarks understands what I'm getting at.

Slow implementation for micro-optimization of code quantity

Yes, now it's time to move on to practice:

Code #1

const a = [1,2,3,4,5]
a.forEach((e)=>{
  if(e === 4){
    console.log(e)
  }
})

Code #2

const a = [1,2,3,4,5]
for (let index = 0; index < a.length; index++) {
  const e = a[index];
  if(e === 4){
    console.log(e)
  }
}

Result:

Let's now take another example:

Code #1

const a = [1,2,3,4,5];
const b =  a.map((e)=>{
  return e + 1;
})

Code #2

const a = [1,2,3,4,5]
const b = [];
for (let index = 0; index < a.length; index++) {
  const e = a[index];
  b.push(e + 1)
}

Result:

Results are based on data from the site https://jsbenchmark.com.

So, what I'm getting at is, if we imagine that from TC39 (Technical Committee) and the developer community in general, the main vector of suggesting ideas will move in such a direction, when we create lodash and jQuery functions, and this will become a standard in ECMAScript, then there will be functions like forEach, which do not change the speed, but in fact slow down the application. This is, of course, worth thinking about.

Here, even in the official slide (the bird flew away) it is shown where the vector should shift and this is true, convenience for users.

And it is convenient for users to use a fast site, and not lagging slop, but for developers "more expressive".

Therefore, I would like it if when this suddenly becomes a standard, such functions were not at the forefront. SOLID, DRY and other principles already slow down modern applications, and now they are making it a standard.

Impact of js-framework-benchmark

This article was inspired, of course, by my experience working with the js-framework-benchmark repository, which, in my opinion, very clearly shows why speed is important today. In fact, people want websites to load faster - that's a fact. Today, most modern popular frameworks and libraries are slow in fact. It may even seem to someone that speed is crap, but it is not. If you put everything together, then with such "optimizations" web applications will work several times worse. Therefore, I think that something like this.

Conclusion

It's cool that ideas like these are coming out today. They move JavaScript and all web programming forward, but there are objective things like speed that shouldn't be written off either.

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

antonmak1 — Thu, 07 Nov 2024 23:33:51 +0000

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.

.

antonmak1 — Thu, 17 Oct 2024 09:03:36 +0000

The concept of a temporary View state in JavaScript

antonmak1 — Fri, 20 Sep 2024 17:10:04 +0000

Greetings to all! In this article, we will talk about a rather unusual topic, information about which for some reason I did not find, although it is quite useful in modern JavaScript frameworks and libraries for creating user interfaces, because, in some cases, applying the concept can help speed up work with the DOM several times.

The name is conditional, but the essence is important.

The problem of the usual state

The term "usual state" refers to data that is saved directly due to the state managers, or due to the internal functionality of the framework or library. An example of the state in Vue.js:



createApp({
  setup() {
    return {
      count:ref(0);
    };
  },
  template: `<div>
        <button @click="count++">Click!</button>
        <div>Clicks: {{ count }}</div>
    </div>`,
}).mount("#app");

In this case, the state is stored directly in the object, which is returned in a predefined method of the framework.

So, DOM nodes can depend on a given state through different syntactic constructions. In the example, such a construction is the string {{ clicks }} , which changes to the current data due to string interpolation.

Also, a commonly used syntactic construct is "loop". A loop is a keyword, either an attribute, or a method that explicitly defines that the creation of DOM nodes will occur, depending on the number of elements and on the values themselves, coming from the state. Example of a loop:



<template>
  <tr
    v-for="{ id, label } of rows"
    :key="id"
    :class="{ danger: id === selected }"
    :data-label="label"
    v-memo="[label, id === selected]"
  >
    <td class="col-md-1">{{ id }}</td>
    <td class="col-md-4">
      <a @click="select(id)">{{ label }}</a>
    </td>
    <td class="col-md-1">
      <a @click="remove(id)">
        <span class="glyphicon glyphicon-remove" aria-hidden="true"></span>
      </a>
    </td>
    <td class="col-md-6"></td>
  </tr>
</template>

Let's say we want to update the class of an element. Our data comes in the form of an array of objects. It is clear that the key must be explicitly specified in the object:You can get the value of the class in double curly brackets by the key, but that's the main problem, because it's slow.

To confirm my words, I will take the benchmarks of the cample.js framework (during the development of which I just noticed a similar problem). It is clearly visible there that a class that depends directly on the data of the normal state is set slower than a class that uses a temporary View state.

Let's take two versions of cample.js: 3.2.0-alpha.45 and 3.2.1-beta.0. There is such a line as “select row” (4 lines), which is exactly the main difference:

The data is taken from 126 and 128 benchmark releases.

As you can see from the image, the difference between one result and the other is almost one and a half times. I've been thinking for a long time about why this is so? I used to assume that the code was just slow, but the fact is different. If the data goes through a regular state, then it becomes necessary to go through all the data, even if we only change one letter in the value of the property in an n-ordinal object.



const oldData = [
  {
    id: 1,
    label: "Text 1",
  },
  { id: 2, label: "Text 2" },
  {
    id: 3,
    label: "Text 3",
  }
];

const newData = [
  {
    id: 1, 
    label: "Text 11", // 1 iteration, one letter has changed, but we're still looking further
  },
  { id: 2, label: "Text 2" }, // 2 iteration
  {
    id: 3,
    label: "Text 3", // 3 iteration
  }
];

Therefore, it will always be slow, but this is the logically correct approach and this is the main joke of all modern frameworks and libraries for creating user interfaces. But what alternative can there be to this approach?

Temporary View state

Especially for such a problem, when it is necessary to introduce a separate state from the main one, so as not to go through the elements several times, you can use a certain concept in the code that will allow you to bind not to an object, but to an element. This concept is a temporary View state.

Its essence is as follows: We create a separate array for each element. It will be located in the code of the module itself, and we give the user methods that interact with this array in the callback function. Thus, the module will store approximately the following code:



{
  el:li,
  temporaryViewState:[{class:"value"}]
}

And in the project something like this:



setClass: [
  (setData, event, eachTemporaryViewState) => () => {
    const { setTemporaryViewState, clearTemporaryViewState } = eachTemporaryViewState;
    clearTemporaryViewState();
    setTemporaryViewState(() => {
      return { class: "value" };
    });
  },
  "updateClass",
],

Also, this array can be created only when the callback function is called, or simply create one array for all elements. This will allow us not to bind to the data that comes from the normal state, but to bind to a specific element that we want to update. That is, we create a temporary state that can be cleared and rewritten. This is well suited for those cases when we want to work with uncontrolled elements:



<!-- Controlled -->
<input type="text" value="{{ value }}" ::change="setValue()" />

<!-- Uncontrolled -->
<input type="text" class="{{ temporaryViewState.class }}" />

That is, it simply does not depend on the usual state directly, so in the DOM, this node can be said to be static (if we make a node template, then this element will skip).

Thus, we have a state that depends only on a specific element and on the callback function. When working with the "loop", you do not have to go through the entire data array to update one letter in one element. It will be enough just to call a specific function for a specific element and update a specific class.

This will allow you to achieve quick results in working with data and DOM. It is quite possible to apply this concept in modern frameworks and libraries and work with it.

.

antonmak1 — Sun, 11 Aug 2024 11:54:10 +0000

.

antonmak1 — Fri, 09 Aug 2024 09:06:53 +0000

.

antonmak1 — Mon, 22 Jul 2024 10:29:16 +0000

.

antonmak1 — Tue, 18 Jun 2024 10:01:58 +0000

.

antonmak1 — Sun, 09 Jun 2024 20:41:02 +0000

.

antonmak1 — Sun, 09 Jun 2024 20:12:21 +0000

.

antonmak1 — Mon, 03 Jun 2024 18:55:36 +0000