Marko — это декларативный язык на основе HTML для создания динамических веб-интерфейсов, расширяющий стандартный HTML возможностями для современных приложений. Любой валидный HTML является корректным Marko, но язык добавляет декларативные конструкции для реактивности и интерактивности, позволяя встраивать JavaScript прямо в шаблоны. Ключевые особенности включают потоковую передачу контента для ускорения первого отрисовки, оптимизирующий компилятор и минимальный рантайм, что обеспечивает высокую производительность даже для высоконагруженных проектов вроде eBay.com.

Фреймворк предлагает гибкость синтаксиса — от привычного HTML до более лаконичных вариантов Concise и JS — и поддерживает TypeScript для строгой типизации. Marko обеспечивает разделение concerns, управляемые компоненты, вложенную реактивность и неизменяемое состояние, что упрощает разработку масштабируемых приложений. Интеграция с экосистемой включает file-based routing и возможность использования как простых шаблонов, так и мощных компонентов по мере роста проекта.

• Обсуждение вращается вокруг того, что веб-разработка циклически возвращается к идеям, похожим на ColdFusion и JSP, и это вызывает у участников разговора разные чувства от ностальгии до раздражения.
• Участники обсуждают, что такое "HTML-основнный" язык, и как он отличается от JSX и других подходов, и почему мы снова и снова возвращаемся к этой идее.
• Обсуждение затрагивает вопрос о том, что некоторые считают, что эволюция веб-технологий просто движется по спирали, где старые идеи периодически перерабатываются и выдаются как новые.
• Участники также обсуждают, что такое "нативный" веб-разработка и как она отличается от подхода, где JavaScript используется для обработки событий и взаимодействия.
• Участники также обсуждают, что такое "нативный" веб-разработка и как она отличается от подхода, где JavaScript используется для обработки событий и взаимодействия.

HTMX предлагает декларативный подход к веб-разработке через HTML-атрибуты, что могло бы сократить потребность в JavaScript, если бы браузеры поддерживали такие семантики изначально. Однако автор отмечает, что HTMX не предоставляет чёткой структуры, подобной SPA-фреймворкам, что ведёт к риску создания спагетти-кода, как в случае с jQuery.

В ответ на это был создан MESH — фреймворк, сочетающий модульный SSR с гидрацией, где каждый компонент соответствует одному эндпоинту. Это позволяет писать бэкенд с фокусом на HTML, сохраняя ощущение работы с SPA. Для демонстрации использовались Go, Templ и Declarative Shadow DOM, с небольшим хаком для обхода ограничений HTMX внутри теневых DOM. Ключевая идея — обеспечить единственно верный способ структурирования кода, избегая хаоса.

• Обсуждается применимость HTMX для различных типов приложений: отличное решение для многостраничных приложений, но может быть неоптимальным для сложных SPA-подобных интерфейсов с интенсивным взаимодействием (например, drag-and-drop).
• Представлены альтернативные подходы и фреймворки: MESH (один эндпоинт на компонент), Data-Star (обновление по SSE), Blazor, Leptos, а также использование чистого JS или Web Components.
• Поднимаются технические нюансы HTMX: поведение по умолчанию при замене контента (innerHTML), обработка ошибок, ограничения парсера DOM при работе с Shadow DOM.
• Критикуется тенденция добавления абстракций поверх HTMX, что, по мнению части участников, противорит его философии простоты и возврата к истокам.
• Отмечается ценность HTMX и подобных инструментов как реакция на сложность современных JS-фреймворков и возможность быстрой разработки без сборки.

В недавнем посте я писал о том, что элементы можно рассматривать как готовые компоненты браузера. Позже я осознал, что сам не следую этому принципу — использовал классы вместо семантических элементов. Это привело к радикальному решению: полностью отказаться от классов на своём сайте.

Я перестроил CSS вокруг трёх слоёв: base, components и utilities. Всё в base уже было на селекторах тегов, поэтому задача свелась к пересмотру компонентов и удалению утилит. Сначала я усилил использование семантических элементов и контекстных стилей, но зашёл слишком далеко, создавая сложные селекторные паттерны.

Решение пришло через кастомные теги и атрибуты по образцу веб-компонентов, но без JavaScript. Например:

note-pad {
  padding-block: var(--size-lg);
  border-block-end: var(--border-default);
}

А кастомные атрибуты заменили модификаторы в стиле BEM:

random-pattern {
  & [shape-type="1"] {
    border: 0.1rem solid var(--color-sheet);
  }
}

Плюсы: сократил CSS до ~5КБ, улучшил доступность и чистоту разметки. Минусы: подход требует большего планирования и не подходит для крупных проектов с разноуровневой командой.

Пока не готов назвать это идеальным решением для всех случаев, но для личного сайта — отличный эксперимент.

• Автор сайта утверждает, что добился минималистичного дизайна почти без использования CSS-классов, полагаясь на семантическую структуру HTML.
• Многие участники дискуссии указывают, что сайт на самом деле содержит множество классов (175+), что противоречит заявлению автора.
• Подход семантической вёрстки (без лишних классов) хвалят за чистоту кода и хорошую доступность, но критикуют за жёсткую привязку стилей к структуре HTML, что усложняет поддержку и изменения.
• Отмечается, что такой подход хорошо работает для статических документов (например, блогов), но не подходит для сложных и динамических веб-приложений.
• В качестве альтернатив упоминаются методологии вроде BEM, фреймворки типа Tailwind CSS и использование современных возможностей CSS (:has, @scope, @layer).
• Часть участников считает, что полный отказ от классов — это скорее эстетическое упражнение, а не практичный паттерн для реальных проектов.
• Общий вывод: важен баланс — использовать семантические элементы по умолчанию, но добавлять классы там, где это необходимо для гибкости.

React победил по умолчанию — и это убивает фронтенд-инновации

React больше не выигрывает за счёт технических преимуществ. Сегодня он побеждает по умолчанию, что замедляет инновации во всей фронтенд-экосистеме.

Команды редко начинают с вопроса «Какие ограничения и какой инструмент подходит лучше?». Чаще звучит: «Давайте использовать React — все его знают». Это создаёт цикл, где архитектуру определяют сетевые эффекты, а не техническая целесообразность.

Между тем, фреймворки с реальными инновациями борются за внедрение. Svelte устраняет накладные расходы компиляцией, Solid предлагает детальную реактивность без виртуального DOM, Qwik обеспечивает мгновенный запуск через возобновляемость. Эти подходы часто превосходят модель React, но редко получают оценку, потому что React выбирают по умолчанию.

Проблема не в самом React, а в мышлении «React по умолчанию».

Потолок инноваций

Технические основы React объясняют современные трудности. Виртуальный DOM был умным решением для проблем 2013 года, но, как отметил Рич Харрис, он вводит издержки, которых можно избежать с помощью компиляторов.

Хуки решили проблемы классовых компонентов, но добавили сложности: массивы зависимостей, устаревшие замыкания, неправильное использование эффектов. Даже документация React призывает к сдерженности: «Вам может не понадобиться эффект». Серверные компоненты улучшают время до первого байта, но добавляют архитектурную сложность.

Компилятор React — умное решение для автоматизации useMemo/useCallback, но его существование сигнализирует: мы оптимизируем вокруг ограничений модели.

Альтернативы предлагают иные подходы: Runes в Svelte 5 упрощают реактивность на этапе компиляции, детальная реактивность Solid обновляет только изменённые части, возобновляемость Qwik устраняет традиционную гидратацию. Это не инкрементные улучшения React, а другие модели с иными пределами.

Инновации без внедрения не меняют результаты. Внедрение невозможно, когда выбор делается рефлекторно.

Технический долг, который мы несём

Выбор React по умолчанию часто означает runtime и затраты на согласование, которые мы больше не questioned. Даже когда он достаточно быстр, его потолок ниже, чем у моделей с компиляцией или детальной реактивностью. Время разработчиков тратится на управление перерисовками, зависимостями эффектов и границами гидратации вместо создания ценности.

Исследования производительности единодушны: JavaScript дорог на критическом пути.

Мы сосредоточили ментальные модели вокруг «React-паттернов» вместо основ веба, снижая переносимость навыков и увеличивая архитектурную инерцию.

Потеря не только в производительности, но и в упущенных возможностях, когда альтернативы не оцениваются. Например, бенчмарки показывают, что Solid в 2-3 раза быстрее React в сценариях с интенсивной реактивностью.

Фреймворки, которым не дают развиваться

Svelte: революция компилятора

Svelte переносит работу на этап компиляции: нет виртуального DOM, минимальный runtime. Компоненты становятся целевыми операциями DOM. Ментальная модель соответствует основам веба.

Но «недостаточно вакансий» искусственно сдерживает внедрение Svelte, несмотря на технические преимущества.

• React побеждает благодаря композиции функций JavaScript, интуитивной модели и стабильности, а не только из-за сетевых эффектов.
• Веб-компоненты рассматриваются как путь к совместимости между фреймворками и снижению зависимости от экосистемы React.
• Многие разработчики ценят React за предсказуемость, лёгкость найма и богатую экосистему, что делает его безопасным выбором.
• Критики указывают на сложности React (хуки, зависимости, ререндеры) и чрезмерный boilerplate-код.
• Альтернативы вроде Svelte или Solid предлагают упрощённые модели и лучшую производительность, но проигрывают в распространённости.
• Инновации во фронтенде часто воспринимаются как «суета», ведущая к устареванию проектов и постоянным переписываниям.
• React доминирует частично из-за React Native, что позволяет использовать единую кодобазу для web и мобильных платформ.
• Браузеры и стандарты Web обвиняются в недостаточной скорости развития, что вынуждает полагаться на фреймворки.
• Стабильность и стандартизация ценятся выше постоянных изменений и «инноваций» в индустрии.

• Lit — простая, быстрая библиотека для Web Components
• Bluesky: lit.dev

---

Основные плюсы

• Simple
  Минимум шаблонного кода: реактивность, декларативные шаблоны, продуманные фичи.

• Fast
  ≈ 5 КБ (сжато), рендер только изменённых частей, без виртуального DOM.

• Web Components
  Нативные кастом-элементы работают в любом фреймворке и без него.

---

Мини-пример

import {html, css, LitElement} from 'lit';
import {customElement, property} from 'lit/decorators.js';

@customElement('simple-greeting')
export class SimpleGreeting extends LitElement {
  static styles = css`p { color: blue }`;
  @property() name = 'Somebody';
  render() {
    return html`<p>Hello, ${this.name}!</p>`;
  }
}

<simple-greeting name="World"></simple-greeting>

Попробовать в Playground

---

Возможности

• Custom Elements — встраиваются как обычные теги.
• Scoped styles — Shadow DOM изолирует CSS.
• Reactive properties — автоматический перерендер при изменении.
• Declarative templates — нативные литералы, без компиляции.

---

Что строят на Lit

• Shareable Components — капсулы для любого стека.
• Design Systems — единые компоненты под разные фреймворки.
• Sites & Apps — постепенное улучшение или полные приложения.

---

Кто использует

Adobe Spectrum, Alaska Auro, Cisco Momentum, Home Assistant, IBM Carbon, Lion, Pharos, PWA Starter, SAP UI5, Shoelace, Hilla, Clarity, Wired Elements и др.

---

Учимся и общаемся

• Туториалы
• Playground
• Документация
• Get started

• Кто-то рад избавиться от Lit, считая его лишним слоем; другие называют «недооценённой» и «лучшей абстракцией» над Web Components.
• Пользователи хвалят маленький размер, отсутствие бойлерплейта и лёгкость внедрения в legacy-проекты, но жалуются на shadow DOM (проблемы a11y, стили) и отсутствие SSR.
• Некоторые вообще отказались от фреймворков и пишут «сырые» web-компоненты, считая, что Lit лишний.
• Вопросы к мейнтейнеру: SSR, реактивность свойств, взаимодействие со сторонними компонентами, работа без бандлера.

Git-граф «плетения» Трампа

Трамп называет свою манеру речи «the weave»: он перескакивает между темами, а потом «все блестяще сводится воедино». Я решил визуализировать это как git-граф.

Использовал Mermaid.js, но горизонтальная схема не подошла, поэтому написал компонент <git-graph>.

Фрагмент из транскрипта совещания в Овальном кабинете:

%%{init: { 'theme': 'base' } }%%
gitGraph
  commit id:"CBO: тарифы принесут $4 трлн"
  branch radical-left
  commit id:"радикальные левые признали Трампа правым"
  checkout main
  merge radical-left
  commit id:"$4 трлн сократят дефицит"
  branch stock-market
  commit id:"рынок +1000 пунктов"
  branch world-respect
  commit id:"весь мир нас уважает"
  branch fifa-event
  commit id:"финал FIFA в Kennedy Center"
  branch kennedy-center-remodel
  commit id:"ремонт займёт год"
  branch oval-office-remodel
  commit id:"золото в Овальном кабинете"
  branch painting-vault
  commit id:"картины великих президентов из хранилища"

Каждая ветка — новая тема, cherry-pick — возврат к уже сказанному.

• Участники обсуждают «ткацкий» стиль речи, когда тема раскрывается «ветвями», сливающимися лишь в финале.
• Предложены улучшения диаграмм: показывать название ветви рядом с «New Topic» и использовать Sankey- или top-to-bottom-режимы.
• Некоторые считают визуализацию забавной и полезной для анализа «словесного салата» политиков и бизнесменов.
• Подняты технические проблемы: сломанный рендеринг в iOS и Firefox, отсутствие тестов и дисклеймеров.
• Обсуждение быстро скатилось в политические споры: «хит-пьеса» против Трампа, сравнение с Обамой, обвинения в трусости и «сенильности».

Современный веб без JS
Фреймворки вроде React и NextJS часто превращают сайты в тяжёлые, медленные и ошибочные конструкции. Виной тому не столько сами фреймворки, сколько килобайты трекеров и плохой код. Тем не менее, многим проектам JavaScript вовсе не нужен — HTML и CSS способны на многое.

CSS не так плох
Негатив к CSS часто идёт от незнания основ. Его считают «карандашом для рамок», хотя это полноценный язык. Центрировать div сегодня тривиально: display: flex; justify-content: center; align-items: center;. В девтулзах есть интерактивный редактор flexbox, забыть синтаксис невозможно.

Писать стало приятно
CSS-фичи последних лет убрали боль:

• Вложенность без препроцессоров
• Кастомные элементы <cool-thing shadow>
• Логические свойства, clamp(), aspect-ratio, @container, :has() и др.

Пример старого vs нового
До:

.post > .buttons .like:hover { color: var(--like-color-hover); }

После:

.post {
  .buttons .like:hover { color: var(--like-color-hover); }
}

Итог
Я не призываю отказаться от JS полностью, но показываю, что большинство сайтов могут обойтись без него, если грамотно использовать современный CSS.

• Некоторые считают CSS «ужасным» и «загадочным», другие — наоборот, хвалят его эволюцию (nesting, flexbox, :has).
• Часть споров сводится к «CSS vs JS»: Tailwind-фанаты и «CSS-only» энтузиасты доказывают, что можно обойтись почти без скриптов.
• Поднимаются боли: каскад, специфичность, нелогичные названия свойств, отсутствие системности.
• Появляются практические советы: уже работают sibling-index(), @mixin, Web Components, а WYSIWYG-редакторы могут вернуться.
• Вопросы доступности и обучения: где взять современный учебник/справочник и как сделать компоненты доступными без JS.

• Главная
• Чат-демо
• Потоковая передача
• Реализации
• Спецификация
• GitHub

• Пользователи спорят: зачем превращать Markdown в React/Svelte/Vue-компоненты, если можно сразу выдавать HTML.
• Автор отвечает: цель — безопасный runtime-DSL для LLM, чтобы чат-боты могли «рисовать» интерактивные формы без сборки.
• Критика: без сборки не получается оптимизированный код, ломается после нескольких кликов, не масштабируется.
• Некоторые сравнивают проект с MDX и mdwiki, предлагают компилировать на этапе сборки или использовать Web Components.
• Автор признаёт проблемы и анонсирует v2: нативные custom elements + тонкие обёртки под React/Svelte/Vue.

Кратко: стандартизировать в браузерах XSLT 3.0 нецелесообразно.
Технология мало используется, реализация сложна, а современные подходы (JS-шаблонизаторы, Web Components, SSR) решают те же задачи быстрее и проще.

• Пользователи мечтают о «навсегда-статическом» сайте без обновлений зависимостей; кто-то до сих пор использует PHP-include, кто-то — <template>+JS.
• Появилась фантазия «а вдруг браузеры вернут XSLT 3.0»; сторонники называют это разделением данных и представления, скептики — «громоздким XML-гипертекстом».
• Поддержка XSLT в браузерах всё ещё есть, но фактически мертва: Google убирает упоминания из спецификаций, а правительственные сайты жалуются на поломки.
• Основные претензии к XML/XSLT: чрезмерная многословность, сложность ручного редактирования, жёсткая типизация и «всегда есть пять способов записать то же самое».
• JSON и современные SSR-шаблонизаторы оказались проще и быстрее, поэтому даже ностальгирующие разработчики признают: «красивый, но неудобный» стандарт проиграл конкуренцию сетевым эффектам и эргономике.

• Это не настоящий WYSIWYG, а прозрачное синтакс-подсветка Markdown в textarea.
• Работает через наложение прозрачной textarea на div-рендер, что даёт лёгкость и совместимость с undo/redo и мобильной клавиатурой.
• Пользователи хвалят простоту (≈45 KB, нет зависимостей), но замечают просадку FPS на телефонах, смещение каретки и невозможность вставки картинок.
• Часто предлагают завернуть решение в web-component с shadow DOM, чтобы избежать проблем CSS-наследования.
• Несколько человек поделились похожими проектами (CodeJar, rich-textarea, Milkdown) и предложили добавить авто-списки, подсветку кода в блоках и поддержку variable-width шрифтов.