alt Hacker NewsZooming UIs in 2026: Prezi, impress.js, and why I built something different
There are essentially two established ways to use zooming in web interfaces today. They serve different purposes and make different tradeoffs. I built a third one, so I'll try to be fair about what each does well and where it falls short.
* Prezi Prezi pioneered the zooming canvas for presentations and remains the market leader in that space. It recently added AI-powered generation and text editing tools. It's a polished product with real traction.
But Prezi is a closed platform, not a library. You can't use its zoom engine in your own app. Pricing starts at $15/month for meaningful features, and exporting to PowerPoint flattens all zoom effects into static slides. A recurring complaint from users is that the zooming and panning transitions cause motion sickness. And fundamentally, Prezi uses zoom as a storytelling device between pre-arranged frames. It's not a navigation model. It's a presentation model.
* impress.js impress.js brought Prezi-like zooming to the open web. It's a presentation framework based on CSS3 transforms and transitions, directly inspired by Prezi. It was genuinely groundbreaking when it launched. Its architecture is step-based: you position "steps" in 3D space and the camera moves between them. That's great for presentations, but it doesn't help you build an app where users navigate by zooming into content. impress.js has no concept of dynamically mounting views, managing zoom depth, or handling navigation state. It's a slide deck engine with a zoom trick.
* Zumly This is what I built. Full disclosure: I'm the sole developer. The idea is offering an alternative to traditional page navigation using zooming. You mark an element as zoomable, point it to a view, and Zumly handles the transition and inserts new views. That's basically it.
I started Zumly in 2020 after leaving behind Zircle UI (a Vue zooming library), trying to take what I learned further. Framework-agnostic, focused just on the zoom part. Since then I've rewritten the engine several times, changed the approach more than once. Only now I'm actually happy with how it feels.
Views are dynamically mounted and unmounted during zoom transitions. In impress.js, all steps exist in the DOM simultaneously. In Zumly, you zoom into a trigger element, and the target view gets injected and scaled into place. This is closer to how routing works in SPAs than to how slide decks work.
The landing page is built with Zumly itself so you can get the feel before touching any code.
Curious if anyone else has thought about this space. What makes zooming UIs work or fail?
Landing page (built with Zumly): https://zumerlab.github.io/zumly
GitHub: https://github.com/zumerlab/zumly
Comments
My jaw did drop. This could pair really well with a hybrid bread crumb + menu that gives you an escape hatch or granular on demand traversal. Love it!
Interesting way to use zooming as a way to transition deeper into sub-dashboards. The navigation from "Mission Control" -> "Satellite" -> "Subsystem" feels oddly intuitive and fun. I would maybe opt for keeping a consistent navbar/sidebar, to support out-of-zoom navigation. And if we are dealing with a lot of power-users some breadcrumb to quickly go back to any zoom-level. But overall, i think this could totally work.
It's extremely easy to break your landing page with the back swipe gesture on mobile safari.
I really love this (and miss the days when Prezi was simple and straightforward).
I've written an app myself along sort-of similar lines, but it's less a presentation app and more a thought organizer (works on all Apple platforms). https://mindscopeapp.com
I think what proved key for my own "zoomable" UI was cross-linking, search, and speed/snappiness. Make the animations too heavy and it just slows you down. Zumly seems really great in this regard. Well done!
Really cool, like others are saying this makes you feel like you are interacting with all the pages at once instead of one page at a time.
I did notice that forward doesn't seem to work. I.E. If I click into a page, it zooms in, press back it zooms back out, press forward it flickers the url but doesn't have normal forward behavior.
I also don't know if you want to support `open in new tab` but that would be a hard req for many people.
This looks seriously impressive. Also, I wonder what the a11y implications are. I don't miss Macromedia Flash hell at all. This is HTML5, so with a bit of effort it could look beautiful and still cater to the visually impaired.
Edit: I can't scroll any of the showcases. Probably deliberate, but a cut-off UI can be annoying.
Edit2: I opened the yellow car on the production line and going back the page got all offscreen and looks messed up
I think about this space a lot, see Eagle Mode: https://www.youtube.com/watch?v=G6yPQKt3mBA
Love it. But there is a significant usability issue: Lack of signifier (aka affordance). How do I known when something is zoomable? Because there is no signifier, I am frequently disappointed when I click on something and it turns out it is not zoomable.
This is indeed seriously impressive. I keep wanting to keep my entire knowledgebase on a canvas so that I can "think" or navigate spatially. Thisis neat.
In the main landing page, as I was clicking around, I kept wishing to have a legend to show me either "how deep I am" or "how do I get out of here?", and like someone else commented, I would love an affordance showing me what was clickable/zoomable.
I'd say this is more of an interesting take on page transitions. I was expecting mouse wheel scroll to zoom, so I instinctively scrolled expecting some kind of zooming effect.
I remembered there was a website featured here on HN that had an interactive tour of the scale of the universe ranging from the very microscopic world (if I remember correctly I think it even went down to Planck length) all the way to the macroscopic (black holes, galaxies). I'd be interested in such a zooming library that achieves something like that.
> remains the market leader in that space
TIL
I think zooming is effective when it's used in isolation for discrete things. It does add a sense of delight, but there is a functional usefulness of this that I'm trying to wrap my head around.. perhaps a transition effect for an immersive demo, etc.. nice work.
HA! I Love it! It's a been a while since I felt this sort of joy exploring a new way to navigate
Interesting. At one point I pinched my iPad to zoom out of habit and it got very confused. But yea, interesting.
Would suggest using history-api navigation over the hash based routing.
I have great respect for people pursuing their special interests with such perseverance - you clearly care about zooming UIs.
And so do I (just to a lesser extent)! It’s a great way to express hierarchy.
One thing I encountered is that it becomes all buggy after using the slide-back navigation gesture in iOS Safari. Yet this being natively handles would be a really cool thing to me, like those iOS “close back to thumbnail” gestures you sometimes see when scrolling up/down that I haven’t really seen replicated anywhere else.
Doesn't work correctly in Firefox.
Feels sluggish, but maybe this could be fixed by reducing the transition time.
But why? People usually don't notice such transition effects and it doesn't affect user experience in any meaningful positive way. It feels absolutely unnecessary.
Maybe you could re-use it as a mod for some game engine. This feels appropriate for video games; not for web-sites.
"Zooming UIs in 2026: Prezi, impress.js, and why I built something different"
[dead]
As someone who suffers from vestibular migraines, unfortunately visiting the demo site instantly made get dizzy. I highly encourage you to implement the "@media (prefers-reduced-motion: reduce)" media query to handle accessibility [1]. I'd hopefully expect the zooms to turn into normal links or failing that, either slow down or have some kind of non-vestibular-attack-inducing flow.
Here are some other good resources: https://www.a11yproject.com/posts/understanding-vestibular-d... or https://web.dev/articles/prefers-reduced-motion
I don't say this as criticism as I'm sure you've never heard of these issues before, but something I'd encourage you (or anyone who relies on animations) to implement into their package.
[1] https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/A...