[Phillippe]

"...isn't quite right — it would break _all_ your existing code that wasn't in .svelte files."

What if it is opt-out reactivity in .svelte files and opt-in reactivity in .ts/.js files? Yeah I know it would be a bit more combersome to copy code from .svelte to .js/.ts files but I think it would be worth it

[rich_harris]

That would be a _terrible_ outcome. Things would routinely break, and code would be vastly more confusing.

[Phillippe]

I love all the changes except that single thing with let count = $state(0);

I'm just brainstorming here, but what about an optional $reactive rune where everything in that is reactive by default?

$reactive(() => { let name = 'world'; });

vs

let name = $state('world');

[omnimus]

They mentioned that the team tried around 50 different variations. Meaning they spent a lot more time than a comment on this. I would trust they know what they are doing considering track record of Svelte team.

Tbh this seems kinda rude. Maybe check github i am sure the whole journey can be seen there.

[Phillippe]

I don't mean to be rude, I'm just brainstorming. I'm sure they have thought about it I'm just commenting in the small chance that they haven't

[Phillippe]

Maybe reuse the $:{} here, tho that would probably be really confusing for svelte 4 developers lol

$:{ let name = 'world'; };

vs

let name = $state('world');

$: is valid javascript right? So that should also work in .js/.ts files I assume

[codelikeawolf]

I think the reason they didn't opt for this approach is that putting stuff in a {} block creates its own scope, so any variables declared within that block are inaccessible from outside said scope.

The $: label syntax is valid JavaScript, but allowing scoped variables to be accessible outside of scope is very invalid JavaScript.