Comment by matchu | Hacker News Reader

Comment by matchu | Hacker News Reader

Parent Full thread

Oh! I think I'm fundamentally misunderstanding the pitch here. Here's my new guess: Svelte analyzes my component tree to discover the graph of data dependencies… and then throws out the component tree entirely, instead outputting code that directly implements my data flow graph.

Is that correct? If so, it's a very cool idea! (I'd been tossing this idea around for a few months last year, but had trouble designing a non-awful API xP)

I wish there were a way to make the messaging around this idea clearer. I know that audiences are different, and this wouldn't work for everyone. But if the introductory blog post had illustrated the transformation from component tree to data graph, I would've immediately understood the performance implications and how this represents a huge paradigm shift in application compilation.

Instead, though, I thought the pitch was "ew, separate runtime library? let's inline it and then it'll be smaller", which seemed misguided. I had to reverse-engineer Svelte's motivation from your comment—and even now I'm still not sure I got it right. (Maybe this entire comment is wrong? Could be wrong. No idea :/)

Are y'all planning a blog post about how Svelte works under the hood? That would go a long way toward clarifying the pitch, I think.

Sort of, yeah. The previous wave of declarative UI libraries essentially followed one of two models — there's the 're-render the entire app then apply a diffing algorithm' approach (React and its many imitators), and there's the data-binding approach (Knockout, Rivets, Ractive and later Vue) whereby different nodes in your model/state/data graph (whatever you want to call it) are linked to the DOM, usually via various levels of indirection.

Both are solid ideas. (As the creator of Ractive I'm biased towards data-binding, but React's success speaks for itself.) But either way, the library has to do a lot of work to essentially just translate state changes into `element.setAttribute('foo', 'whatever')` and so on. Svelte was born out of a realisation that if you can understand the shape of your component graph at build time, you can eliminate those runtime abstractions — and with it, both the bytes and the computational cost associated with them.

> Are y'all planning a blog post about how Svelte works under the hood?

Yes, we have a lot of blog posts we need to write! Hopefully soon.

Please correct me if I'm off base here, but isn't a big part of the whole virtual-dom abstraction performance?

Direct DOM updates are slow (rerender), diffing and smart patching much faster. There must be a reason for virtual doms becoming so popular, even for frameworks that don't have a 'functional' approach like React.

Great question! It's a very common misconception that an app that uses virtual DOM diffing somehow manages to be faster than an app that manipulates the DOM directly.

Re-rendering your entire app (i.e. creating all the nodes from scratch with innerHTML or document.createElement) is too slow for a lot of apps, and is a bad idea for lots of other reasons (losing state in form elements, etc). Virtual DOM just gives you a way to write your app as though you were re-rendering it from scratch, while still being fast enough that you can get away with it.

Svelte is significantly faster than React according to https://github.com/krausest/js-framework-benchmark, because it's taking a more direct approach to the same goal — updating existing elements or only creating/destroying them as necessary. It's also faster than Ember, Angular, Vue, etc. It's not yet quite as fast as Inferno, but it uses less memory.

Agreed with Rich, it's a misconception that virtual-dom is faster, web browsers have made significant improvement to DOM. There must be a reason why vanilla Javascript is fastest than most virtual-dom.

Inferno-1.1.0 have an error at runtime, could not test JS Framework right now. Sveltejs works.

What issue did you have with Inferno, would mind reporting it please so we can fix it? :)

Inferno in JS framework replies use beta, I guess that broken.

Virtual DOMs are used to make the rerender-everything-all-the-time approach acceptably fast, which is desirable since that approach tends to lead to nice UI code with few state related bugs. Still, this is a pretty costly way to update the UI, as the virtual DOM causes a lot of memory churn.

Hmm, okay. I'm starting to poke at the TodoMVC's compiled code in the debugger, and it's not quite the super-duper-aggressive graph conversion that I was imagining—but it's interesting to look at :)

Reply on news.ycombinator.com