[rich_harris]

We evaluated somewhere close to 50 different design ideas (seriously) before settling on this one, and what you describe was one of those ideas.

But one of our goals was for you to be able to use Svelte's reactivity inside .js/.ts files, since that's one of the things people have been crying out for since we released Svelte 3. For that to work, reactivity has to be opt-in, not opt-out.

And that's how it _should_ be — someone reading the code should be clued into the fact that this `let` won't behave like a normal `let` in JavaScript, and it should be possible to move code between modules (and between modules and components) without worrying about whether a specific file was opted in to certain behaviour.

In other words this...

> This way, the change wouldn't break existing code

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

> If I'm not mistaken, the compiler allows Svelte to define its syntax to anything they want.

On this point specifically: unfortunately not. The code in a .ts file, for example, has to be valid and typecheckable. You can't insert a preprocessing step ahead of the TypeScript compiler. Again though we concluded that this is a good thing, since it means this all works with all existing ecosystem tooling.

[aradalvand]

> for you to be able to use Svelte's reactivity inside .js/.ts files, since that's one of the things people have been crying out for since we released Svelte 3

I can't find an issue for that among top 50 open issues on Svelte's GitHub repo. I've also been a member of Svelte's Discord server for years and do occasionally hang out there, I haven't seen people "crying out" for this at all.

On the other hand, there are things like `<style module>` or `forward:class`, etc. that people have ACTUALLY been crying out for (literally one of the most upvoted issues in the repo) which haven't been addressed at all.

[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.

[wentin]

First off, thanks for chiming in with that detailed explanation. It's always a learning curve when you dive into the technical side of things, and I genuinely appreciate it.

Given the constraints with TypeScript not being further compilable, I've been pondering on Svelte's direction. Personally, I'd lean towards letting go of some of the special touches in js/ts file if it means keeping more magic in Svelte. If we're heading towards making Svelte syntax work exactly the same in js/ts entirely, it feels like we might risk turning Svelte from its unique language-like identity into just another framework in the JS world.

Thanks again for the insights! I have already felt a little better about my current work in migrating an app from another framework to svelte 4. I was worried that I have made a very wasteful decision for my own company.