rich_harris

I have to admit I get very disappointed when I see new form abstractions that don't take this seriously — especially if they make bold claims like 'the new paradigm'!. The whole point of forms is that they're part of HTML. You should not need JavaScript to submit a form, period.

I think about the woman in this story — https://shkspr.mobi/blog/2021/01/the-unreasonable-effectiven... — as an industry, we've lost our way if we don't care enough about people like her to make our apps work reliably. Not everyone has JavaScript: https://www.kryogenix.org/code/browser/everyonehasjs.html

Moreover, validation is something that belongs on the server. Client-first approaches to form validation are at best duplicative (because you need to repeat the validation on the server) and at worst dangerous (because it tricks you into thinking that's unnecessary).

I also notice that one of the first forms on your website doesn't adhere to common accessibility guidelines — the email field is marked invalid as soon as you start typing. Ordinarily, you shouldn't validate a field until it has been blurred.

So what I'd like to see from people building form abstractions is a) a full stack approach, b) progressive enhancement, and c) adherence to accessibility guidelines.

FWIW this is how we think about forms in the Svelte project: https://svelte.dev/docs/kit/remote-functions#form

The docs don't appear to cover progressive enhancement. Is this an oversight?

The Svelte implementation is very inefficient. With a small change I was able to get it to the number two spot on both duration and memory, at least running on this machine. Thyn is in the top spot on both counts — not _hugely_ surprising for a brand new project, but impressive nonetheless.

React, needless to say, languishes at the bottom.

Will send a PR to fix the Svelte implementation.

No, if you're using `adapter-static` (or, if not using SvelteKit at all, just not doing any dynamic server-rendering) then you are not affected. But upgrade anyway!

If you think 'helping developers meet their legal obligations to build sites that can be used by everyone' is 'woke', then you should go and use a different framework.

Three of us are employed by Vercel, and we're probably responsible for over 50% of commits. The core team is much larger than just us though

ISR _can't_ be implemented at a framework level without tying the framework to the platform. The fact that we instead chose to implement it via a platform-agnostic adapter API surely demonstrates the opposite of what you're implying

I have no doubts they'll do the same with Nuxt, demanding they implement features that solely exist to pad out hosting costs while providing next to no actual benefits to end users and devs

has that happened with Svelte?

they now have a monopoly over the most popular frontend meta frameworks (Next, Svelte/Kit, Nuxt, Astro)

this would be a surprise to the Astro team!

$:{} for example is not explicit, I'd much rather use a slightly longer token (like useEffect) to help document what's going on

FWIW you're describing a legacy syntax — modern Svelte has explicit effects, and addresses your other concerns. I think you'll find it's much more to your liking https://svelte.dev/docs/svelte/$effect

For sure — just wanted to be totally explicit that SvelteKit will always be platform agnostic

This simply isn't going to happen.

Ha, did not expect this to be on the front page of HN today! Some quick context: in January I was in London for a few days, and while I was there we had a Svelte Society London event.

This document is a text version of a talk I gave there, which expands on some of these ideas: https://www.youtube.com/watch?v=eswNQiq4T2w&t=5211s

It's deliberately brief and vague in parts, because it's designed to spur conversation. It's not set in stone, nor is it an Official Statement on behalf of the Svelte team — it's an attempt to articulate the way that the maintainers tend to find ourselves thinking about some of these topics, as viewed through my personal lens. If it helps explain why you like Svelte, great! If it helps explain why you hate it, that's great too — that's the whole point. Have fun with it, and if there are parts you disagree with then your homework is to think through what kind of tenets would describe your ideal framework.

Also, it's Saturday — get off Hacker News :)

Notice that you just said "You can have a list of components _where each component_ references a bit of global state". In other words, in order to avoid re-rendering everything, you need to have a component for each item in the list.

In React, the component is the unit of re-rerendering. MobX can't change that fact. The only thing you can do is work around it with hacks that imperatively update the DOM.

Michel and I have been internet acquaintances for years, and we've even talked about this stuff IRL. MobX certainly isn't something we just somehow never learned about!

But anyway: it's absurd to compare this with React+MobX. MobX replaces useState, sure, but you're still re-rendering entire components on each change (which is why MobX explicitly recommends that you break apart your app into many small components, regardless of whether that's a boon to readability and maintainability.

By contrast, Svelte (and Solid, and other frameworks) understand signals on a much deeper and more optimal level. They're really not the same thing at all.

Hi! First up — not that it matters, but since people will wonder — our design wasn't informed by the Reactivity Transform. We evaluated something close to 50 designs, some of them extremely wacky, before settling on runes, and it wasn't until after that time that the Reactivity Transform was brought to our attention.

Nevertheless, it's interesting and validating that we landed on such similar approaches. While the Reactivity Transform failed, it did so for reasons that I don't think apply to us:

- $state and $ref are quite different. $state doesn't give you access to the underlying object, so there's no conversion necessary between reactive variables and ref objects (either in your head or in code).

- There's strict read/write separation. Anyone with access to a ref has the ability to change its value, which definitely causes problems at scale. It's something that React, Solid and Svelte 5 get right.

- Reactivity Transform introduces things like $() for magic destructuring and $$() for preserving reactivity across boundaries. We're instead encouraging people to use familiar JavaScript concepts like functions and accessors

- There are already a lot of different ways to work with Vue — SFCs vs non-SFCs, template syntax vs JSX, composition API vs options API, `<script>` vs `<script setup>`... on top of that, adding a new compiler mode that needs to interoperate with everything else is inevitably going to be a challenge. This isn't the case with Svelte. While both runes and non-runes mode will be supported for the next two major versions, meaning there will be some short term fragmentation, we've made it clear that runes are the future of Svelte.

FWIW you can of course implement createSignal in four lines of code, if you prefer the ergonomics of that:

function createSignal(initial) { let value = $state(initial); return [() => value, (v) => value = $state(v)]; }

Note that the Solid change is _not_ 'one step' — the `completed` property is being turned from a property to a function, which means you must update all the usage sites as well. Using getters and setters also allows you to use Svelte's convenient `bind:value` approach, which is much less verbose than using the equivalent event handler code. And don't get me started on the [type narrowing issues](https://www.typescriptlang.org/play?#code/C4TwDgpgBA4hzAgJwD...).

There's nothing _wrong_ with the Solid approach, but the ergonomics aren't to our liking. If we need to take a hit in terms of verbosity, we'd rather do it once at the declaration site than n times at every usage site.

Can you build a $derived from multiple other $derived?

Yes

Will the end result see temporary, half-updated values?

No. It uses a push-pull mechanism — dependency changes don't result in a re-evaluation until something asks for the value, meaning derivations are 'glitch-free'

the more Svelte you write, the more compiled code appears - generally, Svelte compiles to a size somewhat larger than the original source file.

This is one of those things that's more of a problem in theory than in practice, but nevertheless it's worth mentioning that Svelte 5 output is _much_ smaller than Svelte 4 output.

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

Yes. Signals are a wonderful mechanism, but they do come with headaches. Our goal was very much to adopt the elegant reactivity model without all the downsides, and we've approached this by making them an under-the-hood implementation detail that you don't interact with directly.

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 — someone reading the code should be clued into the fact that this `let` won't behave like a normal `let` in JavaScript, and it should be possible to move code between modules (and between modules and components) without worrying about whether a specific file was opted in to certain behaviour.

In other words this...

This way, the change wouldn't break existing code

...isn't quite right — it would break _all_ your existing code that wasn't in .svelte files.

If I'm not mistaken, the compiler allows Svelte to define its syntax to anything they want.

On this point specifically: unfortunately not. The code in a .ts file, for example, has to be valid and typecheckable. You can't insert a preprocessing step ahead of the TypeScript compiler. Again though we concluded that this is a good thing, since it means this all works with all existing ecosystem tooling.

We've toyed with this idea. There's a couple of problems though. Firstly, if you have this...

type Reactive<T> = T; function $state<T>(value: T): Reactive<T>

...then TypeScript will 'unwrap' the type anyway, unless you do funky stuff like this...

type Reactive<T> = T & { [uniquesymbol]: any };

...in which case things like `value += 1` will cause type errors because it coercies `value` from `Reactive<number>` to `number`.

But it also creates problems here:

let message = $state('hello'); obj = { message };

The type of `obj.message` is Reactive<string>, but it's _not_ reactive — it's a non-reactive snapshot of the value when the object was created.

It's possible that we can do some fun stuff with TypeScript plugins, but we haven't dived too deeply into it yet.

Having a great experience with TypeScript was very much one of our goals. Many design ideas failed to clear this hurdle

What I mean by 'implementation detail' is that you _literally can't get a reference to a signal_ in Svelte 5. This alone prevents people from mutating things in unexpected ways.

We never made any such claim! In fact, the reverse: https://twitter.com/nsthorat/status/1653890181592653825

In Svelte 3, you had to opt in to running code on updates, using things like the `$:` label. It was designed to be conservative about updating components, unlike virtual DOM solutions that like to update everything unless you opt _out_.

I too am very sceptical of benchmarks — they can certainly obscure more than they reveal at times. But you don't have to take my word for it, or the benchmark results showing that Svelte 5 is faster than every other framework in existence (https://twitter.com/Rich_Harris/status/1688581184018583558) — you just need to understand the different mechanisms in play.

Did you read the bit about how runes make all those things unnecessary in future?

I'll try — I'm currently fielding a zillion messages so excuse brevity!

Basically, you can only modify state _where it's declared_. If you want to allow the 'outside world' to modify that state, you need to expose a function that does so. This is unlike cases where you're passing around an observable object where anyone with a reference, which they need for reading, can also write to it by doing `thing.value += 1`.

This is something Solid gets right — you can only change a signal's value if you have a reference to its setter.

Yep! https://svelte-5-preview.vercel.app/docs/fine-grained-reacti...

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

Signals and observables (e.g. RxJS) are related but separate concepts. The framework world is converging on signals as the appropriate mechanism for conveying reactivity — even Angular (which has historically been most closely tied to RxJS) is moving in this direction. I promise you it's not just a mass delusion.

As we've taken to saying around the virtual Svelte offices:

The magic of Svelte isn't `let count = 0`, it's `count += 1`

That part hasn't changed!