Live data from Hacker News

Svelte 3: Rethinking Reactivity

svelte.dev

1–10 of 186 posts

Re: Svelte 3: Rethinking Reactivity

#2
I'm very intrigued by Svelte and I really hope that it will succeed. In that sense I also hope that this is the last major version, i.e. no more breaking changes. That would be fantastic!

Does anyone here have a major, non trivial app in production that's built on Svelte?

Re: Svelte 3: Rethinking Reactivity

#3
post #2

I'm very intrigued by Svelte and I really hope that it will succeed. In that sense I also hope that this is the last major version, i.e. no more breaking changes. That would be fantastic! Does anyone here have a major, non trivial app in production that's built on Svelte?

Pinefore is a frontend for Mastodon based on Svelte2, I've found it to be a great non-trivial example: https://github.com/nolanlawson/pinafore

Re: Svelte 3: Rethinking Reactivity

#4
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...

Re: Svelte 3: Rethinking Reactivity

#8
Immer.js (a library to work on data structures, not a framework) uses a similar concept, using Proxies.

The gist of Immer is that your framework needs immutable structures, but you want to interact with them imperatively.

It's very interesting, and a reversal of the traditional "functional core, imperative shell" architecture.

https://github.com/immerjs/immer

Re: Svelte 3: Rethinking Reactivity

#9

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 the framework.

This article reinforces that finding by testing the 'RealWorld' project: https://medium.freecodecamp.org/a-realworld-comparison-of-fr.... It's based on an outdated version of Svelte but the broad strokes will be unchanged.

Of course, Svelte is about far more than just bundle size!

Re: Svelte 3: Rethinking Reactivity

#10
post #8

Immer.js (a library to work on data structures, not a framework) uses a similar concept, using Proxies. The gist of Immer is that your framework needs immutable structures, but you want to interact with them imperatively. It's very interesting, and a reversal of the traditional "functional core, imperative shell" architecture. https://github.com/immerjs/immer

Yep, and Svelte <3 Immer — they work nicely together.
Post reply on HN