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.
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.
? In this very particular case, yeah, the original commenter was holding it wrong, as they inspected the wrong thing. People sometimes hold things wrong and it's okay.
Zoom in, take a look at what code is running, and you'll see it's all `lottie_light.min.js`. Being offscreen doesn't mean it's doing nothing. In fact, it looks like once it shows once it keeps spinning its RAF loop forever. Shrink your window so it disappears, reload, and then profile.
> 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.
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.
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, here, leads to hella janky animations that can’t cope without their inefficient repaint loop.
All this work to replicate the animated blobbiness of Liquid Glass. I thought everyone hated it! So, then, why is this a thing?
> 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 is because a 2021 CPU (intel gen 11) wasn't capable of running notion.so or google meet anymore, it still ran all the video games I care about just fine.
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.
If the geneva convention didn't ban torture, I'd say that web-developers should be forced to actually try and use the apps they develop.
The websites I mentioned use more cpu and memory than most games in Civilization the series, which are largely competently developed. My previous laptop could play civ 5 at a higher framerate than it could scroll github diffs or notion pages.
Civ 5 handled full-speed keyboard input, while notion doesn't let me input text at my roughly 100 wpm typing speed.
I agree that we shouldn't be expecting users to figure out how to close the right tab, however I'm reporting the way things currently are, which is that webpages are poorly optimized messes.
They should also be forced to walk around town with a GDPR cookie banner pasted over their face covering half of their field of view. And then although automatic doors open for most people, for them specifically, the automatic doors shut. The doors are postered with "would you like to subscribe" newsletter ads. They have to manually open each one of them.
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).
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.
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.
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.
> That's exactly what I was saying. Rendering a few widgets shouldn't pin your CPU or GPU because it's so little work.
Your comment doesn't say this at all:
> > 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.
Am I missing something? Are you referring to some other part of the thread?
Sorry, I meant to say that it was what I was suggesting. Video games render a lot more than the widgets on that website. Rendering less takes less time, so your `requestAnimationFrame` loop idles longer between executions waiting for vsync, which means your CPU or GPU usage is not pinned.
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 the newly typed character and caret are rendered. The rest of your entire screen is reused.
> 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" and see the entire textbox view updates when the cursor flashes. The docs say the same thing.
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.
> 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.
> 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.
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.
These downvoters act like native JS doesn't do the exact same thing with event listening and observing the DOM. So does React and other FE frameworks.
Philip J Fry is either being disingenuous or genuinely doesn't know that game rendering has often several MB models, is often raycasting, maintaining camera calculus, and a lot more.
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?"
Would also be trivial for the author to add a warning for users that have that setting enabled. Something like "Heads-up: you have requested reduced motion, and this library disabled animations as per your request"
> Would also be trivial for the author to add a warning for users that have that setting enabled. Something like "Heads-up: you have requested reduced motion, and this library disabled animations as per your request"
They already do exactly this. The commenter wants a switch to force animations anyway, so he can check the demo without changing system settings.
At the time that I viewed it yesterday, there was no indication that it respected the "prefers reduced motion" setting, so I was very underwhelmed at first until I remembered I had that turned on.
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.
I love this, but it does not seem to conform to standard UX best practices.
If I click and hold then move the mouse away to release, I assume an element should not register that as a click. As-is, this is inconsistent: the button registers a click, the checkbox does not.
I always had this issue when working with Flash developers. A common mantra was "don't reimplement scrollbars unless you can implement all the features a scrollbar comes with." They always had to do more than five iterations and spent days on that scrollbar.
This comment is for like three people on HN, but anybody remember when Paul Neave had a website/blog/showcase (c.2007-2010ish?) where the borders of the page had similar jelly effect? That was achieved with Flash back in the day.
Neave was a personal hero of mine back then... hope you're well if you're reading this!
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.
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.
It's cute. But the reaction time on some of the controls is so awful. If I click and drag the slider control back and forth, it lags behind the mouse cursor substantially. It should feel like it's stuck to the mouse cursor like glue.
By contrast, most of the other controls do seem to stick to the cursor, such as jelly-resizable.
Also, the "Placeholder" control seems to fail to actually make the placeholder disappear when clicked in.
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.
I think there is still a point to be made that alternative more granular settings may help in less people turning it on.
e.g. I have "reduced motion" turned on because the workspace switching animation (and some of the other animations) on macOS is unbearably slow, and that flag is the only way to get rid of it.
EDIT: OH MY GOD THAT IS A HUGE CHANGE!! On MacOS: Settings -> Accessibility -> Display -> Reduce Motion. I had no idea that was on. I like motion, I wouldn't have set this myself!
------------------
Original:
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.
1. The AI they used called it "physics-based" as a hallucination (probably due to the popular "JellyCar" game), and they went with it because they don't know better.
2. They don't know better, so they asked the AI for a "physics based" system, and the AI was too sycophantic to correct them.
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.
Meta, but is there a good resource to find these types of HTML UI component frameworks? I have googled and searched but all I get a listicle-style pages that aren't very curated.
Someone clearly had a lot of fun making all of those components. Adorable and whimsy. One nitpick - when writing uppercase letters in text field they should make larger ripples than lowercase.
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.
Is it the UI per se or the site that is requiring local storage? Since the examples don't load with cookies blocked, nor do any of the links/buttons work without it.
Ordinarily I wouldn't comment on this (eg: for the plethora of React-using sites that haven't tested without it yet work fine when manually bypassed) but in this case it's intended as a drop-in UI.
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 inoffensive, spinner dots, progress bars, accordion menus. But basically anything that deforms on click related to where you click are nonsense.
EDIT 2: The buttons in the demo area apparently do have distortion that follows the mouse, but on the left side they don't? For me this is just a lot of bafflingly inconsistent gloss that makes me wonder what's going on or why one thing behaves differently than others, and what that means for actual functionality. Rather than just interacting with the UI.
> 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?
Would be nice for GUI components of a game, but I kind of hope people don't run with this on regular apps/websites.
Also, I expected tooltips and submenus to have some flair to them as well.
It's visually creative. At the same time, the reactive animations would bother me (to the point of deeming it unusable) in any production app or website. I'm glad it respects "reduced motion" preferences.
I think it would be nice if the effect happened on hover as well, maybe to a lesser degree. Also, some of the controls don't appear to have any jelly in them, like the progress bar, toast, and so on. Finally, the performance on that showcase page isn't the best, and it feels like you're hijacking the scrolling somehow. But overall, it's cute. Would fit nicely as a game's UI.
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.
It could just be the particular type of my colour-blindness or my monitor settings, but the red and amber colours look so similar that I couldn't tell that I had even clicked the button.
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.
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.
Is there an easy way to “reverse” the effects here? For example, on the “Jelly Button” I don’t want the part I press on to get bigger. I want it to get smaller and “inflate” the other parts of the controls that aren’t under my finger.
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.
Your scroll is messed up on my Macbook M3 Pro / Opera, it's like a broken "velocity scroll" that is too loose and scrolls past several items leading to a clunky experience
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.
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.
Nobody expects the scroll behavior to be different on a webpage, so it's always a surprise when a page does something like this. Then, you have to learn to adapt to how it expects you to scroll so that you don't screw up its animations or overshoot.
It's the kind of UI that works if you scroll a specific way. A lot of people probably do. But if you don't, it's all very tedious. I consider that to be poor design.
For me, I scrolled, clicked, but the page hijacked my screen, moved its position by force, and I was not certain which pane I was on immediately. It broke my sense of continuity.
I am only being literal when I say this, but as someone who is actively keeping an eye out for this sort of thing (CSS frameworks, UI kits), I lost interest pretty immediately when I saw that and closed the tab immediately. Assuming the people who made this page also made the UI kit, it tells me their web design values run contrary to mine.
I don't even fall into one of the exceptional cases, and this was a very bad using-a-website experience for me.
On a desktop or laptop computer, most trackpads have an immediate response curve. I am using one now, an Apple Wireless Trackpad. A very large amount of engineering effort over decades of time and millions of lifetime hours went into making it behave that way over a common wireless medium. I scroll a little bit, it scrolls a little bit, immediately, I scroll a lot, it scrolls a lot, immediately, and if I flick my finger from the bottom to the top and let go, it behaves as if I swiped a page of paper on my desk in the same fashion, with inertia taking over, proportional to how fast I flicked.
There is therefore an intrinsic physical link between the actions of my fingers, and the motion on the web page. My finger moves, and an immediate, proportional response is observed. This is an utterly base level of how most humans interact with the world. It is why using a mouse or trackpad came quite easy to many people (and why some can flick a mouse in a shooter, turn a precise 274.9 degrees, move up 14.2 degrees, and click on the head of an enemy player in fractions of a second with pinpoint accuracy). It is also why even a toddler can use a touchscreen; direct manipulation is inherently understandable to even a baby.
When I am turning in a screw by hand with a screwdriver, the feeling of the screws threads through the handle into my fingers, the immediate force feedback, the observable, feelable progress of the screw in or out of its screwhole, forms this same interface. Where human and tool meet, latency and unexpected behavior, especially if divorced from the input force, are undesirable qualities of a tool.
Scroll jacking is to a trackpad or a fine scroll wheel as turning a screwdriver handle by twisting a bungee cord is to using a screwdriver. It unhooks the immediate, direct feedback from the motion of my hand; its jarring, unpleasant, frustrating. On this page, I immediately put two fingers on the trackpad and moved them less than a centimeter, and didnt let go, and the entire screen cycled its view, as if I pressed a button "move to next item". Except I didn't (and why would I want that in the first place???), I just moved my fingers less than a centimeter. Nothing in the real world moves like that except for things less than a centimeter away from falling out of balance. And it feels the same. Precarious. A common human reaction to things moving out of proportion to our body is nausea!
I think a better question is, can you give an example of "why/how" this solves any actual problem someone would have had scrolling this website had it not used scroll snapping? Would the top comment have been "Boy I wish this site had used scroll snapping, it would have been more well done and enjoyable that way"?
Some of the "slides" have more content than fits vertically in the viewport, and trying to scroll to the bottom to see it without getting bounced to the next slide or back to the top is very touchy and tedious.
It is bad because you are deciding something for ME, the user. That's bad UX because I want to decide my own experience and scroll jacking is the worst thing you can do for UX. Stop doing this.
It ignores my scroll wheel most of the time if I try to scroll multiple times in a row.
The scroll is delayed significantly from when I scroll to when it actually scrolls.
The amount scrolled is inconsistent, sometimes it scrolls a very slowly a tiny amount because the page doesn't fit on the screen by an unknown tiny fraction, but if I scroll again because it is scrolling both slowly and with delay it now scrolls an entire page.
If I want to scroll past one of the demos I have to wait
If I drag the scroll bar on the side slightly it often snaps backwards.
It feels like I'm interacting with a phone/tablet screen on a computer, there's a reason why windows 8 failed.
I’m on my phone and scrolling this page just leads to it constantly jumping up and down and makes it difficult to read as nothing stays in one place if I scroll a little bit.
It just violates my expectations, and thus feels frustrating. And there's almost no benefit.
It would be like if my shoes suddenly made me take steps at perfect widths, and no matter how/where I tried to step on my own, they forcibly move my foot to the spot they think is best. Like, okay, I see the good intentions here. But I have no trouble walking on my own. I don't need help. So I'm not sure what problem this solves. And this would obviously feel jarring and awkward, and would take a lot of getting used to until it didn't.
Except at least my shoes go with me, so presumably if I had a pair of auto-stepping shoes I would get used to them over time. But this website is a one-off, I'm going to visit once and never again, so it's just going to be weird and jarring, and then I'll leave.
Different browsers handle scrolling differently, and people use a myriad of different "pointer" input devices, there's too many permutations to handle correctly. It's for similar reasons why building native inputs from scratch are fraught with peril (see this item from a few days ago)
I moved my scroll wheel a single tick and the content of the browser window completely changed with no movement to indicate scrolling was happening.
The change was so sudden and stark that I thought some sort of error had occurred and I was looking at a broken render of whatever I should be seeing.
Might be slightly better if the background didn't change color as soon as you move off the first "slide". Then it might not feel like you left the site or got dumped to an error page.
The scrolling behavior on this site worked great for me—it let each example stand on its own and meant I wasn't spending a lot of effort trying to figure out when a given example would end and the next example would begin.
It doesn't look like there's anything custom going on here either, it's all just standard scroll-snap-* CSS properties. if you have an issue with the way your browser is handling the scroll-snap CSS properties, I recommend you take that up with your browser? After all, you should be using a user agent that works for you, not against you.
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.
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.
https://postimg.cc/sQpZxxzv
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.
That's from Lottie, the animations that play in the header and footer of the page. Shrink your window until they disappear and try again.
Oh, yea, "you're holding it wrong"
? In this very particular case, yeah, the original commenter was holding it wrong, as they inspected the wrong thing. People sometimes hold things wrong and it's okay.
Is it? I am in the middle of the page, the header and footer are well off into the distance not being rendered, and I see the same pattern.
https://imgur.com/texxYP0
Zoom in, take a look at what code is running, and you'll see it's all `lottie_light.min.js`. Being offscreen doesn't mean it's doing nothing. In fact, it looks like once it shows once it keeps spinning its RAF loop forever. Shrink your window so it disappears, reload, and then profile.
> 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.
Presumably in a video game the majority of the screen changes every frame. Not so in web pages.
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.
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, here, leads to hella janky animations that can’t cope without their inefficient repaint loop.
All this work to replicate the animated blobbiness of Liquid Glass. I thought everyone hated it! So, then, why is this a thing?
> 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 is because a 2021 CPU (intel gen 11) wasn't capable of running notion.so or google meet anymore, it still ran all the video games I care about just fine.
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.
If the geneva convention didn't ban torture, I'd say that web-developers should be forced to actually try and use the apps they develop.
The websites I mentioned use more cpu and memory than most games in Civilization the series, which are largely competently developed. My previous laptop could play civ 5 at a higher framerate than it could scroll github diffs or notion pages. Civ 5 handled full-speed keyboard input, while notion doesn't let me input text at my roughly 100 wpm typing speed.
I agree that we shouldn't be expecting users to figure out how to close the right tab, however I'm reporting the way things currently are, which is that webpages are poorly optimized messes.
They should also be forced to walk around town with a GDPR cookie banner pasted over their face covering half of their field of view. And then although automatic doors open for most people, for them specifically, the automatic doors shut. The doors are postered with "would you like to subscribe" newsletter ads. They have to manually open each one of them.
This is like saying "I fully expect visiting that neighborhood to have the chance of getting mugged." A true statement and an incredibly sad one.
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).
> 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.
Is your browser running the javascript event loop on the GPU? Because mine isn't
A website isn’t a videogame
Braindead take.
A videogame is expensive to render because of several MB models, constantly moving camera, and other things.
The concept of observing elements is not even new.
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.
> > 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.
Your comment doesn't say this at all:
> > 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.
Am I missing something? Are you referring to some other part of the thread?
Sorry, I meant to say that it was what I was suggesting. Video games render a lot more than the widgets on that website. Rendering less takes less time, so your `requestAnimationFrame` loop idles longer between executions waiting for vsync, which means your CPU or GPU usage is not pinned.
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.
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 the newly typed character and caret are rendered. The rest of your entire screen is reused.
> 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" and see the entire textbox view updates when the cursor flashes. The docs say the same thing.
https://developer.android.com/reference/android/view/View#in...
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.
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.
> 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.
It's mining Bitcoin!
You know nothing about software if you really think this.
He's right - the DOM also has observers.
The difference is what is rendered, not that observers are involved and the concept of looping.
Millions use React - you want to talk about performance?
Your analogy is wrong. The rendering engine is the generator.
The state of the web when you want to compare a website to the most intensive thing a pc can do.
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.
I get what you're saying.
These downvoters act like native JS doesn't do the exact same thing with event listening and observing the DOM. So does React and other FE frameworks.
Philip J Fry is either being disingenuous or genuinely doesn't know that game rendering has often several MB models, is often raycasting, maintaining camera calculus, and a lot more.
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?"
Point taken and now you both get notifications as well as a pretty bunny icon to click on, to over rule the system settings.
Would also be trivial for the author to add a warning for users that have that setting enabled. Something like "Heads-up: you have requested reduced motion, and this library disabled animations as per your request"
> Would also be trivial for the author to add a warning for users that have that setting enabled. Something like "Heads-up: you have requested reduced motion, and this library disabled animations as per your request"
They already do exactly this. The commenter wants a switch to force animations anyway, so he can check the demo without changing system settings.
At the time that I viewed it yesterday, there was no indication that it respected the "prefers reduced motion" setting, so I was very underwhelmed at first until I remembered I had that turned on.
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 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.
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.
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.
"There's a time and place for everything, but not now!"
I think now that llms make it super easy to add anything that its important not to add everything.
I have enabled "reduced motion", so this site doesnt work for me.
I love this, but it does not seem to conform to standard UX best practices.
If I click and hold then move the mouse away to release, I assume an element should not register that as a click. As-is, this is inconsistent: the button registers a click, the checkbox does not.
I always had this issue when working with Flash developers. A common mantra was "don't reimplement scrollbars unless you can implement all the features a scrollbar comes with." They always had to do more than five iterations and spent days on that scrollbar.
Good catch. I've updated the button logic. The click will no longer trigger if the cursor is outside the button boundary.
This comment is for like three people on HN, but anybody remember when Paul Neave had a website/blog/showcase (c.2007-2010ish?) where the borders of the page had similar jelly effect? That was achieved with Flash back in the day.
Neave was a personal hero of mine back then... hope you're well if you're reading this!
I used to "get high" as a kid on the spiral illusion thing he built :)
Haha, yep, first thing I thought of as well. I still have a offline copy of that exact site saved somewhere.
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.
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.
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 :)
It's cute. But the reaction time on some of the controls is so awful. If I click and drag the slider control back and forth, it lags behind the mouse cursor substantially. It should feel like it's stuck to the mouse cursor like glue.
By contrast, most of the other controls do seem to stick to the cursor, such as jelly-resizable.
Also, the "Placeholder" control seems to fail to actually make the placeholder disappear when clicked in.
I don't fully understand the "soft-body physics" part. What's that supposed to mean? Looks like a generic UI library, not a really good one.
opacity: 0.5 for disabled elements is a crime.
pointer-events: none on disabled elements and claiming WCAG AA compliance? Ew.
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.
It's not something for you to not like. Many of us that have visual deficiencies and have that setting turned on for a reason.
I think there is still a point to be made that alternative more granular settings may help in less people turning it on.
e.g. I have "reduced motion" turned on because the workspace switching animation (and some of the other animations) on macOS is unbearably slow, and that flag is the only way to get rid of it.
Oh thanks, I was also pretty confused
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
EDIT: OH MY GOD THAT IS A HUGE CHANGE!! On MacOS: Settings -> Accessibility -> Display -> Reduce Motion. I had no idea that was on. I like motion, I wouldn't have set this myself!
------------------
Original:
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.
I see two options:
1. The AI they used called it "physics-based" as a hallucination (probably due to the popular "JellyCar" game), and they went with it because they don't know better.
2. They don't know better, so they asked the AI for a "physics based" system, and the AI was too sycophantic to correct them.
Either way, it's slop.
> I like motion, I wouldn't have set this myself!
You sure about that? “Turn on Reduce Motion” was a common bit of advice for people who were looking for ways to make Liquid Glass livable.
Wow I actually like it just fine with motion reduced, but it's unbearable with full motion.
Okay I know this is gonna sound rude but who in the world would want form controls that behave this way?
Me.
candy store, ice-cream place, kid's website?
Sometimes we built for the pure joy of making. Practicality is a bonus.
It's the first UI idea in many years that is surprisingly refreshing. It has all the signs of greatness.
Most pages aren't meant to be 100% utilitarian. Most are meant to be little bits of art, that faces a user, that the user will enjoy interacting with.
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.
Meta, but is there a good resource to find these types of HTML UI component frameworks? I have googled and searched but all I get a listicle-style pages that aren't very curated.
https://github.com/topics/design-system
Oh man there are a lot there:
> Here are 5,338 public repositories matching this topic...
Thanks for the link--I didn't know you could search Github by topic.
Someone clearly had a lot of fun making all of those components. Adorable and whimsy. One nitpick - when writing uppercase letters in text field they should make larger ripples than lowercase.
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.
Is it the UI per se or the site that is requiring local storage? Since the examples don't load with cookies blocked, nor do any of the links/buttons work without it.
Ordinarily I wouldn't comment on this (eg: for the plethora of React-using sites that haven't tested without it yet work fine when manually bypassed) but in this case it's intended as a drop-in UI.
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
Agreed. This is the liquid glass interaction the world deserved
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 inoffensive, spinner dots, progress bars, accordion menus. But basically anything that deforms on click related to where you click are nonsense.
EDIT 2: The buttons in the demo area apparently do have distortion that follows the mouse, but on the left side they don't? For me this is just a lot of bafflingly inconsistent gloss that makes me wonder what's going on or why one thing behaves differently than others, and what that means for actual functionality. Rather than just interacting with the UI.
> 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?
i think on HN you tend to get overly critical non-useful signals
very important to filter out and choose who you engage with
Would be nice for GUI components of a game, but I kind of hope people don't run with this on regular apps/websites. Also, I expected tooltips and submenus to have some flair to them as well.
Shape "pill": rounded
Shape "square": still rounded
-----
It's visually creative. At the same time, the reactive animations would bother me (to the point of deeming it unusable) in any production app or website. I'm glad it respects "reduced motion" preferences.
All I want is to be able to shake my phone and watch the UI jiggle.
Too bad that most of the effects become invisible behind the finger that is triggering them.
I think it would be nice if the effect happened on hover as well, maybe to a lesser degree. Also, some of the controls don't appear to have any jelly in them, like the progress bar, toast, and so on. Finally, the performance on that showcase page isn't the best, and it feels like you're hijacking the scrolling somehow. But overall, it's cute. Would fit nicely as a game's UI.
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.
Point taken, scroll-jacking has been removed.
That demo makes me nauseous. Buttons shouldn't do that.
This is cool, but overdone to the point of distracting. Subtle effects can enhance usability but it should be barely noticeable.
It could just be the particular type of my colour-blindness or my monitor settings, but the red and amber colours look so similar that I couldn't tell that I had even clicked the button.
No apparent relation to the jelly slider: https://docs.swmansion.com/TypeGPU/examples/#example=renderi...
Jelly slider was an influence, no denying that.
Really nice library. I’ve reposted this on Reddit r/webdev and you might find some of the feedback there useful.
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.
Combine with liquid glass and add a hover effect and raytraced lighting for, finally, a decent UI.
I don’t like the Chip element it’s supposed to stay in place and toggle instead it goes out of bounds when clicked.
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.
I find clicking on these form controls very satisfying :)
I love it, it’s perfect for a touch screen UI.
No because touching the items cause the effects to become occluded by your finger.
Also, the buttons on those spinboxes are way too small.
Nice idea but I feel like it would work better with a non-flat or mildly-3D theme.
Text boxes should jiggle where I click them, not always in the middle. Drop-down boxes do this correctly.
Ew ew ew visceral uncanny valley reaction to the on/off control. I never made it to scrolling.
I'm torn between ugh and ick.
It's poorly implemented and looks crude and unpolished.
There might be an idea there, for limited applications, but this isn't it.
ah finally. Compiz for react.
I miss wobbly windows.
> Compiz
Wow, you just unlocked a memory. Good times.
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.
Nor Firefox on Windows, nor Chrome on Windows. Very confused about what I'm supposed to be seeing here lol.
Working on mine, but… sluggishly.
That's gross, distasteful. I love it.
Is there an easy way to “reverse” the effects here? For example, on the “Jelly Button” I don’t want the part I press on to get bigger. I want it to get smaller and “inflate” the other parts of the controls that aren’t under my finger.
- anyone mind explaining to a beginner what kind of algorithm is used to achieve this effect
- i can see it changes size on clicking and dragging
- so what is the author actually doing?
Can be a great value add to show a jelly button when waiting for AI responses
Just 25 years too late to be used to design Jelly World
https://neopets.fandom.com/wiki/Jelly_World
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.
I love it - stupidly creative - first time i see this yet it feels I always knew how it was meant to behave
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.
I'm not sure I get why the slider lagging behind where the pointer that's dragging it is a good thing.
It's funny to have squishy buttons. But I also hate eye-candy. It just takes away time. Time is so finite these days...
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.
Your scroll is messed up on my Macbook M3 Pro / Opera, it's like a broken "velocity scroll" that is too loose and scrolls past several items leading to a clunky experience
Point taken, scroll-jacking has been removed.
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.
Looks so nice and it's lots of fun. Great job!
With that said, I hope no one ever uses it, it's terrible.
Stop scrolljacking me.
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.
love it I can think of many projects that could use that
? 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.
ah oh! yea only way to use mac....
I love the aesthetic, and I really love that they implemented it as a web component library.
Absolute bliss.
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.
then we wonder how are modern computers so slow?
it'd be great if flutter had this
Waste of computing resources, and mildly distracting. This reminds me of compiz.
No, compiz was awesome
Terry Davis had a word for things like this.
Material Design engineers furiously prompting Gemini to copy it
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.
Nobody expects the scroll behavior to be different on a webpage, so it's always a surprise when a page does something like this. Then, you have to learn to adapt to how it expects you to scroll so that you don't screw up its animations or overshoot.
It's the kind of UI that works if you scroll a specific way. A lot of people probably do. But if you don't, it's all very tedious. I consider that to be poor design.
Navigating by clicking and holding a desired position on the scrollbar is completely broken.
It's completely broken if you use it with a mouse that has a scrollwheel.
I had no problems moving one tick at a time with my mouse wheel.
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?
For me, I scrolled, clicked, but the page hijacked my screen, moved its position by force, and I was not certain which pane I was on immediately. It broke my sense of continuity.
I am only being literal when I say this, but as someone who is actively keeping an eye out for this sort of thing (CSS frameworks, UI kits), I lost interest pretty immediately when I saw that and closed the tab immediately. Assuming the people who made this page also made the UI kit, it tells me their web design values run contrary to mine.
I don't even fall into one of the exceptional cases, and this was a very bad using-a-website experience for me.
On a desktop or laptop computer, most trackpads have an immediate response curve. I am using one now, an Apple Wireless Trackpad. A very large amount of engineering effort over decades of time and millions of lifetime hours went into making it behave that way over a common wireless medium. I scroll a little bit, it scrolls a little bit, immediately, I scroll a lot, it scrolls a lot, immediately, and if I flick my finger from the bottom to the top and let go, it behaves as if I swiped a page of paper on my desk in the same fashion, with inertia taking over, proportional to how fast I flicked.
There is therefore an intrinsic physical link between the actions of my fingers, and the motion on the web page. My finger moves, and an immediate, proportional response is observed. This is an utterly base level of how most humans interact with the world. It is why using a mouse or trackpad came quite easy to many people (and why some can flick a mouse in a shooter, turn a precise 274.9 degrees, move up 14.2 degrees, and click on the head of an enemy player in fractions of a second with pinpoint accuracy). It is also why even a toddler can use a touchscreen; direct manipulation is inherently understandable to even a baby.
When I am turning in a screw by hand with a screwdriver, the feeling of the screws threads through the handle into my fingers, the immediate force feedback, the observable, feelable progress of the screw in or out of its screwhole, forms this same interface. Where human and tool meet, latency and unexpected behavior, especially if divorced from the input force, are undesirable qualities of a tool.
Scroll jacking is to a trackpad or a fine scroll wheel as turning a screwdriver handle by twisting a bungee cord is to using a screwdriver. It unhooks the immediate, direct feedback from the motion of my hand; its jarring, unpleasant, frustrating. On this page, I immediately put two fingers on the trackpad and moved them less than a centimeter, and didnt let go, and the entire screen cycled its view, as if I pressed a button "move to next item". Except I didn't (and why would I want that in the first place???), I just moved my fingers less than a centimeter. Nothing in the real world moves like that except for things less than a centimeter away from falling out of balance. And it feels the same. Precarious. A common human reaction to things moving out of proportion to our body is nausea!
I think a better question is, can you give an example of "why/how" this solves any actual problem someone would have had scrolling this website had it not used scroll snapping? Would the top comment have been "Boy I wish this site had used scroll snapping, it would have been more well done and enjoyable that way"?
Some of the "slides" have more content than fits vertically in the viewport, and trying to scroll to the bottom to see it without getting bounced to the next slide or back to the top is very touchy and tedious.
It is bad because you are deciding something for ME, the user. That's bad UX because I want to decide my own experience and scroll jacking is the worst thing you can do for UX. Stop doing this.
I liked it.
It ignores my scroll wheel most of the time if I try to scroll multiple times in a row.
The scroll is delayed significantly from when I scroll to when it actually scrolls.
The amount scrolled is inconsistent, sometimes it scrolls a very slowly a tiny amount because the page doesn't fit on the screen by an unknown tiny fraction, but if I scroll again because it is scrolling both slowly and with delay it now scrolls an entire page.
If I want to scroll past one of the demos I have to wait
If I drag the scroll bar on the side slightly it often snaps backwards.
It feels like I'm interacting with a phone/tablet screen on a computer, there's a reason why windows 8 failed.
I’m on my phone and scrolling this page just leads to it constantly jumping up and down and makes it difficult to read as nothing stays in one place if I scroll a little bit.
It just violates my expectations, and thus feels frustrating. And there's almost no benefit.
It would be like if my shoes suddenly made me take steps at perfect widths, and no matter how/where I tried to step on my own, they forcibly move my foot to the spot they think is best. Like, okay, I see the good intentions here. But I have no trouble walking on my own. I don't need help. So I'm not sure what problem this solves. And this would obviously feel jarring and awkward, and would take a lot of getting used to until it didn't.
Except at least my shoes go with me, so presumably if I had a pair of auto-stepping shoes I would get used to them over time. But this website is a one-off, I'm going to visit once and never again, so it's just going to be weird and jarring, and then I'll leave.
Different browsers handle scrolling differently, and people use a myriad of different "pointer" input devices, there's too many permutations to handle correctly. It's for similar reasons why building native inputs from scratch are fraught with peril (see this item from a few days ago)
https://news.ycombinator.com/item?id=48930136
I liked it. I'm curious how it affected you negatively?
I moved my scroll wheel a single tick and the content of the browser window completely changed with no movement to indicate scrolling was happening.
The change was so sudden and stark that I thought some sort of error had occurred and I was looking at a broken render of whatever I should be seeing.
Might be slightly better if the background didn't change color as soon as you move off the first "slide". Then it might not feel like you left the site or got dumped to an error page.
The moment I see scroll-jacking on a website, I bounce. I don't even think twice.
The scrolling behavior on this site worked great for me—it let each example stand on its own and meant I wasn't spending a lot of effort trying to figure out when a given example would end and the next example would begin.
It doesn't look like there's anything custom going on here either, it's all just standard scroll-snap-* CSS properties. if you have an issue with the way your browser is handling the scroll-snap CSS properties, I recommend you take that up with your browser? After all, you should be using a user agent that works for you, not against you.
insightful, thank you
People have spoken, so I removed the scroll snapping.
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.