
Editor.js – Block Styled Editor - tortilla
https://editorjs.io/
======
arciini
Here's my take on this from playing with it a bit:

\- Works on mobile (like Quill, Prosemirror)

\- Does not support collaborative editing (unlike Quill, Prosemirror)

\- Has somewhat unique block-based editing UI - think Notion (the data models
of most editors support this, but the default UI of editorjs is much more
explicit about this)

\- Not built on React (like Quill, Prosemirror, but unlike Slate and Draft)

The mobile support looks quite mature, and I think this could be a good
competitor to Quill and Prosemirror for single-user editing.

Per my previous comments (1), I think for new projects, going with Prosemirror
or Quill are still great choices. I've tried Draft and Slate and both of them
have lacked good mobile support and collaborative editing.

[1]
[https://news.ycombinator.com/item?id=18998042#19000425](https://news.ycombinator.com/item?id=18998042#19000425)

~~~
xixixao
The performance on mobile doesn't look great for me (significant delay between
key stroke and rendering, on iPhone X), also this particular page could be
more responsive and mobile friendly.

Otherwise I love the idea of block-based editor and clean output.

~~~
arciini
You're right. I expect that they're reconciling with their model in JS on
every keystroke. I know Quill does an interesting thing where the DOM is the
canonical model, and the JSON model is actually derived from the DOM by a
strict transformation. Because of that, it works a bit more naturally with
many native mobile editor interfaces.

------
manigandham
Nice, added to the list of editors:
[https://gist.github.com/manigandham/65543a0bc2bf7006a487](https://gist.github.com/manigandham/65543a0bc2bf7006a487)

Perhaps they should've used the MobileDoc standard instead creating another
one.

~~~
putlake
Nice! Could you please augment that list with links to the HN threads about
the release of each? A list like that is the starting point but often the pros
and cons are found in HN discussions.

~~~
manigandham
You can search HN for any relevant discussions:
[https://hn.algolia.com/](https://hn.algolia.com/)

------
blunte
From a data management and flexibility standpoint, I see why block editors are
becoming popular with some people. But as a user, it feels like a downgraded
experience.

When writing multi-paragraph prose, the first draft isn't always the final
draft. Quite often there's some shuffling around of parts of the content. With
blocks, the user can't highlight part of one paragraph and into part of the
next one because of the artificial container boundary.

Perhaps with some well planned keyboard shortcuts and other UI improvements,
the friction can be reduced. Maybe also it will require a change in the way
some of us think about content (although I still object to the user needing to
think of content in terms of its subtypes and storage structures).

~~~
raffijacobs
I agree for most of it.

I'm the current maintainer of [https://github.com/madebymany/sir-trevor-
js](https://github.com/madebymany/sir-trevor-js) which we started in 2012. At
the time we had a fully block based approach and migrated to more of a
document based approach when medium.com gained traction.

Since then we've debated what's the best approach for cross block selection as
now the expected behaviour is very much that of a text editor such as word
rather than a block based editing tool which it started out as. A couple of
years ago we embarked on a rewrite that saw us look for a solution to the
problem that would solve this. Not just a block based selection, but a cursor
based selection between blocks, but this never got to a level we were happy
with.

I think with the evolution of online editing over the years and editors such
as notion.so the approach they've taken with the multiple contenteditable
elements is a good first step. Over time we'll see how far they are able to
take it. Adding features such as cross browser support, undo / redo and
keyboard navigation.

------
bengotow
Hey! I maintain the Mailspring email client and I've thoroughly battle-tested
SlateJS and DraftJS. I'd absolutely love if we could move to something with
broader contenteditable support in the future (it's more or less impossible to
allow people to paste AND EDIT arbitrary HTML in the former two.) A few
questions if the author of the post is around!

\- Does EditorJS support nested blocks? Eg: can I make a list node that
contains a list? Can I make a list that contains a blockquote? (DraftJS is a
/linear/ set of block elements, making it very difficult to model complex
documents - Slate's document model is a tree which is why pretty much why I
chose it over DraftJS.)

\- Does EditorJS have test coverage? What's the overall testing story look
like? I'm not a big TDD person, but we've had a few stability issues with
Slate (granted a slightly out of date version) that cause the document state
to become invalid after certain edits and then subsequent interactions throw
errors. (It's absolutely terrifying to have your text editor crash!)

~~~
gohabereg
Hello! I'm a maintainer of Editor.js.

Regarding to your questions:

\- Editor.js doesn't support nested blocks. We keep structure flat and want
Tools API to be as simple as possible for new developers. The target audience
of the Editor.js is media and blogs, usually you don't need complex structure
there. However, you can implement some complex plugins for your needs, nested
lists as example.

\- We consider development of the editor very serious and understand
importance of the test coverage. At the moment we don't have unit neither e2e
tests but this is the one of our next steps on the way.

Thanks for your feedback!

------
andybak
Why JSON-that-resembles-HTML rather than whitelisted-subset-of-HTML? Seems to
throw away a huge amount of tooling and force an extra step on anything that
wants to render the content?

Although I guess I could render the JSON to HTML server-side and get the best
of both worlds. Everything usually boils down to a question of caching
something somewhere.

~~~
Ralfp
Every browser uses different markup to represent contents of contenteditable.
One browser uses div for text and splits it into two when enter is pressed,
other browser inserts <br/>, next one has paragraph, etc. ect.

JSON is not here for resemblance, but for normalization. You force single
presentation of things from start, and when user presses enter (or other text
composition event happens) you prevent default action, update document model
(JSON) and then update the HTML.

This approach is much more sane and predictable than trying to trust browser's
HTML.

~~~
Reinmar
Still, that does not mean it cannot output HTML. CKEditor 5 implements a
custom data model, works in the way you described (cancel native actions or
extracts stuff from it, apply those changes to its data model and re-renders
the DOM if needed), but it still outputs HTML. Thanks to that you don't need a
processor to use that content on your page. Plus, there are cases where
converting a custom data model to HTML is actually a tricky job (e.g. inline
formatting) and even Editor.js chose HTML for those.

~~~
redmorphium
JSON is quite nice compared to HTML, in my view. It's less verbose. Also, I
like the flatness of Editor.js's data model.

Being JSON makes it easier to render into other formats, too.

------
chinhodado
Every time I see a new contenteditable-based editor I'm reminded of this

[https://medium.com/content-uneditable/contenteditable-the-
go...](https://medium.com/content-uneditable/contenteditable-the-good-the-bad-
and-the-ugly-261a38555e9c)

~~~
Reinmar
Hi! The author of this article here :) I hoped you liked it (cause your
message can read both ways :D)

You reminded me that I was planning to refresh it a bit since it's over 3
years old now. I'd like to cover the rise of modern rich-text editors like
CKEditor 5, ProseMirror, Draft.js and perhaps dive a bit into what we've
learned when developing CKEditor 5 (because after 4 years of work it's
actually out by now [1]). If you have any questions or you're curious about
some particular aspects, please let me know :)

[1] [https://ckeditor.com/ckeditor-5/](https://ckeditor.com/ckeditor-5/)

~~~
chinhodado
I loved the article! I used to have to maintain some custom ckeditor plugins
related to custom elements, spell checking and autocompletion at a job and
that article resonated deeply with me on a personal level. I would love to
read another article about the new editors :)

------
AlexMuir
Two long established predecessors to this: Sir Trevor JS[0] and Colonel Kurtz
[1].

I've used Kurtz extensively and it's been brilliant. The only downside of all
these block-based editors is that you can't easily create layouts where images
float to the left or right of text. Well, you can create them but you don't
get a WYSIWYG idea of what it looks like right in the editor. I can live with
that!

I've explored all sorts of editors and Colonel Kurtz is the one that's worked
best: Trix, Draft, TinyMCE, CKEditor, ContentEditable, ProseMirror - just off
the top of my head.

[0] [https://madebymany.github.io/sir-trevor-
js/](https://madebymany.github.io/sir-trevor-js/)

[1] [https://github.com/vigetlabs/colonel-
kurtz](https://github.com/vigetlabs/colonel-kurtz)

~~~
n8hunzaker
Maintainer of Colonel Kurtz here! It's super awesome to see positive feedback.
Thank you!

CK is our workhorse for tons of sites, and we've struggled to come up with a
good general pattern for editing horizontal layouts. We'd happily take
suggestions, however. I'll admit it's one of the more awkward things with the
editor.

~~~
spiralx
I'm not familiar with your editor or block-based editors in general, but it
looks like a basic version of a visual editor I used in WordPress a while
back. Is there some reason you can't do it similarly to how that did it, by
allowing a row to be split into columns, each of which can have a content
element within it and can have it's width adjusted manually or set to fit to
its content?

If you used flex instead of floats it seems like you could have most of the
functionality without the edge cases of floated elements.

------
samradelie
We were draftjs, but it got very slow on larger texts. We're replacing with
slate but it lacks some very needed textnode manipulation. Glancing at the
editor and api, wow. Can't wait to have something simple (content editable)
but with strong api backbone. Congrats!!!

~~~
Reinmar
Did you try CKEditor 5? It's a modern rich-text editing framework with a rich
API. However, it also comes with a lot of polished and ready-to-use features.
You can read more on:
[https://ckeditor.com/ckeditor-5/](https://ckeditor.com/ckeditor-5/).

~~~
bojanz
Since you mentioned CKEditor 5, I'll be bold enough to go a bit into off-
topic.

CKEditor 5 is an incredibly impressive endeavour, and I've been following it
with great interest. However, one of the things that separates it from the
competition is the GPL license, which makes it impossible to use the editor in
a permissively-licensed (Apache2/MIT) open source project. Your founder has
indicated a readiness[1] to grant a custom license to such projects.

So, I'm wondering whether that is still the policy, and how that's been
working out in practice. Have any projects taken you up on the offer? Have
there been any unforeseen problems? What are the legal limitations imposed (on
distributors/forks of the project, for example)?

[1][https://github.com/ckeditor/ckeditor5/issues/991#issuecommen...](https://github.com/ckeditor/ckeditor5/issues/991#issuecomment-384995497)

~~~
Reinmar
Thanks for such positive feedback :)

Yes, the "Free for Open Source" initiative is up and running. For now, we
didn't promote it a lot because we wanted to learn how it works, but from what
I know, the custom license that we proposed is already used by a couple of
projects.

Based on the feedback that we got so far, we're right now working on a
simplified version of this license. Its initial version still had some
restrictions which didn't work for Apache2/MIT projects with a commercial
branch. Plus, it was simply too long for normal people :). We're removing
these limitations. Once it will be polished, we will talk about it more
officially on ckeditor.com.

~~~
bojanz
That's great to hear. Keep up the good work!

------
viksit
Couple of questions,

\- Are there any plugins to transform the saved output into HTML or other
content (markdown)? Or does the user have to implement these?

\- Whats the difference between this and the CodeX editor referenced in many
places?

Edit: PS: The docs link to
[https://editorjs.io/usage](https://editorjs.io/usage) but that url seems to
be broken.

~~~
neSpecc
Hi from CodeX.

Currently we does not have ready to use implementation for converting JSON
into HTML after saving. It is a trivial and specific task, that depends on
plugins you use.

CodeX Editor is the previous "working" name of early version of Editor.js. We
have decide to change name on beta-testing stage.

------
qrohlf
I've been following this space for some time [1], and for me the constant
struggle has been finding something that is both batteries-included, so I
don't have to build a usable editor from primitives on projects where the core
differentiator is not related to how content gets authored, and mobile-
friendly, so that I don't have weird capslock bugs on iOS [2], completely
broken Android support [3], and just general mobile weirdness [4].

To the best of my knowledge, Prosemirror has been most willing to prioritize
mobile support, and currently has the best mobile browser coverage of the
three most commonly mentioned modern contentEditable options (prosemirror,
draft-js, quill). Unfortunately, building an editor with Prosemirror is a very
hands-on process that requires you to make all the UI decisions and most of
the UX decisions yourself, which isn't a great fit for most projects that
don't need to innovate in the actual _content creation_ side of things.

I would LOVE it if a batteries-included editor like this, which clearly had a
lot of thought put into the UX and UI aspects, was built on the very-robust
technical foundation of Prosemirror (or similar). There are a few efforts at
this on GitHub, but nothing so far with more than one or two contributors that
I've found. The backend of editor.js looks solid, but without any discussion
of mobile IME support, and without the backing of big players like NYT [5],
realistically I can only guess that mobile support for editor.js will end up
similar to the well-intentioned but partially complete mobile support found in
other smaller projects like quill, slate, etc.

[1]
[https://news.ycombinator.com/item?id=14417624](https://news.ycombinator.com/item?id=14417624)

[2]
[https://github.com/codemirror/CodeMirror/issues/3403](https://github.com/codemirror/CodeMirror/issues/3403)

[3] [http://engineering.mindlinksoft.com/why-draftjs-doesnt-
work-...](http://engineering.mindlinksoft.com/why-draftjs-doesnt-work-on-
android/)

[4]
[https://github.com/ianstormtaylor/slate/issues/2062](https://github.com/ianstormtaylor/slate/issues/2062)

[5] [https://open.nytimes.com/building-a-text-editor-for-a-
digita...](https://open.nytimes.com/building-a-text-editor-for-a-digital-
first-newsroom-f1cb8367fc21)

~~~
Reinmar
We've been doing quite a lot of research around mobile support in the early
phase of working on CKEditor 5. We knew from our past experience that on
mobile devices (especially smaller ones) you need a dedicated UI, rather than
a responsive version of the same UI that you use on the desktop. When the
software keyboard is visible (+ when you have autocompletion bar above the
keyboard) there's really not much space for your UI and the text that you want
to edit. It means that you need really good control over what's happening on
the screen in order to be able to implement a reliable UI.

Anyway, we had big plans for mobile support in CKEditor 5. Then we started
doing more research [1] and it turned out there are critical issues with how
WebKit works. You can guess, you can try, but with a tone of hacks you still
won't be able to guarantee a smooth UI and great UX.

Right now, we're in a state where:

* after spending several months on it, text editing is well supported on iOS and Android (including spellcheck and stuff) – we don't get any bug reports recently about that part,

* the default UI is not working great on smaller devices.

The sad part is – we don't have any bigger plans to address the latter. We
have some smaller ideas for making the current UI more responsive, but there
will still be fundamental issues that you will face when using it:

* The conflict between the native UI (the balloons/panels with paste/copy/cut/bold/italic) and the custom editor UI. I've been bringing that to the W3C's attention since 2015 and nothing happened since then (most recent topics: [2], [3]). Right now, I don't have the funds anymore to lobby for this (neither have anyone else, apparently), so those topics seem to be completely stale.

* Inability to display your UI and implement functions like scrolling to the caret in a reliable way on WebKit due to its broken viewport mechanics [4]. I even talked about this with one of the Apple devs responsible for the current behavior and he agreed that there may be a problem (a good first step :D), but I got literally zero feedback after the last year's TPAC in Lyon when I presented this issue. * And more...

IMO, it's due to those issues that we haven't seen a single editor
(implementing more than some really basic functions) with a good and stable UX
on both iOS and Android. Every solution I saw was flawed in one way or
another. I'm not saying that it's completely impossible to build such a
solution, but rather that, taken all the obstacles and moderate demand
(desktop is still the main platform for rich-text editing), the ROI seems too
low for anyone to invest enough in it.

Anyway, feel free to contact me (e.g. via
[https://twitter.com/reinmarpl](https://twitter.com/reinmarpl)) if you'd like
to discuss this more.

[1]
[https://github.com/ckeditor/ckeditor5-design/issues/149](https://github.com/ckeditor/ckeditor5-design/issues/149)

[2]
[https://github.com/w3c/editing/issues/176](https://github.com/w3c/editing/issues/176)

[3]
[https://github.com/w3c/editing/issues/182](https://github.com/w3c/editing/issues/182)
(my presentation from last year's TPAC)

[4]
[https://gist.github.com/Reinmar/91c70d2882523f47da7c49805042...](https://gist.github.com/Reinmar/91c70d2882523f47da7c498050421204)

~~~
qrohlf
This is really nice context to have. I would generally agree with you that, in
the current mobile IME landscape, it's hard-to-maybe-impossible to get close
to the text editing UX of a native app with the web platform.

I guess my point of frustration is to watch project after project toss itself
at the task of implementing a nice Medium-ish desktop UI, announce a new
"standard" for JSON-based rich document serialization, get mobile support
about 80% of the way there, and then just... leave it like that.

I don't have enough data to make a firm statement, but I would bet with
confidence that that if you include native mobile apps in the calculation (iOS
Notes app, Google Keep, Wordpress Mobile), mobile rich text editing is either
more prevalent than desktop, or on a strong upward trend that will overtake
desktop text editing in the next two years. The popularity of hybrid devices
like the iPad pro, where you have a desktop-class processor and screen size
but an iOS IME is only going to boost those numbers.

------
haney
Wagtail, a CMS system for Django uses a very similar abstraction to this for
their StreamField[1] type and I've found it incredibly useful. It allows
frontend services and backend services to easily implement custom types, and
treats streams of content as a list of 'blocks'.

[1]:
[https://docs.wagtail.io/en/v2.4/topics/streamfield.html](https://docs.wagtail.io/en/v2.4/topics/streamfield.html)

------
martin-adams
I seem to be deep in this type of problem on a project. I see they opted to
use multiple content editable sections. This means that using the up arrow
keys, when going between the sections the cursor jumps to the start of the
block, then the last line of the preceding block. It's an interesting trade of
than to use one large contenteditable section.

------
blunderkid
Curious how this stacks up against draft js?

~~~
jjdonov
Or slatejs. As I understand both have (or used to have) some serious problems
with Android mobile. I don't see an explicit claim of Android/mobile support
here either, which to me would be the killer feature.

~~~
evangow
They're hard at work on Android support on SlateJS.

[https://github.com/ianstormtaylor/slate/issues/2062](https://github.com/ianstormtaylor/slate/issues/2062)

~~~
baddox
We just upgraded our Slate version, and the relatively new Android support is
_sort of_ working, but still with a lot of bizarre and janky behavior.

~~~
thesunny
I implemented Android support on Slate. It is currently the first release and
I will be committing time to fixing the remaining bugs starting within this
month most likely.

~~~
baddox
Thanks for what must have been a ridiculous amount of effort! It is already
good enough that we re-enabled edit mode on Android.

------
houshuang
People interested in block styled editors and new takes on editors should look
at hax-the-web, a big effort using web components primarily designed for
educational materials at PSU, but usable for so much more. It's quite amazing
the flexibility that is possible - here's one recent video, there are many
many more on his channel [https://t.co/eXM6yBQA7h](https://t.co/eXM6yBQA7h)

------
revskill
This is really nice. Now HTML is not a concern anymore. Really fit the mental
model of React.

Will try this in my current project. Thanks you very much.

~~~
hombre_fatal
Make sure you try it in any browsers you want to support, especially mobile.
That's where the dragons are.

It also sucks to be in a position to say "lol sorry" to a user for being
unable to do something in a major mobile browser when you could've gone with
something more solid like ckeditor.

~~~
revskill
As i see, this editor only returns the blocks for you. How to render is upon
you instead ? Or i miss something important here ?

~~~
hombre_fatal
Implementing render(blocks) -> html is trivial.

The hard part I'm referring to is making the WYSIWYG editor. Contenteditable
takes things a step further by having you (editor + plugin implementors)
intercept every native event and then reimplement that logic yourself,
especially between click, hover, and touch (mobile) and browser differences
between the events.

Since you said you were going to try it in your current project, I just wanted
to warn you. I learned this the hard way when using Facebook's Draft.js on a
simple chat box input. We moved to either ckeditor or tinymce iirc because
support was more polished all around.

------
neals
That pop-up when I click the 3 dots is way too slow, it's really annoying.
Those buttons should probably be visible on hover.

Or better still, just show them on the side maybe. It takes too many clicks to
get work done. (IMHO)

~~~
neSpecc
Heard you, thanks. Will work on this.

------
stocktech
I've been struggling with ProseMirror for the last 2-3 months. This looks
amazing and I'm looking forward to replacing Prosemirror with it.

~~~
wiktorn
Out of curiosity, what were the most irritating problems you faced there, that
in the end you decided to start looking for a replacement?

------
LoSboccacc
this is very well done!

too bad browser selection api will cause LOT of bugs of this kind
[https://streamable.com/0gc8j](https://streamable.com/0gc8j)

~~~
neSpecc
Capture this. PRs is already on review.

Thanks.

------
phaedryx
Sadly, when I see libraries in other languages I think "oh, nice! Well done!",
but when I see JavaScript stuff I cringe, "oh no, are they reinventing the
wheel again?" as my first reaction.

------
forkLding
Has the backend crashed? The screen just keeps loading

------
o_____________o
Great! Now put this in a CMS that allows for custom React elements so we can
get rid of Wordpress/Gutenberg.

------
openbasic
What about bold, italic, etc?

~~~
greensoup
Either press the word combinations, ctrl+b etc, or select the text you want
bold and there will be a popup.

You`re limited on the selection though, thats kinda a bummer. In my opinion
making a selection and allowing a few operations, like bold, delete, is worth
it.

------
beders
Great effort, thanks!

