ProseMirror (and as the sibling comment mention, Lexical) should handle this fine.
Both mobile Safari and Chrome Android do a ton of weird things that their desktop siblings don't, and play loose and fast with standards, so getting things to work correctly there tends to involve a long tail of hacks. Wordgard will get there but the focus before this first release has been on architecture.
I know that's how sanctions work. What I mean is that the possibility of being locked out of a central facet of my digital life by US legal processes is another strong motivation for self-hosting.
I've had another report like this (they claimed it had been down for days). But I haven't noticed anything wrong with it (and I'm using it a lot). What did 'down' look like?
Also, though GitHub's lack of reliability was part of the motivation to self-host, it was only a minor factor. The way they are trying to make Copilot a thing, at the cost of everything else, the way they handle US sanctions by blocking everybody from entire countries, and the way the web interface feels ever more heavyweight and sloppy were also factors.
There's a significant amount of code in Wordgard that is copy-pasted from CodeMirror or ProseMirror, but modified enough that trying to share it would involve nightmarish amounts of type parameters and extra indirection. You could certainly build a generic editor framework and then build several editors on top of it, but you'd end up with Raku-level amounts of architecture acrobatics and extra complexity, much of which would leak out in the public library interface, and I don't think that is generally worth it. I do occasionally, when I realize a bug fix applies to one of my other projects as well, repeat it there. But that's okay.
First-class mobile support should be there (though there will be bugs, given that this hasn't seen much real-world testing yet — report them if you see them).
I haven't entirely decided what utilities I'm going to include in the core library, but mentions are definitely on the list for potential inclusion.
> The thought that Prosemirror is no more in active development is scary.
Which is a thing that I never said. In fact I went out of my way in all the announcements to stress that ProseMirror maintenance is continuing as it has been.
Also MIT-licensed software doesn't 'go away' all that easily. If a piano fell on my head tomorrow, interested parties would probably manage to continue development in a fork.
It may not be. If you're happy with ProseMirror, continue to use ProseMirror. I have your back.
But as the blog posts describes, I had a whole pile of new design insights that avoid some of the issues I've ran into with ProseMirror, so I had the itch to build a new iteration.
I'll add a link to the blog post to the docs section of the website.
I'll be the first to admit that ProseMirror's change representation is a bit messy, but I don't think that's the root of the issue here. The problem is about generalized tree-structured document representation (as opposed to the flat-string model of Quill). I believe such a representation has value, and is the appropriate choice for a system like ProseMirror or its successor. Joining and splitting blocks is not a weird quirk of ProseMirror—it is a basic, essential editing operation. But there doesn't appear to be a known appropriate way to map that structure to a CRDT in a way that can properly express such splitting and joining. And that's fundamentally limiting the approach taken in y-prosemirror.
I watched the presentation, but I'm getting the impression that you're still using a hierarchical XML-like structure for the document, which sounds like it still cannot merge or split nodes (without recreating the content after the merge or split point). Will issues like https://github.com/yjs/y-prosemirror/issues/205 be addressed by this? (Which not only breaks ProseMirror's position mapping, but also your own, and which I consider a serious enough bug that recommending y-prosemirror for anything feels unserious.)
Hi Alex, I'm the author of prosemirror-collab. I agree with your point that CRDTs are not the solution they often claim to be, and that CRDT editor integrations (at least the ones for Yjs and Automerge) are often shockingly sloppy.
But, seeing how I've had several people who read your article write me asking about this miraculous collab implementation, I want to push back on the framing that ProseMirror's algorithm is 'simple' or '40 lines of code'. The whole document and change model in ProseMirror was designed to make something like prosemirror-collab possible, so there is a lot of complexity there. And it has a bunch of caveats itself—the server needs to hold on to changes as long as there may be clients to need to catch up, and if you have a huge amount of concurrent edits, the quadratic complexity of the step mapping can become costly, for example. It was designed to support rich text, document schemas, and at least a little bit of keeping intentions in mind when merging (it handles the example in the first post of your series better, for example), but it's not a silver bullet, and I'd hate for people to read this and go from thinking 'CRDT will solve my problems' to 'oh I need to switch to ProseMirror to solve my problems'.