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…).
I wonder how different Wordgard is from ProseMirror conceptually and what big gains there are from starting from the ground up. I imagine there must be pretty good benefits to justify all this work.
I also wonder how long until you foresee Wordgard being ready for production, and whether those coming from ProseMirror would have any easier a time transitioning to Wordgard than those coming from any other editor project - or if it’s basically a total rewrite in both cases?
I love to see the progress here but I’m also a little discouraged after spending 2 years getting ProseMirror production-ready for our use case, so I guess I’m just trying to get a sense of future plans both on your end and to develop my own.
Thank you as always for the amazing work @marijn!
The blog post I linked covers most of this. There’s also a migration guide. Many concepts remain similar in Wordgard, so porting code will often not be that difficult.
Hi @marijn I did read the blog post (granted a couple days ago now) but I didn’t really feel those were covered as much as I’d want to hear about.
Like I saw you said probably at least a year until 1.x but Lexical has been pre-1.x for several years now and I wonder if that seems more realistic than ~1 year.
Of course your work is amazing and a huge effort and you don’t owe additional explanation.
I have a (very) different development process than the Lexical devs, so I don’t think that indicates anything. I understand the value of a stable interface, and though there probably will some more wild experimentation in the near future, I think I have done this whole process often enough to know when to stabilize. ProseMirror took about 1¾ years from 0.1 to 1.0, and I had a lot less of an idea what the system should look like at the start of that period, so I don’t think it’s unrealistic to expect a shorter stabilization process this time.
Is it going to work better with SPA frameworks like React?
Probably not. Those that are easy to wrap, like Svelte, work great, but those that insist on pulling everything into their own system, like React, are going to continue to be a pain.
Wow, wonderfully amazing news! Can’t wait to dive into it. Love that Svelte-integration will be much easier. Does this mean NodeViews/MarkViews/Decorations will be now easier to use with such frameworks? And I hope MarkViews won’t sustain the same handicap vs decorations as in ProseMirror (making them practically useless). The native Change tracking seems promising but can’t say much without actually trying it. The blame example at least didn’t track deletions. Too bad no native pagination though, maybe there could be some middle ground solution.
I think you’re reading too much into what I said. You can wrap Svelte components in a widget (because they are mostly just DOM elements). Wordgard is not providing the stateful-component node view abstraction, because that was fraught with state synchronization issues and steered people towards trying to put whatever component nonsense they could think of into the document. Node wrappers and such are now just DOM structure, no state.
Oh okay. Well I hope the NodeView equivalent abstraction is easier. NodeView had a good deal of footguns. But perhaps I should take a closer look before commenting.
As I already wrote via mail - very exciting news. Looking forward to see where Wordgard is going! Framework-integration was already quite easy for most frameworks that don’t start with R and end with eact (at least since version 18 because of batched rendering).
Congrats on wrapping up a first version of Wordgard! Looks promising, particularly the switch to input events. Btw, Firefox is actively implementing the EditContext API right now, and (I hope Webkit’s going to follow within a year). Then there’d be solution for composition events too. 
Aside from that, lots to learn from your blog post. Thanks for sharing!