Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Svelte 3: Rethinking Reactivity

svelte.dev

Post reply on HN
Print view View original

81–90 of 186 posts

Re: Svelte 3: Rethinking Reactivity

#81

Post by anderspitman »

writepub wrote: post #70
anderspitman wrote: post #68

This is really cool. That said, I noticed that it cites performance vs vdom as a selling point. Something I've been wondering lately is how big of an issue is UI performance for most web apps really? So many of the little apps and prototypes I develop aren't hurting for performance. It seems to me the industry made a huge leap from JQuery/Backbone/etc to reactive/vdom. But declarative UIs and virtual doms don't solve…

It's really surprising that people put faith in virtual Dom implementations, when browsers have been optimized for decades for efficiency. With the right batching strategy that minimalistic libraries like FastDom [1] offer, there's no real reason to use the virtual Dom. A frequent argument for the use of vdom has been that it reduces Dom trashing. I am willing to bet that if a vdom library has figured out what elemen…

I like it. You can only hide so much comlexity in 600 bytes. Something like fastdom could probably facilitate what I'm talking about. Basically don't bother diffing, but only actually touch the DOM once per frame. So I guess in that case you'd have tons of "phantom writes" to fastdom as the state is reactively updated.

Re: Svelte 3: Rethinking Reactivity

#82

Post by rich_harris »

dictum wrote: post #79
nailer wrote: post #55

Earlier quoted context omitted.

What about "Faster web apps with less code?" or "Faster, smaller, web apps?" They seem to be the main benefits for using Svelte.

"Less code" implies less authored code, which may be a benefit of Svelte (is it? I haven't been able to use it much but it's on my radar) but doesn't necessarily map to its technical goals (less built code, less runtime processing). (Quick example: the countless hello world projects that result in >100KB bundles)

Authoring less code is definitely an explicit goal: https://svelte.dev/blog/write-less-code

Re: Svelte 3: Rethinking Reactivity

#83

Post by rich_harris »

anderspitman wrote: post #77
rich_harris wrote: post #74

Earlier quoted context omitted.

> Are there any frameworks out there that provide a JSX/VueSFC/hyperscript development experience, without adding the complexity of a virtual dom implementation? Svelte is intended to be exactly that! Whether performance is an issue depends partly on the kind of app you're building. In my line of work (producing interactive data visualisations etc) it absolutely is. As I talk about here, it's going to become even mor…

Thanks for the article link; that was an excellent read. I don't think my post was very clear. I agree that the run-time complexity of svelte is much better than a vdom framework, but it seems like you're just trading that for build-time complexity. Maybe that's the only way to achieve what I'm talking about though. At some point you have to translate from immediate mode to retained mode if you're rendering to the do…

My view on this is that complexity, like energy, can only really be converted from one form into another. Normally the distinction is between runtime complexity and cognitive complexity — the result of hand-optimised imperative code. In other words, the classic trade-off between developer experience and user experience.

Svelte's claim is that converting it into build time complexity is in fact the only sensible thing to do. It doesn't really matter how much complexity is involved in `npm run build` if it means that DX and UX are no longer in tension.

But to answer your point about SVG, Svelte has to obey the same fundamental constraints as any other code, so you will eventually hit performance issues (though you may enjoy this demo https://youtu.be/AdNJ3fydeao?t=1138). One avenue I'm currently exploring is whether the same declarative/compiled model can be used as a wrapper around WebGL APIs, though it's very early days.

Re: Svelte 3: Rethinking Reactivity

#84

Post by arxpoetica »

arve0 wrote: post #80
potiuper wrote: post #66

> Instead, Svelte runs at build time, converting your components into highly efficient imperative code that surgically updates the DOM. So, Svelte is compiled into web assembly? If not, given the emitted imperative code is less efficient than emitted web assembly and the emitted imperative code is less concise than the original declarative code, then what would be the advantage of an imperative translation of the dec…

Are you mixing up code you write vs the code emitted? The code you write in Svelte is reactive/declarative, emitted code is regular imperative JS.

Though the idea has been bounced around a few times in the Svelte forums for compiling to web assembly

Re: Svelte 3: Rethinking Reactivity

#85

Post by Tade0 »

Hooks have some intriguing properties, but they also involve some unnatural code and create unnecessary work for the garbage collector.

Thank you for pointing this out. To me hooks were always a way to solve problems in React that wouldn't be there if it weren't for React. They help, but come at a cost which barely anybody seems to talk about.

We really want to add first-class TypeScript support.

Yes, please!

Re: Svelte 3: Rethinking Reactivity

#86

Post by anderspitman »

rich_harris wrote: post #83
anderspitman wrote: post #77

Earlier quoted context omitted.

Thanks for the article link; that was an excellent read. I don't think my post was very clear. I agree that the run-time complexity of svelte is much better than a vdom framework, but it seems like you're just trading that for build-time complexity. Maybe that's the only way to achieve what I'm talking about though. At some point you have to translate from immediate mode to retained mode if you're rendering to the do…

My view on this is that complexity, like energy, can only really be converted from one form into another. Normally the distinction is between runtime complexity and cognitive complexity — the result of hand-optimised imperative code. In other words, the classic trade-off between developer experience and user experience. Svelte's claim is that converting it into build time complexity is in fact the only sensible thing…

> My view on this is that complexity, like energy, can only really be converted from one form into another.

I like that. I'm definitely going to have to think on it some more.

> It doesn't really matter how much complexity is involved in `npm run build` if it means that DX and UX are no longer in tension.

As long is it doesn't break. I think Vue has a fantastic developer experience. As long as everything works you have incredible leverage as a developer. But the first time I tried to pass it a large nested object I lost many hours figuring out that I needed to call Object.freeze to prevent it from setting up reactive hooks on the whole thing (once set the data was static).

> One avenue I'm currently exploring is whether the same declarative/compiled model can be used as a wrapper around WebGL APIs, though it's very early days.

Keep us posted. I've done some experimenting on this myself. I built this[0] using a lisp-ish markup language I threw together. Think SVG with built-in support for defining and composing sub-components. The language compiles down to canvas calls at runtime. That version renders to 2d canvas, but I started a WebGL implementation that I haven't finished yet.

[0] https://anderspitman.net/apps/hardware-bubblesort/

Re: Svelte 3: Rethinking Reactivity

#87

Post by davnicwil »

burrox wrote: post #73
davnicwil wrote: post #61

> this.set is almost identical to the this.setState method used in classical (pre-hooks) React It's an amazing reflection on the velocity of the web & JS ecosystem that React APIs prior to hooks, which were shipped all of 3 months ago, can be sincerely referred to now as 'classical' :-)

I think he means 'classical'as in class based. Just like you'd refer to 'classical' inheritance.

You might be right - I've never heard 'classical' used in that way, interesting!

Re: Svelte 3: Rethinking Reactivity

#88

Post by Vinnl »

kylecordes wrote: post #11

I'm excited about the updated Svelte. Although it is currently nowhere near being in the top handful of frameworks by adoption, it has some very forward ideas. Most prominently, look at the first main value proposition on its website: “Write less code” Svelte has a ways to go to catch up with the leaders on popularity and future breadth, but it is focused on the right problem: reducing the cost/size/effort of making…

Funny: problems I think are important are "ship less code" and "read less code" (and perhaps "require reading less code to understand what's going on"). The writing part is not something I've considered to be especially problematic, thus far.

Re: Svelte 3: Rethinking Reactivity

#89

Post by PKop »

rich_harris wrote: post #10
revvx wrote: 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.

Great work, just looking in to Svelte now after reviewing your latest release and video. First thing I looked for was routing, and I see Sapper is essentially batteries-included solution to using Svelte.

Will these always be separate libraries? Is Sapper basically the create-svelte-app for your framework? What's the roadmap for Sapper and integrating Svelte v3 changes?

Re: Svelte 3: Rethinking Reactivity

#90

Post by rich_harris »

Vinnl wrote: post #88
kylecordes wrote: post #11

I'm excited about the updated Svelte. Although it is currently nowhere near being in the top handful of frameworks by adoption, it has some very forward ideas. Most prominently, look at the first main value proposition on its website: “Write less code” Svelte has a ways to go to catch up with the leaders on popularity and future breadth, but it is focused on the right problem: reducing the cost/size/effort of making…

Funny: problems I think are important are "ship less code" and "read less code" (and perhaps "require reading less code to understand what's going on"). The writing part is not something I've considered to be especially problematic, thus far.

Allow me to try and convince you of its importance :) https://svelte.dev/blog/write-less-code
Post reply on HN