Viewing profile — v413

This is the second "law" of the dialectical materialism by Engels: "The law of the passage of quantitative changes into qualitative changes" According to Wikipedia it has its roots…

Yep, looks like they are the same.

Well here it stops lol https://www.youtube.com/watch?v=Fu4ZEnIwYZI

Bun is using the JavaScriptCore engine which is the Webkit/Safari Javascript engine. It is not written in Zig.

This is not efficient. Each iteration creates a new array instance due to the spread operator.

React is slow for the perf targets of VSCode.

The # symbol denoting private fields has already been finalized and approved to be a legal part of the language. No going back.

Object properties defined as Symbols (even through classes) are still accessible by e.g. Object.getOwnPropertyDescriptors(myObject) Before the private fields, it was possible to cr…

It is already implemented in the current Firefox, Chrome and Safari 12.

Some TC39 members proposed this. It is in no way even discussed or decided by the TC39 committee yet. The fancy naming is proposed by some as a solution to prevent name collisions …

The premise of the article that the more objects that mutate state locally are used the more complex and more difficult it is to reason about the system becomes is not true. The co…

As an event listener "function(e) {this}" is not the same as "(e) => this". With the regular function "this" points to the element on which the event listener was attached to while…

why not just use acc[prop] = value ?

There are global symbols. You use Symbol.for() to either create or retrieve them. E.g. Symbol.for('hello') is available globally through the global registry. It should be noted tha…

Typescript is designed to be compiled to JS. WASM is designed for staticly compiled languages. Even if there is GC and DOM access through WASM, Typescript will be better off to run…

JS will not compile to WASM.

Or maybe even include the wasm codec/player along with the video. Then it doesn't matter what the platform supports as long as it can run wasm.

Prior to ES5 undefined was overwritable that is why void 0 guaranteed to produce undefined. With ES5 and later using undefined directly is safe.

Feature detection is not always enough. E.g. if a browser reports it has a required feature but that feature is buggy rendering it effectively unusable, then browser detection is n…

It is not precisely clear decorators will make it into ES2016 yet (maybe ES2017?). That is why it is better to say ES Next or something like that.

With the introduction of arrow function you won't need to use .bind(this) as arrow functions capture in their lexical scope the variables/keywords: this, arguments, super. e.g. set…

All code in modules is in the context of "use strict" by default so it won't be necessary to use this pragma explicitly.

Chrome 39 on Windows 7, when scrolling the text gets blurry. On Chrome 41 Canary though things work well and fast.

Looking at the compiled source, it looks like ES5 and not ES3. They use "use strict" and Object.defineProperties which are ES5 features. P.S. IE9 doesn't support ES5 strict mode so…

JS SIMD will support the ARM Neon instructions. Here is the spec http://esdiscuss.org/notes/2014-07/simd-128-tc39.pdf