SvelteKit 3.0 вышел как обновлённая версия официального фреймворка для Svelte, сохранив привычный интерфейс, но добавив больше типобезопасности, упрощённую конфигурацию и меньше лишнего кода. Миграция упрощена командой npx sv migrate sveltekit-3 --tasks all --confirm, которая автоматически переносит код и генерирует список оставшихся задач. Для новых проектов используется npx sv create my-new-app. Ключевые изменения: конфигурация перенесена в vite.config.ts, псевдоним $lib заменён на #lib в соответствии со стандартными субпакетными импортами Node.js, переменные окружения стали мощнее и проще в использовании, сервис-воркеры требуют меньше шаблонного кода, а обработка ошибок улучшена во всех слоях.

Удалённые функции (remote functions), обеспечивающие типобезопасное клиент-серверное взаимодействие, пока не готовы к стабильному использованию — они требуют экспериментального флага и Async Svelte с await-выражениями, но являются приоритетом разработки. В блоге также напоминается о предстоящем Svelte Summit в Любляне, Словения, 19–20 ноября — событии, посвящённом 10-летию Svelte, где планируется не только технический обмен, но и праздничный торт.

SvelteKit 3 улучшает DX и производительность, но остаются проблемы с реактивностью, привязкой данных и поддержкой LLM. Пользователи отмечают мгновенную загрузку страниц и небольшие размеры сборок — особенно с Wails, где бинарники <20 МБ, что экономит ресурсы по сравнению с Electron. Миграция из React, Next.js, Nuxt и Vue проходит без серьёзных проблем благодаря автоматическому мигратору и обратной совместимости. Основные недостатки: «getter trap» (потеря реактивности при забытом экспорте свойства) и тесная связь асинхронного получения данных с компонентами, усложняющая архитектуру. LLM‐модели (Claude, DeepSeek, Opus) успешно генерируют код для Svelte, но ранние версии испытывали трудности с различиями между Svelte 4 и 5 — потребовались специальные бенчмарки. Файловая система роутинга с префиксом «+page.svelte» в глубоко вложенных папках воспринимается как неудобная и запутанная для новых пользователей. Отсутствие Shadow DOM в Svelte снижает перерасчёты и потенциально улучшает память, но точные цифры не подтверждены независимыми тестами. Встроенные стора позволяют двухстороннее связывание без колбэков, упрощая работу с формами и состоянием. Частые breaking changes в новых версиях Svelte вызывают опасения по поводу долгосрочной стабильности. Вопрос о едином стеке для фронтенда и бэкенда открыт, но SvelteKit хорошо сочетается с Go‐бэкендом через Wails, обеспечивая единый язык разработки UI. Удалённые функции (remote functions) ещё не готовы к продакшн и находятся в ожидании реализации.

Transformer — это архитектура нейросети, представленная в 2017 году в статье «Attention is All You Need», которая стала основой для современных языковых моделей, таких как GPT, Llama и Gemini. Её ключевая инновация — механизм самовнимания, позволяющий модели анализировать взаимосвязи между всеми токенами последовательности одновременно, эффективно улавливая дальние зависимости. Трансформеры работают по принципу предсказания следующего токена: на основе входного промпта модель вычисляет вероятности появления каждого следующего слова или его части.

Архитектура трансформера состоит из трёх основных блоков: эмбеддинга, трансформер-блока и выходного слоя. Эмбеддинг преобразует текст в числовые векторы через токенизацию, поиск векторов токенов, добавление позиционной информации и их суммирование. Трансформер-блок включает слой внимания, который распределяет фокус между токенами, и MLP-слой, обрабатывающий каждый токен независимо для уточнения его представления. Выходной слой преобразует финальные представления в вероятностное распределение над словарём через линейное преобразование и softmax.

Transformer Explainer — интерактивный инструмент, визуализирующий работу малой версии GPT-2 (124 млн параметров) прямо в браузере. Он построен на nanoGPT, сконвертирован в ONNX для в-browser выполнения, и использует Svelte и D3.js для динамических визуализаций. Пользователь может вводить собственный текст, наблюдать за вычислением эмбеддингов, весами внимания, активациями MLP и выходными вероятностями, а также экспериментировать с температурой, top-k и top-p семплированием, чтобы увидеть, как эти параметры влияют на креативность и детерминированность генерации. Инструмент разработан командой из Georgia Institute of Technology для наглядного обучения принципам работы трансформеров.

Обсуждение подтверждает, что механизм внимания работает как динамический слой плотных связей, где матрица внимания играет роль весов, а Value‐вектор проходит через него. Указывается на исторический предшественник — Fast‐Weight Programmers Шмидхубера. Трансформеры превосходят dilated CNN по соотношение точность/вычисления, позволяя обмениваться информацией между удалёнными позициями за один шаг. Другие архитектуры работают, но менее эффективно; традиционные сети используют иной порядок умножения матриц, меняя форму представления данных. Визуализации вроде bbycroft.net/llm и Illustrated Transformer существенно упрощают понимание внимания и архитектуры трансформеров, особенно для новичков. Рекомендуются: The Illustrated Transformer (@jasonjmcghee), книга "Hands of Large Language Models" (@hangonhn, @israrkhan). Ключевые параметры внимания — Q/K/V матрицы — должны быть показаны в визуализации в начале блока "Head N of M" (@maciejzj). Запрос на более простое объяснение роли K/Q/V отражает потребность в доступных объяснениях (@bilsbie). Практические ограничения: модели требуют большого объёма скачивания (~600 МБ) (@shagie); визуализатор не работает на мобильных устройствах (@hollowturtle). Предупреждение: визуализатор на GPT‐2 может вводить в заблуждение из‐за устаревшего абсолютного позиционного кодирования (@E-Reverance). Идея динамического формирования весов восходит к Fast Weight Programmers Шмидхубера, но в современных публикациях часто не упоминается (@octoberfranklin).

Hister — это личный поисковый движок, который индексирует полное содержимое посещаемых веб-страниц и локальных файлов, позволяя находить информацию через веб-интерфейс, терминал или AI-ассистента, подключённого через MCP. Он работает полностью локально или на вашей инфраструктуре, не требуя телеметрии или облачных сервисов по умолчанию. Установка проста: скачайте бинарник, запустите hister listen, установите расширение для Firefox или Chrome, и после посещения страницы с включённым расширением вы сможете сразу искать по её содержимому.

Ключевые возможности включают полнотекстовый поиск, автоматическую индексацию через браузерное расширение, мощный язык запросов (фразовые поиски, подстановочные знаки, отрицание, фильтры по полям), опциональный семантический поиск через пользовательский эмбеддинг-эндпоинт, импорт истории браузера и локальных директорий, а также поддержку нескольких пользователей на одном сервере. Hister распространяется под лицензией AGPLv3, написан на Go с веб-интерфейсом на Vite и Svelte, и доступен через Homebrew, Docker и Nix. Исходный код открыт, сообщество активное в IRC и Discord, а вкладки принимаются через GitHub с соблюдением правил из CONTRIBUTING.md.

Hister эффективно решает проблему поиска по истории браузера и локальным файлам, особенно для устаревших или удалённых страниц, сохраняя офлайн-превью контента. Интеграция с Obsidian, MCP и AI-ассистентами повышает его полезность для поиска по личным знаниям и голосовыми/текстовыми интерфейсами. Чем больше индекс, тем чаще он помогает находить забытые ссылки. Индексация работает надёжно с браузерной истории, закладок и файловой системы, но требует настройки правил исключения для избежания мусора. Hister работает локально и может быть развернут в tailnet (например, Tailscale) для синхронизации между Windows, macOS и Linux. Пользователи отмечают, что локальные LLM для классификации, резюмирования и извлечения рецептов повышают ценность. Рекомендуется ручное добавление значимых страниц через расширение, а не автоматическая индексация всего. Альтернатива — сохранение страниц в PDF для контролируемого архива. Есть сомнения в безопасности бинарных файлов из непроверенных репозиториев. Синхронизация между устройствами вызывает путаницу из-за отсутствия чёткой документации. Интеграция с Linkwarden и Cherry для поиска по закладкам желаема, но не реализована. Hister превосходит устаревшую функцию Chrome 2008 года за счёт семантического поиска, версий и AI-поддержки. По сравнению с Zotero — лучше для повседневного поиска по истории, тогда как Zotero ориентирован на академическую работу. Индексация работает на уровне URL (включая HN и целевые ссылки), решая проблему индексации только текущей страницы.

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