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