Svelte 5: Runes

For sure. Look at this Svelte 5 example:

let time = $state(new Date().toLocaleTimeString());

  $effect(() => {
    const timer = setInterval(() => {
      time = new Date().toLocaleTimeString();
    }, 1000);

    return () => clearInterval(timer);
  });

Current time: {time}

These discussions are so tiring.

React has as much two way binding as vue - in vue v-model is just syntactic sugar for setting up event listeners and setting the value on an input element.

Per the docs [0]

Becomes

It's such a small thing that it's crazy it's being discussed this much.

[0] https://vuejs.org/guide/components/v-model.html

Indeed. You can get all the main benefits of two-way binding in a one-way dataflow system like React by using cursors... i.e. whenever you access a property `state.foo.bar`, also derive the setter/updater, `setBar(…)`.

With proper memoization, this is both fast and ergonomic, and it even allows you to turn mutations into data and pass them to a server. I've implemented this as a stand-alone state helper [1] based on JSON patch/diff, and it's magical. Undo/redo, multiplayer, it's all within reach.

[1] https://usegpu.live/docs/reference-live-@use-gpu-state

> At first glance, this might seem like a step back — perhaps even un-Svelte-like. Isn't it better if let count is reactive by default

Actually, it was Svelte who coined the term and sold us on the idea of reactivity by default. I don’t think anybody asked for “Reactivity by default”. Svelte advanced this idea, and it helped the framework gain traction. It was easy to get started, and gave Svelte this sense of better ergonomics than other frameworks. I was always skeptical about the performance claims, amortized, and the real selling point of Svelte was ergonomics and the dev experience.

The problem with the Node.js ecosystem is the devs are borderline marketing and sales type. They’ll justify, rationalize and make things sound good after the fact. Previously, Svelte was persuading us that Svelte was better than the rest because of reactivity by default. Now they did a literal 180. It’s probably in the right direction, and maybe how things should have been. A related symptom of the Node.js ecosystem is reinventing and rediscovering the wheel. The problem here is a lost of trust. Anything else which Svelte purports it’s got figured out or is more enlightened about should be taken with a grain of salt.

So it seems those boring FANG engineers with React has it right all along. They had experiencing building sufficiently complex apps where verbose but explicit code was necessary.

> Because the compiler can 'see' where count is referenced, the generated code is highly efficient

Yeah, I don’t believe such claims anymore. Sure, in cherry picked and constrained settings, the performance benchmarks might seem good. As much as I hate to admit, I will reach for the production ready and battle tested React, as boring as it is.

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 Knockout in the past, it wasn't too clean.

I was just mentioning in another comment how Rust has a similar problem where, as in C, you can mutate variables via pointers anywhere in the codebase, but Rust counters that by having a borrow checker that explicitly tracks the changes made and makes sure that only one user can modify a variable at any one time. An analogous concept might be quite interesting to implement in all these signal based frameworks as well.