Live data from Hacker News

An experiment in UI density created with Svelte

cybernetic.dev

171–180 of 267 posts

Re: An experiment in UI density created with Svelte

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

* basically the only people from your bubble use

Re: An experiment in UI density created with Svelte

#172
post #168

Earlier quoted context omitted.

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.

I'm constantly frustrated by software that tries to limit cognitive overload. Stop treating your users as if they were cognitively impaired. In other words, write a software that also an idiot can use, and only idiots will want to use it.

> I'm constantly frustrated by software that tries to limit cognitive overload. Stop treating your users as if they were cognitively impaired. In other words, write a software that also an idiot can use, and only idiots will want to use it.

I disagree. I’ve been using IntelliJ for a few years now, and the new, simplified interface has made my experience a lot better. IMHO you should limit the cognitive overload but enable power users to increase it. See also Wikipedia, where the main editor is basic but if needed you can switch to the code editor and/or add plugins to make the interface a lot more powerful.

Re: An experiment in UI density created with Svelte

#173

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.

That usually just results in an excessive amount of clicks to get anything done.

Re: An experiment in UI density created with Svelte

#174

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

Ah, the always easy to discover (only in the mind of the designer) gestures.

Let's not forget that with the current gigantic size of phones, I can actually easily reach less than 50% of the screen. The top part is completely out of reach.

Re: An experiment in UI density created with Svelte

#175

Earlier quoted context omitted.

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

maybe oversimplified:

things on screen take effort. less things, less effort

Re: An experiment in UI density created with Svelte

#176

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.

The fact that it's fast enough on your 2000$ machine doesn't really tell us much.

Re: An experiment in UI density created with Svelte

#177

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

gestures are the time wasting way of doing a click

Re: An experiment in UI density created with Svelte

#178
post #169
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…

At $dayjob I work on a very dense UI for a financial institution. Think Bloomberg terminal in React and RTK. It's extremely customizable and had lots of elements updating multiple times per second (charts, graphs, enormous tables, etc.) with realtime data coming through over a websocket. We do very little actual performance tuning and mostly just follow best practices. I don't think React is to blame for your perform…

If seeing how common `eslint-disable-next-line react-hooks/exhaustive-deps` is any indication, people just don't bother with best practices. Not to mention the majority of people I interview or hire don't know anything about CSS performance, they learn on the job. They'll happily add 1000 box shadows in a view if it's in the design.

Also OP is looking to move an existing React UI to Svelte, why not try Preact first instead of an entire rewrite? Or even Inferno or million.dev? If they did and they're insufficient, I don't even believe the browser's DOM is the right technology for that UI then.

Re: An experiment in UI density created with Svelte

#179

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…

Is Cahier built on top of Zotero? It looks very similar.

Good notetaking support is something Zotero lacks, so I see the appeal for an alternative that focuses more on it.

Re: An experiment in UI density created with Svelte

#180
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…

I’m not going to discourage your move to svelte, but we do solar data from over a thousand plants and over a million inverter datapoints supplying literal fuckton of data every minute. We combine this with financial data from over 20 countries and budgeting from so many companies we’ve had to buy so many BC365 instances it’s ridiculous that we even use BC365. We present all of it, along with hundreds of tools in a react frontend. It has various backend services, from external to internal in c++, C#, Go, Typescript and Python

We don’t have performance issues with react. I’m not sure I’d really recommend react as such, with the way the ecosystem is leaning more and more into Next, but I doubt that its react itself which is giving you performance issues. I think you should look into how you’re loading and unloading data.

Post reply on HN