There's also a tutorial [0] which goes through these examples one by one explaining in detail how each concept works. I highly recommend it to anyone interested in learning this framework.
I don't understand why the second example caches the src, checks if the current src matches the cached src, and if not sets both the src and the alt. Does the complier fully check the codebase to ensure they are always set together?
This makes me very glad I have never worked in JavaScript. Why does hello world compile to something with three explicit no-ops and what the heck is safe_not_equals? I had to wonder what an unsafe way to determine equality is and looked this and found this is apparently the code?
export function safe_not_equal(a, b) {
return a != a ? b == b : a !== b
|| ((a && typeof a === 'object') || typeof a === 'function');
}
Why is it possible for a != a to not always be false and b == b to not always be true? How did Javascript defeat the most immutable rule of basic logic discovered by Aristotle 2000 years ago?
Javascript does a lot of implcit conversions, it was badly designed and has dynamic types which means a lot of runtime checks, these quirks can't be removed with breaking a lot of legacy code.
Yet, like with C, you learn the different ways you can shoot yourself in the foot over time and avoid them. In 10 years I've never written a safe_not_equals function, although explicit object/null checks are a thing, but it wouldn't surprise me if libraries used by millions that may end up in Internet Explorer go that extra step. Each language has it's particular use-case, JS happens to be the language of web development.
Although I agree with you in principle, in practice most of js devs never worry about such things. It's mostly library authors and such.
And there are cases where a != a, I think for NaN (not a number).
Fair enough. It makes sense for NaN, but languages like Rust and the various ML variants solve that by defining floating point numbers to not be a type where equality is a valid binary operation.