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

Jelly UI: Soft-body physics for native HTML form controls

jelly-ui.com

Post reply on HN
Print view View original

81–90 of 209 posts

Re: Jelly UI: Soft-body physics for native HTML form controls

#81

Post by hbcdbff »

Rohansi wrote: post #71
jlukic wrote: post #38

Saw the window was a bit laggy so thought I'd delve deeper to figure out what was going on. This lib runs a a RAF animation loop every 8ms across every component on the page that causes the entire document to repaint. The comment above appears of the AI generated sort: // One shared animation frame: step every live component, park when idle. // The delta is capped so a background-tab pause never becomes one giant ste…

> This is the kind of thing usually a human notices and says 'dont do that, that is kind of crazy'. It's not crazy. That is literally what 99.99% of video games do. They repaint everything constantly, only limited by either your vsync rate or hardware.

A website isn’t a videogame

Re: Jelly UI: Soft-body physics for native HTML form controls

#82

Post by nkrisc »

timcobb wrote: post #43
chrismorgan wrote: post #22

Please never use scroll-snap as is done on this demo page (unrelated to the soft-body physics). It leads to an awful experience for a large fraction of users. It improves things in one or two scenarios, but at the cost of far more common great frustration. Scroll-snap is a really risky feature, very niche in its reasonable applications. This is definitely not a suitable place to use it.

> It leads to an awful experience for a large fraction of users. can you give an example of why/how? I thought it was well done and enjoyable. Regular fast scroll was still as expected, and then the slower interactions felt like slide changes.

I’m on my phone and scrolling this page just leads to it constantly jumping up and down and makes it difficult to read as nothing stays in one place if I scroll a little bit.

Re: Jelly UI: Soft-body physics for native HTML form controls

#84

Post by Rohansi »

pennomi wrote: post #74
Rohansi wrote: post #71

Earlier quoted context omitted.

> This is the kind of thing usually a human notices and says 'dont do that, that is kind of crazy'. It's not crazy. That is literally what 99.99% of video games do. They repaint everything constantly, only limited by either your vsync rate or hardware.

Presumably in a video game the majority of the screen changes every frame. Not so in web pages.

My point was more that rendering a few widgets at 60+ FPS is nothing for anything with a GPU, and everything has a GPU these days.

Anyway, something like this only needs to paint when states change or animations are running. That's an easy optimization to make here if it doesn't do it already. And games don't even bother with it, they repaint all UI even if it doesn't change.

Re: Jelly UI: Soft-body physics for native HTML form controls

#88

Post by altairprime »

Rohansi wrote: post #84
pennomi wrote: post #74

Earlier quoted context omitted.

Presumably in a video game the majority of the screen changes every frame. Not so in web pages.

My point was more that rendering a few widgets at 60+ FPS is nothing for anything with a GPU, and everything has a GPU these days. Anyway, something like this only needs to paint when states change or animations are running. That's an easy optimization to make here if it doesn't do it already. And games don't even bother with it, they repaint all UI even if it doesn't change.

Video games only get away with this because their energy draw is obvious: one launched the video game, so one expects the power draw. Visiting a web page does not have that action-reaction causality in people’s minds. Having a random web page introduce maximally-inefficient repaints also leads browsers to start reducing timeslices — especially those with any sort of power drain cognizance, such as Safari — which, here, leads to hella janky animations that can’t cope without their inefficient repaint loop.

All this work to replicate the animated blobbiness of Liquid Glass. I thought everyone hated it! So, then, why is this a thing?

Re: Jelly UI: Soft-body physics for native HTML form controls

#89

Post by csallen »

timcobb wrote: post #43
chrismorgan wrote: post #22

Please never use scroll-snap as is done on this demo page (unrelated to the soft-body physics). It leads to an awful experience for a large fraction of users. It improves things in one or two scenarios, but at the cost of far more common great frustration. Scroll-snap is a really risky feature, very niche in its reasonable applications. This is definitely not a suitable place to use it.

> It leads to an awful experience for a large fraction of users. can you give an example of why/how? I thought it was well done and enjoyable. Regular fast scroll was still as expected, and then the slower interactions felt like slide changes.

It just violates my expectations, and thus feels frustrating. And there's almost no benefit.

It would be like if my shoes suddenly made me take steps at perfect widths, and no matter how/where I tried to step on my own, they forcibly move my foot to the spot they think is best. Like, okay, I see the good intentions here. But I have no trouble walking on my own. I don't need help. So I'm not sure what problem this solves. And this would obviously feel jarring and awkward, and would take a lot of getting used to until it didn't.

Except at least my shoes go with me, so presumably if I had a pair of auto-stepping shoes I would get used to them over time. But this website is a one-off, I'm going to visit once and never again, so it's just going to be weird and jarring, and then I'll leave.

Re: Jelly UI: Soft-body physics for native HTML form controls

#90

Post by im_down_w_otp »

Is there an easy way to “reverse” the effects here? For example, on the “Jelly Button” I don’t want the part I press on to get bigger. I want it to get smaller and “inflate” the other parts of the controls that aren’t under my finger.
Post reply on HN