After a bit of an inspection, it looks like they segment the viewport into multiple canvas elements. I don't think repositioning loads of canvas elements by translating the parent div in CSS is the most performant approach, but I may be wrong.
It would likely be more performant if the map view was a single canvas and panning, segmentation and so on was done in a buffer and rendered to the canvas by blitting the pre-rendered sections, or something along those lines. Maybe even rendering the sections to WebGL textures and using a WebGL context for the canvas.
You're right that using canvas/WebGL will be much faster. It seems the embeddable Google Maps JS library recently moved in this direction, though it appears they kept the layers of stacked divs (almost certainly for backwards compatibility with existing users who have HTML layers that need to be kept in sync.)
But something fun to notice with Felt is that the rendering library (LeafletJS) is using transform3d to do 2d translations (instead of just using translate), so you may wonder "why?" At least in Chrome (and it seems in Safari) if you use transform3d the browser is more likely to keep the div in its own layer. This will reduce a lot of the paint/compositing time, and make the frame rate dramatically better. Of course in this case the micro-optimizations are irrelevant in comparison to Felt's JS performance problems (which on my machine appears to be due to projecting 2000 points from lat/lng space to pixel space every frame.) Choosing to project points every frame is super confusing because the whole point of the translate/transform3d optimization is to avoid having to recalculate pixel space during the latency-sensitive pan interaction. Odd.
I was exactly the same. As soon as I read that hyperbole I immediately closed the page. You’re either dishonest or perform terrible tests which means I’m not going to trust much else of what you write on your landing page.
Given the context, "Never wait for a dataset to load again. Where typical internet maps take 30+ seconds to load after each pan and zoom, ...", it seems to be specifically talking about loading and rendering new bits of data taking 30+ seconds when you pan and zoom, not just panning and zooming the map itself.
""" Where typical internet maps take 30+ seconds to load after each pan and zoom """
What typical maps are the talking about?