Как обычно мы храним в базе данных что-то, что нужно показать пользователю и обладает некоторыми свойствами разметки? Кто хотя бы раз делал свой блог, хабр или похожее сразу скажет — html. А что, если я скажу, что можно сделать иначе? JSON. Я бы хотел рассмотреть преимущества и недостатки подобного хранения, ну или попытаться, по крайней мере.  Описание: У нас имеется сервис, в бд мы храним html для отображения некоторого контента.  Если я не ошибаюсь, то так как раз сделано на всем нами любимом (или не сильно) хабре. \
(Я посмел предположить, что хабр хранит статьи именно так) Проблема: Мы, как фронтендеры, должны поддерживать на клиенте некоторый набор легаси css или как-то тяжело его обновлять. Если наш фронтендер захочет как-то обновить наш UI, то он должен учитывать, что на сервере весь html в бд содержит старые классы css и волшебным образом не поменяется и скорее всего вообще меняться не будет. Можно, например, посмотреть, что выдается для мобильной версии фронтенда хабра под недавним мегапостом ссылка на апи. Конечно, сомнительно, что пост хранится прям в таком виде в бд, но все может быть. (возможно, это связанно с тем что апи хабра до сих пор не открыто) Внимание: Небольшой скрин, просьба спрятать женщин, детей и слишком чувствительных гиков:  Некоторое количество заинлайненого css и javascript (около половины поста генерируется им) осталось за кадром. Решение: Будем хранить не html, а json, с определенной заранее или легко расширяемой структурой, что бы каждый элемент имел четкую структуру и был далек от представления у фронтендера. Профит, который получим: Мы полностью абстрагировались от представления данных и сконцентрировались лишь на содержимом. Благодаря этому мы в любой момент сможем с достаточной простотой обновить код преобразования (или рендер) json в отдаваемый браузеру html. Только теперь мы сможем написать похожий рендер из json'а не только в html, но и для нативных приложений без необходимости использовать Web View и аналоги. Для этого предлагаю ознакомится с тем, что выдает по api Хабр (только уже без мегапостов) \
Важно: я предполагаю, что статьи хранятся в том же виде, в каком и отправляются. Показывать я будут сначала html, а потом альтернативу в виде json. Изображение с подписью: источник: https://habr.com/ru/company/tuturu/blog/526710/ Изображение с подписью: источник: https://habr.com/ru/post/526676/ Думаю, что человек, который знает про тег figcaption, начал грустить, а фронтендер, который видит подобное многообразие на которое не может или может, но с трудом, повлиять еще больше грустит. Рассмотрим более комплексный пример. Оригинал откуда взята часть текста А вот так может например выглядит спойлер (просто напомню, что в html5 давно есть details): Иииии… преобразуем это в json: Вообще, Html очень удобен, чтобы представлять просто текст.
Только взгляните на этого монстра: Примечание: mode используется для того, чтобы представлять такие значения как bold, italic, strike и группировать их, просто пример не очень удачный. Столько символов, чтобы представить один параграф с одной ссылкой. Удобно ли это? Не уверен, легко можно выяснить какие стили у конкретного span без необходимости ходить для поиска предыдущих нод, но, например, в андроид есть стандартный TextView, который без проблем сработается с простеньким html Все это я, конечно, переводил не в ручную (кроме некоторых кейсов). Я брал некоторые статьи и прогонял html через свою небольшую консольную утилиту на Dart, её результаты работы вы и увидели. Да, она написана не идеально, но для проверки концепта — сойдет. Потыркать утилиту и посмотреть код можно по ссылке на мой репозиторий. Вообще к чему эти примеры. Ими я хотел сказать, что если заставляете пользователей использовать html для создания статей, то результат становится непредсказуемым, а повлиять на него можно лишь большим усилием и при желании самого пользователя. Что я вообще сравниваю? Мне интересно 2 вещи: Зачем тестировать второй вариант? Если вы используете React, например, вместе с библиотекой "html_to_react" (внутри она использует "html-dom-parser"), то, думаю, вам будет интересно узнать об альтернативе. Кратко опишу методику тестирования: Код бенчмарка: Результаты тестирования После запуска бенчмарка мы получим такие результаты: плюсы: Сделав подобное преобразование на сервере, в некоторых ситуациях можно немного ослабить нагрузку на гаджет пользователя Независимость от html Мы устраняем зависимость от того как хотим представлять на клиенте кнопку, спойлер, или цитату. независимы от css классов от различных атрибутов. Мы получаем возможность безболезненно создать на основе данных с сервера нативные виджеты, будь то андроид, ios, flutter, web или что-то из мира десктопа. И это все без WebView и аналогов. Избавляемся от зависимостей минусы: json весит незначительно, но больше чем аналогичный html  возможно и обратное, если: json придется в любом случае конвертировать в нативные для данной платформы виджеты будь то веб с его html или нативный мир уже с собственными особенностями И при этом не очень понятно, когда это лучше делать в случае веб-приложений: html очень многогранный, и если есть необходимость поддерживать весь html, то, на мой взгляд, затея выглядит достаточно сомнительной и трудоемкой (не придешь ли ты случайно к тому, что изобретешь браузер) отсутствует стандартизация, получается, что вы создаете велосипед и поддерживать его придется вам Вот мой небольшой список: В качестве итога я бы хотел сказать, что не предлагаю всем разом переходить на описанный мной в данной статье подход. В первую очередь мне интересно мнение других разработчиков, как бекенд, так и фронтенд. Скорее всего, я не учел нюансы и готов выслушать и обсудить критику и замечания. bomj computer science