Check out Nix 🤠

@AlanBreck sure! Here's a REPL with a couple examples.
If you want every component to accept a baseline of props, you can define an interface with TypeScript, and then extend that interface within each component. In the example, the circle and rectangle components both have color and stroke props, but the circle also has a radius and the rectangle also has width and height.
A really handy use case, though, is if you want to extend the functionality of an existing HTML element, like a button, you can extend the HTMLButtonAttributes type provided by Svelte. This is much easier to do in Svelte 5, compared to Svelte 4.

Thank you! What about from a runtime perspective? Will the $props rune help determine what props are available for a component during runtime, though?

Not totally sure on that one! Someone from the core team could probably give a good answer, but I'm guessing the compiled code gets optimized based on which props you destructure from $props()

I think that's it @eddiemcconkie, that's the argument that can convince me 👌 As a typescript fan, I can definitely see the advantage of being able to just define the types myself, it's probably even easier to generally document 👍

Addition to my big comment above: I'm still not a hype fan of Runes, but now I just don't like them when outside Svelte files.
If everything stays in the Svelte file, all is good 👌 And Runes are actually interesting.
I'm almost convinced.
It just took time.
I'm still into this "separation of concerns" thing: Svelte code in Svelte files, JS/TS code in JS/TS files.
I would still dislike very much the obligation to compile JS/TS code with Svelte outside of Svelte components, because IMO that's completely different.
I really like Svelte also because it's more okay to use it as a frontend templating engine, or as plug-and-play JS components (just like Web components).

(sorry for all the fuss)

I also started in the web track back in 2016 and I wasn't fond of frontend, but came back to it in 2020 because I heard the word svelte on reddit and watched a crash course from traversy media, and quickly fall in love with svelte & frontend.

cosign, i'm here for the aesthetic ;)

Harris for president :)

it would be crazy if would be able to add python to it...and integrate with ai models in seconds......or simple python integration in seconds

My guess is with Bun this will be possible since they make it easy to import files if they have a good C FFI. We've already seen Rust and C++ being imported easily into Bun. The only thing I'm not sure about is svelte/kit's tight coupling to vite since I assume Bun would need to do all the bundling and etc

That's actually a great idea.

Yes please

https://github.com/semicognitive/sveltekit-modal

I've just realized that with Tailwind you put css in html, and with htmx you put js in html. It is wild how powerful just html can be. I've personally been fully converted to the church of html first 😅 I reeeally like how Svelte is html first, but then also gives you all of css and js right there in <style> and <script> tags if you need them.

Those are fair points, and longstanding odd quirks of Svelte 3/4, but I'd argue they had a much smaller impact on DX than the potential pitfalls with proxies might have

You literally say, "I learned the Svelte 3/4 quirks the hard way (the only way to learn it is to step on and debug for hours only to find out that it is Svelte's unfixable bug) and got used to them", which, in fact, isn't good DX at all.

I believe you think about states too much. Unless a function stores somewhere the passed arguments, it's ok to pass in a proxied state.

You literally say, "I learned the Svelte 3/4 quirks the hard way (the only way to learn it is to step on and debug for hours only to find out that it is Svelte's unfixable bug) and got used to them", which, in fact, isn't good DX at all.

When do I literally say that? I don't remember saying anything of the sort. The Svelte 4 docs, as well as the tutorial, outline that reactivity is triggered by assignment to the reactive variable, and Svelte 4's behavior largely follows this rule. I doubt many people lost hours in the debugger for this issue that's very prominently pointed out pretty much anywhere that the docs teach you how reactivity works in the first place.

Unless a function stores somewhere the passed arguments, it's ok to pass in a proxied state.

Right, but the issue is that it's impossible to tell at a glance whether the argument you're receiving (or passing, for that matter) is proxied state, particularly when you're dealing with code that lives somewhere other than where said state is declared. Even if you meticulously keep mental track of where exactly every argument you're receiving comes from while you write it, good luck remembering that a few months down the line when you have to touch that code again while refactoring some other feature.

I probably misunderstood your words about Svelte quirks, sorry.

Svlete 3/4 has many undocumented quirks of the reactivity: canges made inside reactive blocks can be ignored; $: blocks can be reordered which isn't obvious; $: blocks are executed at the end of initialization, but it isn't obvious; ambiguous $: a = b + 2; invalidating "unrelated" variables; reactivity can be lost in deeply nested slots; beforeUpdate called twice when bind:this used; etc (I have found 54 issues about reactivity, though some repeats). Roughly half of them are caused by the reactivity implementation, and the other half - by the reactivity design (syntax + rules).

Almost all of them are undocumented, and you encounter many of them when writing more or less complex apps. It's awful to spend hours debugging the app only to find out that it is Svelte's unfixable bug.

I hope Svelte 5 will properly document the edge cases of the runes so we can write apps without unexpected surprises.

the issue is that it's impossible to tell at a glance whether the argument you're receiving (or passing, for that matter) is proxied state

I haven't written big apps with Svelte 5, but I don't notice complaints about it from people who have. So, I believe that either you overestimate the problem, or your personal code style doesn't go well with runes (or kinda both).

Regarding adding reactivity to "Array.push()" and other stuff, I personally wouldn't have minded a few Svelte-specific data structures. I mean, doing something like const myData = new ReactiveArray(); in order for myData.push(someData) to call reactivity, that would have been great, because it's only a data structure, and the implementation behind is clear: when internal array is modified, reactivity is triggered.

For the rest, I still think having a mix of too complex&generic structure (like proxies) is both nice and bad. It's generic enough so it's good for many purposes, but it comes with other quirks (and we already have enough quirks everywhere).
To me, the issues @7nik pointed that Svelte has in v3 and v4 are maybe fixed, but when I look at how it works, it's more like "Fixed with another hack, but instead of a syntax hack, it's now a generic-data-structure-based hack".

I hope I will be convinced once I use Svelte 5 every day 😕

"Fixed with another hack, but instead of a syntax hack, it's now a generic-data-structure-based hack"

I felt that. Some degree of "generic-data-structure-based hack" is acceptable but right now it just doesn't feel right. Way overcomplicated for what it's worth. Not going to replace stores as it is currently, not with this many gotchas and conditions.

EDIT: It's actually fine.

I will just say, that's how I felt initially, when it was announced. I always thought of Svelte as the one where you didn't have to think of this - where reactivity "just happened" and "just worked". In hind sight, this feels reactive. Having seen Rich talk about runes more recently, and then deciding to try it, I gotta say, I get it now. It's still declarative, but the runes are not just annoying boilerplate, they're useful to the reader because you don't have to figure out what's reactive or not. I changed my mind. Maybe you can too? 🙃

😂😂😂