4 ms·

The recent changes to the API in 0.50 look good. The number of iteration passes really shows. Out of the available open source editor frameworks, Slate is proba

by jitl 5y ago

The recent changes to the API in 0.50 look good. The number of iteration passes really shows. Out of the available open source editor frameworks, Slate is probably most similar to Notion’s internal editor system. If I had to rebuild on a framework tomorrow, it’d be Slate or ProseMirror. Still if I used Slate it would be with the expectation that I’d end up owning an aging fork of a forgotten version at some point.

williamstein 5y ago
I've been using Slate heavily this year. I'm not a Slate developer, but I've read a lot of the source code, follow all the Github issues, etc., and I'm "owning an aging fork". As far as I can tell, the API instability mentioned elsehwere in this thread resulted from a nearly complete rewrite (inspired by immerjs) that launched in May 2020; for over a year since then, the API has been very stable, mainly because Ian Taylor, who wrote most of Slate, seems to have moved on to other projects (see https://github.com/ianstormtaylor/slate/graphs/contributors); https://github.com/ianstormtaylor/slate/graphs/contributors)... there's still a lot of work on Slate, but it's mainly by other people who are trying to preserve the vision that Ian laid out. I ended up forking only the React part of Slate, which is officially a plugin, and massively rewriting it to support virtualized windowing, so we can work with very large possibly complicated to render documents. I also added fairly generic realtime collaboration support. This is currently used in https://cocalc.com https://cocalc.com for WYSIWYG editing of Markdown documents. I also have plans to extend my use of Slate with windowing to Jupyter notebooks and other document types. I chose Slate over Prosemirror because the source code of Slate is Typescript written in a clear modern style, and I was able to start reading any part of it and understand it easily, whereas I find Prosemirror's core source code more difficult (this may just be a reflection of my shortcomings). I spent a lot of time initially just reading Slate PR's claiming to fix bugs, then integrating the PR's into my fork, often in a way that makes sense for my project, but likely wouldn't in general (I left helpful remarks on Github). Slate is an interesting project, and it is comparable to Prosemirror. However, development is structured very differently at present, and I think there's little funding behind Slate, whereas the author of Prosemirror seems to have done a good job encouraging sustainable donations. I think Ian Taylor, who mainly wrote Slate, also cofounded a company called Segment.io, which is a serious startup that was recently sold to Twilio, so I don't know what his motivations are. I have no plans to switch from Slate to Prosemirror. Getting virtualized windowing to work with Slate was quite difficult, but it's really table stakes for what I plan on doing longterm, and I don't even know where to begin to do virtualized windowing in Prosemirror.
- thatswrong0 5y ago
  How does virtualization play with text search? Did you end up having to roll your own? I'm still working on migrating my team's Slate implementation from 0.47 to 0.5x.. the new API is simultaneously simpler but also.. harder for me to grok? Maybe I just am having trouble with the documentation because I end up reading the source more often than not.
  - williamstein 5y ago
    Yes, I very much have to implement my own text search. There are many custom elements, so I would have to roll my own anyways at some point. In my experience, I think the official documentation is just an introduction and overview, and that you have to read the source code of Slate when you're serious about doing development using it. This is not necessarily bad, since the source code is pretty readable, and the fact everybody seriously using slate is reading the source increases the number of contributors.
    - thatswrong0 5y ago
      I don't mind reading the source, but it can feel a lot slower than it needs to to get the information I need. Of course, it's completely understandable that it would be lacking because it did just (relatively speaking) undergo a major refactor. I can tell though that I'm going to have to write my own documentation (for my coworkers) about how to use Slate, because for me, having explicit examples of proper function usage is incredibly helpful and there isn't much of that in the documentation.. so we're basically just left with the existing examples which don't come close to covering all of the options each function has. I'll also probably have to include a migration guide (e.g. if you used to do (a) with the old API, try (b) in the new one.. (it's probably just Editor.nodes))
- dmitryminkovsky 5y ago
  The Slate rewrite looks much better than the previous version. It was a big step for them to remove Immutable, which had to happen given the state of that project (which, incidentally, got new maintainers last week). I'm not surprised it's rolling steady now. It's good that Ian delegated smoothly. I wondered how he did that rewrite while simultaneously working at Segment as a cofounder… I agree that Slate is nicer than ProseMirror with a more standard code style, the fact that it's not scattered among a bunch of repos, and that it's written in TypeScript. And it's not great that ProseMirror seems to have a bus factor = 1, maybe 2 or 3. That's not the case with Slate right currently, right? It's remarkable you built cocalc with Slate. And the virtualization. Really big work.
bhl 5y ago
What features of Slate put it closest to Notion's editor compared to other frameworks besides the obvious one that Slate's view layer is built on top of React? Is it somehow that Slate is more suitable handling asynchronous data (e.g. server generated uuids for each block, recursively fetching content for each block and its children)?
DmitriT 5y ago
That's my experience. I own a fork of Slate and Slate plugins that I've been doing my best to maintain, as well as a wrapper: https://github.com/roast-cms/french-press-editor https://github.com/roast-cms/french-press-editor. My project is small enough not to have bandwidth to upgrade Slate or switch to another editor but popular enough to keep alive and maintain two years past the version release I solidified. The implementation I have isn't very buggy, I've used it almost every day and have over a hundred users who successfully used it as well. There was only one time when a serious bug surfaced, the rest being minor inconveniences. This is the implementation: https://www.analog.cafe/write/draft https://www.analog.cafe/write/draft

by jitl 5y ago

williamstein 5y ago

I've been using Slate heavily this year. I'm not a Slate developer, but I've read a lot of the source code, follow all the Github issues, etc., and I'm "owning an aging fork". As far as I can tell, the API instability mentioned elsehwere in this thread resulted from a nearly complete rewrite (inspired by immerjs) that launched in May 2020; for over a year since then, the API has been very stable, mainly because Ian Taylor, who wrote most of Slate, seems to have moved on to other projects (see https://github.com/ianstormtaylor/slate/graphs/contributors); https://github.com/ianstormtaylor/slate/graphs/contributors)... there's still a lot of work on Slate, but it's mainly by other people who are trying to preserve the vision that Ian laid out. I ended up forking only the React part of Slate, which is officially a plugin, and massively rewriting it to support virtualized windowing, so we can work with very large possibly complicated to render documents. I also added fairly generic realtime collaboration support. This is currently used in https://cocalc.com https://cocalc.com for WYSIWYG editing of Markdown documents. I also have plans to extend my use of Slate with windowing to Jupyter notebooks and other document types. I chose Slate over Prosemirror because the source code of Slate is Typescript written in a clear modern style, and I was able to start reading any part of it and understand it easily, whereas I find Prosemirror's core source code more difficult (this may just be a reflection of my shortcomings). I spent a lot of time initially just reading Slate PR's claiming to fix bugs, then integrating the PR's into my fork, often in a way that makes sense for my project, but likely wouldn't in general (I left helpful remarks on Github). Slate is an interesting project, and it is comparable to Prosemirror. However, development is structured very differently at present, and I think there's little funding behind Slate, whereas the author of Prosemirror seems to have done a good job encouraging sustainable donations. I think Ian Taylor, who mainly wrote Slate, also cofounded a company called Segment.io, which is a serious startup that was recently sold to Twilio, so I don't know what his motivations are. I have no plans to switch from Slate to Prosemirror. Getting virtualized windowing to work with Slate was quite difficult, but it's really table stakes for what I plan on doing longterm, and I don't even know where to begin to do virtualized windowing in Prosemirror.

thatswrong0 5y ago
How does virtualization play with text search? Did you end up having to roll your own? I'm still working on migrating my team's Slate implementation from 0.47 to 0.5x.. the new API is simultaneously simpler but also.. harder for me to grok? Maybe I just am having trouble with the documentation because I end up reading the source more often than not.
- williamstein 5y ago
  Yes, I very much have to implement my own text search. There are many custom elements, so I would have to roll my own anyways at some point. In my experience, I think the official documentation is just an introduction and overview, and that you have to read the source code of Slate when you're serious about doing development using it. This is not necessarily bad, since the source code is pretty readable, and the fact everybody seriously using slate is reading the source increases the number of contributors.
  - thatswrong0 5y ago
    I don't mind reading the source, but it can feel a lot slower than it needs to to get the information I need. Of course, it's completely understandable that it would be lacking because it did just (relatively speaking) undergo a major refactor. I can tell though that I'm going to have to write my own documentation (for my coworkers) about how to use Slate, because for me, having explicit examples of proper function usage is incredibly helpful and there isn't much of that in the documentation.. so we're basically just left with the existing examples which don't come close to covering all of the options each function has. I'll also probably have to include a migration guide (e.g. if you used to do (a) with the old API, try (b) in the new one.. (it's probably just Editor.nodes))
dmitryminkovsky 5y ago
The Slate rewrite looks much better than the previous version. It was a big step for them to remove Immutable, which had to happen given the state of that project (which, incidentally, got new maintainers last week). I'm not surprised it's rolling steady now. It's good that Ian delegated smoothly. I wondered how he did that rewrite while simultaneously working at Segment as a cofounder… I agree that Slate is nicer than ProseMirror with a more standard code style, the fact that it's not scattered among a bunch of repos, and that it's written in TypeScript. And it's not great that ProseMirror seems to have a bus factor = 1, maybe 2 or 3. That's not the case with Slate right currently, right? It's remarkable you built cocalc with Slate. And the virtualization. Really big work.

bhl 5y ago

What features of Slate put it closest to Notion's editor compared to other frameworks besides the obvious one that Slate's view layer is built on top of React? Is it somehow that Slate is more suitable handling asynchronous data (e.g. server generated uuids for each block, recursively fetching content for each block and its children)?

DmitriT 5y ago

That's my experience. I own a fork of Slate and Slate plugins that I've been doing my best to maintain, as well as a wrapper: https://github.com/roast-cms/french-press-editor https://github.com/roast-cms/french-press-editor. My project is small enough not to have bandwidth to upgrade Slate or switch to another editor but popular enough to keep alive and maintain two years past the version release I solidified. The implementation I have isn't very buggy, I've used it almost every day and have over a hundred users who successfully used it as well. There was only one time when a serious bug surfaced, the rest being minor inconveniences. This is the implementation: https://www.analog.cafe/write/draft https://www.analog.cafe/write/draft