5 ms·

One of Svelte's biggest advantages is its compiler, positioning it more as a language than just another JS framework. If I'm not mistaken, the compiler allows S

by wentin 3y ago

One of Svelte's biggest advantages is its compiler, positioning it more as a language than just another JS framework. If I'm not mistaken, the compiler allows Svelte to define its syntax to anything they want. Given this, I'm curious: couldn't the traditional syntax of `let counter = 0` be made to function similarly to the new let count = $state(0);? Transpile it to let count = $state(0) under the hood? If that can work technically, instead of introducing a new rune for reactivity, why not introduce a "negative" rune to denote non-reactive statements? This way, the change wouldn't break existing code; it would be more of a progressive enhancement. I agree the move to unify the Svelte <script> tag with regular js/ts files is an improvement. It was indeed a little odd that certain syntactic sugar, like the $, would work exclusively within the Svelte <script> and not in a js/ts file that's right next to it. However, from what I gather, it seems the Svelte team is aligning the Svelte script more with js/ts, rather than bringing the js/ts closer to Svelte's unique syntax. This trajectory seems to be pushing Svelte towards resembling traditional JavaScript frameworks, like React. It's a departure from Svelte's unique strength of having a custom compiler and behaving more like a language. If every syntax in Svelte is expected to mirror its behavior in js/ts, eventually svelte will lose all it secret sauce that made it so unique. Why can't we add a rune into js/ts file, a note in the beginning to tell svelte compiler that this is svelte enhanced js/ts file, compile it like svelte script tag code? Bring js/ts more alike to svelte?

deleted 3y ago
[deleted]
rich_harris 3y ago
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.
- Phillippe 3y ago
  "...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 3y ago
    That would be a _terrible_ outcome. Things would routinely break, and code would be vastly more confusing.
    - Phillippe 3y ago
      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');
      - Phillippe 3y ago
        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 3y ago
        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.
      - omnimus 3y ago
        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.
spacebuffer 3y ago
> Given this, I'm curious: couldn't the traditional syntax of `let counter = 0` be made to function similarly to the new let count = $state(0);? Just transpile it to let count = $state(0) under the hood? If that can work technically, instead of introducing a new rune for reactivity, why not introduce a "negative" rune to denote non-reactive statements? This way, the change wouldn't break existing code; it would be more of a progressive enhancement. exactly my thoughts, feels like they could've kept it much simpler

by wentin 3y ago

deleted 3y ago

[deleted]

rich_harris 3y ago

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.

Phillippe 3y ago
"...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 3y ago
  That would be a _terrible_ outcome. Things would routinely break, and code would be vastly more confusing.
  - Phillippe 3y ago
    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');
    - Phillippe 3y ago
      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 3y ago
        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.
    - omnimus 3y ago
      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.

spacebuffer 3y ago

> Given this, I'm curious: couldn't the traditional syntax of `let counter = 0` be made to function similarly to the new let count = $state(0);? Just transpile it to let count = $state(0) under the hood? If that can work technically, instead of introducing a new rune for reactivity, why not introduce a "negative" rune to denote non-reactive statements? This way, the change wouldn't break existing code; it would be more of a progressive enhancement. exactly my thoughts, feels like they could've kept it much simpler