6 ms·

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

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!

ipsum2 3y ago
Lexical (https://lexical.dev/ https://lexical.dev/) is really nice to use and doesn't use Prosemirror or CKEditor.
- conaclos 3y ago
  Did you try both Prosemirror and Lexical? I am curious to read some comparisons between these two editors.
  - ipsum2 3y ago
    Yes I did, but it was 3+ years ago and I don't recall the details, but the data representation was elegant for Lexical.
p4bl0 3y ago
> 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. [1] https://pagedjs.org/ https://pagedjs.org/
- creshal 3y ago
  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.
wolverine876 3y ago
> Both Gdocs and Zoho Writer, do a tremendous amount of plumbing and keeps rendering logic out of browser's control How do these in-browser applications keep rendering logic out of browser's control? They do it server-side?
- creshal 3y ago
  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.
chrismorgan 3y ago
> 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 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.
- snewman 3y ago
  I don't understand your points here. 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.
zokier 3y ago
> 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
- mavhc 3y ago
  They're thinking of what we should call a "print processor" or a "paged processor" these days.
amadeuspagel 3y ago
> To call an editor a word-processor it should support pagination & page layouts. Not supporting this is why it's called a word processor for the web.
ergonaught 3y ago
> But to call this component a word-processor The About page is clearer, "Wax is a framework for building web-based word processors", but that lacks pop.

ipsum2 3y ago

Lexical (https://lexical.dev/ https://lexical.dev/) is really nice to use and doesn't use Prosemirror or CKEditor.

conaclos 3y ago
Did you try both Prosemirror and Lexical? I am curious to read some comparisons between these two editors.
- ipsum2 3y ago
  Yes I did, but it was 3+ years ago and I don't recall the details, but the data representation was elegant for Lexical.

p4bl0 3y ago

> 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. [1] https://pagedjs.org/ https://pagedjs.org/

creshal 3y ago
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.

wolverine876 3y ago

> Both Gdocs and Zoho Writer, do a tremendous amount of plumbing and keeps rendering logic out of browser's control How do these in-browser applications keep rendering logic out of browser's control? They do it server-side?

creshal 3y ago
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.

chrismorgan 3y ago

> 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 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.

snewman 3y ago
I don't understand your points here. 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.

zokier 3y ago

> 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

mavhc 3y ago
They're thinking of what we should call a "print processor" or a "paged processor" these days.

amadeuspagel 3y ago

> To call an editor a word-processor it should support pagination & page layouts. Not supporting this is why it's called a word processor for the web.

ergonaught 3y ago

> But to call this component a word-processor The About page is clearer, "Wax is a framework for building web-based word processors", but that lacks pop.