Item — HN Reader

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.

1 comments

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.

[0] https://anderspitman.net/apps/hardware-bubblesort/