Architectural Patterns in Rich Text Editing: Block-Based vs. ContentEditable

When integrating rich text editing into a modern frontend application, the choice of library dictates not just the user interface, but the entire data flow of your content system. The four major contenders—@editorjs/editorjs, ckeditor, quill, and tinymce—split into two distinct architectural camps. Understanding this split is critical because it determines whether your backend stores clean JSON structures or sanitized HTML strings.

🏗️ Core Architecture: Blocks vs. HTML Strings

The most profound difference lies in how these libraries represent data internally. This decision impacts how you save, load, and render content on other devices.

@editorjs/editorjs rejects the traditional HTML approach. It treats every paragraph, list, or image as an independent "Block." The editor outputs a pure JSON object, keeping your database free of HTML tags and presentation logic.

// editorjs: Outputs structured JSON
const output = await editor.save();
/*
{
  "time": 1550476186479,
  "blocks": [
    {
      "type": "header",
      "data": {
        "text": "Welcome to our blog",
        "level": 2
      }
    },
    {
      "type": "paragraph",
      "data": {
        "text": "This is clean data without HTML tags."
      }
    }
  ]
}
*/

ckeditor, quill, and tinymce all rely on the browser's contenteditable attribute. They manipulate the DOM directly and typically output HTML strings (though some can serialize to JSON, HTML is their native tongue).

// ckeditor: Gets HTML content
const data = await editor.getData();
// Returns: "<h2>Welcome to our blog</h2><p>This is HTML content.</p>"

// quill: Gets HTML content
const html = quill.root.innerHTML;
// Returns: "<h2>Welcome to our blog</h2><p>This is HTML content.</p>"

// tinymce: Gets HTML content
const content = tinymce.get('my-editor').getContent();
// Returns: "<h2>Welcome to our blog</h2><p>This is HTML content.</p>"

🛠️ Initialization and Configuration

Setting up these editors reveals their philosophical differences. @editorjs/editorjs requires you to explicitly define which tools (blocks) are available, promoting a modular mindset. The others often come with a default toolbar that works out of the box.

@editorjs/editorjs demands a configuration object where you map tool names to their classes. This gives you fine-grained control over the bundle size and features.

// editorjs: Explicit tool registration
const editor = new EditorJS({
  holder: 'editorjs',
  tools: {
    header: Header,
    list: List,
    image: SimpleImage,
    quote: Quote
  },
  data: {
    blocks: [
      { type: 'header', data: { text: 'Hello World', level: 2 } }
    ]
  }
});

ckeditor uses a declarative class-based setup. You import the specific build or customize the editor via a configuration object that defines the toolbar layout.

// ckeditor: Classic build initialization
ClassicEditor
  .create(document.querySelector('#editor'), {
    toolbar: [ 'heading', '|', 'bold', 'italic', 'link', 'bulletedList', 'numberedList' ],
    heading: {
      options: [
        { model: 'paragraph', title: 'Paragraph', class: 'ck-heading_paragraph' },
        { model: 'heading1', view: 'h1', title: 'Heading 1', class: 'ck-heading_heading1' }
      ]
    }
  })
  .catch(error => console.error(error));

quill focuses on simplicity. You define a theme (like 'snow' for the default white toolbar) and pass a configuration object for modules.

// quill: Simple module configuration
const quill = new Quill('#editor', {
  theme: 'snow',
  modules: {
    toolbar: [
      [{ 'header': [1, 2, false] }],
      ['bold', 'italic', 'link'],
      [{ 'list': 'ordered'}, { 'list': 'bullet' }]
    ]
  }
});

tinymce often uses a global script tag or an npm import that scans the DOM for elements with a specific selector. Its configuration is highly granular, allowing deep customization of menus and plugins.

// tinymce: Init with selector and plugins
tinymce.init({
  selector: '#editor',
  plugins: 'lists link image table code help wordcount',
  toolbar: 'undo redo | formatselect | bold italic | alignleft aligncenter alignright | bullist numlist',
  content_style: 'body { font-family:Helvetica,Arial,sans-serif; font-size:14px }'
});

📝 Handling Content Changes

Listening for changes is essential for auto-saving drafts or validating input. The event systems vary slightly in what they pass to your callback.

@editorjs/editorjs provides an onChange callback that fires whenever the content changes. It doesn't pass the data directly to avoid performance hits; you must call save() inside the handler if you need the payload immediately.

// editorjs: onChange callback
const editor = new EditorJS({
  holder: 'editorjs',
  onChange: async (api, event) => {
    console.log('Content changed');
    // Must explicitly save to get data
    const output = await api.saver.save();
    saveToDatabase(output);
  }
});

ckeditor, quill, and tinymce use standard event emitters. They often provide the data or event context directly, making real-time validation straightforward.

// ckeditor: Change event
editor.model.document.on('change:data', () => {
  const data = editor.getData();
  validateContent(data);
});

// quill: Text-change event
quill.on('text-change', (delta, oldDelta, source) => {
  if (source === 'user') {
    const html = quill.root.innerHTML;
    autoSave(html);
  }
});

// tinymce: Keyup or Change event
tinymce.get('editor').on('change', (e) => {
  const content = e.target.getContent();
  updatePreview(content);
});

🧩 Extensibility: Custom Blocks vs. Blots vs. Plugins

No editor covers 100% of use cases out of the box. How you extend them determines long-term maintainability.

@editorjs/editorjs requires you to write a custom class implementing a specific interface (render, save, validate) to create a new block type. This is more work but ensures strict data consistency.

// editorjs: Custom Tool Class
class WarningTool {
  static get toolbox() {
    return { title: 'Warning', icon: '<svg>...</svg>' };
  }

  render() {
    this.wrapper = document.createElement('div');
    this.wrapper.classList.add('warning-block');
    return this.wrapper;
  }

  save(blockContent) {
    return { message: blockContent.innerText };
  }
}

quill uses a concept called "Blots" to extend content. You define a new blot class that extends Block or Inline, allowing you to insert custom DOM nodes that Quill manages safely.

// quill: Custom Blot
const Block = Quill.import('blots/block');

class VideoBlot extends Block {
  static create(url) {
    let node = super.create();
    node.setAttribute('src', url);
    node.setAttribute('width', '100%');
    return node;
  }
}

VideoBlot.blotName = 'video';
VideoBlot.tagName = 'iframe';
Quill.register(VideoBlot);

ckeditor and tinymce rely on plugin architectures. You typically write a plugin that hooks into the editor's lifecycle to add buttons, dialogs, or processing rules.

// tinymce: Custom Plugin Registration
tinymce.PluginManager.add('myplugin', function(editor) {
  editor.addButton('mybutton', {
    text: 'My Button',
    onclick: function() {
      editor.insertContent('Hello from custom plugin!');
    }
  });
});

// ckeditor: Custom Plugin (simplified structure)
export default function MyPlugin(editor) {
  editor.ui.componentFactory.add('myButton', () => {
    const button = createButton({
      label: 'My Button',
      execute: () => {
        editor.model.change(writer => {
          writer.insertText('Hello from CKEditor!', editor.model.document.selection);
        });
      }
    });
    return button;
  });
}

🌐 Shared Capabilities: Common Ground

Despite their architectural differences, all four libraries solve the same fundamental problems: sanitization, formatting, and media embedding.

1. 🛡️ XSS Protection and Sanitization

All libraries automatically sanitize input to prevent Cross-Site Scripting (XSS) attacks when rendering content. They strip dangerous tags like <script> by default.

// All libraries handle this internally upon output
// Example: User inputs <script>alert('hack')</script>
// Output in editorjs/ckeditor/quill/tinymce: Safe text or stripped tag

2. 🖼️ Image Handling

Each provides mechanisms to handle images, though the implementation varies from base64 encoding to server upload callbacks.

// quill: Image handler configuration
quill.getModule('toolbar').addHandler('image', () => {
  const input = document.createElement('input');
  input.setAttribute('type', 'file');
  input.click();
  input.onchange = () => { /* upload logic */ };
});

// tinymce: Images upload handler
images_upload_handler: (blobInfo, progress) => new Promise((resolve, reject) => {
  // Upload blobInfo.blob() to server
  resolve('url_to_image');
})

3. 📱 Mobile Responsiveness

All modern versions support touch interactions and responsive layouts, ensuring the editor works on tablets and phones.

/* Common CSS pattern for all editors to ensure responsiveness */
.editor-container {
  width: 100%;
  max-width: 800px;
  margin: 0 auto;
}

📊 Summary: Key Differences

💡 The Big Picture

Choosing the right editor is not about which one has the most features; it is about which data model fits your application architecture.

@editorjs/editorjs is the modern choice for developers building API-first applications. If your frontend is React, Vue, or Angular, and your backend is Node or Go, storing clean JSON prevents the nightmare of parsing and sanitizing HTML later. It forces a separation of concerns that pays off in large-scale systems.

ckeditor is the powerhouse for document-centric applications. If your users need to create complex reports with tables, footnotes, and track changes, nothing else compares. It is heavy, but it replaces a word processor, not just a text box.

quill strikes a balance for standard web content. It is free, open-source, and easy to embed. If you need a rich text area for user comments or simple blog posts and don't want to deal with licensing or complex setups, Quill is the pragmatic choice.

tinymce remains the industry standard for general-purpose editing. Its familiarity reduces training time for non-technical users, and its plugin ecosystem covers almost every edge case imaginable. It is the safe bet for enterprise intranets and content management systems where stability is paramount.

Final Thought: If you are building a new product today and control both the editor and the renderer, strongly consider the block-based approach of Editor.js. If you are replacing a legacy textarea or need complex document features, TinyMCE or CKEditor will save you months of development time.