В начале Осени

2026-02-06T00:00:00+00:00

В этой главе мы увидим основные идеи, стоящие за новой CMS (кодовое имя «Осень»). Из этого хаотичного наброска вырастет цельное представление о том, что мы хотим реализовать. Основная идея — создать простую в обращении и обслуживании, продуманную и отполированную систему в духе Ghost и Craft, но добавить больше инструментов редактирования и представления контента. Это позволит использовать CMS изданиям, требующим большего, чем просто блог.

Одновременно мы хотим избежать хаоса и тяжёлого наследия прошлого, которым страдает WordPress. Вопрос кастомизации должен быть продуман с самого начала, но конкретная форма требует дополнительного исследования.

Существующие решения</h2>

WordPress</h3>

Ghost</h3>
Он классный, но в нём не хватает нескольких компонентов:

Публикации на нескольких языках</li>
Шаблонов для разных видов публикаций, который могут потребоваться онлайн-изданию (новости, интервью, эссе, репортажи, около-академические статьи)</li>
Интеграции с соцсетями, не распространёнными на Западе</li>
Интеграции с платёжными системами, не распространёнными на Западе</li> </ol>
Craft CMS</h3>
Craft CMS</a>
Публикация, ключевой элемент</h2>

</div> </figure>
Метаданные</h3>
Авторы. Нам нужна гибкая настройка авторов — их может быть несколько и они могут отличаться между версиями на разных языках.
Переводчики. Указывать авторство перевода это хороший тон.
Иллюстраторы. Иногда иллюстрации могут быть не менее важной частью публикации.
Редакторы. Если это большая статья, то она может быть результатом коллективной работы и редакторы тоже могут быть указаны.
Тэги. Категоризация публикаций.
SEO. Заголовок, описание и микроформаты для поисковиков и социальных сетей.
Связи между публикациями. Публикации могут быть объединены в серии или представлять собой онлайн-дискуссию.
Даты. Дата создания, последнего изменения и публикации.
Внешние связи. Если публикация была также опубликована в соцсетях и других внешних источниках, мы должны сохранить эту связь, хотя бы в виде ссылки.
Документ</h3>
Сам документ должен хранится в формате, который отвечает нескольким требованиям:

Поддерживает совместное редактирование (Automerge</a>)</li>
Поддерживает шаблоны для вёрстки контента</li>
Позволяет эффективно представить контент в виде HTML с дополнениями в виде веб-компонентов</li> </ul>
Компоненты системы</h2>
Редактор, в котором хочется писать</h3>
Цель создать редактор, который будет использоваться напрямую, а не просто «написал в другом месте и скопировал сюда».
Базовое форматирование</h4>
Редактор должен поддерживать базовое форматирование (курсив, полужирный, таблицы и т.д.). Администратор должен иметь возможность настроить доступные редактору возможности форматирования для сохранения общего стиля издания. К примеру, отключить выделение разными цветами или ограничить палитру цветами бренда.
Блочное редактирование</h4>
Документ разбит на сегменты, которые инкапсулируют свой контент в универсальный контейнер. Внутри может быть параграф текста, заголовок, изображение, произвольный HTML и т.д.

Виды сегментов</summary>

Параграф</li>
Разделитель</li>
Закладка (Ссылка с изображением и предпросмотром, аналогичная preview в соцсетях)</li>
Разделение на публичную/закрытыю часть</li>
Call to Action/Ad</li>
Email content</li>
Callout/Hero</li>
Header</li>
Signup</li>
Toggle</li>
Video</li>
Audio</li>
File</li>
Product</li>
HTML</li>
Markdown</li>
Картинка</li>
Галерея</li>
Кнопка/Группа кнопок</li>
Вставки
Youtube</li>
X</li>
Unsplash</li>
Vimeo</li>
CodePen</li>
Spotify</li>
SoundCloud</li>
Telegram</li>
Custom</li> </ul> </li> </ul> </details> 
Сегмент можно перемещать по документу. Сегмент можно расположить в зоне шаблона.
Шаблоны</h4>
К документу можно применить шаблон, который описывает какие сегменты могут быть в документе и как они расположены. К примеру, шаблон «Интервью» содержит в себе сегменты «Вопрос» и «Ответ» помимо сегментов по умолчанию, таких как параграф.

400px) and (width <= 800px)" type="image/avif" > 800px)" type="image/avif" > </picture> </a>
Выбор сегмента в шаблоне интервью</figcaption> </div> </figure> 
Шаблоны могут также описывать вёрстку и расположение сегментов относительно друг друга для создания более динамичной структуры контента.

400px) and (width <= 800px)" type="image/avif" > 800px)" type="image/avif" > </picture> </a>
Шаблон в вёрсткой в две колонки</figcaption> </div> </figure> 
Нам нужна спецификация и API для создания и использования блоков. Это позволит создавать специализированные продукты для разных сегментов рынка и, в будущем, позволит пользователям создавать собственные шаблоны.
Предпросмотр</h4>
Редактор должен быть реализован таким образом, чтобы использовать стили темы и сделать оформление в процессе редактирования максимально близким к отображению публикации на сайте. Для этого надо реализовать загрузку стиля из темы, установленной администратором сайта. Отдельно нужен полноэкранный предпросмотр в двух режимах — мобильный и десктоп.
Вопрос Markdown</h4>
В Ghost можно вставить Markdown отдельным блоком, который будет распознан и трансформирован в HTML. Хотим ли мы сделать также или стоит создать отдельный режим редактирования для Markdown, в котором редактор будет трансформировать Markdown на лету (как, к примеру, в Obsidian)?
Всё для перевода</h3>
Перевод сайта должен быть всеобъемлющим, все компоненты системы должны быть доступны для локализации.
Перевод интерфейса</h4>
Система должна предоставлять возможность добавить перевод любых строк в интерфейсе и набор функций для более глубокой локализации (форматы дат и единиц измерения, варианты множественного числа) Переводы должны хранится в одном или нескольких файлах (чтобы загружать их отдельно по необходимости). В будущем нужно предоставить интерфейс для загрузки перевода и базовой проверки на полноту. Возможно, в будущем можно предоставить механизм автоматического перевода, но это требует дополнительного исследования вопроса.
Перевод контента</h4>
Каждая сущность в системе (публикация, автор и прочие создатели, тэг и т.д.) должна иметь версии на разных языках и собственный набор связей с другими сущностями. Публикации на разных языках могут иметь разный набор тэгов, авторов и переводчиков, могут попадать в разные категории, если издание имеет разный набор категорий на разных языках. В связи с этим, каждая языковая версия должна быть отдельной записью в базе данных, связанной с сестринскими версиями отдельным уникальным идентификатором.

структура тэгов на разных языках </div> </figure> 
Перевод публикаций</h4>
«Осень» должна предоставлять удобный интерфейс для перевода контента. Каждый перевод это отдельный документ со своими авторами, переводчиками, иллюстраторами и т.д., датами публикации и т.д. Как указано выше, каждая языковая версия публикации должна быть отдельной записью в БД и иметь общий уникальный идентификатор.
Переводы должны быть интегрированы в процесс работы и интерфейс.
Списки сущностей должны иметь фильтр по языку.

список публикаций отфильтрованных по языку </div> </figure> 
Каждая публикация должна ясно показывать, на какие языки она переведена.

языки на которые переведена публикация </div> </figure> 
Создание перевода должно быть легко доступно из интерфейса публикации.

интерфейс создания перевода </div> </figure> 
Редактор должен поддерживать продвинутые методы работы с переводом. Две версии рядом друг с другом

две версии перевода рядом друг с другом </div> </figure> 
Предложение автоматического перевода с возможностью редактирования

автоматическая и окончательная версии перевода рядом друг с другом </div> </figure> 
Интерфейс с оригиналом, переводом и предложенным автоматическим переводом

оригинал, окончательный и автоматический перевод рядом друг с другом </div> </figure> 
Инструменты редактора</h3>
Для эффективной работы онлайн-издания CMS должна поддерживать гибкий рабочий процесс, где каждая публикация может проходить через несколько этапов перед публикацией.
Процесс производства и публикации</h4>
Публикация начинается с черновика, который доступен только в административном интерфейсе.
Далее черновик может быть переведён в статус "готово" и ожидать публикации. Здесь нам нужен интерфейс для обсуждения и редактуры материала, который включает в себя:

Комментирование, привязанное к отдельным разделам материала</li>
Обсуждения (треды) по каждому комментарию</li>
Предложения изменений, которые могут быть приняты или модифицированы автором</li> </ol>
После того, как работа закончена, материалу назначается время публикации, включая публикацию немедленно, к определённому времени, или в специальный режим "ожидания", когда материал публикуется по триггеру, ручному или автоматическому.
Статусы публикации:

Черновик. Назначается при создании нового материала</li>
Готов. Назначается, если материал требует этапа редактуры и не публикуется немедленно.</li>
Ожидает доработки. Назначается, если редактор вернул материал на доработку автору.</li>
Ожидает публикации. Назначается, если материалу назначено время публикации в будущем.</li>
До звонка/по триггеру. Назначается, если материал должен быть опубликован по триггеру.</li>
Опубликован. Назначается, когда материал опубликован в открытый доступ.</li>
Отозван. Назначается, когда ранее опубликованный материал отозван.</li> </ol>
Описанный выше порядок работы это "программа-максимум". Администратор сайта должен иметь возможность выбрать несколько вариантов порядка работы — "полный", "упрощённый" или какую-либо ещё комбинацию статусов.
Доступ для внешних авторов</h4>
CMS должна иметь возможность предоставить доступ к редактированию одной публикации для внешнего автора и последующего обсуждения при редактуре. Для этого может потребоваться специальная роль и возможность авторизации через внешние источники, которые поддерживают OAuth и аналогичные механизмы.
Совместная работа</h4>
Система должна поддерживать одновременное редактирование несколькими пользователями, сохраняя и совмещая изменения в виде CRDT.
Расписание публикаций</h4>
«Осень» должна предоставлять интерфейс для контент-плана, в виде календаря с запланированными публикациями и временными слотами.
Версионирование</h4>
Каждое изменение статуса публикации создаёт новую версию. Система должна предоставлять механизм для просмотра истории версий и изменений между версиями.
Доставка контента</h3>
HTML страницы</h4>
JSON API</h4>
RSS и Atom</h4>
Интеграции</h4>
SEO</h4>
Микроформаты</h4>
Аналитика</h3>
Платежи и подписки</h3>
Роли, права и доступы</h3>
Структура данных</h2>
Публикации</h3>
Ресурсы</h3>
Рендеринг HTML и API</h2>
CMS должна предоставлять серверный рендеринг HTML и REST API — публичный для отображения контента используя фронтенд пользователя и закрытый за авторизацией для административной панели.
Возможно, нужно предусмотреть возможность отделить модуль рендеринга HTML и запустить его вместе с веб-сервером на Edge-воркерах и подобных системах, получая при этом контент из базы данных через API. Насколько это востребованный и полезный функционал пока неясно.
Федерация</h2>
ActivityPub</h3>
ATProto</h3>

Редакторы текста в Вебе

2026-02-01T00:00:00+00:00

Ниже краткий путеводитель по редакторам текста для Веба. Мы пройдёмся по базовым технологиям, подходам и свободным библиотекам.
Задачи: какие мы редакторы мы рассматриваем?</h2>
Мы будем исходить из задачи создания редактора текста общего назначения — для редактирования публикаций в CMS, чат-клиенте, написания комментариев в социальной сети и так далее. Нам нужно разнообразное форматирование: общепринятые выделения курсивом и полужирным, заголовки и так далее. Также нам нужны добавление изображений, видео, кода и прочих произвольных виджетов.
400px) and (width <= 800px)" type="image/avif" > 800px)" type="image/avif" > 400px) and (width <= 800px)" type="image/avif" > 800px)" type="image/avif" > 400px) and (width <= 800px)" type="image/avif" > 800px)" type="image/avif" > </picture> </a>
Редактор текста в CMS Ghost. Типичный представитель софта, о котором мы будем говорить далее</figcaption> </div> </figure>
Общие принципы</h2>
Рассмотренные здесь редакторы воплощают несколько общих базовых подходов, на которых сошлись как на оптимальных:
Conteditable как база</h3>
Иммутабельные структуры данных</h3>
ProseMirror хранит контент и метаданные редактора в состоянии (state), иммутабельной структуре состоящей из объединённых в дерево нод1</a>. Такой подход стал общим местом и похожие решения используются в других редакторах. Автор ProseMirror описывает главное преимущество иммутабельности: при каждом изменении контента создаётся новый объект состояния всего редактора, что позволяет избежать «промежуточных» некорректных состояний.
Текстовые координаты</h3>
Lexical</h2>
Quill</h2>
ProseMirror</h2>
Редакторы на основе ProseMirror</h3>
TipTap</h4>
ProseBlock</h4>
CKEditor</h2>
Overtype</h2>
Достоин отдельного упоминания Overtype</a> — простой редактор для Markdown, который использует интересный трюк чтобы избежать всех сложностей описанных выше. Он совсем из другой лиги, но идея отличная!

ProseMirror Guide</a> ↩</a> </li> </ol> </section>

2025-11-04T00:00:00+00:00

Заскочил чтобы написать что SmolCSS</a> and Modern CSS</a> прекрасны. CSS прошёл большой путь за последние несколько лет.

2025-10-29T00:00:00+00:00

Performance.now() это одна из конференций, на которые всё ещё стоит сходить (или, по крайней мере, посмотреть выступления). Фундаментальные темы, содержательные выступления. Множество конференций превратились в маркетинговые мероприятия (вспоминается VueConf. И почти всё, что касается Реакта)

Зачем нужен VueMapbox

2019-02-01T00:00:00+00:00

Хорошие новости</h2>
Библиотека Mapbox Gl JS</a> прекрасна. Если вам нужно создать веб-приложение для работы с географическими картами, реализовать в нём сложный функционал, то трудно найти инструмент лучше. Она красивая. Она быстрая. Она открытая. Она уникальна в своём роде: по-моему, это единственная живая и развиваемая открытая реализация векторных карт в браузере. Был ещё MapZen, но его разработка прекращена, так что выбор на самом деле не так уж велик.
Vue</a> тоже хорош. Это фреймворк для построения интерфейса в котором найден хороший баланс между простой и функциональностью, "магией" и возможностями для тонкой настройки. Его система реактивности хорошо помогает в разработке сложных интерфейсов и почти никогда не путается у вас под ногами. Почти… но это требует отдельного поста 😉.
Новости похуже</h2>
Сами по себе обе библиотеки прекрасны, а вот уживаются они не очень. Друг другу они, конечно, не мешают, но если логика вашего интерфейса построена в парадигме Vue и вы хотите и дальше пользоваться его преимуществами, то возникает вопрос: как в эту парадигму вписывается Mapbox Gl JS? Ответ не очень утешительный: примерно никак.
Тут необходимы пара небольших отступлений для прояснения вопроса.
Декларативный стиль Vue</h2>
Vue исповедует декларативный стиль программирования. Вы создаёте компонент, передаёте в него данные в props</code> и добавляете его в дерево компонентов. Изменились данные — параметры прокидываются в компонент — компонент обновляется. Для реализации в логике Vue, карта должна быть компонентом. Хотелось бы видеть что-то вроде этого:
<template> <MyMap :style="mapStyle" :center="mapCenterCoordinates" …some other props… /> </template></code></pre> Обычно на карте размещаются какие-нибудь объекты, например, маркеры, чтобы отметить какие-либо места. Опять же, хотелось бы видеть их в виде компонентов, которые естественно разместить внутри карты, так же, как мы бы поступили с какими-то HTML-элементами. Если у нас есть список мест, то мы бы создали список с данными маркеров и добавили их с помощью встроенной директивы v-for</code>. Кроме того, содержимое маркера хотелось бы менять в зависимости от условий, а также добавлять и убирать их с помощью v-if</code>. Что-то типа:
<template> <MyMap :style="mapStyle" :center="mapCenterCoordinates" …some other props… > <MapMarker v-for="marker in markers" v-if="markerCondition" :coordinates="marker.coordinates" > <span>I am marker!</span> </MapMarker> </MyMap> </template></code></pre>
Если данные меняются, то компоненты должны реагировать на это соответственно. Vue предоставляет элегантное решение для двойного связывания (two-way data binding) с помощью synced props</a>. Если какой-то метод меняет состояние карты (например, мы добавили красивый перелёт карты к какому-то месту), было бы здорово использовать двойное связывание для обновления данных.
Также, карта и её элементы могут генерировать события, и естественно слушать их на компонетах самой карты и её элементов.
Как-то так (обратите внимание на .sync</code> у параметра center</code>):
<template> <MyMap :style="mapStyle" :center.sync="mapCenterCoordinates" @movend="moveHandler" …some other props… > <MapMarker v-for="marker in markers" v-if="markerCondition" @click="markerClickHandler(marker)" :coordinates="marker.coordinates" > <span>I am marker!</span> </MapMarker> </MyMap> </template></code></pre> Всё как во Vue.
Императивный стиль Mapbox GL JS</h2>
Проблема в том, что Mapbox GL JS это совершенно другой зверь и спроектиован для работы в другой парадигме. Для того, чтобы создать карту, нам надо вызвать её конструктор и передать ему все необходимые параметры, включая id</code> HTML-элемента, в котором будет рисоваться карта. Конструктор вернёт нам объект Map</code> с которым мы и должны дальше работать.
Пример из документации Mapbox GL JS:
import mapboxgl from "mapbox-gl"; const map = new mapboxgl.Map({ container: "map", style: "mapbox://styles/mapbox/streets-v9" });</code></pre> Если мы хотим, к примеру, поменять центр карты, нам надо вызвать соответствующий метод:
import mapboxgl from "mapbox-gl"; const map = new mapboxgl.Map({ /* …map config… */}); map.setCenter([50, 50]);</code></pre> И так далее. Любые манипуляции с картой делаются через методы этого объекта. Тоже самое с получением данных. Чтобы узнать координаты центра карты, мы должны вызвать соответсвующий метод:
import mapboxgl from "mapbox-gl"; const map = new mapboxgl.Map({ /* …map config… */}); const center = map.getCenter();</code></pre> Если мы хотим слушать события карты, то нужно добавить обработчики событий к самому объекту Map</code>:
const map = new mapboxgl.Map({ /* …map config… */}); const moveHandler = event => { /* …some actions… */ }; map.on("moveend", moveHandler);</code></pre> И если элементы карты, например, слои, генерируют какие-то события, то нам нужно опять же слушать их на самом объекте карты, передав идентификатор слоя в качестве «фильтра»:
const map = new mapboxgl.Map({}); const layerId = "myLayer"; const clickHandler = event => { /* …some actions… */ }; map.on("click", myLayer, clickHandler);</code></pre> Не очень-то похоже на наш гипотетический пример выше в декларативном стиле… Ах да, слои. О слоях стоит сказать несколько слов отдельно.
Слои в Mapbox GL JS</h3>
Сами слои не представлены в виде объектов в API Mapbox GL. Чтобы добавить слой на карту нужно вызвать метод карты .addLayer()</code>, указав источник данных. Пример из документации Mapbox GL JS:
map.on("load", function () { map.addLayer({ "id": "main", "type": "fill", "source": { "type": "geojson", "data": {/* …GeoJSON data */} }, "layout": {}, "paint": { "fill-color": "#088", "fill-opacity": 0.8 } }); });</code></pre> Все дальнейшие манипуляции производятся также с помощью методов карты с передачей id</code> слоя в качестве аргумента. Всё это значит, что работать со слоями в объектно-ориентированном и декларативном стиле очень неудобно. В частности, для добавления или удаления слоёв было бы удобно использовать хуки жизненного цикла Vue, однако напрямую это невозможно. По сути, для этого нам нужно реализовать отдельную прослойку, которая будет предоставлять декларативный API и заботится о трансляции всех необходимых изменений на карту. Асинхронные методы и события</h2> В одном из проектов, с которыми я работал, требовалось последовательно показывать ряд анимаций на карте, останавливая/изменяя их в зависимости от действий пользователя, и я столкнулся с тем, что определить момент, когда асинхронные методы карты, такие как .flyTo()</code>, закончили работу, не так-то просто. В JavaScript для этих целей существет Promise</code>. Но, к сожалению, асинхронные методы не возвращают Promise и, судя по этому фич-реквесту</a>, серьёзных подвижек в этом направлении в ближайшее время не предвидится. Mapbox GL JS генерирует события, когда какое-либо действие заканчивается, например, события moveend</code>, rotateend</code> etc. Можно подписаться на эти события, но если на карте происходит несколько действий одновременно или порядок их может меняться, то как нам определить, какое имеено действие вызвало то или иное событие? Механизм для этого есть, но его трудно назвать удобным в использовании. В асинхронные методы карты можно передать объект eventData</code> в качестве аргумента. Когда какое-либо дествие с картой заканчивается, Mapbox GL JS генерирует событие и возвращает в качестве нагрузки этот объект. Таким образом, мы можем сгененрировать уникальный ID для каждого действия и по нему определить, какой именно метод вызвал определённое событие: const actionId = "uniqueActionId"; map.on("moveend", event => { if (actionId === "uniqueActionId") { // Do something! } }); map.flyTo({ center: [50, 50] }, { actionId: "uniqueActionId" });</code></pre> Второй вариант — передать в eventData</code> коллбэк, и вызвать его когда поймается событие. const callback = () => { console.log("Done!") }; map.on("moveend", event => { if (event.callback) { event.callback() } }); map.flyTo({ center: [50, 50] }, { callback });</code></pre> Делать так каждый раз довольно утомительно и не очень красиво, так что я написал небольшую библиотеку map-promisified</a>, которая оборачивает методы Mapbox GL JS в асинхронные функции, кторые возвращают Promise</code>. Когда действие заканчивается, Promise</code> разрешается, возвращая данные об изменившихся параметрах карты. Счастливый конец: VueMapbox</h2> В результате упорной борьбы с несовпадением парадигм программирования двух замечательных библиотек, родилась новая: Vue-Mapbox</a>. Она решает описанные выше проблемы, предоставляя удобный декларативный API для работы с картой. Распространияется под лицензией MIT и весит около 7Кб в сжатом виде. Vue Mabpox Документация </a> Исходный код Vue and JavaScript </a>

Компоненты системы</h2>

Редактор, в котором хочется писать</h3>
Цель создать редактор, который будет использоваться напрямую, а не просто «написал в другом месте и скопировал сюда».</p>

Всё для перевода</h3>
Перевод сайта должен быть всеобъемлющим, все компоненты системы должны быть доступны для локализации.</p>

Совместная работа</h4>
Система должна поддерживать одновременное редактирование несколькими пользователями, сохраняя и совмещая изменения в виде CRDT.</p>

Расписание публикаций</h4>
«Осень» должна предоставлять интерфейс для контент-плана, в виде календаря с запланированными публикациями и временными слотами.</p>

Доставка контента</h3>

HTML страницы</h4>

JSON API</h4>

RSS и Atom</h4>

Интеграции</h4>

SEO</h4>

Микроформаты</h4>

Аналитика</h3>

Платежи и подписки</h3>

Роли, права и доступы</h3>

Структура данных</h2>

Публикации</h3>

Ресурсы</h3>

Федерация</h2>

ActivityPub</h3>

ATProto</h3>

Общие принципы</h2>
Рассмотренные здесь редакторы воплощают несколько общих базовых подходов, на которых сошлись как на оптимальных:</p>

Conteditable как база</h3>

Lexical</h2>

Quill</h2>

ProseMirror</h2>

Редакторы на основе ProseMirror</h3>

TipTap</h4>

ProseBlock</h4>

CKEditor</h2>

В начале Осени

Существующие решения</h2>

WordPress</h3>

Craft CMS</h3>
Craft CMS</a></p>

Редакторы текста в Вебе

Зачем нужен VueMapbox

В начале Осени

Существующие решения</h2>

WordPress</h3>

Craft CMS</h3> Craft CMS</a></p>

Компоненты системы</h2>

Редактор, в котором хочется писать</h3> Цель создать редактор, который будет использоваться напрямую, а не просто «написал в другом месте и скопировал сюда».</p>

Всё для перевода</h3> Перевод сайта должен быть всеобъемлющим, все компоненты системы должны быть доступны для локализации.</p>

Совместная работа</h4> Система должна поддерживать одновременное редактирование несколькими пользователями, сохраняя и совмещая изменения в виде CRDT.</p>

Расписание публикаций</h4> «Осень» должна предоставлять интерфейс для контент-плана, в виде календаря с запланированными публикациями и временными слотами.</p>

Доставка контента</h3>

HTML страницы</h4>

JSON API</h4>

RSS и Atom</h4>

Интеграции</h4>

SEO</h4>

Микроформаты</h4>

Аналитика</h3>

Платежи и подписки</h3>

Роли, права и доступы</h3>

Структура данных</h2>

Публикации</h3>

Ресурсы</h3>

Федерация</h2>

ActivityPub</h3>

ATProto</h3>

Редакторы текста в Вебе

Общие принципы</h2> Рассмотренные здесь редакторы воплощают несколько общих базовых подходов, на которых сошлись как на оптимальных:</p>

Conteditable как база</h3>

Lexical</h2>

Quill</h2>

ProseMirror</h2>

Редакторы на основе ProseMirror</h3>

TipTap</h4>

ProseBlock</h4>

CKEditor</h2>

Зачем нужен VueMapbox

Craft CMS</h3>
Craft CMS</a></p>

Редактор, в котором хочется писать</h3>
Цель создать редактор, который будет использоваться напрямую, а не просто «написал в другом месте и скопировал сюда».</p>

Всё для перевода</h3>
Перевод сайта должен быть всеобъемлющим, все компоненты системы должны быть доступны для локализации.</p>

Совместная работа</h4>
Система должна поддерживать одновременное редактирование несколькими пользователями, сохраняя и совмещая изменения в виде CRDT.</p>

Расписание публикаций</h4>
«Осень» должна предоставлять интерфейс для контент-плана, в виде календаря с запланированными публикациями и временными слотами.</p>

Общие принципы</h2>
Рассмотренные здесь редакторы воплощают несколько общих базовых подходов, на которых сошлись как на оптимальных:</p>