[bryanrasmussen]

I don't know that I buy the would break existing code - sure the language would change but do we actually have stats of uses where we can see people did.. what would they have done?

if (typeof varname === "object" && !varname) { loggingNull("varname"); }

it seems far fetched and maybe those people's code should break.

I guess it doesn't really affect me though.

[jraph]

If my programming language changed something so fundamental, I would lose all trust in it even if I don't rely on this particular quirk.

PL design is complicated and you pretty much have to keep this kind of quirks forever or at least for a very long time if you want to avoid a painful transition, which can lead to the old language version hanging out forever in the wild because a lot of code is already written in it. You can deprecate the features the quirks affect and introduce new ones to replace them that do not have the quirks, but now you need to support both ways for a very long time until the ecosystem is ready, which may never happen.

there's nothing wrong with:

    switch (typeof v) {
       ...
       case ...:
          ...
          break;
       case "undefined":
          // handle undefined;
          break;
       case "object":
          if (!v) {
              // handle null;
          } else if (v instanceof 'Array') {
             // handle array;
          } else if (...) {
              ...
          } else {
             // handle anything else
          }
          break;
    }

that's within spec and an alternative could be more verbose / more difficult to navigate (it's a matter of taste). If you need to handle undefined and null differently, you need to test for it and typeof === "object" is one way. I would probably do it differently, but I can see someone thinking differently and we can't blame them.

[aflag]

"doesn't really affect me" until you find out one of the libraries you use is affected by it and you find yourself scrambling to fix it in production as new users update their browsers

[bryanrasmussen]

I find, via experiences on HN, that language is a vague and irritating source of misunderstandings, but I thought it was clear that doesn't really affect me was because I was not going to use typeof in this way ever, thus I did not really care if it got 'fixed' or not.

[shadowgovt]

The point is you don't have to.

If you rely on any frameworks or libraries whatsoever, you can't assume they aren't using null in this way and would break if the language spec changed. The only common ground you and those developers have is the language specification's rules.

(If you actually do roll all your JS by hand in house, congratulations and I'm impressed, but (a) that's a minority position in any house that has to do professional JavaScript and (b) oh wow you're reinventing a lot of wheels).

[chrismorgan]

It’s waaaaaaay more common than you think. As a simple example, with React, the presence of a component with null state (which I imagine to be an extremely common combination) would break your entire site.