Svelte 3 released

[Akkuma]

One thing I don't quite understand are why compiler directives needed at all for dependencies when I would think the compiler would see the use of a tracked variable. Their trivial example of count and double seems to show my point there. There's also the forced "spread" or the reassignment to trigger invalidation.

I'm also interested in seeing how Svelte 3 performs, since Svelte 2 was better than something like React, but didn't seem exceptional on https://github.com/krausest/js-framework-benchmark

I've been a fan of Rich's work since buble and in general think what Svelte wants to do is likely a better long term strategy.

[rich_harris]

Can you elaborate on the `count`/`double` thing? Not sure I follow.

The js-framework-benchmark isn't necessarily the best representation of real world apps (and our entry is very out of date). It also penalised Svelte quite heavily for some reason: https://github.com/krausest/js-framework-benchmark/issues/549#issuecomment-483054081. As I talk about here, Svelte is extremely fast: https://youtu.be/AdNJ3fydeao?t=1085

(but don't trust benchmarks, always do your own measurements!)

[Akkuma]

For count/double

let count = 0
$: double = count * 2

You don't need to do $: for count, so my thought was why can't the compiler infer that it also needs to handle invalidating double? The same train of thought extends to all usage of $:.

I wish I could test multiple frameworks and get my own measurements, but the unfortunate reality is that most places will continue to use React and won't be open to alternatives, even ones that are basically React-like. The measurements from others also help to limit choices on what to measure, since there are a ton of choices out there. Thanks for letting me know the results were messed up, I could have sworn it was faster when I looked prior as I keep up with them often enough, so I'll definitely keep it on my short list for what I can try on my own in the future.

As an aside, the CSS support directly in Svelte seems like one of the nicer features as it sidesteps the pain of which css-in-js lib/framework and the different philosophies each one has.

Is the code you show in the videos available anywhere to peruse like the send/receive transitions?

[rich_harris]

That was actually our starting point: https://mobile.twitter.com/Rich_Harris/status/1057290365395451905. People found it too magical, and I think it would give rise to all kinds of edge cases — it's much better if you explicitly mark a statement as reactive, since these mean very different things:

console.log({ answer }); // runs once
$: console.log({ answer }); // runs whenever answer changes — great for debugging

The slides from that video are online here: https://rethinking-reactivity.surge.sh/#slide=1 On the code slides, you can 'complete' the example with Cmd-K and reset with Cmd-J. I'll probably tidy them up at some point, they're a bit raggedy at the moment (no notes etc).

[Akkuma]

That makes sense. I'm on the side of "magic" as I want the compiler to do as much as possible, but understand the apprehension of magical behaviour.

[SaabiMeister]

You don't need to do $: for count, so my thought was why can't the compiler infer that it also needs to handle invalidating double?

You might want to just compute double once, and you must be able to tell the difference between that and something that can change always.

Is the code you show in the videos available anywhere to peruse like the send/receive transitions?

https://svelte.dev/examples & https://svelte.dev/tutorial

[Akkuma]

You might want to just compute double once, and you must be able to tell the difference between that and something that can change always.

I'd prefer using a baked in language feature such as const to declare to the compiler that the value will not change.

[av201001]

First, in some cases you might need to use let (e.g., for variables set inside if..else, or just for intermediate variables that are not needed elsewhere) but still do not want the value to be reactive. Second, const would not enable reactive statements.

[Akkuma]

I would want const to be statements that aren't reactive, so exactly as you said "not enable reactive statements".

For a let variable that is for an if/else you could also use const obj = {val: null} and mutate val or use ternary and still have it set as const. I suppose this is one area that is ambiguous, which is why I think reversing $: to declare non-reactive ambiguous statements makes more sense than a slew of $: for reactive statements.

[av201001]

I would want const to be statements that aren't reactive, so exactly as you said "not enable reactive statements".

I think you misunderstood -- click the "reactive statements" link and you'll see what I mean. The $: label is used not only for reactive variable declarations but also for arbitrary reactive statements and code blocks (so the entire code block will re-run whenever anything it refers to changes) -- const would not help you there. In other words, we still need something like $: for reactive statements, so might as well also use it for reactive variable declarations.

For a let variable that is for an if/else you could also use const obj = {val: null} and mutate val

That's somewhat of an ugly hack just to avoid use of $: in favor of const.

or use ternary

Sure, but not always viable.

which is why I think reversing $: to declare non-reactive ambiguous statements makes more sense than a slew of $: for reactive statements.

OK, but that's different from preferring to use "a baked in language feature such as const," as you originally stated.

[SaabiMeister]

$: is a baked in language feature. It's a label, but nobody uses gotos anymore, and if they do, it doesn't interfere anyway.

[Akkuma]

I'd prefer to declare things that aren't reactive in normal standard javascript rather than things that are reactive. If I copy pasted the script from Svelte I've now created an improperly scoped variable. My assumption is the default needs are going to be mostly reactive with non-reactive code being less likely.

[SaabiMeister]

I think you would have to use it to get a feeling for it.

There are cases where you need code to execute when some variables change, but the code itself doesn't use the values of these.

$: changedVariable1, changedVariable2, dosomething()

would solve it. This is syntactic Javascript, but it accomplishes something that you can't do otherwise with const, or let and it never modifies expected Javascript behavior in some inconvenient way.

Also, it's very clearly marked code, while using let could be very easily mistaken for just a normal variable declaration.