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

91–100 of 209 posts

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

#91

Post by nightpool »

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.

The scrolling behavior on this site worked great for me—it let each example stand on its own and meant I wasn't spending a lot of effort trying to figure out when a given example would end and the next example would begin.

It doesn't look like there's anything custom going on here either, it's all just standard scroll-snap-* CSS properties. if you have an issue with the way your browser is handling the scroll-snap CSS properties, I recommend you take that up with your browser? After all, you should be using a user agent that works for you, not against you.

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

#92

Post by nightpool »

dymk wrote: post #69
ranger_danger wrote: post #67

Earlier quoted context omitted.

I had no problems moving one tick at a time with my mouse wheel.

This is why you don't override basic interactions like scrolling. Good luck ensuring that your setup matches everybody else.

It's like 3 lines of standard CSS. If you have an issue with the way your browser is handling it, you should probably take that up with them.

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

#94

Post by NuclearPM »

codegeek wrote: post #75
timcobb wrote: post #43

Earlier quoted context omitted.

> 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 is bad because you are deciding something for ME, the user. That's bad UX because I want to decide my own experience and scroll jacking is the worst thing you can do for UX. Stop doing this.

I liked it.

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

#95

Post by dxdm »

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.

Waste the cycles, everyone has too many cycles, is it even waste if the cycles would just go unused, GPUs are expensive, they better do their bit, who's got no GPU, go play somewhere else without your GPU, pal. It's all a game, anyway.

Point being: your comment made me sad and I needed to lighten myself up a bit.

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

#96

Post by Philip-J-Fry »

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 shouldn't be pinning CPU or GPU. When people run a game they expect some sort of battery drain. People don't expect that some websites will thrash your CPU/GPU like a game.

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

#97

Post by pverheggen »

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.

Different browsers handle scrolling differently, and people use a myriad of different "pointer" input devices, there's too many permutations to handle correctly. It's for similar reasons why building native inputs from scratch are fraught with peril (see this item from a few days ago)

https://news.ycombinator.com/item?id=48930136

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

#98

Post by jquip »

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.

insightful, thank you

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

#99

Post by smilespray »

itishappy wrote: post #58

I love this, but it does not seem to conform to standard UX best practices. If I click and hold then move the mouse away to release, I assume an element should not register that as a click. As-is, this is inconsistent: the button registers a click, the checkbox does not.

I always had this issue when working with Flash developers. A common mantra was "don't reimplement scrollbars unless you can implement all the features a scrollbar comes with." They always had to do more than five iterations and spent days on that scrollbar.

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

#100

Post by TheDong »

altairprime wrote: post #88
Rohansi wrote: post #84

Earlier quoted context omitted.

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, her…

> Visiting a web page does not have that action-reaction causality in people’s minds

It does in my mind. I fully expect visiting any of reddit.com, github.com, notion.so, or meet.google.com to have the chance to pin a cpu core at 100% for as long as the site is open.

At this point, I expect the average webpage to use more CPU than any of the video games I play. The only reason I had to upgrade to my current machine is because a 2021 CPU (intel gen 11) wasn't capable of running notion.so or google meet anymore, it still ran all the video games I care about just fine.

Post reply on HN