7 ms·

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

by matchu 10y ago

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.

rich_harris 10y ago
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.
- the_duke 10y ago
  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.
  - rich_harris 10y ago
    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 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.
  - proyb2 10y ago
    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.
    - trueadm 10y ago
      What issue did you have with Inferno, would mind reporting it please so we can fix it? :)
      - proyb2 10y ago

by matchu 10y ago

rich_harris 10y ago

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.

the_duke 10y ago
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.
- rich_harris 10y ago
  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 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.
- proyb2 10y ago
  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.
  - trueadm 10y ago
    What issue did you have with Inferno, would mind reporting it please so we can fix it? :)
    - proyb2 10y ago