Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An experiment in UI density created with Svelte

cybernetic.dev

Post reply on HN
Print view View original

11–20 of 267 posts

Re: An experiment in UI density created with Svelte

#11

Post by jonahx »

daemonologist wrote: post #8

Some very cool looking UI elements here, but I'm also wondering what the experiment was and what conclusions you drew from it. On sheer number of interactive elements, my experience (Svelte 4) is that the rendering usually starts to cause problems before the interactivity, i.e. you run into performance problems at the same number of elements regardless of whether they're interactive. As you implemented for the some o…

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

Re: An experiment in UI density created with Svelte

#13

Post by jeffbee »

This obviously does not fit "as much data on a screen as possible". My laptop has a 7.7 megapixel display and each pixel has 1 billion possible states. This page is putting maybe 10000 bits of information on the screen, not even scratching the surface of machine's capacity.

Re: An experiment in UI density created with Svelte

#15

Post by razodactyl »

jeffbee wrote: post #13

This obviously does not fit "as much data on a screen as possible". My laptop has a 7.7 megapixel display and each pixel has 1 billion possible states. This page is putting maybe 10000 bits of information on the screen, not even scratching the surface of machine's capacity.

I hate that this can be taken seriously even though it's obviously a joke. It's a joke right?

Re: An experiment in UI density created with Svelte

#17

Post by razodactyl »

razodactyl wrote: post #15
jeffbee wrote: post #13

This obviously does not fit "as much data on a screen as possible". My laptop has a 7.7 megapixel display and each pixel has 1 billion possible states. This page is putting maybe 10000 bits of information on the screen, not even scratching the surface of machine's capacity.

I hate that this can be taken seriously even though it's obviously a joke. It's a joke right?

Seriously though. I'm finding it increasingly frustrating how small the screen is on my iPhone 13. Makes me wonder how the hell I managed on the 4. Perhaps I'm just getting old.

Re: An experiment in UI density created with Svelte

#18

Post by benatkin »

daemonologist wrote: post #8

Some very cool looking UI elements here, but I'm also wondering what the experiment was and what conclusions you drew from it. On sheer number of interactive elements, my experience (Svelte 4) is that the rendering usually starts to cause problems before the interactivity, i.e. you run into performance problems at the same number of elements regardless of whether they're interactive. As you implemented for the some o…

Svelte can be used with renderless components. https://imfeld.dev/writing/svelte_domless_components

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.

Re: An experiment in UI density created with Svelte

#20

Post by Mathnerd314 »

jonahx wrote: post #11
daemonologist wrote: post #8

Some very cool looking UI elements here, but I'm also wondering what the experiment was and what conclusions you drew from it. On sheer number of interactive elements, my experience (Svelte 4) is that the rendering usually starts to cause problems before the interactivity, i.e. you run into performance problems at the same number of elements regardless of whether they're interactive. As you implemented for the some o…

> 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. https://svelte.dev/blog/svelte-5-release-candidate

Disclaimer: I haven't actually looked at Svelte 4 to see why it is so much slower than Svelte 5

Post reply on HN