Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Svelte 5: Runes

svelte.dev

Post reply on HN
Print view View original

211–220 of 404 posts

Re: Svelte 5: Runes

#211

Post by wentin »

rich_harris wrote: post #194
wentin wrote: post #178

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 w…

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 —…

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.

Re: Svelte 5: Runes

#212

Post by rich_harris »

Phillippe wrote: post #208
rich_harris wrote: post #194

Earlier quoted context omitted.

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 —…

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

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

Re: Svelte 5: Runes

#213

Post by pcthrowaway »

satvikpendem wrote: post #148
softfalcon wrote: post #132

Earlier quoted context omitted.

I could not agree more. There is a huge push to make both side of the rendering “the same”. Next.js is pushing it really hard for their edge level rehydration. I get it, it gives you flexibility to hydrate the view as close to the user, as late as possible. That sounds cool, but I wonder how many folks really use it and how much you pay for not clearly defining where and when each bit is happening.

As someone who tries to limit their client-side JS usage through uBlock/uMatrix, websites that aren't just blank with JS disabled would be nice to see, which is why I like React Server Components. Of course, if it's a useful enough web app, I'll enable JS, but if someone's writing a blog, ecommerce site, or really any site that may not require a full blown SPA. Sending minimal unneeded JS to the client is best, as it…

You can also achieve this with Astro, which will render your React islands statically and also enable client-side JS for interactivity / progressive enhancement when the client has JS enabled

Re: Svelte 5: Runes

#215

Post by jakelazaroff »

ttfkam wrote: post #176
satvikpendem wrote: post #99

Earlier quoted context omitted.

Thanks for the reply, Rich. It seems that, given a large enough codebase, that sort of spaghetti mess will emerge on its own, as not everyone will be so thorough. Granted, I haven't used runes and based on your blog post here, I'm not reading where it would prevent such headaches as there's not much mention of that there, so I don't know exactly how it'd work, but just based on my experience using things like Vue and…

> An analogous concept might be quite interesting to implement in all these signal based frameworks as well. Which is what Svelte 5 is doing with its compiler. > […] given a large enough codebase, that sort of spaghetti mess will emerge on its own, as not everyone will be so thorough. LOL! You've just described React projects! Yes, of course you and your team are wonderful and have all the FP experience, so obviously…

I think the true lesson here is that if you fundamentally dislike a programming paradigm, then everything written in it looks like a big ball of mud.

Re: Svelte 5: Runes

#216

Post by trafnar »

What I like about Imba is that you can update a variable, and the result in the view/page is updated, without any special syntax.

  let count = 0

  def increment
    count++

  tag App
    
       "Increment"
       "Count: {count}"

  imba.mount
Try this example here: https://scrimba.com/scrim/cpbmKzsq

(Imba is a compile-to-js language that includes JS/HTML/CSS and a react-like framework all as part of the language. https://www.imba.io)

Re: Svelte 5: Runes

#217

Post by corbezzoli »

hajile wrote: post #122
rich_harris wrote: post #81

Earlier quoted context omitted.

Yes, Vue and Solid — like Knockout — use a dependency tracking mechanism. Back in the day it was called `ko.observable`, nowadays we call them signals. That's the part Knockout was right about. It's absolutely true that you can mishandle them and create a spaghetti mess, _if your design allows it_. Svelte 5 doesn't — it uses signals as an implementation detail, but in a way that prevents the sorts of headaches you're…

Not everyone has teams of perfect developers given all the time they want to make their perfect frontend app. Most of us deal with average teams where half the devs are at or below par while managing very tight deadlines. The spaghetti from everything in the whole system mutating always comes back to bite. You call signals an "implementation detail", but if someone doesn't know that's what they are, then they'll wind…

> You call signals an "implementation detail",

You haven’t even seen Svelte 5 yet, I don’t think it’s fair to say its internals will create trouble yet.

Re: Svelte 5: Runes

#219

Post by pcthrowaway »

pevey wrote: post #73
epmatsw wrote: post #6

This looks like it’s moving closer to React Hooks, but using the compile step to optimize them out? Kinda like a better React Forget?

This might be the impression on first glance because it uses the word "state." But keep reading, and its much more akin to what Solid is doing. In fact, the new docs openly credit the work Solid's team is doing. They also credit Knockout's approach form way back in 2010.

Under the hood it's doing something more similar to solid, but the API exposed is a step in the direction of React (it doesn't expose the signals to the user). It's not quite React either because there's no 'setter', just a different way to opt in to reactivity which also (IIUC) makes it possible in .js/.ts files

Re: Svelte 5: Runes

#220

Post by WuxiFingerHold »

satvikpendem wrote: post #52

This is basically what Vue and Solid do, no? Same sort of state and derive/computed variables, it seems like. Also, I will never understand why people like reactive signals. The article even quotes "Knockout being right all along" which, no, reactivity and two way data binding creating a spaghetti mess of changes affecting other changes all over the place unless you're really careful is why React was made in the firs…

Architecture and the used reactivity mechanics are different things.

You need architecture to avoid a big ball of mud or spaghetti code. Organising your code in layers, modules, each with its own API. Rules which layer can access what other layer. Like backend does for ages. You can and should do this in large frontend SPAs as well. No matter if written Svelte, Angular or React.

Post reply on HN