3 ms·

ProseMirror is great. A few months back i was looking for a rich text editor for use in an isomorphic js webapp that uses react. I probably spent more time rese

by nsfmc 11y ago

ProseMirror is great. A few months back i was looking for a rich text editor for use in an isomorphic js webapp that uses react. I probably spent more time researching and testing out other libraries than i did getting prosemirror working in our app (and even ended up even contributing back some code in the process). Highly recommended, i think for most cases, prosemirror strikes a good balance between sensible defaults and easy integration. Where it falls down is mostly in documentation, which is 100% understandable, since it was crowdfunded(!), but the code is very legible and amenable to most kinds of webapps. Where i suspect draft.js probably shines is having tighter client/data boundaries and code that natively expects to be rendered isomorphically, so calls to window/document are probably more tightly managed given that the whole view layer uses react and likely expects to be rendered on the server. That said, ProseMirror has a 100% fantastic "give me the current ast rendered as markdown" which, in my case at least, was the thing i wanted the most and that ProseMirror supplied handily. Draft.js will have you roll your own[1], but at least the draft.js api is fairly friendly. There's obviously more than enough room for both projects, but i think that for react based projects, draft.js will feel like a more natural fit even if it will take more effort in the short term until more functionality builds up around it. [1]: https://github.com/facebook/draft-js/blob/06891490069d3ccfb89caf53f33a7545d39fc3ec/docs/APIReference-Data-Conversion.md https://github.com/facebook/draft-js/blob/06891490069d3ccfb8...

marijn 11y ago
What kind of improvements would you want in the docs [1]? [1]: http://prosemirror.net/docs.html http://prosemirror.net/docs.html
- true_religion 11y ago
  Well what I liked about Mobiledoc-kit[1] is that their demo was essentially an explanation of their document model. You changed things on the left, then saw the document model mutate in real time, and finally saw the rendered output. Also, the very first thing in their documentation is an explanation of how to write a 'card' for embedded input, which is what is used to embed images in the demo. It was an ah-ha! moment for me because most editor documentation begins by telling you how they parse ranges, and showing you how you can use regex to back-check to document and change it to your own elements, etc. That's just too deep into the internals for me to get an idea of what's going on. [1]: https://github.com/bustlelabs/mobiledoc-kit https://github.com/bustlelabs/mobiledoc-kit
- nsfmc 11y ago
  hi marjin! thanks again for all your work on prosemirror. the docs are quite thorough (and have gotten moreso in the past few months!), but a specific thing which i ended up needing to dive into the code for was something like setting up a custom menubar[1] with a menugroup. The docs back then (and even now) do this thing where they get rapidly tautological and have you hop around between type definitions but don't, for instance, show you what the default `menuBar`'s content value is, in terms of a MenuGroup so it's not readily obvious how to customize my own without reading the source. So reading the docs, while i can certainly find out what things are and how they connect, i don't have a good sense of what decisions prosemirror made for me (or how it made them) so that i can intentionally customize or integrate in a non-backwards way. If the code weren't so legible, this would be a massive problem, but it's the sort of in-depth documentation that needs somebody working strictly on documentation in that way that kaplan-moss talks about[2]. I totally get that prosemirror is early days and integrating it has been a good experience, but that's the sort of documentation pain-point i was referring to. Thanks again! [1]: http://prosemirror.net/ref.html#menu/menubar http://prosemirror.net/ref.html#menu/menubar [2]: https://jacobian.org/writing/great-documentation/ https://jacobian.org/writing/great-documentation/

by nsfmc 11y ago

marijn 11y ago

What kind of improvements would you want in the docs [1]? [1]: http://prosemirror.net/docs.html http://prosemirror.net/docs.html

true_religion 11y ago
Well what I liked about Mobiledoc-kit[1] is that their demo was essentially an explanation of their document model. You changed things on the left, then saw the document model mutate in real time, and finally saw the rendered output. Also, the very first thing in their documentation is an explanation of how to write a 'card' for embedded input, which is what is used to embed images in the demo. It was an ah-ha! moment for me because most editor documentation begins by telling you how they parse ranges, and showing you how you can use regex to back-check to document and change it to your own elements, etc. That's just too deep into the internals for me to get an idea of what's going on. [1]: https://github.com/bustlelabs/mobiledoc-kit https://github.com/bustlelabs/mobiledoc-kit
nsfmc 11y ago
hi marjin! thanks again for all your work on prosemirror. the docs are quite thorough (and have gotten moreso in the past few months!), but a specific thing which i ended up needing to dive into the code for was something like setting up a custom menubar[1] with a menugroup. The docs back then (and even now) do this thing where they get rapidly tautological and have you hop around between type definitions but don't, for instance, show you what the default `menuBar`'s content value is, in terms of a MenuGroup so it's not readily obvious how to customize my own without reading the source. So reading the docs, while i can certainly find out what things are and how they connect, i don't have a good sense of what decisions prosemirror made for me (or how it made them) so that i can intentionally customize or integrate in a non-backwards way. If the code weren't so legible, this would be a massive problem, but it's the sort of in-depth documentation that needs somebody working strictly on documentation in that way that kaplan-moss talks about[2]. I totally get that prosemirror is early days and integrating it has been a good experience, but that's the sort of documentation pain-point i was referring to. Thanks again! [1]: http://prosemirror.net/ref.html#menu/menubar http://prosemirror.net/ref.html#menu/menubar [2]: https://jacobian.org/writing/great-documentation/ https://jacobian.org/writing/great-documentation/