I see this is built on top of the amazing Prosemirror richtext toolkit. I'm a huge fan of Prosemirror's architecture which powers extremely customizable editors like this one.
But to call this component a word-processor - is a bit overkill. Why? To call an editor a word-processor it should support pagination & page layouts - as in Google Docs & Zoho Writer. Given the limited graphics capabilties of DOM, it is near impossible to build a paginated editor on top of the DOM.
Both Gdocs and Zoho Writer, do a tremendous amount of plumbing and keeps rendering logic out of browser's control to achieve a proper word processing experience on the web. Something like that can never be built upon contenteditable augumented frameworks like Prosemirror.
There are other players in this category that are building extensible editors without pagination - like Tiptap, Froala, CKEditor, etc. Except CKeditor, every other project is built on top of Prosemirror too!
> Both Gdocs and Zoho Writer, do a tremendous amount of plumbing and keeps rendering logic out of browser's control to achieve a proper word processing experience on the web
I can’t speak for Zoho Writer, but despite popular impression, Google Docs doesn’t actually do this: its text layout and rendering, at the very least, is left entirely to the browser. Thus, Google Docs does not offer static pagination. Sure, it does some layout itself, but it doesn’t really offer anything even vaguely interesting to justify doing so: it’s all stuff all major browsers could already do at least as well. (And the whole “Google Docs renders using canvas” thing people often speak of is essentially false, measuring it against what people generally understand that to mean: https://news.ycombinator.com/item?id=33863185. I still have no idea why they’ve gone canvas to the extent they have, as they haven’t gone far enough to make it worthwhile, but they have gone far enough to makes things significantly worse in the general case.)
I’d be surprised if Zoho Writer were any “better” in this regard, because being “better” in this regard makes you fundamentally worse in other, generally-more-important regards. Because the web simply doesn’t give you the primitives you need to make a traditional paginated word processor good.
It does seem that Google Docs is using the browser to measure and render individual units of text. But that is very much not the same thing as layout: deciding how much text fits onto a line, how many lines fit onto a page, making room for footnotes, etc. My understanding is that Docs is handling layout itself, in order to support features like pagination and footnotes.
You say the browsers can support all of the layout features Docs provides, but do they allow live editing and on-screen display of paginated text? That certainly wasn't the case back when I wrote the original Google Docs (I'm a co-founder of Writely) and I don't believe it was the case when the current canvas implementation shipped. (I had left Google by then and have no inside knowledge of that rewrite.)
One final note: back in the day, I have implemented and shipped a full word processor for the Mac (FullWrite). We very much handled layout ourselves, but relied on the OS for text measurement and rendering, presumably in a similar fashion to how Docs leverages the browser today.
Text shaping is a critical part of layout. Different systems use different and incompatible techniques, e.g. in measuring slightly different things, or in using fixed-point or floating-point calculations, and a variety of other such things—quite apart from differences in capabilities (e.g. whether you support complex layout for certain languages, or certain newer Unicode features). Every serious desktop publishing system uses its own shaping engine, configured to act in a platform-independent way (some will otherwise try to match the platform’s conventions).
It’s worse when you do it with browsers, because you can’t inspect anywhere near as much, and because you can’t even guarantee which font will be used: font files may fail to load (networks are far less reliable than people imagine, quite apart from third-party origins), or you might get users like me who just disable custom fonts altogether because it makes the general experience of the web so much better.
As far as pagination is concerned, there was never any reason why you couldn’t do that in DOM—and in fact, Google Docs did do it in the DOM. You simply have to monitor where the break position should be, and adjust things at that point. It’s not hard. The specific adjustment, there are a few approaches for. You could have the whole document be a contenteditable, and draw the page background outside that, and just inject an inline spacer element in the location of the break; or maintain it inside distinct block elements, using text-align-last on the last line of the previous page if it’s mid-paragraph and justified (or an approximation of the effect for older browsers); or there are several other viable approaches. Seriously, it’s not hard. You’re not limited to “just contenteditable”, you expect you have to maintain various more complex DOM. But I contend that maintaining that is easier that rendering the whole thing in a canvas, and entirely adequately powerful, and probably faster, if you perform similar performance optimisations, and that it functions better. I just all-round cannot think of any legitimate reason why they went the way they did. It’s not like switching from DOM to canvas allowed them to add any new functionality: no, they stayed at just the same feature set, just worse in places, from my perspective.
This is not strong evidence. While, ideally, the behavior you describe should not happen, there are many reasons it could arise. (Bugs, font sizing comes out differently at printer resolution, paper size is different than on-screen page size, different implementation for printing, etc.)
Given that Docs nowadays uses Canvas to render the document being edited, how would it even be possible to delegate rendering to the browser? (Not to mention the challenge of live rendering of pages, footnotes, etc.)
> Given the limited graphics capabilties of DOM, it is near impossible to build a paginated editor on top of the DOM.
This is developed by the some of the same people who work on paged.js [1], which enables exactly that and is actually used to create printed materials, including books.
I love paged, but the performance really shows why other word processors keep their rendering out of the DOM: 150 page documents with footnotes and forward+backward page references, which instantly load in a desktop app or take a few seconds in GDocs or Word Online, take several minutes to fully render in pagedjs in my experience.
> To call an editor a word-processor it should support pagination & page layouts
Is this just historical vestige stemming from Words dominance? I don't see why word processor should handle print layout instead of doing it in dtp or something
iirc GDocs mostly uses a huge canvas: Rendering is still client side, but you don't need 100 garbage collected DOM nodes to render any particular part of the page.
Seems interesting, we definitely need more advanced open source editors.
However, this gives off very unpolished vibes.
The demo renders poorly on mobile, with the textarea on the first page squished horizontally. The "Basic Editors" demo has the opposite problem, and there is horizontal scrolling with elements out of view. It's not clear if this is a fault of wax.js or of the demo page, but it's a bad first impression.
There is also a typo on the Features page:
> Select text and add a comment or particpate [...]
You might consider merging the landing page with the "features" page - it takes a second or two to realize there's nothing to really see when you first get to the page, and you have to look around to kind of get a feel for what the thing really is. Pretty cool otherwise.
They have actually quite a lot of open source projects, among others "paged.js", a "Typesetting Engine for Creating PDF from HTML" and "CokoDocs", an "open source, collaborative, web-based Word Processor."
This source for this project has almost no comments at all.
I don't understand how projects like this ever get new contributors, or how the current maintainers manage to remember everything about why the code is the way it is.
Strangely also the site linked in the gitlab is not a live site. One other question: why gitlab instead of github? I think this is the first OS library I've seen using gitlab instead of github or a self-hosted site
Gitlab is self hostable for free, hosting GitHub is very expensive. I'm happy to see anyone breaking github's monopoly, and gitlab has been around longer then the other open source code forges afaik
But to call this component a word-processor - is a bit overkill. Why? To call an editor a word-processor it should support pagination & page layouts - as in Google Docs & Zoho Writer. Given the limited graphics capabilties of DOM, it is near impossible to build a paginated editor on top of the DOM.
Both Gdocs and Zoho Writer, do a tremendous amount of plumbing and keeps rendering logic out of browser's control to achieve a proper word processing experience on the web. Something like that can never be built upon contenteditable augumented frameworks like Prosemirror.
There are other players in this category that are building extensible editors without pagination - like Tiptap, Froala, CKEditor, etc. Except CKeditor, every other project is built on top of Prosemirror too!