[matchu]

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.

[rich_harris]

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

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.

[pedalpete]

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.