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

191–200 of 209 posts

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

#191

Post by marklubi »

NiloCK wrote: post #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-u…

https://github.com/jelly-org/ui

It's buried at the bottom. Had to click on the "sponsoring" link, and then select the package.

Feels like they should make the repository more prominent.

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

#192

Post by amelius »

NiloCK wrote: post #190
amelius wrote: post #185

Earlier quoted context omitted.

Another nitpick: why are only the button outlines having a jelly effect and not the texts written on them? This makes them feel physically unconnected.

I had the same nit, but I imagine deforming text / inline content generally would be a much larger effort.

Maybe, but changing the font size of individual chars could already help.

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

#193

Post by NiloCK »

marklubi wrote: post #191
NiloCK wrote: post #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-u…

https://github.com/jelly-org/ui It's buried at the bottom. Had to click on the "sponsoring" link, and then select the package. Feels like they should make the repository more prominent.

Thanks much. Source code is for customers only I guess :)

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

#194

Post by moralestapia »

goobatrooba wrote: post #125
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.

> Yes my car is running all night while it stands in front of my house, but it's not really a waste of resources or a nuisance because generators do the same thing.

Your analogy is wrong. The rendering engine is the generator.

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

#196

Post by brettermeier »

snitty wrote: post #114
tiohijazi wrote: post #48

I dont get why people are so mad at this? Looks fun, will I ever use it? Probably not, but it looks fun

A single function button should not behave differently based on where on the button you click it. EDIT: It's also WILDLY inconsistent. Click and drag on a button and the shape doesn't change. Click and drag on an on/off and the deformation follows the mouse. Merely click an on/off and the deformation does not follow the the little circle thingy, or bear any relation to the action of the button. Some of the things are…

> But basically anything that deforms on click related to where you click are nonsense.

Why would you say this? These buttons recognize every click I do on them and I find it very nice that the deformation is different for different click areas. The button still works like a normal button but is nice to look at, or have I misunderstood you?

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

#197

Post by ben-schaaf »

Rohansi wrote: post #182
ben-schaaf wrote: post #144

Earlier quoted context omitted.

This is just plain false. Retained UIs like the DOM and what your OS uses only ever render when something changes, so the vast majority of the time they sit idle. There's extensive effort throughout the entire stack to do as little work as possible. For instance, the mouse cursor is composited on the GPU during scanout. That means simply moving your cursor requires zero rendering. Another example: When typing only th…

> Another example: When typing only the newly typed character and caret are rendered. The rest of your entire screen is reused. You're right that they avoid unnecessary painting but it is not this granular anymore. It used to be but rendering is so much faster these days where it is cheaper to just render a bit more than tracking dirty regions. It's easily visible on Android where you can enable "Show view updates" a…

Wow, that's quite silly - and might partially explain some of the worsening battery life on Android. GTK4 also removes such an API, but just like those docs say, dirty rects are still calculated internally. You can enable the same visual debugging in GTK4 and see that dirty rects are done the same as they always have been.

Chrome on desktop has an option for flashing whenever it paints and it only highlights the line of text you're typing on. So clearly chrome still tracks dirty rects properly.

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

#198

Post by ben-schaaf »

yesithinkso wrote: post #187
ben-schaaf wrote: post #144

Earlier quoted context omitted.

This is just plain false. Retained UIs like the DOM and what your OS uses only ever render when something changes, so the vast majority of the time they sit idle. There's extensive effort throughout the entire stack to do as little work as possible. For instance, the mouse cursor is composited on the GPU during scanout. That means simply moving your cursor requires zero rendering. Another example: When typing only th…

That doesn't mean that the process stops, it runs indefinitely because it has to. The DOM does this. React does this. Did you know CSS even invokes the GPU for certain tasks? You guys really need more experience. I can't believe how many people apparently know nothing at all about web dev and computers.

> That doesn't mean that the process stops, it runs indefinitely because it has to.

The processes don't stop, no, but they do pause and go idle, waiting for the next event to come in. Not sure what that has to do with this.

> The DOM does this. React does this.

What does react have to do with any of this discussion, and what do you mean by "this"?

> Did you know CSS even invokes the GPU for certain tasks?

Whether the GPU or CPU does work is unrelated to how frequently and how much of the screen is rendered. Damage regions work just fine for GPU-based rendering.

> You guys really need more experience. I can't believe how many people apparently know nothing at all about web dev and computers.

Part of my job is maintaining a retained mode UI library. I've literally written some of the parts that handle damage regions, as well as the GPU-based rendering. But do go on about how I don't know how any of this works.

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

#199

Post by odo1242 »

Looks good overall. My main complaint is that the animations don't all seem to go together - the "Jelly" style of the toggle switch or button (which has squish animations that respond to pointer location) is WAY different from the "Jelly" style of the checkbox (which just resizes), for example.

Also, some Jelly buttons animate correctly when you move your mouse over them mid-click, while some remain stuck in the original position when you clicked them.

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

#200

Post by dxdm »

yesithinkso wrote: post #186
dxdm wrote: post #95

Earlier quoted context omitted.

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.

> GPUs are expensive Do you know that regular HTML and CSS use GPU all the time?

Nothing wrong with browsers using resources to do useful work. I'm just not a fan of bloat that eats resources because they're assumed to always be available.

That's what this thread is about, I thought.

Post reply on HN