Author here. Thanks for posting this. I had posted it earlier as a ShowHN (https://news.ycombinator.com/item?id=10087162), but without much notice, so I'm ecstatic to see lots of comments here. Great feedback.
Some responses to the various comments:
1) This is a very early release. I'm aware of all the missing functionality, and the README is pretty clear about all the missing stuff, including undo/redo, bullets, numbered lists, tables, and more. I don't have access to a Mac, so I wouldn't expect any of the Mac keybindings to work. That should be pretty easy to solve though.
2) Piotrek Koszuliński's article was really eye opening. Being completely new to the field of editors, and even new to Javascript (this is my first major Javascript project -- my background is mostly enterprise Java and some Scala), I defer to experts in this field like Piotrek and Marijn, the author of Codemirror and Prosemirror. I'm honored that Marijn even took the time to comment :-) It's possible that Ritzy could still serve as a useful tool within some narrower contexts that do not require handling the long tail of hard behavior mentioned (accessibility and RTL/bidi). OR, with the appropriate expertise, that some of that functionality could be added. Re. touch interfaces, fair point -- my thought was that could be worked around (e.g. by an alternate native component on touch interfaces that talked the same CRDT language -- I believe that's the approach that Google Docs took with editing Docs on mobile). Currently on mobile, basic cursor navigation by text, keyboard / text input, and viewing others' changes in real-time appears to work pretty well (better than I expected actually!). Selections don't work at all.
@marijn: how difficult would it be to add multiple cursors and selections to Prosemirror? I notice that currently the Prosemirror collaboration demo does not show cursors or selections, which is pretty key to a great user experience.
3) @gritzo (the author of Swarm.js, a key library used in Ritzy) mentions that the implementation uses a JS object for each char. That is true and it's very heavy. My initial goal was correctness and as a POC, with something easy to understand and debug. Optimization can come later, if indeed there is interest in taking this general approach further.
4) Recent changes to Ritzy (not yet pushed to the demo page) make each cursor, line, and selection a separate React component within a hierarchy. This makes navigation, rendering and selections pretty quick. However, the editor has never been tested against documents larger than a few hundred lines. My gut feeling is that the limiting factor right now is not React, but the "fat" CRDT data structure I used. It gets particularly bad when a lot of characters are deleted. There is no tombstone clearing logic yet.
5) It should be pretty easy to strip out the server-side stuff and make it client-side only. You lose the "killer feature" of Docs-style collaborative editing though. The server-side is pretty simple to self-host -- check out the demo source code @ https://github.com/ritzyed/ritzy-demo for an example.
I'll try to get the demo back up and running. Its hosted on the smallest (free) tier of Openshift and I've done zero server-side optimization. I'm sure it didn't take much traffic to kill it. Any other suggestions for (free) hosting for NodeJS projects?
I'll also try to write up a design doc over the next few days for those who requested that / are more interested in those aspects.
> how difficult would it be to add multiple cursors and selections to Prosemirror? I notice that currently the Prosemirror collaboration demo does not show cursors or selections, which is pretty key to a great user experience.
If you mean Sublime Text-style multiple cursors, that'd be very hard. CodeMirror's contentEdtiable-base mobile backend does support them, but that's only possible because it already contains a full implementation of cursor/selection for the non-mobile version.
If, on the other hand, you mean showing the cursors from other people working on a collaborative document, that isn't very hard, it just involves inserting widgets and marked ranges at the right places.
> If, on the other hand, you mean showing the cursors from other people working on a collaborative document
This is what I meant. Good that its not very hard. Though I'm curious: how do you know what the "right place" actually is i.e. don't the coordinates of the cursor position depend on the rendering of the text which is under the browser's control?
What about showing multiple selections from other authors like Google Docs (and Ritzy) does?
> don't the coordinates of the cursor position depend on the rendering of the text which is under the browser's control?
Yes, but you can ask the browser (using `getBoundingClientRect` and `getClientRects`, which also exist for text range object on all halfway modern browsers.) Or you can insert the caret element inline at the correct place.
What would be hard about showing a selection from another person?
Not "hard" as such. Just requires a completely separate code path than the local cursor and selection machinery. That isn't too much of a barrier though... I look forward to its implementation in Prosemirror!
Some responses to the various comments:
1) This is a very early release. I'm aware of all the missing functionality, and the README is pretty clear about all the missing stuff, including undo/redo, bullets, numbered lists, tables, and more. I don't have access to a Mac, so I wouldn't expect any of the Mac keybindings to work. That should be pretty easy to solve though.
2) Piotrek Koszuliński's article was really eye opening. Being completely new to the field of editors, and even new to Javascript (this is my first major Javascript project -- my background is mostly enterprise Java and some Scala), I defer to experts in this field like Piotrek and Marijn, the author of Codemirror and Prosemirror. I'm honored that Marijn even took the time to comment :-) It's possible that Ritzy could still serve as a useful tool within some narrower contexts that do not require handling the long tail of hard behavior mentioned (accessibility and RTL/bidi). OR, with the appropriate expertise, that some of that functionality could be added. Re. touch interfaces, fair point -- my thought was that could be worked around (e.g. by an alternate native component on touch interfaces that talked the same CRDT language -- I believe that's the approach that Google Docs took with editing Docs on mobile). Currently on mobile, basic cursor navigation by text, keyboard / text input, and viewing others' changes in real-time appears to work pretty well (better than I expected actually!). Selections don't work at all.
@marijn: how difficult would it be to add multiple cursors and selections to Prosemirror? I notice that currently the Prosemirror collaboration demo does not show cursors or selections, which is pretty key to a great user experience.
3) @gritzo (the author of Swarm.js, a key library used in Ritzy) mentions that the implementation uses a JS object for each char. That is true and it's very heavy. My initial goal was correctness and as a POC, with something easy to understand and debug. Optimization can come later, if indeed there is interest in taking this general approach further.
4) Recent changes to Ritzy (not yet pushed to the demo page) make each cursor, line, and selection a separate React component within a hierarchy. This makes navigation, rendering and selections pretty quick. However, the editor has never been tested against documents larger than a few hundred lines. My gut feeling is that the limiting factor right now is not React, but the "fat" CRDT data structure I used. It gets particularly bad when a lot of characters are deleted. There is no tombstone clearing logic yet.
5) It should be pretty easy to strip out the server-side stuff and make it client-side only. You lose the "killer feature" of Docs-style collaborative editing though. The server-side is pretty simple to self-host -- check out the demo source code @ https://github.com/ritzyed/ritzy-demo for an example.
I'll try to get the demo back up and running. Its hosted on the smallest (free) tier of Openshift and I've done zero server-side optimization. I'm sure it didn't take much traffic to kill it. Any other suggestions for (free) hosting for NodeJS projects?
I'll also try to write up a design doc over the next few days for those who requested that / are more interested in those aspects.
Thanks again for all the comments / feedback!