Comment by matchu | Hacker News Reader

Comment by matchu | Hacker News Reader

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.

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

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 :)

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.

Reply on news.ycombinator.com