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 from ancient Greece https://en.wikipedia.org/wiki/Dialectical_materialism

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 create private properties through a WeakMap object which is somewhat clumsy and not very performant.

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 with the flatMap and flatten array methods used by an old version of the Mootools library. I.e. do not break the web.

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 core principle of data encapsulation in OOP ensures your system will be manageable as it grows. This principle breaks down the complexity into manageable units of self managed simpler pieces of subprograms that are more easily to reason about. And as history has shown this approach did provide capability to programmers to build more complex and manageable systems.

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 with the arrow function "this" points to the context (i.e. "this") of its lexical environment.

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 that an already existing symbol e.g. Symbol('hello') is not the same as Symbol.for('hello') while Symbol.for('hello') === Symbol.for('hello')

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 for the natively JIT optimized JS path.

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 necessary.

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.

setTimeout(function(){alert(this.a)}.bind(this));

becomes simply

setTimeout(() => alert(this.a));

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 "use strict" might introduce some subtle bugs for that case.

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

How about converting this viewer through Emscripten using asm.js. Would be interesting to see performance comparison with pdf.js :)

You need:

['10', '10', '10'].map(Number);

Well, PS4 has 3.5GB allocated for system memory. Plenty for running lots of things in the background.

Node.js is the keyword here, not the web.

The "this" value in functions is not lexically scoped. It is determined during function invocation, not during function declaration.