Viewing profile — 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 po…

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

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

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

> $:{} 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 Sv…

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

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, yo…

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

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 …

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 [() …

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

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

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

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…

We've toyed with this idea. There's a couple of problems though. Firstly, if you have this... type Reactive = T; function $state (value: T): Reactive ...then TypeScript will 'unwra…

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 …