4 ms·
The problem with this and the wat talk is that * you don't actually see the case-space (value space) of all the comparisons that do work as expected, and * yo
by spion 8y ago
The problem with this and the wat talk is that
* you don't actually see the case-space (value space) of all the comparisons that do work as expected, and
* you don't a sense of what is the likelihood that these sort of comparisons would happen in real world code
Some of them like the empty string are likely to happen from user input, but Typescript mitigates those by forcing you to e.g. use Number(inputField.value) to conver to number and complaining about the assignment otherwise.
Others pretty much never ever happen - instead of comparing 1 or -1 to true, you're more likely to use if (val) which casts to boolean, and the truthy table is different from the equality comparison table (it makes a bit more sense)
Most of the real world comparisons are to non-empty strings or numbers, and those are only equal to arrays in some cases - but its rare for an actual array to be produced by anything. Things you know are arrays already you don't compare using "==" to begin with.
So yeah, in practice the confusing rules of JS equality comparison don't really matter all that much.
- ryanong 8y ago"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?
- spion 8y agoThe 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 :)
- haburka 8y agoThe 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.