> it is very hard to reproduce the native look and feel of text selection, editing and stuff, and even if you manage to get close to it, there will always be some "uncanny valley" effect...
People who want what they already have can just use what they already have.
And it's not just about matching it... you can scroll butter smooth at 240 fps. Or maybe you could make undo leave traces that fade out where something changed, making it more easy to follow when just keeping ctrl+y/z pressed for a bit -- or maybe that would make it harder, but the cool thing is that you easily try out all sorts of crazy things things when something is in shader form that would take a lot more effort to get working at 1/100th the speed any other way.
Browsers zoom in and out in 10% steps. That's incredibly crude and jarring. Like smooth scrolling, there could be smooth zooming. Or the other way, you only change zoom once the user has confirmed the new zoom level -- you can't do either in a browser. And that's such a tiny thing!
Of course how the GPU prefers things to be laid out kind of funnels what you'll end up experimenting with, but that's absolutely an avenue worth exploring, until you hit a wall, and then you climb that wall and keep going. Please :)
Not entirely true — on Mac I can pinch zoom this Hackernews page super smoothly (in Chrome) using trackpad.
My point is that while people may want to pursue what you described (some advanced UI behaviors), in practice they fuck up even basic functionality, because even that is almost impossibly hard to implement with text rendering and editing.
For example, in Repaint some basic emojis don't work. And I didn't even try inputting some Arabic or Hebrew or Chinese — I am sure that doesn't work too. Hats off if they manage to do it, but at this point they have spent all their funding on a custom text editor, while they could have spent in on actual features.
I, as a customer, don't care if a product uses WebGL or is written in Rust... All I care if it works or not.
Maybe there's a way and we didn't find it? We looked at every example we could find. There's a lot of canvas apps without WebGL. But they're all orders of magnitude behind the Figma benchmark. Everything not using WebGL felt noticeably less smooth.
And in our user testing, our texting editing is already past the valley :)
True, but you don't need everything at max resolution simultaneously, so you can update your caches according to the current zoom level and thus get infinite zooming if you want.
At a large zoom level, few things get into the viewport, so it shouldn't cause troubles. My guess is that the troublesome scenario is when you zoom out (so that lots of pages can get rendered simultaneously), not when you zoom in?
Regarding the text editor — I can’t stand using any editor that doesn’t have the hotkeys and multi cursor editing that I’m used to. I even stopped using note apps and just use vscode anytime I need to author more than a paragraph of text.
I worry that a clever image caching strategy and the Monaco npm package would be a better alternative for many reasons — especially considering the role that easy access to Devtools plays in the design process, which you also lose with a canvas.
Or at least we'll match Chrome. Sometimes browsers don't match each other.
Does it really need WebGL? You could pre-render things to images (memoize your rendering basically) and update the cached images only when the editing happens. As the interactive editing usually happens only locally, it could probably work well.
The obvious upside is that you don't need then to re-invent the browser's renderer and text editing from scratch, you could re-use it.
For example, this stroke me as an extreme NIH:
> We also can’t use the browser’s built-in text editor, so we made one ourselves
People usually just hate custom non-system text inputs, because it is very hard to reproduce the native look and feel of text selection, editing and stuff, and even if you manage to get close to it, there will always be some "uncanny valley" effect...