This is really cool. That said, I noticed that it cites performance vs vdom as a selling point. Something I've been wondering lately is how big of an issue is UI performance for most web apps really? So many of the little apps and prototypes I develop aren't hurting for performance. It seems to me the industry made a huge leap from JQuery/Backbone/etc to reactive/vdom. But declarative UIs and virtual doms don't solve exactly the same problem; they just go well together. Are there any frameworks out there that provide a JSX/VueSFC/hyperscript development experience, without adding the complexity of a virtual dom implementation? I think developing UIs in a declarative fashion is a big win, but having a virtual dom seems like it should be treated more like an optimization to me.
back
3 comments
> Are there any frameworks out there that provide a JSX/VueSFC/hyperscript development experience, without adding the complexity of a virtual dom implementation?
Svelte is intended to be exactly that!
Whether performance is an issue depends partly on the kind of app you're building. In my line of work (producing interactive data visualisations etc) it absolutely is. As I talk about here, it's going to become even more important as the 'embedded web' becomes a thing: https://youtu.be/AdNJ3fydeao?t=1498
Bonus thoughts on virtual DOM: https://svelte.dev/blog/virtual-dom-is-pure-overhead
Thanks for the article link; that was an excellent read.
I don't think my post was very clear. I agree that the run-time complexity of svelte is much better than a vdom framework, but it seems like you're just trading that for build-time complexity. Maybe that's the only way to achieve what I'm talking about though. At some point you have to translate from immediate mode to retained mode if you're rendering to the dom.
I also work in interactive visualizations. I think this is one of the areas (in addition to games especially) where vdoms quickly fall short. Once you start animating a lot of SVG elements, it doesn't matter much what framework is under the hood; it's going to crawl. Canvas/WebGL is the only real solution I'm aware of. Does svelte somehow provide a significant speedup in these situations? I obviously need to read up more on what your compiler is actually doing.
My view on this is that complexity, like energy, can only really be converted from one form into another. Normally the distinction is between runtime complexity and cognitive complexity — the result of hand-optimised imperative code. In other words, the classic trade-off between developer experience and user experience.
Svelte's claim is that converting it into build time complexity is in fact the only sensible thing to do. It doesn't really matter how much complexity is involved in `npm run build` if it means that DX and UX are no longer in tension.
But to answer your point about SVG, Svelte has to obey the same fundamental constraints as any other code, so you will eventually hit performance issues (though you may enjoy this demo https://youtu.be/AdNJ3fydeao?t=1138). One avenue I'm currently exploring is whether the same declarative/compiled model can be used as a wrapper around WebGL APIs, though it's very early days.
> My view on this is that complexity, like energy, can only really be converted from one form into another.
I like that. I'm definitely going to have to think on it some more.
> It doesn't really matter how much complexity is involved in `npm run build` if it means that DX and UX are no longer in tension.
As long is it doesn't break. I think Vue has a fantastic developer experience. As long as everything works you have incredible leverage as a developer. But the first time I tried to pass it a large nested object I lost many hours figuring out that I needed to call Object.freeze to prevent it from setting up reactive hooks on the whole thing (once set the data was static).
> One avenue I'm currently exploring is whether the same declarative/compiled model can be used as a wrapper around WebGL APIs, though it's very early days.
Keep us posted. I've done some experimenting on this myself. I built this[0] using a lisp-ish markup language I threw together. Think SVG with built-in support for defining and composing sub-components. The language compiles down to canvas calls at runtime. That version renders to 2d canvas, but I started a WebGL implementation that I haven't finished yet.
It's really surprising that people put faith in virtual Dom implementations, when browsers have been optimized for decades for efficiency. With the right batching strategy that minimalistic libraries like FastDom [1] offer, there's no real reason to use the virtual Dom.
A frequent argument for the use of vdom has been that it reduces Dom trashing. I am willing to bet that if a vdom library has figured out what elements don't need updating, the browser's Dom implementation tuned over decades has that logic built-in. So go ahead and trash the Dom, but batch your updates and the browser's logic will likely not trash more than necessary. And since that logic is implemented in an AOT compiled language, it probably is much faster than a js v-dom
I was waiting for someone to post this. We have tried hyperhtml, various VDOM implementations like Vue and React, but nothing compares for our complex app. We use FastDOM however we are starting to realize it may in fact be causing some issues with write conflicts with third party scripts requiring DOM mutations. That said requestAnimationFrame which FastDOM also uses, can be majorly helpful for any thrashing. Curious what Rich thinks of FastDOM library or while I'm at it his opinion on (not a UI)..https://meiosis.js.org/
People used to look at me like I was crazy when I told them that React is nice, but you can actually write faster code with alternative methodologies. It seems like other engineers are coming around to this and creating these faster alternatives.
React made writing frontends generally better, but often slower and as rich_harris points out that it entails a lot of developer work to build and use optimizations to speed it up.
I like it. You can only hide so much comlexity in 600 bytes. Something like fastdom could probably facilitate what I'm talking about. Basically don't bother diffing, but only actually touch the DOM once per frame. So I guess in that case you'd have tons of "phantom writes" to fastdom as the state is reactively updated.
Large React apps get slow very easily once the component density gets high in a complex web app. Part of the reason for that is actually the overhead of a virtual DOM.