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.
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.
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?
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.
So browsers are evil when they prefer to be backwards bug compatible rather than fix their contenteditable. That puts the onus on billions of users who can't do shit about it, and that's supposed to be okay. What a shoddy state of affairs!
That's what makes me applaud the effort here, and any defects it may have are less important than fixing the basic deterministic key-stroke driven editing behavior (which is what they fail at).
It's not necessary to fix everything to the needs of everybody, and be perfect. It's rather easy to be better in that one critical aspect, and put contenteditable to shame in 80% of the use cases.
I think you defeated yourself when you took on the responsibility for a 100% coverage replacement. Didn't you notice that this wasn't your responsibility to begin with? There is a market for a neat, capable, and deterministic markdown based editor.
I take advice and feedback like yours seriously, thank you for giving your opinion, I appreciate it. For iOS, I tried to make it work, but iOS has really made it tough in that regard. For some reason they do not like a hidden contenteditable controlled by a canvas. That is part of the reason I have an iOS app published on the App Store.
Also, I know that LLMs might sound wrong to many, and I get where this is coming from.
For me, AI gives me, as one lone developer, the power to create and implement these ideas. It helped me translate and do so much more. I agree this may create a feeling of distrust, and I don't think it should not replace thinking.
iOS was telling you “don’t do this, it won’t work”, and your answer was to ignore it, ship something broken, and make an app for certain platforms as well.
The LLM will happily help you to implement the wrong thing. It’s not good at saying “you can try doing this, but the result will never be good”.
> What other choice is there, if iOS restricts it?
Normal contenteditable, just as everyone has done successfully for many years. There’s a reason why almost no one does things in this canvas way at all, and even closer to no one does it so on mobile platforms.
“iOS restricts it” is altogether the wrong take. It’s more that the approach only lets the browser/keyboard see one word at a time, and that’s fundamentally limiting beyond what they can cope with. Honestly, the implementation here is one of the best ones I’ve seen, but it’s still fundamentally not acceptable.
And that’s a part of why I said the approach is bad: there’s a long tail of native features that depend on being able to see/interact with more than just the current word or selection or whatever, and you’re thwarting that. You cannot make a lot of them work, and the more effort you put into trying to cover them, the more you end up with something even unholier than contenteditable.
Give up. Seriously, please. Switch to DOM, it is genuinely mandatory for acceptable results.
You can get close enough on desktop that many users won’t notice, but you emphatically cannot reach even tolerable on mobile.
Google has switched in 2020 (if i am not mistaken to canvas), but I am not saying this would be the solution to everything, It is just another option one could do. I do not know if someone noticed this, but that is part of the reason you could not just open google docs on mobile. Because I would suspected that it would been too much effort for them back than. In anyway Tasfer tried as best as possible to do that on mobile too.
As far as I know, Monaco, the editor behind VS Code, does not use canvas. I noticed that Google Docs uses canvas, and that was the start of my project a year ago. I think that if I had used another context, like WebGL or WebGPU, it would have been much more performant, but it is really hard to render text and parse font files that way.
Anyway, I have gotten good enough results, and I don’t think normal usage will exceed the limits of the 2D canvas.
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.
reply