Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Svelte 5] - Consider support for Svelte 4 (no Runes) and provide clear way to have it not mixed with the new Svelte Runes #9676

Closed
kabaluyot opened this issue Nov 28, 2023 · 8 comments

Comments

@kabaluyot
Copy link

Describe the problem

Our little company was heartbroken by Vue 3 composition API and been learning, migrating, and started building new projects using Svelte 4.

I understand the needs why to add "opt-in" support for Runes (which from the blogs sounds like the way to go in the long run).

It was also mentioned that the current Svelte (Svelte 4 way) will be supported in Svelte 5 (but there's a high chance of being deprecated or not maintained -- see Vue Class Component being ditched vuejs/vue-class-component#632 even after assurances from Vue team)

Describe the proposed solution

Is there a possibility or plan that we can use Svelte 4 and Svelte 5 syntaxes separately and without them being mixed in 1 svelte file?

For example in the <script> tag of a .svelte file for Svelte 5, by default it will support and enforce Runes .. and people cannot anymore add "Svelte 4" related syntax to this to avoid spaghetti codes / mixing.

But if we want to still write using Svelte 4, we can add something like <script classic> or whatever then this file won't accept any Runes related syntaxes and easily support / onboard creating new .svelte using Svelte 4 syntax.

The tags is not necessary, it can also be automatically detected -- just wanted to avoid being mixed.

Alternatives considered

n/a

Importance

nice to have

@trueadm
Copy link
Contributor

trueadm commented Dec 4, 2023

You can always add <svelte:options runes={false} /> to your modules to ensure they always work without rune mode.

@kabaluyot
Copy link
Author

Just tried it with Svelte5 preview. Please support this in the future versions as well until so we can freely upgrade our Svelte projects to 5 without changing a thing.

@Conduitry
Copy link
Member

I don't know what this issue is asking for. <svelte:options runes={false} /> will work throughout Svelte v5. Regardless, you're not able to mix runes mode and non-runes mode within a single component, anyway. I don't see the benefit of a syntax like <script classic> as opposed to <svelte:options runes={false} />.

If the request is for non-runes mode to be supported indefinitely, that's not going to happen. We'll endeavor to fix regressions in Svelte 5's non-runes mode versus Svelte 4 behavior, but in Svelte 6, non-rune components are likely to not be supported at all.

@kabaluyot
Copy link
Author

Agree with <svelte:options runes={false} />. Looks fine and clean.

In an application developer POV:

So does this mean migrating a Svelte 4 project to Svelte 5 will just need to add <svelte:options runes={false} />. That's it?

Then we can reap the benefits of the new Signal-based implementation with non-runes?

Then from there we can slowly migrate / be comfortable with runes cause most likely it won't be supported anymore in future major versions?

@notramo
Copy link

notramo commented Mar 5, 2024

@kabaluyot, most of the Svelte 4 syntax components will work seamlessly after upgrading to Svelte 5. The compiler detects if the component uses Svelte 4 or Svelte 5 syntax.
From the Svelte 5 preview docs:

The easiest way to opt in to runes mode is to just start using them in your code. Alternatively, you can force the compiler into runes or non-runes mode either on a per-component basis... [...]

Also, the two syntaxes can not be mixed in one file. That was never an option.

@dummdidumm
Copy link
Member

As pointed out by people in here, you can upgrade to Svelte 5 and then gradually migrate your components to runes one by one.
We strive to make the whole thing as backwards-compatible as possible. Unless you're using stuff from svelte/internal (or use component libraries that do) you should be good. Closing as there's nothing actionable here.

@dustinc
Copy link

dustinc commented Mar 8, 2024

Our little company was heartbroken by Vue 3 composition API and been learning, migrating, and started building new projects using Svelte 4.

That is exactly how we feel about Svelte 4 -> 5. It's good to know 4 syntax is still supported but who knows for how long. Kinda like meeting your soulmate then they develop a personality disorder and become someone else. Heartbreaking.

@notramo
Copy link

notramo commented Mar 9, 2024

Kinda like meeting your soulmate then they develop a personality disorder and become someone else. Heartbreaking.

Svelte 5 changes seem strange at first look, it may seem less ergonomic than Svelte 4. I suggest starting a small project in Svelte 5, and getting familiar with it, then re-evaluate the opinions. I guess you would like it better. And don't forget, it's still in the baking so if something feels less fun, feel free to provide feedback. But the “we don't have resources to update, so please stop improving the framework” kind of feedback is not valuable. If Svelte 5 was the same as Svelte 4 then it would not be any improvement. Then why not stay on Svelte 4 forever? Vue 2 has LTS support, it can happen to Svelte 4 too.

Svelte 4 -> 5 is much less different than Vue 2 (options) -> Vue 3 composition change. It's mostly only syntax.

I tested 4 -> 5 migration on a small project. It does not take much time. I guess most projects can be migrated in a day by one developer. And since the two versions can interoperate, you can update incrementally.

Also, in order to avoid Svelte 4 -> 5 migration as much as possible, I'm now starting all new projects in Svelte 5. It's quite usable already, and after getting familiar with it, it's more fun than Svelte 4.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants