Hacker News Reader

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?

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.

How does Slate compare to draft in package size? I find that including Draft for simple simple simple WYSIWYG editing to be enormous. I don't have the exact size on me, but it made my bundle huuge

Honestly right now it's probably worse. It's still in beta, so I've been working on the core architecture and logic, before diving into things like package size. So I'm not sure. It also hugely depends on whether you were already using React and Immutable.js as dependencies inside your app, or whether you have to add them just for the editor.

For super simple WYSIWYG editing, like I mentioned, you're not going to want to use Slate. (Or maybe Draft either.)

Slate is designed for much more advanced use cases. Things like building wiki tools, or chat tools, or anything where the editing experience itself is a significant enough portion of your product that you want total control over it, and don't want to be constrained by the opinions that most editing frameworks bake into their core libraries.

Thanks, Slate looks good - great work. Thanks for useful feedbacks. I will check slate more deeply soon.