Thread:Talk:JavaScript performance/lorem == null/reply (2)

You're comparing something using an equality tester with an explicitly named value but relying on loose type checks to really compare it to two different values. It's a bad form that results in code that can be hard to follow.

Frankly if higher level code is passing null in situations where you would want to `== null` to treat them the same there is something fundamentally flawed with the code. There are only two valid cases to use null. A) When working with low level dom that uses it rather than undefined. B) When writing code where the difference between undefined as 'not set' and null as 'something that means nothing' is important and needs to be distinguished. And in that case you aren't testing for both. And if you do find yourself in a small part of the code where you do want to do the same thing for null or undefined in that case if you use `== null` you place it near other `=== null` that actually require only null and make the code harder to follow.

jQuery has different priorities. jQuery deals with low level dom which in various ways is flawed and buggy and inconsistent between browsers, so they do need to catch that. jQuery's source is also not a good example for code style practices, jQuery is optimised for short concise code, not code readability. Forget our practice of requiring {}'s around an if even if it only does one thing, jQuery uses the ternary operator over 5 lines (two comments) in a way that would end with someone kicking you if you tried that anywhere in MediaWiki.

To top it off I might want to make a reminder of one of JS' oldest mistakes `typeof null === 'object'`. Sure ES-harmony is finally trying to get rid of it, but that's not really relevant since that's a harmony opt-in and we're still working with browsers that only do ES3, not even half implemented ES5.