Live data from Hacker News

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

jelly-ui.com

171–180 of 209 posts

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

#171

Okay I know this is gonna sound rude but who in the world would want form controls that behave this way?

I would say that this is a joke, someone made a wobbly UI, isn't that funny. But I get a bit worried when trying to gauge much work went into this that is not required for the joke. It looks like the author actually expect people to pick up this thing and use it, and that is kind of scary.

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

#172

If 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 don't know. At the point in which you have to reinforce visual context with animations, I feel like you've already failed at the part of UX that actually matters. Like there's already been a cascade of structural failure, and now you're trying to put bandaids over it.

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

#173
I like this a lot and am going to experiment w/ incorporating in my early literacy app.

Heads 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

#174
post #71
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.

If you take about optimizing then games are the prime example of doing that. You don't load textures every frame into gpu memory. Tou don't load vertices into memory every frame. Sure they repaint every pixel every frame. But low level your display driver is doing that anyway. The cpu cycles are not in sending the RGB value to each pixel. We are far beyond that bandwidth issue. Recalculating every single position in a css styled document is pretty heavy. There are millions of calculations done to solve flex boxes, floats, percentual widths etc. this example is doing something like that. Super heavy. Super inefficient. Super bad.

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

#175

Earlier 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…

[deleted]
Post reply on HN