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-фреймворков и возможность быстрой разработки без сборки.

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 обвиняются в недостаточной скорости развития, что вынуждает полагаться на фреймворки.
• Стабильность и стандартизация ценятся выше постоянных изменений и «инноваций» в индустрии.