Okay I know this is gonna sound rude but who in the world would want form controls that behave this way?
Jelly UI: Soft-body physics for native HTML form controls
171–180 of 209 posts
Re: Jelly UI: Soft-body physics for native HTML form controls
#172If 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).
Re: Jelly UI: Soft-body physics for native HTML form controls
#173Heads up: the "See it live in the showcase → " links in the API documentation do not go back to the showcase - they just reload the same current API section.
Question: maybe I've missed it, but what exists here wrt distribution / packaging / bundling / source availability? I see MIT listed, but no repo. I see src="https://jelly-ui.com/package.js" as a sourcing import, but obviously I'm not going to bundle foreign assets into my app.
Re: Jelly UI: Soft-body physics for native HTML form controls
#174Saw 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.
Re: Jelly UI: Soft-body physics for native HTML form controls
#175Earlier quoted context omitted.
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…