Hi all, I’ve published a first version of Wordgard, a new system in the same space as ProseMirror. If that sounds interesting, read the announcement post, which also goes into the main differences between Wordgard and ProseMirror.
This does not make ProseMirror legacy, and there is no need to worry about it being abandoned anytime soon.
WOW. That’s such a big surprise!
Nice! I can see how it can become a lot easier to build new editors on top of this as (based on the explanation) it sounds as if it addresses many of the issues we have run into. However, for those of us who have already built extensive editors on top of ProseMirror, working around these issues, there is the question whether or not to rebuild everything on top of Wordgard or whether to stick with ProseMirror. If ProseMirror is not legacy, does that mean that some parts of Wordgard, such as using beforeinput events rather than dom diffing will eventually also come to ProseMirror (it they prove to work out in Wordgard), or will this stay being a Wordgard feature? Are there any types of editors for which it will continue to choose ProseMirror also in the future (such as editors with very strict content order requirements)? Or is it just a question of whether or not the editor existed prior to Wordgard being announced?
We’ll have to see how much trouble the beforeinput approach causes (I expect there will be quite a few gnarly situations—I’ve already ran into a few issues where mobile browsers misuse these events in dumb ways). But if it ends up working well, that is definitely something that could be retrofitted to ProseMirror. Though that would also mean dropping support for some browsers, which may cause issues for existing users.
For the time being, if you need a stable library, you won’t want to use an unproven thing like Wordgard. And if ProseMirror is working well for you, sticking with it is perfectly fine. Once Wordgard is stable, I wouldn’t recommend building a new system on ProseMirror anymore. Even for strict schemas, you can probably do just what you need just as well with Wordgard corrections.
What a very happy surprise!
I for one am very happy to see CodeMirror’s facet system come over — we were even trying out some very anemic ways of expressing dependencies on other plugins in ProseMirror, and yearning for that api.
The new change model sounds pretty interesting as well. We build a number of features on knowing what region of the document has changed for performance reasons. And I remain interested the idea of document projections, where schema composition will make a number of tricks possible.
What sort of feedback are you looking for at this point, if any?
What a surprise! Can’t wait to build on top of this.
Great to hear. I can already tell from experience that extending Wordgard feels like it has an order of magnitude less friction than extending ProseMirror.
Firstly of course I want to know when stuff is broken, which some stuff probably will be. Then it’s also really helpful to see examples of things that are still annoying or impossible to do with the new interface, so that I can try to address that. And finally if you just see something in the API or user interface that you feel I should have done differently, definitely tell me. I may not always make the change you wanted, but I do integrate your feedback in my thinking about the system.
Awesome news. Have you considered making Wordgard canvas-first (like google docs (hn thread)) to avoid browser feature limitations and performance limitations?
I have and I don’t think that would be a good idea. It’d pull all the complexity of a layout engine into the library, making it a lot bigger, ruin screen reader accessibility and mobile support unless I do a lot more work, and generally require me to redo a bunch of things that the browser can do very well.
It does give more control and allows things like pagination, but like ProseMirror, Wordgard aims more at semantic editing than the pixel-perfect WYSIWYG use case.
The editing model (document, editor state, many of the commands) are independent of the DOM component implementation though, and could be used to build other editors (React editor, desktop editor, or canvas-based…).