Building a WYSIWYG Editor: Why I chose Slate.js over Draft.js
Tags: react, wysiwyg, javascript, slatejs
Published: 2020-05-20 21:12:09

Three months ago I started developing a rich text editor. Since I had no idea on how to do it, I started searching about ways to implement it using React.js and ran into **Draft.js**, a widely used, well documented and mobile-working framework, and **Slate.js**, which has been fully refactored, is poorly documented and **doesn't have mobile support right now**. Even after taking all those facts into account, I still chose Slate.js, why?

## About Draft.js 
### First Impressions
At first glance, I thought it would be the best choice because, well, who would be better at developing a React framework than Facebook itself? After discovering Draft.js, the next thing I did was look it up on bundlephobia and, to my surprise, the [minified bundle size was around 210kB](https://bundlephobia.com/result?p=draft-js@0.11.5). Even though it looked too big for the project, I still gave it a shot.

### How you've grown!
Using Draft was the easiest thing in the beginning: with a little effort, I've built a basic-featured editor, however I stumbled upon a big problem: **creating custom components**. I had to write a lot of code, do a lot of merges with `Immutable.js` and soon I got confused by a giant, convoluted code. I had no time to learn about Immutable and just got stuck.

## Slate.js: A promising solution
Slate is a known framework for building "What you see is what you get" editors. It was created with the main goal of [simplifying the creation of complex RTEs](https://github.com/ianstormtaylor/slate#why), this is amazingly achieved by creating an **extensible**, **modular** and **highly reusable** framework that really knows how to use Hooks and other React features. Oh!, and [it's 69% smaller than Draft.js](https://bundlephobia.com/result?p=slate@0.58.0)

### The Problems 
Slate still has a long road ahead to improve. Using and understanding it could be even simpler if their documentation were better: some features lack description even to the point that there's no way of discovering them but by muddling through the source code or asking at Slate's Slack. Also, if you're going to develop a mobile editor, you should look for another framework, at least for now, because Slate **does not work on mobile**, but, since the internal project is desktop-only, this is not actually a problem in my case.

### About 0.5x
Since November 2019, Slate is being completely reworked. Among the nicest features introduced, are: Hooks to access the editor state and using `immer` to manage the immutable state. Those features, along with the principles of the framework, made the development of the editor a piece of cake. The schema can be understood in a snap, the way how **Elements**(editor blocks like paragraphs and images) and **Leaves** (inline text decorations, like **bold** and __italic__) work is really intuitive and their *First-class plugins* makes it easy to extend third-party code.

## TL;DR
Draft has much more features than Slate. It's well-documented, works wonderfully on mobile and it makes it easy to build an editor with basic features. However, when it comes to creating complex components for the editor, or extending it through **plugins**, everything becomes much harder and learning about this framework becomes a big pain. This is where Slate.js shines: Even though it still doesn't have mobile support and is poor documented, it was really easy to comprehend, hooks and plugins make everything highly reusable, creating custom components isn't difficult, and it's much lighter than its counterpart. Also, by using `Immer` instead of `Immutable.js` made the learning curve a lot gentler!

You can check out an example of both in this repository:
{% github hnrq/rich-text-editor no-readme %}