171–180 of 404 posts
Perl called these sigils. They were incredibly useful and powerful, but the dev community decided that they hated them.
Apart from the superficial use of the $ sign, what else is Perl about any of this?
Earlier quoted context omitted.
I wonder if it's due to how new people are to the industry, as well as how new the industry itself is. In disciplines like mechanical or chemical engineering, you don't see nearly this much reinvention of the same patterns. I imagine most people these days using React, Vue, Svelte, or Solid have never even used jQuery or Knockout, as those are almost 15 years or older at this point.
If you're an engineer, physics are always there to smack you in the face. As a result, engineers collect sets of things that physics seem to be fine with and reuse them. If engineering were programming, a woodpecker in Central Park would bring down the Eiffel Tower. Programming is not physical. It is generally bound by Turing completeness, the halting problem, 2 generals problem, and the like, but most developers don…
Earlier quoted context omitted.
Huh? It's called observable because it can be observed (that's what "-able" means). If it were actually meant to observe something (as you say), it would have been named "observer." But it's not - it's the callback that's the observer. Also observables are more like streams than arrays.
I don't think I'm entirely out of band to say there could be a better way of naming them, like why not call them SubscribableStream . Saying its an observable invokes a messy gray area in people's brains. I know this because I've had to explain observables to co-workers more times than I can count in my career (I'm a big fan of RxJS, I didn't mean what I said as a dismissal), and I like them for async work vs promise…
> Isn't it better if let count is reactive by default? > Well, no. The reality is that as applications grow in complexity, figuring out which values are reactive and which aren't can get tricky. People keep re-learning that there's a certain amount of context that needs to be explicit, and you can't just imply everything. Just like when ruby and python made the mistake of getting rid of let/contst/var/etc and program…
Earlier quoted context omitted.
> code written in 2018, when hooks first came out, still works today Does not Svelte from 2018 works today?
jQuery from 2009 also still works today. What I meant was, developers want to use the latest and greatest. Hooks added in 2018 havent changed, there’s no replacement api for them - it’s still modern code. They got the DX right from the start, that other libraries are still trying to emulate.
DX Amaze.
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…
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…
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 this isn't an issue for YOU.
Most React codebases however turn into big balls of mud. Enormous balls of useMemo-y, useEffect-y, re-render the world-y, spaghettified mud without even any compiler-enabled guardrails that get re-written every 18-24 months but "this time we'll do it right."
Perhaps I'm just the grumpy old guy that's afraid of change. But I fell in love with Svelte because it was dead simple (according to me). It was a breeze of fresh air and I felt I just program again without wiring enchantments together. I do agree that its simplicity has downsides too, so perhaps it's just nothing to be afraid of? But I can't help seeing this as ominous: > This is just the beginning though. We have a…
This set of changes makes things more explicit. That's the opposite of a black magic box as far as I can see
Maybe it's because of using the "runes" word :)
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 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 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?
One thing that popped out was that it seems like .js files will also need to be transformed now to accommodate the $ to rune translation.
Feature request to make that optional, perhaps something like:
import { rune } from "svelte/rune"
let $count = rune(0)
Earlier quoted context omitted.
I recently took Solid for a spin and I found none of that 2-way data binding mess you complain about. To be fair, I think you’re assuming is has behavior that it doesn’t. Eg if a form input changes, that change triggers an onChange and in a handler function, you can let the change just flow through the data layer (ie through a signal or a store, which is just a hierarchy of signals). This then updates the input, but…
What you’re talking about is unidirectional data binding, and what you’re replying to specifically mentions its failure to scale with complex applications. It’s not the kind of problem you can appreciate when taking any framework for a spin with a form input.