Marko – A declarative, HTML‑based language 🔥 Горячее 💬 Длинная дискуссия
Marko — это декларативный язык на основе HTML для создания динамических веб-интерфейсов, расширяющий стандартный HTML возможностями для современных приложений. Любой валидный HTML является корректным Marko, но язык добавляет декларативные конструкции для реактивности и интерактивности, позволяя встраивать JavaScript прямо в шаблоны. Ключевые особенности включают потоковую передачу контента для ускорения первого отрисовки, оптимизирующий компилятор и минимальный рантайм, что обеспечивает высокую производительность даже для высоконагруженных проектов вроде eBay.com.
Фреймворк предлагает гибкость синтаксиса — от привычного HTML до более лаконичных вариантов Concise и JS — и поддерживает TypeScript для строгой типизации. Marko обеспечивает разделение concerns, управляемые компоненты, вложенную реактивность и неизменяемое состояние, что упрощает разработку масштабируемых приложений. Интеграция с экосистемой включает file-based routing и возможность использования как простых шаблонов, так и мощных компонентов по мере роста проекта.
Комментарии (166)
- Обсуждение вращается вокруг того, что веб-разработка циклически возвращается к идеям, похожим на ColdFusion и JSP, и это вызывает у участников разговора разные чувства от ностальгии до раздражения.
- Участники обсуждают, что такое "HTML-основнный" язык, и как он отличается от JSX и других подходов, и почему мы снова и снова возвращаемся к этой идее.
- Обсуждение затрагивает вопрос о том, что некоторые считают, что эволюция веб-технологий просто движется по спирали, где старые идеи периодически перерабатываются и выдаются как новые.
- Участники также обсуждают, что такое "нативный" веб-разработка и как она отличается от подхода, где JavaScript используется для обработки событий и взаимодействия.
- Участники также обсуждают, что такое "нативный" веб-разработка и как она отличается от подхода, где JavaScript используется для обработки событий и взаимодействия.
Lit: a library for building fast, lightweight web components
- 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>
Возможности
- 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 и др.
Учимся и общаемся
Комментарии (139)
- Кто-то рад избавиться от Lit, считая его лишним слоем; другие называют «недооценённой» и «лучшей абстракцией» над Web Components.
- Пользователи хвалят маленький размер, отсутствие бойлерплейта и лёгкость внедрения в legacy-проекты, но жалуются на shadow DOM (проблемы a11y, стили) и отсутствие SSR.
- Некоторые вообще отказались от фреймворков и пишут «сырые» web-компоненты, считая, что Lit лишний.
- Вопросы к мейнтейнеру: SSR, реактивность свойств, взаимодействие со сторонними компонентами, работа без бандлера.
Комментарии (48)
- Пользователи отмечают, что VibeFlow позиционируется как «бекенд для Lovable-UI» и выигрывает за счёт визуального редактора workflow и шаблонов без чёрного ящика.
- Критика: демо-видео слишком быстрое и не раскрывает главную фичу; в Safari появляется Union Jack; были ошибки при генерации TODO-приложения.
- Вопросы о самостоятельном хостинге, поддержке других баз данных (не только Convex) и экспорте кода.
- Собеседники сравнивают с Bolt.new, Replit, Leap.new и обсуждают, не перегрет ли рынок AI-генераторов приложений.
- Основатель отвечает: Convex выбран за zero-setup и реактивность, экспорт кода возможен, скоро выйдут более подробные демо, а безопасность обеспечивается «белым ящиком» кода.
Lessons learned from building a sync-engine and reactivity system with SQLite
Итоги постройки синхронизатора и реактивной системы на SQLite
Первый опыт: PGlite + Electric
- PostgreSQL в WASM + Electric даёт точную синхронизацию и LISTEN-реактивность.
- Недостатки: Electric ещё молод, старт до минуты без компакции; PGlite в single-user-режиме течёт памятью и тормозит при росте БД.
Переосмысление задачи
- SQLite-WASM стал зрелым; моё приложение однопользовательское и почти всегда онлайн.
- Значит, достаточно простого собственного решения.
Минимальный синхронизатор
- При первом запуске клиент вытягивает всё по
updated_at. - Каждые 2–3 с опрашивает сервер за записями новее этой метки и делает upsert.
- Локально при каждом UPDATE ставится флаг
modified = 1; фоновый процесс отправляет изменения. - Для текстов можно добавить CRDT (Yjs) на случай конфликтов.
Для отслеживания изменений используется триггер, который игнорируется во время синхронизации через таблицуsync_control.
Реактивность на SQLite
- SQLite не умеет LISTEN, но:
- Триггер пишет в лог-таблицу пару «таблица + id».
- Broadcast Channel API рассылает это в другие вкладки/воркеры.
- UI подписывается на канал и перечитывает нужные строки.
- Использую wa-sqlite: стабильно, без сбоев с момента установки.
Комментарии (35)
- Сообщество обсуждает проблемы PGlite и Electric, поэтому Electric развивает Tanstack DB как «sync-native» JS-решение без привязки к бэкенду.
- Предлагаются альтернативы: Evolu, SQLite-Sync, CouchDB и CRDT-движки, но авторы предупреждают, что продакшен-синхронизация сложнее PoC.
- Некоторые отказались от SQLite в браузере вовсе, храня лишь простые индексы и рассылая дельты.
- Участники подчёркивают важность консенсуса (Lamport/CRDT/raft) и отмечают, что гранулярная синхронизация не гарантирует консистентность без транзакций или разрешения конфликтов.
- В итоге рекомендуют использовать готовые движки, а не изобретать велосипед, особенно если нужны офлайн, e2e-шифрование и многопользовательский доступ.
Representing Python notebooks as dataflow graphs
marimo — новый open-source Python-ноутбук, в котором программа представлена графом потока данных. Это снимает главные боли Jupyter: скрытое состояние, невоспроизводимость, невозможность повторного использования и сложную поддержку.
Почему старый формат не подходит
- Воспроизводимость. Исследования 2019–2020 гг. показали: только 4–24 % ноутбуков на GitHub можно перезапустить без ошибок и получить те же результаты. Причина — скрытое состояние: удаление или переупорядочивание ячеек ломает выводы.
- Интерактивность. В Jupyter интерактивен процесс, но не сами данные: выделение точек на графике не возвращает датафрейм.
- Поддержка и переиспользование. Файл
.ipynb— это JSON-блоб, не валидный Python-код; сложно версионировать в Git и переиспользовать как модуль или пайплайн.
Как marimo решает задачу
- Каждый ноутбук — корректный Python-скрипт и модуль.
- Граф зависимостей ячеек строится статически; изменение одной ячейки автоматически перезапускает только зависимые.
- Реактивность: обновление переменной мгновенно отражается во всех графиках и виджетах.
- Один файл можно экспортировать как приложение или запускать без ядра Jupyter.
Комментарии (27)
- Пользователи хвалят marimo за реактивное исполнение, «песочницу» uv и лёгкий обмен с коллегами.
- Сторонники Jupyter считают, что «restart kernel & run all» решает проблему воспроизводимости, но критики отвечают: это требует дисциплины и не работает при тяжёлых вычислениях.
- Некоторые видят в ноутбуках лишь инструмент разведки и предлагают после исследования переносить код в обычные .py-файлы.
- Участники сходятся, что метаданные зависимостей и чистые DAG-подобные модели вычислений могли бы улучшить ситуацию.