Editor.js – Block Styled Editor | Hacker News Reader

Editor.js – Block Styled Editor

editorjs.io

347 pointstortilla72 comments

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

Great summary! I've researched WYSIWYG editors recently and second this.

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.

Yea, it was even causing my keyboard to lag. Keystroke queued up, but the key press state (enlarged visible letter above your finger) was really delayed.

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.

Nice, added to the list of editors: https://gist.github.com/manigandham/65543a0bc2bf7006a487

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

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.

You can search HN for any relevant discussions: https://hn.algolia.com/

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).

I agree for most of it.

I'm the current maintainer of 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.

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!)

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!

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.

I think the idea is platform agnosticism. What if you're serving to a client that doesn't understand html? You'll need to interpret it somehow...

Text objects are apparently still HTML, I.e. HTML parsing is still required to understand the input.

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.

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.

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.

In all cases you override the default action and determine what content to generate. The format (JSON or HTML) is an entirely separate discussion.

Totally agree. In fact, they even used HTML inside the "text" property so, in fact, they mix JSON with HTML which doesn't seem to make a lot of sense.

You can have a nice structured HTML and it will be as portable, as interoperable (if not more) as that JSON.

Another take on this (by my colleague from CKEditor team): https://medium.com/content-uneditable/a-standard-for-rich-te...

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

https://medium.com/content-uneditable/contenteditable-the-go...

Heh, I remember a fun bug(?) I had found in IE while using contenteditable on my previous job.

I had been assigned to implement a rich text editor which was pretty close to what OP has posted, except that it a feature where the editable text had 'islands' of uneditable text sprinkled in-between. Sounds simple enough? Just add a nested element with contenteditable set to `false`. This worked well enough in Firefox and Chrome, but for some reason it wouldn't work in IE (surprise!).

After hours of scouring the internet, I found the solution[1], which was setting contenteditable to `true` for disabling the edit in the case of IE. The reason for this behavior? Nobody knows.

I still feel pangs of guilt for the poor sod who has to maintain that dumpster fire that I wrote as a fresh faced grad.

[1] https://stackoverflow.com/questions/7522848/contenteditable-...

I read this! And then we decided that the right thing to do for MOBILE is to completely AVOID native selections. The editor we built is way more clean than ANYTHING professional companies like Froala, Imperavi, TinyMCE, CKEditor and others have put out. But only for mobile touchscreens.

We are thinking of hiring a manager to license this to everyone using the other editors on their site (sites like BuiltWith can tell you entire lists of these sites) or just negotiate to give an unlimited / open source license to Froala / Imperavi themselves!

See for yourself: https://youtu.be/-DgaTwG1csc

Contact greg at the domain qbix.com if interested. It would be a commission based job, but can involve a lot of fun things like producing videos and websites w our team.

Yeah, unfortunately this one breaks Emacs keybindings on macOS :(

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/

I would love to read an article like that! I'm very curious how the architecture of the new CKEditor 5 compares to younger alternatives like ProseMirror and Draft.js.

Seconding that other comment.

Really curious if that grasshopper(Draft.js) is stil green.

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 :)

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/

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

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.

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.

Thanks for the sirtrevorjs link.

Looking at the structure I was thinking how similar it is.

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!!!

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/.

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...

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.

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

Highly recommend Prosemirror. At least in my limited testing, it's much faster than Slate but you need a React wrapper for it

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 but that url seems to be broken.

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.

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

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

[3] http://engineering.mindlinksoft.com/why-draftjs-doesnt-work-...

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

[5] https://open.nytimes.com/building-a-text-editor-for-a-digita...

Thanks for a feedback and links.

We have done a lot of work on core stabilisation and API improvement. First version of editor.js is used for a while by local big (well, relatively) media projects — vc.ru, dtf.ru, tjournal.ru with the 200-500k DAU. This projects have UGC communities, so the Editor is using many times in a day. I mean most of our resources on the past stage was directed to the stability purposes.

Fully agree with you about the importance of UI and UX (and mobile adaptation) in our case. This is a next step we have start today. And this is a reason why it is an open source and free. We see many talented developers and the demand, so we will continue to work.

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) if you'd like to discuss this more.

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

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

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

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

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.

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

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.

Curious how this stacks up against draft js?

Or ProseMirror, Slate, Quill, Trix, or probably a dozen other very similar contenteditable-based editor frameworks.

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.

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

https://github.com/ianstormtaylor/slate/issues/2062

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.

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.

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

Why is Android a concern ? Aren't articles written and their layout tuned on a desktop/laptop anyway, at least for anything taking much longer than writing a tweet ?

Articles yes. Blog posts not so much.

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

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.

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.

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

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.

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)

Heard you, thanks. Will work on this.

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.

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

this is very well done!

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

Capture this. PRs is already on review.

Thanks.

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.

Has the backend crashed? The screen just keeps loading

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

What about bold, italic, etc?

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.

Great effort, thanks!

Reply on news.ycombinator.com