[thatswrong0]

Slate looks awesome. I wish I had seen it when I was looking for a replacement for our core rich text editor library.. although I probably would still have gone with Draft merely because of the Facebook support. Should they stop updating it, I know what ship I'll be jumping to. It looks like the concepts are similar enough that porting wouldn't be too painful.

I've built and am maintaining a rich text editor that is a lot like Gmail's except it also supports dynamic variables, snippet insertion, and a few other things like that. Nested content hasn't been a concern for me, so DraftJS has been pleasant for the most part. Using Immutable for core state makes my life so much easier.

But I do agree with your assessment that Draft's API and docs are lacking, and some of the design decisions are a bit odd. Doing relatively simple operations can require quite a few more steps than you would expect, meaning I had to implement a lot of helpers (that you think would be included) myself. Slate's Transform API looks a lot more capable and straightforward out of the box.

HTML serialization, something you would expect to be part of the core library, only has a half-assed implementation that isn't customizable and that doesn't handle anything more than anchor tags.. so you have to install a third-party library to do it.

Just one question: if you can have nested blocks, do you really even need marks? Are they just there for convenience?

[ianstormtaylor]

Thanks! I totally agree with you, those were some of the other limitations I ran into and tried to solve for.

> If you can have nested blocks, do you really even need marks? Are they just there for convenience?

Interesting question!

It depends slightly on your use case, but I think for most of the "rich text editing" use cases, you'll probably want them.

They're beneficial in that they have separate semantics to inline nodes in the tree, since they aren't nested. Such that you can apply them in any order, and the JSON data structure is the same. This is useful because you don't have to worry about ordering when doing things like bold(italic(strikethrough(comment(TEXT)))). Which is usually simpler for users to understand, and simpler to work with in code anyways.

The inline nodes are only really useful for what you'd model in HTML as `display: inline-block`, for things that aren't really running "text" but can appear in the middle of the document, like inline images, latex, etc.

But if you're able to avoid inline nodes altogether, it's easiest to model things as blocks and marks.

This has me thinking about whether it's possible to get rid of "inline" nodes though, that's interesting.