Live data from Hacker News

Svelte 3: Rethinking Reactivity

svelte.dev

21–30 of 186 posts

Re: Svelte 3: Rethinking Reactivity

#21
From the tutorial:

> Svelte is giving us a warning:

> A11y: element should have an alt attribute

> When building web apps, it's important to make sure that they're accessible to the broadest possible userbase, including people with (for example) impaired vision or motion, or people without powerful hardware or good internet connections. Accessibility (shortened to a11y) isn't always easy to get right, but Svelte will help by warning you if you write inaccessible markup.

Thank you! We accessibility advocates have wanted this kind of checking to be built into mainstream development tools for years. I hope Svelte becomes popular for this reason alone.

Re: Svelte 3: Rethinking Reactivity

#22
Since you are reading here Rich Harris; while I really admire your solutions, one weak point with Svelte seems to be a clear unit testing solution, or at least docs last I looked. I also noticed this with Ractive, and feel it weakens these in the eyes of many businesses considering these tools.

I know it's a solved/solvable problem but it feels like better docs and samples in quick start guides would help.

Re: Svelte 3: Rethinking Reactivity

#24
post #16

So basically mostly the same thing MobX does in React and Vue does out of the box? That's not a bad thing - that's the "good" kind of Reactivity and how most UI should be written IMO - it involves significantly less boilerplate.

Yes! I talk a bit about prior art in this section of a recent talk: https://youtu.be/AdNJ3fydeao?t=504 . (Michel Weststrate, the MobX creator, was in the audience!) The difference in how you end up writing your code when you don't have a `this` turns out to be quite profound, and is the main reason that Svelte components are so concise: https://svelte.dev/blog/write-less-code It's also worth noting that this approach…

And also, since you don't need Proxies, you can target not so old browsers.

We're working on a project with MobX 5 and mid project we realized some of our users on iOS 9 or KitKat do not have Proxy.

Re: Svelte 3: Rethinking Reactivity

#25
post #22

Since you are reading here Rich Harris; while I really admire your solutions, one weak point with Svelte seems to be a clear unit testing solution, or at least docs last I looked. I also noticed this with Ractive, and feel it weakens these in the eyes of many businesses considering these tools. I know it's a solved/solvable problem but it feels like better docs and samples in quick start guides would help.

You're totally right. This is good feedback — we'll have a think about how we can best address this.

Re: Svelte 3: Rethinking Reactivity

#26

Odd that they don't mention Angular amongst the component-based frameworks, as what they're describing sounds very similar to Angular's compiler and change-detection system.

Svelte as a lot in common with Angular, arising from the decision to use a component compiler at build time. But culturally it appears most attention to Svelte comes from a React direction, so Svelte is most often described as a “diff” from React.

You could possibly predict the future of Angular and Svelte by comparing them and looking for ways to cross-pollinate.

Re: Svelte 3: Rethinking Reactivity

#27

I haven't used it yet but I really like the idea of Svelte, just how I really enjoy using Preact over React for certain projects. One question about version 3. I was wondering if they addressed the issue of how a Svelte code base can grow in size larger[1] than a Preact based codebase the bigger it gets. [1] https://medium.com/@chrisdaviesgeek/tiny-js-frameworks-preac...

Creator here. We get this question a lot, and should probably dedicate a blog post to it. It's true that the incremental cost per-component is higher than with some frameworks. In theory, you hit an inflection point. In practice though this doesn't really happen, because by the time you get there, you should be code-splitting anyway — and each of your code-split chunks have a hard minimum size which is the size of th…

How does Svelte compare directly To more minimal Reactive libraries like most.js or flyd.js? Even MobX? Besides the dissapearing at runtime? It looks very cool I'd like to see how it performs with some complex DOM opps. Might mess around today.

Re: Svelte 3: Rethinking Reactivity

#28
post #16

So basically mostly the same thing MobX does in React and Vue does out of the box? That's not a bad thing - that's the "good" kind of Reactivity and how most UI should be written IMO - it involves significantly less boilerplate.

Yes! I talk a bit about prior art in this section of a recent talk: https://youtu.be/AdNJ3fydeao?t=504 . (Michel Weststrate, the MobX creator, was in the audience!) The difference in how you end up writing your code when you don't have a `this` turns out to be quite profound, and is the main reason that Svelte components are so concise: https://svelte.dev/blog/write-less-code It's also worth noting that this approach…

I was actually physically close to YGLF but unable to attend, I spoke there at a previous year. Michel is a friend and I collaborated with him on MobX. He's also one of the nicest people I know and he visits often.

I think you might want to check out WPF + PostSharp for something very similar to this approach in C# land. I definitely think it's the right approach for reactivity.

Re: Svelte 3: Rethinking Reactivity

#29

Earlier quoted context omitted.

Creator here. We get this question a lot, and should probably dedicate a blog post to it. It's true that the incremental cost per-component is higher than with some frameworks. In theory, you hit an inflection point. In practice though this doesn't really happen, because by the time you get there, you should be code-splitting anyway — and each of your code-split chunks have a hard minimum size which is the size of th…

How does Svelte compare directly To more minimal Reactive libraries like most.js or flyd.js? Even MobX? Besides the dissapearing at runtime? It looks very cool I'd like to see how it performs with some complex DOM opps. Might mess around today.

Those are all libraries for state management. Svelte is a UI framework. It incorporates its own state management (https://svelte.dev/tutorial/reactive-assignments for local state, and https://svelte.dev/tutorial/writable-stores for cross-component state), but you can also wrap third party libraries if needed.

Re: Svelte 3: Rethinking Reactivity

#30
post #16

So basically mostly the same thing MobX does in React and Vue does out of the box? That's not a bad thing - that's the "good" kind of Reactivity and how most UI should be written IMO - it involves significantly less boilerplate.

Yes! I talk a bit about prior art in this section of a recent talk: https://youtu.be/AdNJ3fydeao?t=504 . (Michel Weststrate, the MobX creator, was in the audience!) The difference in how you end up writing your code when you don't have a `this` turns out to be quite profound, and is the main reason that Svelte components are so concise: https://svelte.dev/blog/write-less-code It's also worth noting that this approach…

Also, thanks for rollup, I've used it today and it was a lot of fun to work with. I was up and running (after experience with webpack) very quickly and everything I needed was well maintained and I was pleasantly surprised!

The main blocker for me adopting Svetle (and opting for Vue and React) is tooling to be honest. I want code that has a lot of visibility, meaningful stack traces and the debugger stopping in relevant places. If Svetle 3 does everything synchronously (like MobX) I'd love to check it out!

Post reply on HN