This article discusses the process of choosing a new React-based editor library for PR TIMES’s press release editor.
At PR TIMES, press release publishing is one of the core services that we provide, therefore, we strive to provide the best possible editing experience to our users so that they can express their ideas better.
However, our current editing page is built with legacy codes that have not been well maintained over the past several years. Because of this, it is really hard to introduce new features or even fix small bugs. Therefore, we decided to rewrite the whole editing experience in React and also replace the core editor library with a better one, which is the main reason for this article.
PR TIMES’s Current Editor
Before diving into how we plan to implement the new editor, let’s take a step back and look at the problems that the current editor is currently facing first.
The current editor is composed of 2 parts:
smartytemplate engine code)
New Editor’s Requirements
Usually, it is not an easy task when it comes to choosing a library or framework for whatever project you are working on. However, it’s much easier to pick a library based on your project’s actual requirements.
Therefore, before choosing which editor library to use, I have laid out the requirements for our new editor as below:
- able to produce HTML as output
- integrates well with
- able to implement all the current editor’s functionalities (ex: image, table, basic editing, etc…)
- able to process the already published press release data
- highly customizable and composable
- supports collaborative editing (we want to enable this feature in the future release)
- have great Japanese support on small screen devices
- Nice to have:
- have great TypeScript support
- framework agnostic
- have great community
- well documented
React-based Editors’ Research
After defining our requirements, I started to do some research on several editor libraries to see which one matches our requirements the most.
Here is the list of libraries that I have considered.
One thing to note is that there are many other great React-based editor libraries out there such as
TinyMCE. However, some of them might require some extra costs or other drawbacks, so I suggest you also check them out to see whether they fit your project’s requirements or not.
This comparison is solely based on my own experience, hence, there might be some biased opinions. I’m open to corrections and suggestions as well.
I have used
Slate about one or two years ago, and only recently started using
Tiptap mainly. For
CKEditor, I only went through their documentation as my reference.
Also, I have excluded the
long-term factors from the comparison. That’s because:
- they are all popular libraries
- they are either supported by a huge community who are using them or by the company they are developed at. So, I do not think they will go anywhere soon.
-sign means the answer is somewhere between
|Japanese input support(no bug)||Yes||Yes||No||Yes|
|Current functionalities available||Yes||Yes||Yes||Yes|
|Can process saved data||Yes||Yes||Yes||Yes|
|Customization & composability||Yes||–||Yes||–|
The above table tells us that while
Tiptap is the only editor that has all the requirements checked, the other editors are not far off.
- Slate: Aside from having 1
Nofor Japanese input support, Slate is the one that comes real close to Tiptap. I feel like Tiptap and Slate are almost the same, especially their
plugin/extensionbased concept. Both are also inspired by
Prosemirror. However, I have to give it to Tiptap for its high customizability (from what I have seen so far).
- Quill: Just like this section from
slate documentationexplaining why the author decided to build
slateafter trying Quill and other editors, I also feel like there is a limitation to how customizable Quill could be. This could be mainly due to the differences in the underlying data model.
- CKEditor v5: From its documentation, I get the impression that it’s harder to integrate with React in general, compared to the others. The same way goes for customization and composability as well.
As you can see, it’s sometimes difficult to make a decision based on the comparison table alone. Therefore, we also need to consider other factors as well.
Those factors could be:
- GitHub’s issues
- community’s size and support (forum, discord groups…)
- how well are the documentation and examples
- how well is the maintenance
- and so on…
As you would expect from the comparison table above, we chose
Tiptap as the library to build our new editor. While the main reason is that it checks all the requirement boxes that we have, it is also well balanced regarding the other factors that we talk about above.
Here is my list of things that I like about Tiptap:
- Tiptap is a headless editor. That means we have full control over how we want the editor to be
Tiptap gives you full control about every single aspect of your text editor experience.
- great TypeScript support since the library itself uses TypeScript internally
- great documentation explaining core concepts with clear examples
- built on top of ProseMirror (supported by The New York Times, Atlassian, asana, etc… ), a well-written, reliable, and very powerful editor toolkit Introduction – Tiptap Editor
- more importantly, it has great extension system
Since most of the editor libraries are pretty good, it’s fairly hard to say which one is better than another. So, what I suggest is that you should decide on your main requirements first, then start trying to build a simple editor component using a few top libraries. Along with that, reading documentation is also a great way to check out small differences between those libraries.
Similar to framework, there are many editor libraries out there to choose from. That makes it difficult for developers to decide which library to use. So, I hope that this article could be a reference for your decision if you ever face the same problem.
I will also write about the experience of actually implementing the editor itself after the release of the project. So, stay tuned for that also!