Not to discount the work or end result that went in to this, but when I saw Pixels I assumed it used a 'standard' library, e.g. Leaflet, used for many maps (which have similar zoom) and tiles. I'm wondering why you wrote something from scratch?
From the article:
"For this project, I chose to use vanilla JavaScript with no external dependencies or libraries. In general, we strive to keep the dependency count and build process minimal for these projects, since keeping the complexity level low gives them a better chance of aging well in the archives."
The initial idea was to use a tileserver-based approach like leaflet. Writing a custom renderer allowed us to have unique views per client infinitely deep that zoomed smoothly, rather than at fixed intervals. Another benefit is avoiding the on-disk size and generation CPU time of building tiles, as well as the bandwidth costs of serving a bunch of redundant views of the same image data.
As someone who helped convert #1110 (Click and drag) into one of the (subjectively) better zooming implementations (http://dump.ventero.de/xkcd1110/), I immediately wondered whether Pixels would benefit from Seadragon as well. Then I noticed that it's infinite and I wasn't quite sure anymore whether a DZI could do that properly. Perhaps by generating a sparse DZI on the fly in the browser. But that way probably lies madness, too. Also anti-aliasing would have to be turned off beyond 100 % zoom of individual images, which I'm not sure is trivial to hack in there.
Still, I think from a UX perspective the slightly springy behaviour of Seadragon is much nicer than the algorithmic rigidity of things like Leaflet or Google Maps.
Leaflet only allows discrete zoom levels as far as I know, whereas Pixels zooms continuously. I'm not sure a tile layer with an infinite number of zoom levels is possible either. At the very least, it would require extensive hacking.
