Live data from Hacker News

Svelte 3: Rethinking Reactivity

svelte.dev

71–80 of 186 posts

Re: Svelte 3: Rethinking Reactivity

#71
post #59

Congratulations on the release, Rich! Minor suggestion: it should be easier to find how to get started (read install) for people trying to give Svelte a try. I had already played a bit with Svelte before but wanted to try v3 and the only thing I could find about how to install it was in https://svelte.dev/blog/the-easiest-way-to-get-started .

Agree, we can always improve onboarding. We have some simple instructions using `npx` on the homepage, but we'll try and signpost it better.

Re: Svelte 3: Rethinking Reactivity

#73

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

Re: Svelte 3: Rethinking Reactivity

#74

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…

> 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 more important as the 'embedded web' becomes a thing: https://youtu.be/AdNJ3fydeao?t=1498

Bonus thoughts on virtual DOM: https://svelte.dev/blog/virtual-dom-is-pure-overhead

Re: Svelte 3: Rethinking Reactivity

#75
I recommend everyone to take a look at the talk linked in the article. It gives you a good overview of how awesome svelte is and how easy it is to use.

I chose vue over react for simplicity and I'll be damned if I don't choose svelte over vue for the same reason and more after this talk.

Re: Svelte 3: Rethinking Reactivity

#76

Hey Rich if you're still lurking - I really like the Tutorial layout (even on mobile!) and how that all works. Is this something you built yourself or is there a re-usable component that I can use?

It was all built in-house by me and other members of the Svelte community. The playground widget is technically a standalone thing, but it wasn't totally designed to be used outside https://svelte.dev so may be a bit warty! https://github.com/sveltejs/svelte-repl (the code for the site itself is in the main project repo https://github.com/sveltejs/svelte/tree/master/site)

Re: Svelte 3: Rethinking Reactivity

#77

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…

> 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 dom.

I also work in interactive visualizations. I think this is one of the areas (in addition to games especially) where vdoms quickly fall short. Once you start animating a lot of SVG elements, it doesn't matter much what framework is under the hood; it's going to crawl. Canvas/WebGL is the only real solution I'm aware of. Does svelte somehow provide a significant speedup in these situations? I obviously need to read up more on what your compiler is actually doing.

Re: Svelte 3: Rethinking Reactivity

#78

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 was waiting for someone to post this. We have tried hyperhtml, various VDOM implementations like Vue and React, but nothing compares for our complex app. We use FastDOM however we are starting to realize it may in fact be causing some issues with write conflicts with third party scripts requiring DOM mutations. That said requestAnimationFrame which FastDOM also uses, can be majorly helpful for any thrashing. Curious what Rich thinks of FastDOM library or while I'm at it his opinion on (not a UI)..https://meiosis.js.org/

Re: Svelte 3: Rethinking Reactivity

#79
post #55

Earlier quoted context omitted.

We certainly debated this one over in the Discord channel...

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)

Re: Svelte 3: Rethinking Reactivity

#80

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

Post reply on HN