5 ms·

The code examples page is a thing of beauty and simplicity, bravo! https://svelte.dev/examples#hello-world https://svelte.dev/examples#hello-world

karolkozub 6y ago
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. [0]: https://svelte.dev/tutorial https://svelte.dev/tutorial
iudqnolq 6y ago
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?
nonameiguess 6y ago
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?
- mping 6y ago
  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).
  - nonameiguess 6y ago
    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.
- marcus_cemes 6y 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. Unsafe equality: "1" == 1 is true (string and float, https://dev.to/mkrl/javascript-quirks-in-one-image-from-the-internet-52m7 https://dev.to/mkrl/javascript-quirks-in-one-image-from-the-...). 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.

karolkozub 6y ago

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. [0]: https://svelte.dev/tutorial https://svelte.dev/tutorial

iudqnolq 6y ago

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?

nonameiguess 6y ago

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?

mping 6y ago
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).
- nonameiguess 6y ago
  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.
marcus_cemes 6y 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. Unsafe equality: "1" == 1 is true (string and float, https://dev.to/mkrl/javascript-quirks-in-one-image-from-the-internet-52m7 https://dev.to/mkrl/javascript-quirks-in-one-image-from-the-...). 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.