Well done. Tables are very dense, still easy to read. Proof that information hidden behind empty screens with tons of blank space has never been the way to go.
An experiment in UI density created with Svelte
91–100 of 267 posts
Re: An experiment in UI density created with Svelte
#92This a flashback to the DOS era for me, or CLI utils like 'top'. I can't quite express why, but I find it a bit ugly and vaguely annoying. Probably reminds me too much of unstyled spreadsheets, or maybe I've just been brainwashed by modern trends... Regardless, I guess my primary gripe with it is the cognitive overload. A bunch of numbers (stocks? not sure) and names that all look the same, sometimes with different c…
I wonder if it would feel less annoying if the majority of the text was a bit higher contrast
You can fiddle with the interface and tweak some layout parameters in the sidebar somewhat.
By the time I got it to something I liked, it severely violated the spirit of the experiment, lol (was too big and sparse, with lots of padding between items – the opposite of what it was trying to show): https://share.cleanshot.com/0xD9bPcWD1CL5wDvlVhB
And I still don't know how these numbers are used. I wouldn't be able to keep track of even 3-4 numbers at once, much less the dozens here.
Re: An experiment in UI density created with Svelte
#93Earlier quoted context omitted.
> 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…
> Svelte's whole selling point was ultra-targeted and efficient DOM updates as a result of the compilation step and not having vdom Going by performance ( https://krausest.github.io/js-framework-benchmark/ ), Svelte 4 is essentially vdom, Svelte 5 is ultra-efficient based on the direct-DOM approach pioneered by Solid. Svelte 5 is currently a release candidate, API stable but also not necessarily production ready. htt…
> ...pioneered by Solid
Excuse me what?
Re: An experiment in UI density created with Svelte
#94One thing I especially like about developing data-heavy financial apps in Windows Forms is the DataGridView control. High density and high performance with filtering, sorting, and drag-and-drop column reordering and resizing. No paging required; if you want to stick 10,000 rows in there, that's fine. Most of the UIs we write are screens full of DataGridView panes. Ugly? Yes. Fast? Also yes. My attempts to write simil…
WinForms is still probably my favorite UI framework. It's absolutely a blunt tool but by god can you swing it around. Incredibly flexible, reasonably easy to use, pretty fast, and ugly as all hell.
Hell, you can even throw arbitrary Objects at it and it will just work. You can nest PropertyGrids within PropertyGrids, extend them to collections of objects, build arbitrarily deep nests of controls. All without touching or even caring about the underlying structure of the objects your UI connects to (within limits).
WinForms is my platonic ideal of a UI framework. It's exactly how I would design things.
Re: An experiment in UI density created with Svelte
#95I work have built some dense UI for certain types of fixed income (bonds and swaps) trading, looking to move it all to svelte because react cannot handle the quantities of data (and if even if it could the code is unbelievably ugly). Something I've been banging on about for a while is the following: Programmers and designers keep trying to rebuild instagram in every domain, pretty UIs, regular UIs, "simple" UIs. This…
>> react literally cannot handle the quantities of data Presented at fact but I’m not sure this is universally correct. I don’t see why the application that is linked here couldn’t be done in react.
Yep not true at all lol. I’ve built extremely complex UIs with react with solid performance. Just need to know react better, I guess.
Re: An experiment in UI density created with Svelte
#96I work have built some dense UI for certain types of fixed income (bonds and swaps) trading, looking to move it all to svelte because react cannot handle the quantities of data (and if even if it could the code is unbelievably ugly). Something I've been banging on about for a while is the following: Programmers and designers keep trying to rebuild instagram in every domain, pretty UIs, regular UIs, "simple" UIs. This…
> 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 but usable when the CPU is throttled down 4x, and too slow after that. But that's a lot of cells.
Here's a performance comparison, btw: https://krausest.github.io/js-framework-benchmark/2024/table...
Or filtered down to just Svelte vs some common React libs: https://share.cleanshot.com/LlFXtNx9p6y4kMvqXgc7 (lower numbers are faster; React is generally just a little slower than Svelte, except when it's swapping 2 rows in a big table... then it's 8x slower)
Re: An experiment in UI density created with Svelte
#97I work have built some dense UI for certain types of fixed income (bonds and swaps) trading, looking to move it all to svelte because react cannot handle the quantities of data (and if even if it could the code is unbelievably ugly). Something I've been banging on about for a while is the following: Programmers and designers keep trying to rebuild instagram in every domain, pretty UIs, regular UIs, "simple" UIs. This…
>> react literally cannot handle the quantities of data Presented at fact but I’m not sure this is universally correct. I don’t see why the application that is linked here couldn’t be done in react.
The application linked here is only showing 270 cells at once. I think even the slowest framework can handle that...
It's when you get to thousands/tens of thousands of data points that things can really slow down without good optimizations, especially if you're modifying the DOM or manipulating SVGs (as opposed to drawing to Canvas, typically).
Re: An experiment in UI density created with Svelte
#98I work have built some dense UI for certain types of fixed income (bonds and swaps) trading, looking to move it all to svelte because react cannot handle the quantities of data (and if even if it could the code is unbelievably ugly). Something I've been banging on about for a while is the following: Programmers and designers keep trying to rebuild instagram in every domain, pretty UIs, regular UIs, "simple" UIs. This…
>> react literally cannot handle the quantities of data Presented at fact but I’m not sure this is universally correct. I don’t see why the application that is linked here couldn’t be done in react.
Removed the word "literally" (riffed too enthusiastically there) because my point was that's its already a bit slow, will only get slower as more things are added, and the code is already ugly despite being basically conventional/boring react.
The data I'm displaying also is quite deep and results in the creation of a lot of DOM elements (i.e. its visual rather than tabular). It noticeably chugs a bit even when the actual changes to be displayed are relatively small.
Re: An experiment in UI density created with Svelte
#99I work have built some dense UI for certain types of fixed income (bonds and swaps) trading, looking to move it all to svelte because react cannot handle the quantities of data (and if even if it could the code is unbelievably ugly). Something I've been banging on about for a while is the following: Programmers and designers keep trying to rebuild instagram in every domain, pretty UIs, regular UIs, "simple" UIs. This…
I suspect Bloomberg terminals fit that bill.
avg salary of a bloomberg user is lower than some people might think because there are a lot of support staff who have bloomberg.
As for the UI: I wish more things were like bloomberg, but bloomberg itself can be slightly hobbled by wanting to lay everything out as a table all the time when a custom chart designed by a creative domain-expert would be almost as useful.
Re: An experiment in UI density created with Svelte
#100I work have built some dense UI for certain types of fixed income (bonds and swaps) trading, looking to move it all to svelte because react cannot handle the quantities of data (and if even if it could the code is unbelievably ugly). Something I've been banging on about for a while is the following: Programmers and designers keep trying to rebuild instagram in every domain, pretty UIs, regular UIs, "simple" UIs. This…
> 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…
Amongst other things, the primary expense is lot of visual elements in a very dense chart that ideally would be ticking with the market in ~real time and allow more than one on the screen.
A lot of it probably should be a canvas but there's a good amount of interactivity on the chart itself so moving it all over might be expensive.
You obviously can bludgeon that into react but it's at the point where the diffing does seem to be non-trivially expensive and requires a bunch of nursing in the code which is frankly an insane waste of time in 2024.
React is completely fine for big tables, especially if they don't actually change very much.
I will also note that in turn this started out as a d3 project, react was much much faster than d3.
Edit: Completely forgot to mention memory consumption. We have beefy machines so it's not really a critical problem but think of the poor caches!