This is really valuable! Just to add a bit of context: I'm not the only one using canvas for rendering. Google Docs did it years before me. Think of it this way: I've built this almost entirely alone and still get most of the basics working.

Let's start with your test. I think the reason it struggled with the Gutenberg text is that it had a lot of images. Either way, that's a bug and it should be fixed (it shouldn't load all the images at once, and there's probably too much work happening on the main thread). I really appreciate the effort you put in.

I could also use a WebGPU or WebGL context, which would certainly be faster. I think I had a working version last year, but it had problems with blurry rendering (font hinting). I don't remember the exact details now.

Overall, I'm really thankful that you pointed these out. I'll try to work through them over the next few days. I do disagree with the premise, though: canvas is more than capable of achieving this. Performance shouldn't be an issue. That said, I agree with your points about integration with context menus and other tooling.

▲

chrismorgan 11 hours ago | parent [-]

I have pointed out various fixable bugs, but I also pointed out some critical things that are fundamentally unfixable, and make the entire approach unbearable. You cannot make it acceptable on a pretty large fraction of mobile devices, and even where it’s not horribly broken, it’s still radically different from every single other thing on the device in extraordinarily frustrating ways.

As for Google Docs, well, I’ll just link to what I’ve written about it before: https://news.ycombinator.com/item?id=42253177. I honestly believe they lied in their justification, because the resulting experience is genuinely worse in every way. I can’t comment on how it is on mobile, because I’m too lazy to log in, and they probably do something different on mobile anyway.

▲

hamza512b 8 hours ago | parent [-]

What choice do we have? We have to find a solution to the problem. ContentEditable is much harder to work with. This is a solution, and I hope we will at some point work out a new web API that makes these tasks easier.

Your reasoning is that I am missing out on a large percentage of users. I understand where this is coming from. I am working on mobile apps as well, as I did with iOS. I can try to close that gap even more, but I can't just switch to ContentEditable. I don't have the time, and there are already tons of projects that do that.

But if Google did it at their scale, then I think the tradeoff is reasonable, don't you think? You said in another HN post that they don't really use pure canvas. What do you mean? ContentEditable for capturing input?

	▲	chrismorgan 8 hours ago \| parent [-]
		By the time you’ve fixed as much as you can, you will certainly have more code, more complex code and more fragile code than you would have had from massaging contenteditable into your desired shape, and your result won’t even be better than it in any indisputable way. “Pure canvas” means when the entire app runs inside a canvas to the maximum extent possible, such as with https://www.egui.rs/. Google Docs isn’t pure canvas because it uses regular DOM for the chrome, leaves text rendering to the browser (fillText or whatever) and uses real scrolling area (multiple canvases, tiling). Yours is similarly not pure canvas, though it’s a little closer in the obviously-bad way of how you implement scrolling yourself. “Google did it” is not an endorsement for others doing it. They have often quite bizarre rationales that truly don’t apply to smaller organisations. As I have written, I’ve thought it through carefully multiple times in multiple ways, and I honestly believe they were lying about their motives through and through, because they just don’t make any sense. Google Docs was unambiguously better before they migrated to canvas, and most of their claims about what it got them were demonstrably false.