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

React, needless to say, languishes at the bottom.

Will send a PR to fix the Svelte implementation.

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!

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

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 :)

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.

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.

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, `