Just 25 years too late to be used to design Jelly World
Jelly UI: Soft-body physics for native HTML form controls
101–110 of 209 posts
Re: Jelly UI: Soft-body physics for native HTML form controls
#102If I were younger I would love this. nowadays I spend most of the time tweaking websites to remove this stuff using local stylesheets...or using dark + read mode... how times have changed.
I like the fact that it gives animated feedback to emphasize what is happening/being altered. Native components don't always do that very well. Animations are not just artsy fluff, they have real UX value (if done right, of course).
I think the trick to using libraries like this is to not go all in on them. Applying these effects to every element would be garish.
But for a single like button, an effect slider, or magic search bar? It would be be a lovely touch.
Re: Jelly UI: Soft-body physics for native HTML form controls
#103Saw 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…
Running a performance profile in Chrome doesn't back this up for me, and looking at the loop it looks like it maintains an active `Set ()` of which components to update, and clears them out when they stop moving. Agreed the comments look a bit slop-ish but I don't see anything obviously wrong with its approach, and the core loop is running in microseconds for me when nothing is happening.
Here's the perf profile, just to clarify.
Cursor idle, viewport on the button examples. 3ms repaint every 8-11ms. Animation frame points to the code i mentioned.
The problem isn't doing work on a website, its if you have an idle task that is taking up a significant portion of the frame budget then its easy to have frame drops when you do significant work like clicking, scrolling, browsing.
Idle work showing up in flamecharts is usually the thing to be cautious of.
Re: Jelly UI: Soft-body physics for native HTML form controls
#104Earlier 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.
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.
Yes, visual effects and animations in UIs burn cycles just to make it look nicer. Doesn't matter if it's a website or the native system UI.
To be clear, I'm not saying it's fine to constantly render when you know nothing changed. I'm saying the load from this should be very small. Most of the performance issues from this page are actually from the header animation, which you can delete in the inspector to see a significant drop in usage (mine went from ~35 to ~6.6 CPU).
Re: Jelly UI: Soft-body physics for native HTML form controls
#105Earlier quoted context omitted.
The library does respect the client-side reduce motion setting (by disabling all animated effects).
I think you can respectfully disobey that for a demo.
Or at the very least mention to the user that their host is set to not show animations. i too was confused
Re: Jelly UI: Soft-body physics for native HTML form controls
#106Earlier quoted context omitted.
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 i…
As a web developer, I am not included in the perception difference I describe. I am also 0.000001% and not a representative sample of People As A Whole Or Even As A Majority Or Significant Fraction. So while my personal awareness is akin to yours, extrapolating from that towards the masses is a dead end exercise.
CPU bound games examples: Chess, Go, Final Fantasy XIV, Elite Dangerous, and any competent Civilization / 4X or turn-based strategy game. Yes, you can dial up the graphics on these to force them to be GPU bound, but they’re each CPU bound in their own unique ways. Perhaps none such games appeal to you, but as with above, extrapolating from personal preferences is a non-starter.
Non-tech people teach each other to force-quit apps to stop their battery drain. Websites aren’t apps, so their phone ‘randomly’ gets hot sometimes and they either have no idea why or just try closing all tabs in a vague hope that it works. Sometimes a webpage uses up all their data for the month downloading ads and so they stop using the web over cellular at all.
This is the baseline level of competence that improving the web must be aiming for — not ‘web developers will understand that the tab is using lots of battery and must be closed’. Making the web better is not about making the web significantly more battery-hungry, no matter how pretty it might seem. No visual advancement in radio button UX is worth a continuous repaint in JavaScript.
Re: Jelly UI: Soft-body physics for native HTML form controls
#107Earlier 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.
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.
> A website shouldn't be pinning CPU or GPU.
That's exactly what I was saying. Rendering a few widgets shouldn't pin your CPU or GPU because it's so little work.
This page, however, has an animated SVG and moving DOM elements in the header which consume far more resources than the widgets it is trying to showcase. Compare usage before and after deleting the header element (`section.hero`) in the inspector to see for yourself.
Re: Jelly UI: Soft-body physics for native HTML form controls
#108That demo makes me nauseous. Buttons shouldn't do that.
Re: Jelly UI: Soft-body physics for native HTML form controls
#109Saw 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.
The browser and OS does that as well (unless absolute zero updates and you don't even move your pointer around).
But many smaht people out there don't know that.
Re: Jelly UI: Soft-body physics for native HTML form controls
#110Earlier quoted context omitted.
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.
Oh, "you're holding it wrong".
I can break basic user interaction with one line of CSS, does that mean I should?