• Apple удалила репозиторий, что вызвало обсуждение о том, что Apple использует Svelte для своих веб-интерфейсов, и что это может быть связано с тем, что Apple не хочет, чтобы их код был доступен.
• Участники обсуждения также обсуждали, что Apple не использует свои собственные фреймворки, такие как SproutCore, и что это может быть связано с тем, что Apple не хочет, чтобы их код был доступен.
• Также обсуждалось, что Apple не использует свои собственные фреймворки, такие как SproutCore, и что это может быть связано с тем, что Apple не хочет, чтобы их код был доступен.
• Участники обсуждения также обсуждали, что Apple не использует свои собственные фреймворки, такие как SproutCore, и что это может быть связано с тем, что Apple не хочет, чтобы их код был доступен.

Библиотеки React Flow и Svelte Flow представляют собой мощные open-source решения для создания интерфейсов на основе узлов. Они готовы к использованию сразу после установки и при этом предлагают практически безграничные возможности кастомизации. React Flow интегрируется с экосистемой React, а Svelte Flow - с фреймворком Svelte, предоставляя разработчикам гибкий выбор технологии для реализации визуальных редакторов, диаграмм и других node-based интерфейсов.

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

• React Flow и Svelte Flow — мощные, но гибкие библиотеки для построения node-based UI, активно развиваются и имеют обширную экосистему примеров и документации.
• Пользователи отмечают простоту интеграции, готовность кастомизировать ноды и рёбра, а также активную поддержку сообщества.
• Некоторые упоминают отсутствие React Native и Svelte Native поддержки, но при этом отмечают, что можно обернуть в WebView и использовать в мобильных приложениях.
• Пользователи делятся примерами своих проектов, включая IaC-конструктор, визуализатор GitHub Actions, генератор диаграмм организационной структуры и т.д.
• Библиотека MIT-лицензирована, но коммерческое использование без финансовой поддержки разработчиков может вызвать публичное осуждение.

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

Эффект фольги в Three.js
Создаём шейдер, имитирующий голографическую наклейку: угловая иризация + блёстки.

Иризация

Цвет меняется с углом обзора: отражённый вектор → HSL-оттенок, имитируем тонкоплёночную интерференцию.

Блёстки

Процедурный шум (2D-случайные точки) даёт блестящие частицы, которые мигают при движении камеры.

Реализация

PBR-параметры используются как художественный приём, а не физика.

Вершинный шейдер

uniform float uPeelAmount, uPeelAngle;
varying vec2 vUv; varying vec3 vWorldPos, vNormal; varying float vAOIntensity;

void main() {
    vUv = vec2(uv.x, 1.0 - uv.y);
    vec3 pos = position, hinge = vec3(0);
    vec3 toVertex = pos - hinge;
    float peelFactor = (uv.x + uv.y) * 0.5;
    float angle = radians(uPeelAngle) * uPeelAmount * peelFactor;
    vec3 axis = normalize(vec3(cos(radians(uPeelAngle + 90.)), sin(radians(uPeelAngle + 90.)), 0));
    float c = cos(angle), s = sin(angle);
    pos = pos * c + cross(axis, pos) * s + axis * dot(axis, pos) * (1.0 - c);
    vNormal = normalize(normalMatrix * (normal * c + cross(axis, normal) * s + axis * dot(axis, normal) * (1.0 - c)));
    vAOIntensity = peelFactor * uPeelAmount;
    vWorldPos = (modelMatrix * vec4(pos, 1.0)).xyz;
    gl_Position = projectionMatrix * modelViewMatrix * vec4(pos, 1.0);
}

Фрагментный шейдер

uniform vec3 uBaseColor, uLightDir;
uniform float uMetalness, uRoughness, uFoilScale, uFlakeDensity, uFlakeSize;
varying vec2 vUv; varying vec3 vWorldPos, vNormal; varying float vAOIntensity;

float hash(vec2 p) { return fract(sin(dot(p, vec2(12.9898, 78.233))) * 43758.5453); }
vec3 hueShift(vec3 c, float h) { return c * cos(h) + vec3(-.14861, 1.78277, -.29227) * sin(h); }

void main() {
    vec3 N = normalize(vNormal), V = normalize(cameraPosition - vWorldPos);
    float NdotV = max(dot(N, V), 0.0);
    float fresnel = pow(1.0 - NdotV, 4.0);

    vec2 uv = vUv * uFoilScale;
    float flake = smoothstep(1.0 - uFlakeSize, 1.0, hash(floor(uv * uFlakeDensity)) * hash(floor(uv * uFlakeDensity * 10.0)));
    vec3 iridescence = hueShift(uBaseColor, NdotV * 6.28318);

    vec3 color = mix(uBaseColor, iridescence, fresnel) + vec3(flake) * uMetalness;
    color *= 1.0 - vAOIntensity * 0.5;

    gl_FragColor = vec4(color, 1.0);
}

Лицензия

MIT.

• Участники делятся ссылками на похожие шейдер-эффекты: физически корректный металл, голографический «golden ticket» в Threads и Pokémon-CSS.
• Разработчики обсуждают, как встроить разнообразные фольг-эффекты MTG-карт в Svelte-приложение без потери производительности.
• Несколько человек вспоминают, что iOS-стикеры и старые мобильные игры уже используют ориентацию телефона для «блеска» 3D-объектов.
• Поднимаются технические детали: шум, воронои, лицензии (CC BY-NC), Shadertoy как песочница.
• Некоторые критикуют перегрузку «блёстками» и опасаются, что ИИ «вымоет» авторство и лицензии.

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

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

Иллюзия мастерства

Claude выдал прекрасные Go-тесты — и бесполезные: все сводились к true == true.
ИИ дарит облик мастерства без труда. Код выглядит правильно, поэтому легко пролистать детали.

Я не ленюсь, просто использую инструмент. Claude пишет Go, SQL, Svelte, знает сигнатуры API — кажется, что boilerplate решён. Но когда я отлаживал фронтенд, понадобилось 40 минут чтения документации, чтобы заметить, что он смешал синтаксис Svelte 4 и 5. Я проглядел, пока не проследил вручную.

ИИ продвинул меня, но не избавил от работы. Настоящее мастерство — это модель в голове и собственное мышление. Убедительный синтаксис ≠ понимание.

Ловушка

Мы, разработчики, стараемся делать хорошо, и именно поэтому опасна эта иллюзия: ИИ заставляет расслабиться и верить, что результат будет отличным без усилий.

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

Сначала ИИ облегчает работу, но уже через пару дней видно: он не несёт когнитивную нагрузку. Финальный рывок остаётся за нами, а поднять «положенное» бремя тяжело.

Требуется усилие

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

• Опытные разработчики подчеркивают: без контроля и понимания архитектуры AI-помощь превращается в «красивый, но бесполезный» код.
• Многие замечают, что младшие коллеги перестают думать, слепо принимая сгенерированные тесты и решения.
• AI хорош для рутины, но требует «copilot», а не «main pilot»: человек должен оставаться капитаном.
• Сравнение с IKEA-шкафами: большинство проектов станут «фабричными», но сложные и критичные системы всё равно останутся ручной работой.
• Итог: навыки критического мышения и рефакторинга «AI-слякоти» станут новой ценностью.