Jelly UI's Real Trick Isn't the Physics
The wobbly Web Components demo hides a reference-grade implementation of form-associated custom elements.
A UI library where buttons squish, switches wobble, and text inputs deform like a poked gummy bear shouldn't be worth serious attention. Jelly UI is, though — not because of the physics, but because of what's underneath it. The demo that hit the Hacker News front page this weekend (nearly 300 points and climbing) is a dependency-free Web Components library where every one of its 40 controls is a real, form-participating, keyboard-accessible HTML element. The wobble is the hook. The plumbing is the story.
What's actually squishing
The soft-body effect isn't a CSS trick or an SVG filter. Each control renders its visible chrome to a Canvas 2D surface driven by a custom simulation the author calls JellyBody: a closed ring of spring-coupled membrane points around a rounded rectangle, with pressure-based volume preservation so the shape squashes instead of collapsing. Press a button and the membrane deforms toward your pointer; release and it rings back to rest.
A single shared requestAnimationFrame loop steps the whole page's bodies in fixed-size substeps — the standard trick for keeping spring integration stable when frame timing jitters — and parks itself when everything reaches rest, so an idle page is supposed to cost nothing. There's even a defensive reset: if a body produces a non-finite number, it snaps back to its rest state rather than exploding, which anyone who's shipped a spring system will recognize as a scar earned the hard way.
That "supposed to" matters. An HN commenter profiled the demo and found repaints firing every 8–11ms while idle. The author's response — the loop maintains an active set and evicts settled bodies — is architecturally right, but the profile suggests the parking logic wasn't airtight at launch. If you're evaluating this for anything real, open DevTools' performance panel on your own page, not the marketing site, and check what happens after interactions settle. Canvas-per-control is a fundamentally more expensive rendering model than CSS, and on battery-powered devices that difference is a product decision, not a nitpick.
The part worth stealing
Here's what separates Jelly UI from a decade of physics-toy demos: the controls are real. The library uses ElementInternals so its custom elements participate in native form submission — a <jelly-input> shows up in FormData, responds to form resets, and reports validity like a built-in <input>. Focus lands on genuinely focusable elements inside shadow roots. The ARIA patterns are the correct ones (combobox, tablist, modal dialog), keyboard maps include details like Shift+Arrow fast-stepping on sliders, RTL works via logical properties, and the color tokens clear WCAG AA in both themes. Under prefers-reduced-motion, the springs collapse to instant state changes.
Form-associated custom elements have been shipping in every major browser for years now, and almost nobody uses them. The overwhelming majority of component libraries — including expensive commercial ones — still fake form controls with div soup and re-implement (badly) what the browser gives away for free: autofill, validation, form participation, focus management. A solo developer building a novelty physics library did the boring standards work more rigorously than most design systems at funded companies. That's simultaneously a compliment to this project and an indictment of the ecosystem.
If you read one thing in the source, read how the form controls wire up internals, not how the springs integrate. It's a working reference implementation of a pattern the platform has been quietly begging developers to adopt.
Launch day as public QA
The HN thread doubled as a live bug tracker, and the author's response is instructive. Scroll-snapping on the demo page — which broke middle-click autoscroll and made scroll distance unpredictable — got ripped out after sustained complaints. Buttons that fired clicks after the pointer left their bounds got fixed. Users with OS-level reduced motion enabled couldn't see the physics at all, so a toggle appeared to opt back in. Hit-target gaps between switches and their labels got flagged.
None of these are exotic bugs; they're exactly the interaction details that separate a demo from a component library, and they're why "40 components, one person, launched this week" should temper adoption enthusiasm regardless of how clean the architecture is. The repo sits at a few dozen stars with a bus factor of one. MIT-licensed and readable, yes — but you're adopting a codebase, not a community.
The pendulum has been swinging back for a while
Wobbly UI is not new. Compiz gave Linux desktops jiggling windows in 2006, and the Flash era produced a whole genre of elastic interfaces before flat design sanded every surface down to a rectangle with a 200ms ease-out. What's changed is that the platform caught up: spring physics that once required a plugin or a compositor now fits in a zero-dependency script tag. And Jelly UI isn't alone — Software Mansion has been prototyping GPU-rendered jelly components with TypeGPU, and Apple's Liquid Glass push has design teams everywhere re-litigating how much material physicality UI should have.
The direction of travel seems clear: after a decade of flat minimalism, tactility is becoming a differentiator again. Motion that communicates state — this button felt your press, this switch has mass — is genuinely useful affordance, several HN commenters noted, when applied selectively. Forty wobbling controls on one screen is a theme park. One or two, on the interactions you want users to feel, is design.
Verdict
As a product dependency, not yet: it's a week-old, single-maintainer library with launch-day performance and interaction bugs still warm, and canvas-rendered chrome carries real costs that CSS-rendered controls don't. As an engineering artifact, it's one of the best arguments for form-associated custom elements anyone has shipped — proof that you can have an aggressively weird visual layer on top of boringly correct platform semantics, instead of choosing one. Drop the script tag in a side project, poke a checkbox, then go read how ElementInternals is wired. The squish will stop being fun in ten minutes. The pattern underneath will outlast the trend.
Sources & further reading
- Jelly UI - Soft Web Components — jelly-ui.com
- Jelly UI: Soft-body physics for native HTML form controls — news.ycombinator.com
- jelly-org/ui: Soft, tactile components for product interfaces — github.com
- gooui: UI components made of Jelly, built using TypeGPU — github.com
Lenn writes about cloud platforms, Kubernetes internals, and the infrastructure decisions that quietly make or break engineering organizations. Based in Berlin's vibrant tech scene, they have a talent for turning dense platform-engineering topics into prose that people actually finish reading.
Discussion 0
No comments yet
Be the first to weigh in.