This is surprisingly fast. A really impressive showcase of the design philosophy of Svelte. Even loads and renders fast on mobile!
DOM Loaded: 134ms
FCP/FP: 163ms
LCP: 218ms
TTI: 1826ms
An experiment in UI density created with Svelte
141–150 of 267 posts
Re: An experiment in UI density created with Svelte
#142I 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…
I don't know what GitHub projects uses but we have ~200 tickets in it and it absolutely chugs. Even typing text into new entries will regularly hang for multiple seconds every few words.
Re: An experiment in UI density created with Svelte
#143I 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…
> Programmers and designers keep trying to rebuild instagram in every domain, pretty UIs, regular UIs, "simple" UIs.
Well, Instagram is basically the only application people use, along with e-mail, YouTube and TikTok. Some people use Spotify, and fortunately no one is trying to copy its design, so I feel like the programmers and designers are onto something.
Re: An experiment in UI density created with Svelte
#144It's a thing of beauty
Re: An experiment in UI density created with Svelte
#145Earlier quoted context omitted.
> 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?
it is specifically the signals-based approach pioneered by Solid, https://youtu.be/82dzMKZzHrY?t=12314
Re: An experiment in UI density created with Svelte
#146I 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 love Svelte and agree with you about performance, but its built-in CSS management has some showstopper bugs that are more likely to become apparent the bigger your app gets. If you use :global to target elements in child components (which is inevitable), you’ll run into specificity issues caused by Svelte not removing CSS after components stop rendering. Apparently it’s “by design”, i.e. it’s too hard for the Svelte maintainers to figure out and/or cleaning up would hurt them in benchmarks.
I guess it’s OK if you use something else for CSS such as Tailwind.
Re: An experiment in UI density created with Svelte
#147Earlier quoted context omitted.
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.
> there are a lot of support staff who have bloomberg.
Re: An experiment in UI density created with Svelte
#148Low UI density is the new emperor's clothes in modern UI design. It's being actively promoted by companies in order to cut design costs, but the truth is that it's only reasonable on touch interfaces or casual apps. Mouse interfaces are fundamentally different, because you have much more pointing precision, so it pays off to show more data on the screen. You don't have to cram your interface with with spaces to make…
> It's being actively promoted by companies in order to cut design costs I'm curious why you think it reduces design costs to put less information on the screen? My experience has been the reverse -- the companies that chase trends (including but not limited to low-information-density screens and using mobile-first designs for desktop applications) also tend to spend more money on UI design compared to other companie…
> I'm curious why you think it reduces design costs to put less information on the screen?
The question is for whom it saves costs? For the developers of UI framework it certainly saves cost to treat the desktop as a second rate platform and to focus just on mobile.
Developers of desktop applications have to pay the price, by working around libraries and frameworks that do not consider them as a first tier clients.
Re: An experiment in UI density created with Svelte
#149I 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…
It's always worth thinking about who the audience / userbase of your UI is, and whether they'd benefit from an expert user interface [1] or not.
Sometimes, they would (e.g. the "users paid more than the programmers" rule of thumb, but also: various technical disciplines, most anything used for professional-grade work). Sometimes, they wouldn't - or perhaps some would and some wouldn't (so perhaps you're looking for a simple base UI with some accelerators [2]).
IMHO the issue is that many products fall into this last camp - where a well-designed simple UI is called for, but also accelerators could greatly help a small but important subset of power users - but we treat the power users as though they don't exist.
[1] https://www.nngroup.com/articles/testing-expert-users/ [2] https://www.nngroup.com/articles/ui-accelerators/
Re: An experiment in UI density created with Svelte
#150Earlier 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…
React is also considerably slower than svelte in this benchmark in selecting, clearing, adding and creating rows and also uses a lot more memory. For a lot of apps React is fast enough but you're definitely starting at a non-negligible performance disadvantage compared to faster frameworks.
I don't know that a 15 millisecond difference in rendering performance is going to matter to anyone =/ The memory usage is in megabytes too. It's not much. For sure React is slower on paper, but in most cases it's a non-issue. Nobody chooses React for its performance benefits anyway, but because of its huge ecosystem of libs and developers. In most cases it's fast enough.