HN Debrief

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

  • Design
  • Frontend
  • Accessibility
  • Developer Tools

Jelly UI is a showcase site and component library for animated web controls that deform like jelly when you click, drag, or type. It is implemented as custom elements and aims to make standard UI parts feel more tactile. The appeal landed immediately for some people. They saw a rare bit of fun on the web, liked that it respects the system reduced-motion setting, and said the effect could work for playful surfaces like games, kids sites, or a single standout control rather than an entire product.

Treat this as a visual experiment, not a drop-in design system. If you build custom controls like this, profile idle rendering, preserve native interaction rules, and test reduced-motion, scrolling, and hit targets before you ship anything user-facing.

Discussion mood

Mixed leaning negative. People liked the creativity and novelty, but most of the energy went into complaints about janky scrolling, laggy or inconsistent interaction, and the usual pitfalls of replacing native controls with custom animated ones.

Key insights

  1. 01

    Pointer tracking has to feel locked on

    For direct-manipulation controls like sliders, the effect only works if the handle feels physically attached to the cursor or finger. Once the visual deformation introduces noticeable lag, the illusion flips from tactile to broken. That also points to a more promising use case than eye candy alone: shape changes that help people acquire small targets or compensate for limited motor control.

    If you animate input controls, set a hard bar on input latency before you tune aesthetics. Accessibility gains will come from improving targeting and feedback, not from making controls look more alive.

      Attribution:
    • JoshTriplett #1
    • socalgal2 #1
    • rickydroll #1
  2. 02

    Native behavior is the hard part

    The detailed teardown makes the core problem plain. Building custom controls means reimplementing all the fiddly behavior users expect without thinking about it. That includes canceled clicks, keyboard navigation, grouped selection semantics, large and continuous hit targets, and sane text entry. The visual layer is the easy part. The long tail of interaction correctness is where most of the real work sits.

    Do not evaluate a custom control library on screenshots or demos alone. Run it through keyboard use, drag-out cancel behavior, text input edge cases, and assistive workflows before you consider adopting it.

      Attribution:
    • chrismorgan #1
    • smilespray #1
    • itishappy #1
  3. 03

    Idle rendering is a real smell

    The useful performance point was not that every animation loop is automatically wrong. It was that visible idle work in a browser UI deserves suspicion because it eats frame budget before the user does anything demanding. Another commenter noted the header animation appeared to cost more than the widgets themselves, which is a familiar web performance trap: the showcase chrome can dominate the thing being showcased.

    Profile demo pages separately from the library code. If you see steady repaints while nothing is moving, treat that as debt that will compound once your app adds real work.

      Attribution:
    • jlukic #1 #2
    • wbobeirne #1
    • Rohansi #1
  4. 04

    Reduced motion needs visible handling

    Several people initially thought the site was broken because their system had Reduce Motion enabled and the main effect disappeared. Respecting the accessibility setting was the right default, but a motion-heavy demo also needs to explain what happened and offer an explicit preview toggle. The author added both after the feedback.

    When your product changes dramatically under accessibility preferences, surface that state in the UI. Otherwise users will misdiagnose the experience as a bug and never see what you meant to show.

      Attribution:
    • TurkTurkleton #1
    • zdragnar #1
    • baldvinmar #1
    • wbobeirne #1
    • anotheryou #1

Against the grain

  1. 01

    The rendering cost may be overstated

    The pushback on the performance pile-on was that a requestAnimationFrame loop is not inherently absurd, and a few animated controls should be trivial work on modern hardware when implemented sanely. In this reading, the worse offender was the page’s decorative header and the scroll behavior, not the jelly math itself. One commenter also said the scroll-snapped layout helped isolate each example cleanly on their setup.

    Separate objections to the concept from defects in the demo page. If you are judging a motion-heavy UI, test the widgets in isolation before concluding the whole approach is too expensive.

      Attribution:
    • Rohansi #1 #2 #3
    • nightpool #1
  2. 02

    Used sparingly, the effect can help

    The pro case was not that every app should look like this. It was that animated deformation can add immediate feedback and make a single control memorable when used with restraint. People pointed to game-like surfaces, playful brands, or one-off interactions where delight is part of the product rather than a distraction from it.

    If you borrow this style, keep it local. Pick one or two moments where stronger feedback supports the brand or task, and leave the rest of the interface conventional.

      Attribution:
    • blauditore #1
    • red_hare #1
    • kfarr #1
    • madebysnacks #1
    • NetOpWibby #1

In plain english

custom elements ↩
A web standard for defining new HTML tags with their own behavior, often used in web component libraries.
OTP ↩
One-Time Password, a short code often used for login verification or two-factor authentication.
scroll-jacking ↩
A design pattern where a webpage overrides normal scrolling behavior, often making scrolling feel delayed, jumpy, or forced.

Reference links

Performance evidence and related demos

Resources for finding UI systems

Pop culture and nostalgia references

Related Hacker News discussion