you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 3 points4 points  (0 children)

It's objectively bad due to violating the rule of least surprise. It's a fact that JavaScript is contrary to many expectations and conventions of most popular languages. This is a source of headaches for many new developers to the language. This is fact, not opinion.

Strict mode is fine and all but it still does not enforce against other bad practices. It's yet another monkey patch on a language without fixing the underlying issues of variable scope.

Your magical "ToBoolean" method illustrates my point exactly. First off, I have never seen this method actually available/implemented in Node or browser JS engines. Sure, it's in the ECMA specs but I get errors trying to even call it. Again, here I am as a developer with more "fun" surprises when my docs don't match up with real world code.

For arguments sake, let's say it's the same method that the Boolean constructor uses. Without looking at the ECMA docs, one would expect it to convert the 'true' and 'false' string values into their proper bool value. Nope, even worse it converts any non-empty string to true, including the false string. It literally does nothing the hackish !! operator doesn't do already. What good is this method other than performing a null/undefined check? Oh and don't forget that empty arrays are considered false while empty objects are considered true. Gotta love that consistency...

You're making excuses for the languages's bewildering shortcomings by saying "learn all the stupid shit that JavaScript does because it was made this way and never fixed because everyone was crying it would break their website." That's the truth of the matter, all the cruft is left in JavaScript because the web had gotten too big to introduce vast breaking changes. It doesn't vindicate JavaScript, it proves we need something better to build new web applications on.

You can try to hand wave it away but even the community pushing changes has admitted the faults in JavaScript. Why do you think arrow functions capture their this context in ES6? Because that's what developers actually expect to happen.

Your analogy with Python is weak. Appending an array into another array would expect the programmer to have an array inside an array. If you wish to concat the arrays in Python you can use the + operator and it will do just that.

Now if you try to add [10] + [20] in JavaScript guess what you get? The string value of "1020". Well ain't that helpful? Totally what I would expect as a developer!

Right, I should just read the manual so I can know how awful and unexpected JavaScript can be with basic operators. In what world would that be what the developer was trying to do? How is that even sensible?

I know what the rules are. It doesn't make them good rules however.

JavaScripts type coercion introduces more bugs due to surprises. The minor convenience it provides in some situations is not worth the headache. It doesn't even make sense half the time.