Having a super natural way to peer into the past as much as possible while the more recent data are larger is pure fcking genius. I can't believe why I never thought of this.

2. Companies don't want to design two very different UIs and by-in-large users prefer their skills transfer across platforms.

3. Accessibility is easier if the design leaves room for bigger font sizes and doesn't require fine motor control. Watching my dad start to noticeably age I'm realizing that even spacious spacious apps don't go far enough in this regard.

I'm not sure how we get to information dense design without something changing the forces that pushed us that way in the first place.

I thought it was still actively developed. Are you saying this has been killed by Google?

https://m3.material.io/

It definitely feels very influenced by it.

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.

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

You can be very intelligent, but still benefit from well-designed and accessible UIs. Don't assume people who need it are less intelligent.

1. You mentioned this in passing, but I'll repeat for emphasis: The contrast between a hovered/highlighted table row and ones that are not is too low. I have decent eyes and I also have a hard time seeing it.

2. Table rows (and/or columns) should be striped between two or more high contrast colors for better legibility. White, black, white, black for example. This table is all black through and through.

3. The table borders' contrast is way too low, it's hardly even visible. This combined with the singular row/column color makes legibility even worse.

TL;DR: Table itself is actually fine, the colors are terrible.

Svelte can also draw on a canvas. There is Threlte: https://threlte.xyz/

As for performance within Svelte, I don't think it needs something like Jotai as much as React does to prevent unnecessary re-rendering.

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 of the elements here, eg, could have been rendered via DOM but needs canvas purely for perf?

I'm biased, but as a frontend dev and sometimes-UI guy, responsive design is one of my favorite parts of the job. It forces me to think creatively (and scientifically, whenever we can actually afford to do testing) on how to present information and create controls for everything from a small iPhone to a giant ultrawide monitor.

I mean, even in the Windows days (as in when most apps were still desktop Windows apps), basic responsiveness was already a thing, since even then you had no guarantee your app was going to be running in fullscreen at 1024*768 only. How your main windows, toolbars, etc. scale to different screen widths & orientations is a fun challenge to solve. Even in gaming, it's fun to see how desktop games (like Terraria) scale their controls down to a phone.

Anyway, for me it usually ends up being about 1.5x the work compared to a single viewport, since most components can still be reused in slightly different arrangements. Menu navigation and information architecture can be tricky though, switching from "broad but shallow" organization to "narrow but deep" hierarchies.

Huh. I expect user-interface surprises on web pages. Interacting with the other user interfaces in my life is much less surprising.

Bit humbling, but there you have it.

Case in point: I have a fancy “prize wheel spinner” for UIKit, that I wrote, a few years ago[0]. I started working on a SwiftUI version of it, but stopped.

The reason was, because I kept not using it, in my shipping projects. It’s too “in your face.”

Some of the UI approaches that I tried, in my test app, were “sexy,” but I didn’t use any of them. The one I ended up using, was a bit pedestrian.

[0] https://github.com/RiftValleySoftware/RVS_Spinner

This is very wrong. Read the announcement and the docs: https://svelte.dev/blog/svelte-5-release-candidatehttps://svelte-5-preview.vercel.app/docs/introduction

Svelte 5 has change its reactivity model to signals. I anything, it's became similar to SolidJS. All other changes are minor but make Svelte even simpler to use.

I design, develop and maintain an ERP-style application with lots of tables. The fashions in UI design have made my life much more difficult over the last decade.

The problem is that designers tend to follow fashion trends. And the trend over the last decade has been "lightweight! clean! lots of space!". This is great if you are making a landing page, not so great if you need to display lots of data.

Google made things worse with its terrible UI design, which people accepted as mantra. Yes, there is lots of white. Your screen will mostly display… space. But just try using the Google Ads interface: it doesn't even fit in a normal browser, you need to have an extra-wide window just to see stuff in the tables. Not to mention they keep redesigning it, and every new update is hated by the customers, as well as by Google people (I've been told by Google ads consultants how to switch to the older interface, "which they all use because the new one is worse").

Another problem which compounds the situation for me is that designing tables is not cool. So, UI designers (and self-proclaimed UX experts) will "obsess" over every pixel in iOS-style switches that for some reason have replaced checkboxes, writing blog posts about how things are misaligned, while tables are left as an afterthought. Take a look at all modern UI toolkits: you will find very few with good tables, and likely not a single one with dense tables.

Oh, and on the functionality front: JavaScript libraries like DataTables are great for simple things, but are nowhere near a complete solution for complex apps.

Even Apple has sorely neglected their desktop APIs. Play around with SwiftUI on the Mac for more than a few hours and this will become glaringly apparent.

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

Another massive consideration is that a mouse (and a keyboard, if you want to expand from UI to UX) pairs that precision with significantly more available control actions - LMB, RMB, MMB, scrolling, and hovering.

With a mouse, the edges and corners of the screen are the easiest and most reliable areas to interact with; this is the inverse of touchscreen UIs, in which the center of the screen is the most ergonomic area of the screen to use, and edges and corners are practically unusable, leading to large margins in almost every UI targeting them.

With controls like LMB/RMB, you can also have functionality _immediately_ available wherever the pointer is located, which is now quintessential for practically all desktop applications, and which can't be faithfully emulated with touchscreen UIs.

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

If you look at Tailwind UI, which is clearly governed by the principles laid out in Refactoring UI, you can pretty much see the blueprint behind 95% of websites today.

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)

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.

I don't think React is to blame for your performance issues.

I guess it’s OK if you use something else for CSS such as Tailwind.

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/

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.

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.

(Svelte is awesome, mind, I compare the two to compliment them both)

https://static.crowdwave.link/index.html

And the source: https://static.crowdwave.link/sveltetest.zip

It's even got a batch update API.

I doubt that naively rewriting the app in Svelte is gonna give you the perf boost you're looking for.

That's why we like btop and htop, but a normal PC user wouldn't understand anything.