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

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.