Hacker News Reader

Comment by xpl | Hacker News Reader

> We wanted users to be able to see all their content on one screen > with many thousands of nodes on the screen

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...

View on HN

I don't think of it as "needing WebGL", but as something finally utilizing it for this. Just about anything gets better if you can find a way to do it on the GPU, at least when considering hardware easily available for consumers. The sheer performance that enables is a quality of its own IMO.

> 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 :)

> Browsers zoom in and out in 10% steps

Not entirely true — on Mac I can pinch zoom this Hackernews page super smoothly (in Chrome) using trackpad.

Same on Windows if you have a "precision" trackpad.

> People who want what they already have can just use what they already have.

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.

I had the same thought regarding the renderer — the worst case scenario would be a complex design with correct code that renders incorrectly in the app. I’d sacrifice frames per second just to avoid ever being in that position.

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.

We agree that making the editor match the browser is super important. At some point we'll have implemented the whole CSS spec. Then, it should always match exactly.

Or at least we'll match Chrome. Sometimes browsers don't match each other.

Building a layout engine is, i think, most of the browser, in a world where we have extremely few browser engines. I'm sure you've got enough on your plate already but in your back pocket, maybe have a thought for running your renderer on standalone wgpu, throwing in V8 bindings, and becoming the next Ladybird / Servo?

We already do lots of rendering to cached images. It's not a panacea. It saves you from unnecessary recomputing. But many actions update the rendered state per-frame. Zooming is a great example. You can't cache it at every resolution.

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 :)

Do you have any plans to open source / license the core rendering engine. Seems very useful for rendering in other contexts like textures for animations.

We weren't planning on it. It's not very clean or transferrable. We really hacked it together. We'd have to do a ton of work to make it useful for anyone.

> You can't cache it at every resolution

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?

Reply on news.ycombinator.com