An experiment in UI density created with Svelte • Hacker News Board

Re: An experiment in UI density created with Svelte

#151

Post by funcDropShadow » Sun, Jul 28, 2024, 6:22 AM UTC

solardev wrote: post #96

mhh__ wrote: post #80

I 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…

> Here's an example table with 100,000 cells ...

> 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.

No, it is not a lot of cells in a table. It is something a Windows95 era PC had no problem doing in something like Delphi Builder. And you find it acceptable that it slows down, if an M2 Max throttles down? Even a throttled down M2 Max is supposed to be 1000x (obviously an exageration, because I am to lazy to apply Moore's Law more rigorously on a Sunday morning) faster than an Intel 486DX. Where did all the compute power go? Are we really using the right tools for our jobs?

Re: An experiment in UI density created with Svelte

#152

Post by funcDropShadow » Sun, Jul 28, 2024, 6:25 AM UTC

doctorpangloss wrote: post #143

mhh__ wrote: post #80

I 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.

> Well, Instagram is basically the only application people use, along with e-mail, YouTube and TikTok

No, those people are not using email, they are using what Google tells them what email is. A poor imitation of email.

Re: An experiment in UI density created with Svelte

#153

Post by funcDropShadow » Sun, Jul 28, 2024, 6:31 AM UTC

solardev wrote: post #108

ChrisMarshallNY wrote: post #82

Earlier quoted context omitted.

I suspect Bloomberg terminals fit that bill.

I'd never heard of those until your post, and had to look up a Youtube about what they were: https://www.youtube.com/watch?v=2ee-x6IXWK8 That's super fascinating. There's an entire industry that runs off these things, on their totally custom UI, showing everything from stock tickers to news headlines to maps? That must be a fun project to work on (except probably the finance users don't like random UI changes, lol).

> except probably the finance users don't like random UI changes, lol

I have bad news for you, nobody who works with a system more than casually, likes random UI changes. NOBODY. Younger people are often more tolerant to these distractions, because they are often more curious. But when you have used a tool for some longer time, and suddenly it looks or behaves different, that erodes trust. That forces the user to turn of the mental autopilot and to proceed with care. Which A/B tests will report as increased engagement of the users. And there is our vicious cycle.

Note, how a scheduled update with release notes does the opposite. It increases trust, because it tells you what is going to happen and then it happens. (Hopefully)

Re: An experiment in UI density created with Svelte

#154

Post by arendtio » Sun, Jul 28, 2024, 6:34 AM UTC

karaterobot wrote: post #3

That helix chart is very sexy. I'm not really sure I could use it, but danged if it isn't cool looking. If this is an experiment, what were your conclusions?

It doesn't seem to work in Firefox, or is it just me?

Re: An experiment in UI density created with Svelte

#155

Post by funcDropShadow » Sun, Jul 28, 2024, 6:36 AM UTC

solardev wrote: post #97

andrewstuart wrote: post #89

Earlier quoted context omitted.

>> 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).

But isn't that exactly the point of such UI libraries? To provide those optimizations. Because the easy case, I can do myself.

Re: An experiment in UI density created with Svelte

#156

Post by pfix » Sun, Jul 28, 2024, 6:36 AM UTC

funcDropShadow wrote: post #151

solardev wrote: post #96

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…

> Here's an example table with 100,000 cells ... > 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. No, it is not a lot of cells in a table. It is something a Windows95 era PC had no problem doing in something like Delphi Builder. And you find it acceptable that it slows down, if an M2 Max throttles down? Even a thro…

In general I agree with your sentiment. But here we are in a browser environment so we should compare performance to a raw HTML table. And then complain if the raw HTML is still slower than Delphi on win95 because HTML tables have been around since back then :D

Re: An experiment in UI density created with Svelte

#157

Post by cageface » Sun, Jul 28, 2024, 6:38 AM UTC

solardev wrote: post #150

cageface wrote: post #138

Earlier quoted context omitted.

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.

I agree that React is fast enough for a lot of things without worrying too much about performance.

I've also worked on several apps where we had to work really really hard to get decent performance out of React and the resulting code was ugly and brittle.

Re: An experiment in UI density created with Svelte

#158

Post by elschneider » Sun, Jul 28, 2024, 6:44 AM UTC

felipefar wrote: post #135

Low 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…

I think there is a fundamental difference depending on what kinds of users you are targeting and how often they're using your app. Blender is a prime example of software for professionals, that are also willing the spend a considerable amount of time on learning the UI. A lot of software is not targeting a similar audience and should limit cognitive overload.

Re: An experiment in UI density created with Svelte

#159

Post by zozbot234 » Sun, Jul 28, 2024, 6:44 AM UTC

felipefar wrote: post #135

Low 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…

Touch interfaces have less pointing precision, but more swiping precision compared to mouse interfaces. The optimal touch interface probably involves lots of pie menus and/or drag-and-drop gestures that ought to easily compensate for the somewhat increased size of initial touch targets. (Note that, by contrast, these gestures tend to be quite awkward when using mouse or touchpad input.)

Re: An experiment in UI density created with Svelte

#160

Post by solardev » Sun, Jul 28, 2024, 6:47 AM UTC

funcDropShadow wrote: post #151

solardev wrote: post #96

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…

> Here's an example table with 100,000 cells ... > 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. No, it is not a lot of cells in a table. It is something a Windows95 era PC had no problem doing in something like Delphi Builder. And you find it acceptable that it slows down, if an M2 Max throttles down? Even a thro…

I think all software is a balance of factors, from performance to ease of use to DX to maintainability, cost, etc.

I don't think most tables need to be as peformant as possible, especially when a slow render is still measured in sub-seconds.

That level of performance is totally fine for many use cases. If you have a special need for large datasets, yes, you should pay more attention to how that's optimized.

But for your average bog standard web app, I think any framework will be just fine, performance wise, on any 10 ish year old device. If it's slow, it's more likely because of ads, tracking, large media, poor caching, distance from a CDN, etc. Especially since React these days is typically rendered to HTML during the build anyway and then rehydrated for interactivity later.

React isn't a performance optimization to begin with, but a DX improvement and architecture abstraction lib (vs vanilla or jQuery). It makes some apps much easier to write and maintain across generations of low cost developers. The performance is a small sacrifice, but it's usually not even noticeable.

For performance critical apps, probably you'd just bypass the DOM anyway and draw to canvas instead, and offload all the heavy processing to wasm.

Yeah, compared to the 90s, our computers and modems are much faster and used less efficiently. But there are billions more users and millions more developers of various skill levels now, and that's just a tradeoff we get for mass adoption. It's no longer just a tool for elites, but just another tool in the office, and often times a race to the bottom like anything else in business (in terms of React devs being low cost commodities). A small React team can put together a functional app much quicker and cheaper than with vanilla, at the cost of some usually negligible performance. Probably a good tradeoff for most apps.

If you're talking about web apps in general, compared to desktop or CLI apps, then yeah, I agree that it's a bit of a shame this is what won the desktop platform wars. At least on mobile we have native apps (which often feel much faster than anything web based), so there's that at least.