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 step.
The "JellyEngine" instead of just calculating the jelly animation on pointer events is recalculating for every active component on the page every frame.
This is the kind of thing usually a human notices and says 'dont do that, that is kind of crazy'.
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<JellyComponent>()` 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.
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.
Agreed. I almost exclusively use the "middle click" autoscroll feature to scroll on websites. It is completely broken on this site because of the scroll-snap.
> 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.
Cute (and I mean that sincerely, not sarcastically), and I appreciate that it appears to gracefully degrade for `@media (prefers-reduced-motion: reduce)`, but for the demo site, it would probably be a good idea to allow the user to override that without having to change their system settings, or at least alert them that they won't see the animations.
PSA: Apple menu > System Settings > Accessibility > Motion
These cool demos come up now and again and it always takes me a minute to remember I have reduced motion. But for that minute I was disappointedly clicking around thinking "Whats the big deal?"
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).
Oh, thanks for the hint. I actually don't like this - similarly to dark mode setting detection. But I guess thats more a criticism on the OS preferences not being granular enough.
How does that make anything about this "physics-based"? I'm not being snarky, I'm genuinely trying to figure out what part of this is completely going over my head. I don't see any "soft-body physics" interactions, but maybe I don't understand what to look for.
I don't see any deformation or elastic collision physics, and those are usually the most obvious things that I associate with "soft bodies" in engineering/physics.
This could be modified to be very useful for folks with less-than-ideal hand ability. I don't have much fine motor control in my hands. Hitting one of the modern tiny targets usually involves clicking a few times around the target until I finally manage to randomly twitch the mouse into the right place. Something like this, where the target changes shape to improve targeting ability or increase the size of the click zone, would be wonderful.
that's a real frustrating form of scrolljacking, a forced timed animation & lockout for concurrent scroll events until the timer is relinquished and input ceases; impressive.
I'm so glad it allows for preferences to reduce motion. I don't like these kinds of UIs at all... unless maybe I'm inside a video game and even then it bothers me after the initial novelty.
on chrome on a macbook pro page scrolling is noticeably degraded and animations are low fps. It's a very subtle effect which is nice i guess, but the feeling of jankiness overrides it.
This would be awesome if someone could add 3D rendering to make it actually look like I’m pressing a little jelly ball. It would make it so fun to press buttons that CA and EU would have to make jelly buttons illegal.
It requires JS to work, which could have been avoided at some arguable ergonomic cost. Personally I’d disqualify it from being considered “native HTML form controls”—it’d need to be just an enhancement to qualify in my mind.
—⁂—
Your sets of chips like mode auto/dark/light should be marked up and behave as radio buttons: when one is checked, it should be the only one in the tab order, and arrow keys and such cycle through them. <jelly-segmented> gets this right.
—⁂—
The demos show a “click” toast on buttons even if you move out of the button before releasing, which should cancel it. Either the event handler is linked to something other than activation (which should be fixed), or activation behaviour is wrong (which should be fixed).
—⁂—
> <jelly-checkbox indeterminate>
Oh how I wish <input type=checkbox> had an indeterminate attribute and a way of telling it to cycle through indeterminate when clicking. As it is, it’s purely a property, not attainable in serialised HTML.
—⁂—
> <jelly-otp>
I hate it. Do not under any circumstances use a sequence of single-character inputs for OTPs. It behaves really nastily. Sure, you made the simple paste case work, but all kinds of other normal interactions are busted. You must use one input. If you want to style it in a way that shows the intended length and puts characters in those boxes, you can still do it. Use `font-variant: tabular-nums` or `font-family: monospace`, then rely on the ch unit and probably add some letter-spacing (one of the very few legitimate cases for letter-spacing), and draw behind. Or, if you want more control… contenteditable is available.
—⁂—
> <jelly-range>
I thought we were talking “native HTML form controls”? There ain’t no such thing in HTML. (It becomes apparent the further I go that it’s not intended to be limited to what HTML has.)
—⁂—
> <jelly-switch>
There’s a gap in the hit target between the switch and the label. This needs to never happen. It didn’t seem to with checkboxes or radio buttons.
—⁂—
> <jelly-textarea>
Hold down a letter until it gives up expanding, and I found text and scrollbar drawn on top of the jelly border.
—⁂—
> <jelly-alert dismissable>
The × hit target is much too small.
—⁂—
> <jelly-pagination>
Not pleasant to use. Bad hit targets (too small, gaps between), poor choice of pages to offer (‹ 1 … prev self next … last ›: you want 2 instead of … if prev is 3, and you want more than one prev/next), and if it’s ever going to be interactive, the layout changes far too much.
—⁂—
> <jelly-tabs>
Ugh. Ugh. Unpleasant appearance, presenting tab bar and panel as unrelated widgets. Bad cross-fade (opacity drops below 1).
—⁂—
> <jelly-dialog>, <jelly-drawer>
Opening it in dark mode was very jarring: no transition, and the backdrop lightens (should darken; that may require changes to the dialog background colour).
—⁂—
> <jelly-menu>
You reused a <select> dropdown, and it shows. Interactions are all wrong. It also says “typeahead keyboard support” but I see no such thing.
Gotta say, I like most of the effects except for the wiggly "membrane" on inputs and buttons: I'd prefer to see the the whole thing jiggle when clicked or focused, rather than a small circle, and to turn off the effect entirely for typing. I suppose it's trivial enough to go into the source, but if there's a cheap and easy way to expose customization knobs like that, perhaps take it as a suggestion.
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 step.
The "JellyEngine" instead of just calculating the jelly animation on pointer events is recalculating for every active component on the page every frame.
This is the kind of thing usually a human notices and says 'dont do that, that is kind of crazy'.
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<JellyComponent>()` 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.
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.
Agreed. I almost exclusively use the "middle click" autoscroll feature to scroll on websites. It is completely broken on this site because of the scroll-snap.
> 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.
In my case it's way too sensitive, causing me to scroll too far every time.
I dont get why people are so mad at this? Looks fun, will I ever use it? Probably not, but it looks fun
We're porting our electron app to it as we speak
Cute (and I mean that sincerely, not sarcastically), and I appreciate that it appears to gracefully degrade for `@media (prefers-reduced-motion: reduce)`, but for the demo site, it would probably be a good idea to allow the user to override that without having to change their system settings, or at least alert them that they won't see the animations.
I'm glad I read your comment, I missed that it intentionally gracefully degraded and assumed it was broken, as I'd forgotten I'd set that.
PSA: Apple menu > System Settings > Accessibility > Motion
These cool demos come up now and again and it always takes me a minute to remember I have reduced motion. But for that minute I was disappointedly clicking around thinking "Whats the big deal?"
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).
Honestly same, I was less interested in the styling and just interested in the immediacy of response which is ironically missing in a lot of modern ui
I flip back and forth every year or so between wanting more fun in my software, and wanting it to get the hell out of my way.
Okay I know this is gonna sound rude but who in the world would want form controls that behave this was?
Me.
I'm having trouble identifying any physics at all in this UI design system.
The library does respect the client-side reduce motion setting (by disabling all animated effects).
Oh, thanks for the hint. I actually don't like this - similarly to dark mode setting detection. But I guess thats more a criticism on the OS preferences not being granular enough.
Oh thanks, I was also pretty confused
I think you can respectfully disobey that for a demo.
How does that make anything about this "physics-based"? I'm not being snarky, I'm genuinely trying to figure out what part of this is completely going over my head. I don't see any "soft-body physics" interactions, but maybe I don't understand what to look for.
I don't see any deformation or elastic collision physics, and those are usually the most obvious things that I associate with "soft bodies" in engineering/physics.
I am similarly very confused. Tried in multiple browsers, including a stock chrome install where I haven't messed with any animation settings.
This could be modified to be very useful for folks with less-than-ideal hand ability. I don't have much fine motor control in my hands. Hitting one of the modern tiny targets usually involves clicking a few times around the target until I finally manage to randomly twitch the mouse into the right place. Something like this, where the target changes shape to improve targeting ability or increase the size of the click zone, would be wonderful.
that's a real frustrating form of scrolljacking, a forced timed animation & lockout for concurrent scroll events until the timer is relinquished and input ceases; impressive.
Waste of computing resources, and mildly distracting. This reminds me of compiz.
No, compiz was awesome
ah finally. Compiz for react.
It does not seem to work on Firefox for iOS. I could not see any animation just the tiny click registration cards.
Nor Firefox on Android.
It's fun, but a menu would be so much better instead of the weird scroll-jacking. It takes a minute to get to the bottom of it.
No apparent relation to the jelly slider: https://docs.swmansion.com/TypeGPU/examples/#example=renderi...
I'm so glad it allows for preferences to reduce motion. I don't like these kinds of UIs at all... unless maybe I'm inside a video game and even then it bothers me after the initial novelty.
on chrome on a macbook pro page scrolling is noticeably degraded and animations are low fps. It's a very subtle effect which is nice i guess, but the feeling of jankiness overrides it.
Pretty cool. Love the button. Not sure I will ever build an app where this makes sense but cool
So this works on Chrome on my Android phone, but not on Chrome desktop nor firefox.
This is perfect for gaming sites like Splatoon and Roblox.
This would be awesome if someone could add 3D rendering to make it actually look like I’m pressing a little jelly ball. It would make it so fun to press buttons that CA and EU would have to make jelly buttons illegal.
Some review of Jelly UI itself.
—⁂—
It requires JS to work, which could have been avoided at some arguable ergonomic cost. Personally I’d disqualify it from being considered “native HTML form controls”—it’d need to be just an enhancement to qualify in my mind.
—⁂—
Your sets of chips like mode auto/dark/light should be marked up and behave as radio buttons: when one is checked, it should be the only one in the tab order, and arrow keys and such cycle through them. <jelly-segmented> gets this right.
—⁂—
The demos show a “click” toast on buttons even if you move out of the button before releasing, which should cancel it. Either the event handler is linked to something other than activation (which should be fixed), or activation behaviour is wrong (which should be fixed).
—⁂—
> <jelly-checkbox indeterminate>
Oh how I wish <input type=checkbox> had an indeterminate attribute and a way of telling it to cycle through indeterminate when clicking. As it is, it’s purely a property, not attainable in serialised HTML.
—⁂—
> <jelly-otp>
I hate it. Do not under any circumstances use a sequence of single-character inputs for OTPs. It behaves really nastily. Sure, you made the simple paste case work, but all kinds of other normal interactions are busted. You must use one input. If you want to style it in a way that shows the intended length and puts characters in those boxes, you can still do it. Use `font-variant: tabular-nums` or `font-family: monospace`, then rely on the ch unit and probably add some letter-spacing (one of the very few legitimate cases for letter-spacing), and draw behind. Or, if you want more control… contenteditable is available.
—⁂—
> <jelly-range>
I thought we were talking “native HTML form controls”? There ain’t no such thing in HTML. (It becomes apparent the further I go that it’s not intended to be limited to what HTML has.)
—⁂—
> <jelly-switch>
There’s a gap in the hit target between the switch and the label. This needs to never happen. It didn’t seem to with checkboxes or radio buttons.
—⁂—
> <jelly-textarea>
Hold down a letter until it gives up expanding, and I found text and scrollbar drawn on top of the jelly border.
—⁂—
> <jelly-alert dismissable>
The × hit target is much too small.
—⁂—
> <jelly-pagination>
Not pleasant to use. Bad hit targets (too small, gaps between), poor choice of pages to offer (‹ 1 … prev self next … last ›: you want 2 instead of … if prev is 3, and you want more than one prev/next), and if it’s ever going to be interactive, the layout changes far too much.
—⁂—
> <jelly-tabs>
Ugh. Ugh. Unpleasant appearance, presenting tab bar and panel as unrelated widgets. Bad cross-fade (opacity drops below 1).
—⁂—
> <jelly-dialog>, <jelly-drawer>
Opening it in dark mode was very jarring: no transition, and the backdrop lightens (should darken; that may require changes to the dialog background colour).
—⁂—
> <jelly-menu>
You reused a <select> dropdown, and it shows. Interactions are all wrong. It also says “typeahead keyboard support” but I see no such thing.
This is surprisingly delightful to play around with. We have to put some more fun into UIs, not the same type of AI-slop everywhere.
? what am I missing? The demo is just rounded corners? do we need a special library for that?
Do you have reduced motion enabled? That disables all the effects.
love it I can think of many projects that could use that
I love the aesthetic, and I really love that they implemented it as a web component library.
Absolute bliss.
Material Design engineers furiously prompting Gemini to copy it
Gotta say, I like most of the effects except for the wiggly "membrane" on inputs and buttons: I'd prefer to see the the whole thing jiggle when clicked or focused, rather than a small circle, and to turn off the effect entirely for typing. I suppose it's trivial enough to go into the source, but if there's a cheap and easy way to expose customization knobs like that, perhaps take it as a suggestion.