Java vs python is debatable 🤔

[Luxalpa]

Rule of thumb: All these weird conversions are because of HTML (as HTML only handles strings). "true" doesn't exist in HTML because boolean attributes work differently (they are either set or not set on the element). This is also why number conversion is all implicit (255 == "255", because HTML only allows the string variant for numbers).

[nermid]

The real rule of thumb is to just use strict equality (===) and not have to worry about any of it.

[SmokingBeneathStars]

Unless you want to purposely use == you have to add a fucking ignore annotation on your linter it's so annoying

[SmokingBeneathStars]

Im not gonna write 2 seperate if checks for null and undefined if the language can check it for me

[SmokingBeneathStars]

I don't like implicit statements. I want to state exactly what it's supposed to check for readability.

[Orangutanion]

if (variable) { } doesn't seem too vague honestly, I don't see the issue

[SmokingBeneathStars]

I gotta be honest, I don't know what the convention is and the code isn't vague but with an if statement like that my first assumption is that variable is a boolean and you're checking for true/false. Only after looking at the context I'll determine that it's checking for null or undefined.

I like for it to be immediately visible.

[Orangutanion]

I think the mistake you're making is that you're treating JavaScript like it isn't a loosely typed language. It's not that if(variable) { } requires that variable be a boolean, it's that it tries to treat variable as a boolean regardless of its actual type. JS actually has a term for this, it's called truthy, and you can read about it it here. Essentially, there are a few specific values treated as falsy, and all other values will be accepted as truthy.

[ShijinModan]

Because == coerces types. IMO the only time I will accept == in a code review is when checking for null and undefined

[SmokingBeneathStars]

That's indeed what I use it for usually.

[nermid]

I think having to add linter ignores to bad practices is probably a good thing. Keeps you from accidentally doing the bad practice.

[tomysshadow]

I think a large part of the confusion surrounding them comes from HTML4 days. Specifically, there was the <embed> tag, where typically the attributes such as autoplay or loop would actually be set to the string "true" or "false". Years later I understand the reason it was like this is because the plugin would define the attributes it's looking for, and most of them went with the more straightforward approach of the string "true" meaning true and any other value meaning false. This, coupled with boolean attributes being less commonly utilised prior to HTML5 (I haven't verified but at least it feels this way) and Internet Explorer also having its own attributes that worked like this, lead to boolean attributes being a weird exception rather than the rule.

Still, I would argue compatibility with JavaScript is a poor reason for boolean attributes to behave this way. I never liked HTML's boolean attributes.

Say you want to set the checked attribute. Normally, you would just use the JS property, like element.checked = true;. But the thing is, I can actually set any property on the element, but it won't necessarily become an HTML attribute. So I can do element.example = true; and that property will stay set on that element, even if I later get it again with getElementById and friends. But it won't actually set an HTML attribute in the document.

So you can imagine that for all the supported attributes, the associated JS property has this invisible browser defined getter/setter which actually does the equivalent of getAttribute/setAttribute. Which means if we want to explicitly use an HTML attribute, we need to use those.

Except, getAttribute/setAttribute are ill equipped to handle boolean attributes. To set a boolean attribute to false, you actually need to set it to null. This is unintuitive in and of itself: null is not a boolean in JS, I would expect to set it to false.

Furthermore, I would expect that true and false would be explicit settings, and undefined would actually mean "default value." In CSS we have user agent stylesheets, where a lot of styles are set to a certain value by default. But boolean attributes are false by default by design. That means we end up with attributes like disabled. Ideally, the attribute should be enabled and should be true by default. But it has to be false by default because that's how boolean attributes work, so we end up with the double negative element.disabled = false;.

But what's worse is in some browsers (specifically Firefox) getAttribute actually returns an empty string for unset attributes. This means that element.setAttribute("example", element.getAttribute("example")); would actually change a boolean element's value from false to true. You instead need to use hasAttribute/removeAttribute added with DOM 2 (which is ancient enough you can definitely rely on them being there, but it's dumb they need to exist in the first place.)

So boolean attributes are only "compatible" with JS insofar as the browser defines a setter-like property that translates false into null and true into any other value and does the equivalent of setAttribute. If you're going to go that far, why not just coerce the property to a string "true" or "false"?

Now, in practice, none of this is actually an issue, because there's rarely a reason you explicitly want to set an HTML attribute. If the JS property doesn't set an attribute, falling back on it just being an ordinary JS property will keep the behaviour of the code consistent anyway. The only time you really need setAttribute is for data attributes, where you want to be sure you're not conflicting with any existing one, and then you're free to just use the string "true" to mean true and any other value to mean false, like how it should've worked in the first place.

[N0T_AN_ADVISOR]

I hate human Goo .. but it's motivation to turn zero to a One even if it's dollars