> you run into performance problems at the same number of elements regardless of whether they're interactive. As you implemented for the some of these pages, the solution is to go to a canvas.
That's surprising. I thought Svelte's whole selling point was ultra-targeted and efficient DOM updates as a result of the compilation step and not having vdom. Are simple large tables still a problem within that paradigm? Which of the elements here, eg, could have been rendered via DOM but needs canvas purely for perf?
The browser can take very long to layout and draw a page with a huge number of DOM elements.
Hardware starts to mask a lot of these issues, but even a table with 1000 to 10,000 rows will already cause issues. And table layout is very optimized (for this reason, there are plenty of CSS gotchas around tables). So a 10,000 row plain HTML table still is rendered relatively fast, but not practical for an interactive UI.
But for "snappy" UI and more involved CSS + many nested DOM elements, you'll need to start to consider viewport virtualization a lot earlier.
This is independent of JS UI frameworks though.
HTML+CSS rendering is an expensive, blocking operation. CSS even requires multiple passes for rendering nowadays AFAIK. Of course this is optimized to hell by browsers too.
But you still need "viewport virtualization" in markup+CSS, or switch to canvas rendering, which does away with the markup and CSS entirely.
VS Code Editor which is based on Electron, is really fast, even with large codebase & many open tabs. Their monaco engine (https://microsoft.github.io/monaco-editor/) uses custom, virtual code processor that is optimized for surgically updating underlying DOM. It also uses WebGL + canvas rendering to show minimap of the file.
Similar approach (custom virtual processor) is leveraged by Google docs/sheets.
Canvas rendering may be the last resort when nothing worked.
As far as I know, VSCode/Monaco does use viewport virtualization
> Canvas rendering may be the last resort when nothing worked
For the minimap, yes. But AFAIK, for text rendering, it's not really a goto solution. Text wouldn't look crisp enough, apart from the fact that text layout is a science in itself.
Basically you can get away with a debounced and cached canvas version of the full rendered DOM for that minimap, but you cannot use a huge DOM representing the full source for the actual editor.
Docs afaik implements an expensive custom text rendering engine, similar to Flutter.
Monaco doesn't.
Take it with a huge grain of salt, I haven't researched this really and generally am not very familiar with the Monaco or VsCode source. I'm on mobile, so not inspecting a Monaco instance either.
The Monaco repository seems to contain some files only in minified form, and refers to the VsCode repo.
Skimming through the interfaces there, it definitely seems to have hints for viewport virtualization.
Apart from that, WebWorkers seem to be used heavily to move the language server logic out of the main thread (completely different topic).
What I wanted to say is that "surgical DOM updates" might be good, but DOM _size_ is the main issue for rendering.
Sure, heavy-handed DOM updates have an effect too (it's the same as rendering a new large DOM tree).
But keeping DOM elements consistent instead of replacing large subtrees is without alternative anyway, regardless how optimized browser rendering and parsing will ever be, because of focus states for example.
Also worth noting that querying layout via JS is similarly expensive (not related to Svelte either).
Back to your comment:
React might be less performant than Svelte, but a React "render" is not as expensive as a browser rendering the changed DOM.
And Svelte's main differentiation is that it doesn't need a runtime in the browser and instead directly produces DOM-API code.
The difference is not on the number of updates (React, Vue etc are "surgical" there too). It's how the required DOM API calls are computed.
I can't speak to perf differences between 4 and 5 specifcally, but I'm pretty sure Svelte's mission has been "no vdom" from the start. Here's a 2018 article, eg:
Svelte first came around in 2015-2016, and never had a virtual DOM - it was actually the one that introduced compiler-based optimizated DOM updates. This is mentioned in the Solid.js documentation [1].
Svelte itself is a successor to Ractive.js which already existed in 2013 [2] with similar ideas, but before JS transpilers came into the picture.
That's surprising. I thought Svelte's whole selling point was ultra-targeted and efficient DOM updates as a result of the compilation step and not having vdom. Are simple large tables still a problem within that paradigm? Which of the elements here, eg, could have been rendered via DOM but needs canvas purely for perf?