231–240 of 267 posts
https://en.wikipedia.org/wiki/Tempest_(video_game)
except it really is a helix and not a cylinder like a Tempest level. Still would be fun to fight bugs in.
Earlier quoted context omitted.
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. B…
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 ren…
> 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.
https://github.com/microsoft/vscode/blob/2c46cf10d6773e690cb...
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.
On mobile, if I zoom out to 85% everything gets smaller and more things fit on the screen (great!). Zooming out further to 75% makes everything larger... 50% and things get larger still (more so than they were at their default size at 100%). The layout works remarkably well on mobile regardless, but I wasn't expecting such unintuitive zoom behaviour.
>I wasn't expecting such unintuitive zoom behaviour. Huh. I expect user-interface surprises on web pages. Interacting with the other user interfaces in my life is much less surprising.
Earlier quoted context omitted.
> I think high information density === high intelligence. Just packing loads of stuff on-screen at once, with tiny fonts and tiny margins and all the rest presents a lot of accessibility issues, even for intelligent people. Google et al are adding padding and white space to make their UIs more accessible for more people. It's not just eye sight we're talking here, but also physical issues with clicking/tapping small…
> Google et al are adding padding and white space to make their UIs more accessible for more people. It's not just eye sight we're talking here, but also physical issues with clicking/tapping small targets accurately (e.g. someone with Parkinson's), and also neuro divergent issues where a page full of text or whatever can disorient just by sheer amount of stuff happening on-screen at once (e.g. epilepsy) We’re not in…
I deal with a lot of data in tabular form, and I like to have as much of it in front of me at once as I can. The biggest influence on my report design has been, believe it or not, iTunes: no more padding than necessary, zebra striping, fast and easy sorting, and something like a column browser if possible. I've been using DataTables happily for years. One thing I've been experimenting with lately is sorting vs. showi…
I absolutely love it, very intelligently put together. The gold standard for this in the terminal is btop. Check it out if you’re into this sort of thing: Example: https://terminalroot.com.br/assets/img/cpp/btop.png Repo: https://github.com/aristocratos/btop
Earlier quoted context omitted.
> looking to move it all to svelte because react literally cannot handle the quantities of data I have nothing against Svelte, but how much data are you showing on screen, exactly? Here's an example table with 100,000 cells (100 rows * 1000 columns per row) that seems fine, from a common React UI kit: https://mui.com/x/react-data-grid/virtualization/#column-vir... It seems fast on my computer normally (M2 Max), slow…
It's defective because the browser's find feature does not work.
I'd like to think projects like these are somehow signaling a return to well designed but information dense , space saving interfaces ... The amount of bloat, whitespace, extra spacing, "air" and other such waste - starting with (now Google-dead) "Material Design" has been egregious.- (One can dream ...)
I think it started with Apple when switching from OS 9 to OS X, I couldn’t explain it at the time and still feel disappointed with so much waste of expensive screen estate.
But since Big Sure it means that it got even worse than what It was with the first version of OS X. I remember how crazy it was it setup a mac emulator, set it's resolution to my mac's resolution, full screen mode, and see how much space you could have with classic Mac OS, it's just crazy and everything remains legible.
Suddenly the windows desktop metaphor makes more sense because you can actually have many windows next to each other. OS X has almost always tried to diverge from than, that lead to great things like exposé, spaces and then mission control but it looks like they never considered to reduce elements size.