4 ms·

I'm confused by the anti-runtime argument. The file size problem is about unused code, right? If we tree-shook the runtime and shipped the minimal version that

by matchu 10y ago

I'm confused by the anti-runtime argument. The file size problem is about unused code, right? If we tree-shook the runtime and shipped the minimal version that our app needs, wouldn't that be even better for most apps than inlining the framework? I'd expect that, the moment you use a feature even twice, the runtime approach yields a smaller bundle. Or is Svelte accepting a file size penalty to avoid the performance overhead of function calls? If so, it'd be nice to see that tradeoff discussed more explicitly: in every app, there are probably features worth inlining and features worth keeping as function calls. Really, it sounds like Svelte is trying to solve a very general compilers problem with a very specific sledgehammer solution. Sure, tree-shaking and thoughtful inlining are difficult to do well, especially in Javascript, so this makes sense as a first draft for certain use cases. I just wish it were touted as a first draft, rather than a new beautiful finished paradigm.

pedalpete 10y ago
I took the runtime to be the bootstrap time of the framework before your code actually runs, but I could be wrong. I'd like to see some performance metrics from Svelte compared to page loads with other frameworks to see where the savings are.
rich_harris 10y ago
> If we tree-shook the runtime and shipped the minimal version that our app needs I've heard this sentiment a lot. The reality is that UI libraries are inherently difficult to tree-shake. You can't run a library that can be used to produce an infinite range of outcomes and expect a tool like Rollup to whittle it down to just the bits you need (source: I'm the creator of Rollup). Code is reused. While the compiler will output 'standalone' modules by default, it can also generate modules that share code between components — the zero-runtime part is about generating abstraction-free DOM manipulation code rather than having a complex virtual DOM reconciliation or data-binding process. > rather than a new beautiful finished paradigm Nowhere does it claim to be finished. If anything, it's the start of a new approach to building UIs.
- 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.

by matchu 10y ago

pedalpete 10y ago

I took the runtime to be the bootstrap time of the framework before your code actually runs, but I could be wrong. I'd like to see some performance metrics from Svelte compared to page loads with other frameworks to see where the savings are.

rich_harris 10y ago

> If we tree-shook the runtime and shipped the minimal version that our app needs I've heard this sentiment a lot. The reality is that UI libraries are inherently difficult to tree-shake. You can't run a library that can be used to produce an infinite range of outcomes and expect a tool like Rollup to whittle it down to just the bits you need (source: I'm the creator of Rollup). Code is reused. While the compiler will output 'standalone' modules by default, it can also generate modules that share code between components — the zero-runtime part is about generating abstraction-free DOM manipulation code rather than having a complex virtual DOM reconciliation or data-binding process. > rather than a new beautiful finished paradigm Nowhere does it claim to be finished. If anything, it's the start of a new approach to building UIs.

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.