On: JavaScript Equality Minesweeper

[ryanong]

"So yeah, in practice the confusing rules of JS equality comparison don't really matter all that much."

I run into this all the time. Plenty of junior devs I work with do this. Unfortunately we haven't implemented typescript yet. Yea === solves this problem but I wish there was a deprecation path for ==. Why can't we figure out as a community how to deprecate horrible javascript apis? Why can't we as a community figure out how to have a good standard library?

[haburka → ryanong]

The deprecation path for bad apis is to use eslint. If you make it so you can’t merge without eslint passing then you have effectively deprecated syntax.

[spion → ryanong]

The anemic JS standard library is a much bigger problem, resulting with bloated bundles with all sorts of basic stuff in them (lodash, timezones, etc). Even worse, the fact that things aren't standard means that multiple "standard" library replacements might be used, depending on the preference of the developers who wrote the library you depend on (ramda? lodash? individual lodash subpackages? etc). Small modules don't solve the problem, because you can still have 5 small modules with a slightly different API doing the same thing, all of them used by different libraries you depend on due to different preferences of their authors.

IMO TypeScript fits like a glove on top of JS and largely gets rid of the language problems, leaving mainly library / ecosystem problems.

Dart did many things wrong, but one thing it did do right was the standard library. If we had a standard library like that in JS, that would change everything.

Another serious problem are modules. The fact that the ES6 loader is "open ended" just means that we don't really have a solution to the problem of distributing JS. The fact that HTTP2 push is somewhat broken means we can't rely on it to load ES6 modules either.

At the very least we need the concept of absolute and relative module identifiers. Even if the specifics are implementation-defined, e.g.

* whether module ids are used,

* or content hashes,

* or absolute paths (or maybe npm module names with the version?)

the ability to provide absolute modules via a DLL:

  provides 'lodash@2.0.5' {
    export ... // multiple things
  }

  provides 'other-module@version' {
  }

would be of incredible help.

That, or maybe we can fix HTTP2 push.

I mean, JS definitely has serious problems, but equality coercion is not one of them :)