Tongyi DeepResearch — первый полностью открытый веб-агент, демонстрирующий производительность на уровне DeepAI OpenAI. Модель достигает передовых результатов: 32.9 на тесте академического рассуждения Humanity's Last Exam, 43.4 на BrowseComp и 46.7 на BrowseComp-ZH в сложных задачах поиска информации, а также 75 на пользовательском бенчмарке xbench-DeepSearch, превосходя все существующие проприетарные и открытые агенты глубоких исследований. Авторы делятся полной методологией создания таких агентов, включая инновационное решение для синтеза данных на всем конвейере обучения.

В основе обучения лежит Agentic Continual Pre-training (CPT) с использованием системы AgentFounder для масштабного синтеза данных. Разработчики создают цикл данных, перегруппируя различные источники в привязанную к сущностям открытую мировую память знаний. Для сложных вопросов с высокой неопределенностью они синтезируют веб-данные через высокосвязанный граф знаний с помощью случайных обходов. Модель демонстрирует мощные возможности в режиме ReAct без инженерии промптов, а продвинутый Heavy Mode раскрывает верхний предел ее потенциала сложного рассуждения и планирования.

• Обсуждение в основном вращается вокруг трёх тем: «Deep Research» как продукт vs. обычный поиск, практичность мелких моделей, и то, что большие модели всё ещё уступают специализированным инструментам в конкретных задачах.
• Участники обмениваются опытом, что мелкие модели (Qwen 3 4B и т.п.) уже способны обеспечить приемлемое качество при минимальных затратах, особенно если квантовать и/или запустить их на Apple Silicon.
• Обсуждается, что влияние этих моделей на рынок: будут ли они заменять крупные модели в нишевых задачах или же будут использованы как основа для дальнейшей настройки.
• Также поднимается вопрос о том, что, возможно, в будущем мы увидим взрыв специализированных моделей, обученных под конкретные задачи, и что это может быть следующим шагом после исчерпания выгод от предобучения.

Разработчик создал одно и то же мобильное приложение 10 раз на разных фреймворках, чтобы сравнить их производительность. Новые фреймворки (Marko, SolidStart, SvelteKit, Qwik) показывают практически мгновенную загрузку с временем First Contentful Paint в диапазоне 35-39мс, что в 12-13 раз быстрее, чем у Next.js. Реальная разница между лидерами минимальна — все они ощущаются как мгновенные, а ключевым фактором становится размер бандла.

Марко стал чемпионом по размеру бандла, достигая всего 28.8 kB в сжатом виде, что в 6.36 раза меньше, чем у Next.js (176.3 kB). Qwik City использует паттерн "возобновляемости", устраняя традиционную гидратацию и обеспечивая мгновенную интерактивность для крупных клиентских приложений. Автор рекомендует выбирать фреймворки на основе приоритетов проекта, а не микро-разниц в метриках производительности.

• Svelte/SvelteKit и Solid/SolidStart показали наилучшую производительность и удобство разработки, особенно в мобильных условиях.
• React критикуют за фундаментальные проблемы производительности и большие размеры бандлов, несмотря на его популярность.
• Многие разработчики предпочитают использовать знакомые стеки (например, Django/React) вместо поиска "самого быстрого" решения, ценя скорость и комфорт разработки.
• Статья вызвала споры о важности оптимизации для мобильных устройств и критику за игнорирование нативных разработок и PWA.
• Стиль и содержание статьи были раскритикованы как "ChatGPT-slop" за шаблонность и отсутствие глубины.

Несмотря на 15 лет развития фронтенда, сравнение React и Backbone показывает удивительно мало прогресса в снижении сложности. Код для одинаковой функциональности в обеих фреймворках примерно одинаков по длине, что ставит под сомнение все усилия сообщества. React выглядит чище, но это достигается за счет скрытой сложности абстракций, в то время как Backbone предлагает явное, хоть и многословное, описание происходящего.

"Вы торгуете явной простотой за сложность абстракций" — ключевая мысль статьи. React скрывает множество деталей: неожиданное очищение инпутов из-за смены ключей компонентов, бесконечные циклы в useEffect из-за нестабильных зависимостей, "устаревшие" замыкания в обработчиках событий. Эти не крайние случаи, а обычные проблемы, требующие понимания алгоритмов согласования, фаз рендеринга и планировщика React.

Для 99% приложений, не имеющих тысячи компонентов на странице, такая сложность может быть избыточна. Фундаментальная задача "событие + состояние = UI" остается простой, но современные фреймворки создают ненужные абстракции, мешающие пониманию и отладке. Возможно, сообществу стоит искать более прозрачные и "взламываемые" решения, подобные Backbone и jQuery.

• Обсуждение показало, что споры между сторонниками React и Backbone часто сводятся к сравнению простых примеров, что не отражает реальную сложность больших приложений и может вводить в заблуждение.
• Участники подчеркнули, что React и Backbone решают разные задачи: первый предлагает сложную, но мощную систему управления состоянием, тогда как второй предоставляет прямой и прозрачный контроль над DOM.
• Несколько человек отметили, что выбор между инструментами должен зависеть от характера проекта и команды, а не от сравнения "Hello World" примеров.
• Обсуждение также затронуло вопрос о том, что разработчики могут переоценивать или недооценивать сложность, связанную с управлением состоянием, и как это влияет на выбор инструмента.
• Наконец, было высказано мнение, что выбор между React и Backbone должен быть основан на факторах, таких как размер команды, сложность проекта и долгосрочная поддерживаемость, а не на сравнение простых примеров кода.

Библиотеки 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-лицензирована, но коммерческое использование без финансовой поддержки разработчиков может вызвать публичное осуждение.

Пользователь работает с несколькими моделями одновременно, каждая из которых выполняет атомарные коммиты. Основной стек — TypeScript и React, развернутый на Vercel.

Основная идея — использование инструмента codex (предположительно, внутренний инструмент или API) в качестве основного драйвера для разработки. Вместо того чтобы писать код вручную, пользователь использует несколько экземпляров codex (до 8 одновременно), каждый из которых работает над своей частью задачи. Каждый агент коммитит изменения самостоятельно, что позволяет поддерживать чистую историю.

Ключевые моменты:

• Контекст и координация. Несмотря на то, что агенты работают параллельно, пользователь тщательно управляет их работой, чтобы избегать конфликтов. Например, при работе над крупными изменениями он сначала запускает один агент для оценки, а затем уже основную группу.
• Инкрементальный подход. Вместо того чтобы пытаться решить все сразу, пользователь разбивает задачи на мелкие, атомарные шаги. Например, при обновлении зависимостей он не просто запускает скрипт, а сначала проверяет каждое изменение, затем тестирует, и только потом обновляет.
• Отказ от излишеств. Пользователь избегает сложных систем вроде прекоммит-хуков для валидации, так как они замедляют процесс. Вместо этого он полагается на то, что агенты достаточно умны, чтобы не допускать ошибок.
• Практичность. Инструменты выбираются по принципу "работает — не трогай". Например, codex используется вместо Claude Code, потому что последний стал слишком абстрактным (например, он может часами "думать" над простой задачей). codex же просто делает.

В целом, подход напоминает принцип "двигайся быстро и не ломай" (move fast and don't break things), но с уклоном в "двигаться быстро", даже если иногда что-то сломается. Это компенсируется скоростью: один агент может заменить целую команду, и даже если он ошибся, это быстро фиксится.

• Дискуссия разделилась на два лагеря: «AI пишет почти весь код» против «никакой AI не заменит разработчика»; при этом обе стороны сходятся в том, что важно уметь читать и ревьюить весь код, независимо от того, кто его написал.
• Участники обсуждали, что 300k строк кода, которые, как утверждается, были написаны ИИ, на самом деле могут быть просто увеличены в 10-15 раз по сравнению с тем, что написал бы человек, и что это вызывает сомнения в надёжности такого подхода.
• Поднимался вопрос о том, насколько можно доверять ИИ-написанному коду, и какие именно навыки требуются, чтобы эффективно использовать такие инструменты.
• Также обсуждалось, что важно ли вообще писать статьи о таких инструментах, если они не раскрывают, как именно они используются, и какие именно задачи они решают.

Meta и Linux Foundation запустили React Foundation — новый дом для React и React Native. Фонд возьмёт на себя инфраструктуру, конференции и финансирование экосистемы, а техническое руководство останется в руках команды React. Meta вложит $3 млн и инженерную поддержку на 5 лет, чтобы обеспечить плавный переход к независимому управлению.

• React Foundation объявлена как шаг к «децентрализации» React, но участники обсуждения подчеркивают, что фактически Vercel и другие корпорации продолжают контролировать развитие библиотеки, и что это может быть просто маркетинговым ходом.
• Обсуждение затрагивает тревожный факт, что React становится всё более сложным, и что это может отпугнуть новых разработчиков, особенно если учесть, что даже такие базовые вещи как Jest и Create React App были убиты.
• Участники также обсуждают, что влияние Vercel на React может привести к тому, что React становится менее доступным для сообщества, и что это может быть не лучшим путем для такой важной библиотеки.
• Некоторые выразили обеспокоенность тем, что React может быть «захвачен» корпоративными интересами, и что это может быть не лучшим путем для такого важного проекта.

Диалог высмеивает современную тенденцию усложнять разработку на Rails, добавляя множество инструментов вроде Vite, React, TypeScript, Babel, PostCSS, Tailwind, ESLint, Prettier, Husky, Docker и Redis. Всё это оправдывается стремлением к «современности» и скорости, но приводит к громоздкой настройке.

В противовес этому демонстрируется простота «ванильного» Rails: один командой запускается мгновенно работающее приложение с быстрой загрузкой и формами. Ключевая идея — Rails уже содержит всё необходимое, а избыточные инструменты лишь создают сложность без реальной выгоды. Фраза «Просто используй Rails, блин!» резюмирует мысль: не усложняй там, где это не нужно.

• Участники обсуждают растущую сложность современных веб-фреймворков, отмечая, что Rails предлагает более простой и "батарейками включенный" подход по сравнению с перегруженными инструментами JS-экосистемы.
• Многие выражают ностальгию по классическому Rails, критикуя такие новые решения, как Hotwire и Stimulus, за сложность освоения и недостаток документации, в то время как другие защищают их как "путь Rails".
• Поднимается тема чрезмерного усложнения проектов (over-engineering), особенно для небольших команд, где монолитные фреймворки (Rails, Django) часто продуктивнее разделения на фронтенд и бэкенд.
• JS-экосистема подвергается критике за постоянное "изобретение велосипедов", сложность инструментов и модульность, которая приводит к усталости от инструментария, хотя некоторые защищают её гибкость.
• Отмечается, что выбор инструментов должен определяться конкретными задачами проекта, а не модными тенденциями, и что проверенные временем технологии часто эффективнее для небольших и средних приложений.

OpenAI выпустила chatkit-js — JavaScript-библиотеку для создания чат-интерфейсов с поддержкой их моделей ИИ. Она упрощает интеграцию чат-функциональности в веб-приложения, предоставляя готовые компоненты и API для управления диалогами, историей сообщений и реальным взаимодействием с пользователем.

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

• Критика заявленной "независимости от фреймворков" при поддержке только React и отсутствии интеграции с бэкенд-фреймворками
• Опасения по поводу привязки к OpenAI (вендор-локин) и отсутствия поддержки других моделей ИИ (например, Claude)
• Отмечается сходство с существующими решениями (CopilotKit, AG-UI) и их недостатки, включая платность и закрытый исходный код
• Предложения по интеграции ИИ через тегирование в существующие интерфейсы (как в Figma или Google Docs), а не через отдельный чат
• Обсуждение бизнес-модели и необходимости функции "Bring your own subscription" для применения собственных квот и API-ключей

Функциональное программирование принесло во фронтенд мощные абстракции: React с компонентами как функциями от состояния, Redux с предсказуемыми редюсерами и TypeScript для типобезопасности. Однако эти принципы — чистота функций, неизменяемость данных и явные побочные эффекты — вступили в конфликт с природой веба, где DOM мутабелен, CSS каскадируется глобально, а пользовательские события асинхронны и хаотичны. Вместо адаптации к платформе разработчики стали строить слои абстракций, фактически объявляя войну встроенным механизмам браузера.

Это привело к парадоксу: инструменты, созданные для упрощения, добавили сложности, переизобретая роутинг, формы и управление состоянием поверх нативных возможностей. Ценой предсказуемости стала потеря гибкости и производительности, заложенной в вебе десятилетиями. Ключевой вопрос — не отвергать FP-принципы, а искать баланс между их строгостью и адаптивностью платформы, которая по своей сути допускает хаос и мутации.

• Критика излишнего усложнения фронтенд-разработки из-за увлечения функциональным программированием и абстракциями в ущерб простоте и нативным возможностям платформы.
• Споры о читаемости и уместности использования методов массивов (map, filter, reduce) вместо классических циклов, а также о качестве кода на CSS.
• Обсуждение проблем управления состоянием и иерархией данных в UI, включая сравнение React с другими подходами и фреймворками.
• Вопросы к эволюции веб-платформы и стандартов, которые не успевают за потребностями разработчиков и популярными решениями из фреймворков.
• Замечания о качестве статьи-первоисточника: построение на спорных утверждениях (straw man) и продвижение авторской технологии (HTMLX).

Разработчик перевёл свой проект детализированного градостроительного симулятора с Go на Deno, чтобы использовать веб-технологии без потери локальности исполнения. Идея в максимально точной симуляции городских процессов на основе реальных социологических данных, а не упрощённой игровой логики, как в классическом SimCity.

Deno с его встроенным инструментарием и возможностью компиляции в нативный исполняемый файл через webview_deno позволил интегрировать ThreeJS для 3D-вида и React для сложных интерфейсов данных. Это избавило от необходимости использовать Electron и сохранило цели автономности, мультиплеера и кросс-платформенности.

• Критика использования WebView2 из-за негативного восприятия пользователями установки Microsoft Edge и предложения альтернатив, таких как Tauri или локальные веб-приложения.
• Обсуждение технических подходов к созданию игр с использованием веб-технологий (Deno, Bun, WebGPU, React) и сравнение их производительности с традиционными движками вроде Unity.
• Вопросы о целесообразности и практичности выбора Deno в качестве основы для игрового движка, а не просто рантайма.
• Положительные отзывы о образовательной и градостроительной ценности игры, а также предложения по доработке механик и открытию исходного кода.
• Обсуждение бизнес-моделей и коммерческого потенциала инди-игр, созданных как "труд любви", в противовес стремлению к прибыли.

• Разработчики ищут удалённую работу, многие открыты к релокации, предпочитают гибридный формат или готовы к редким командировкам.
• Основные технологические стеки включают Python, JavaScript/TypeScript, React, Node.js, облачные платформы (AWS, GCP) и контейнеризацию (Docker, Kubernetes).
• Специализации варьируются от full-stack, data engineering и машинного обучения до дизайна продуктов и UX/UI.
• Ключевые интересы: работа с LLM, AI-агентами, компьютерным зрением, распределёнными системами и дизайн-системами.
• Многие кандидаты имеют опыт более 10 лет, опыт построения масштабируемых продуктов и решения сложных бизнес-задач.

tldraw SDK 4.0 introduces major updates for developers building interactive whiteboards in React, focusing on accessibility, licensing, and new starter kits. The release includes a CLI tool for quick project setup and four MIT-licensed starter kits tailored for AI chatbots, workflow tools, branching chats, and multiplayer apps, making it easier to prototype canvas-based applications.

Significant improvements include WCAG 2.2 AA compliance for accessibility, benefiting all users, and a new licensing model requiring keys for production use—though free 100-day trials are available. The project has seen substantial growth, with 40,000 GitHub stars and 70,000 weekly installs, reflecting its expanding community and practical utility.

• Пользователи выражают обеспокоенность новой моделью лицензирования и высокими ценами на коммерческое использование tldraw (от $500/мес до $6K/год).
• Критикуется короткий 90-дневный пробный период и отсутствие гибких тарифов для малого бизнеса, стартапов и хобби-проектов.
• Отмечается, что некоторые ключевые функции (например, несколько страниц на холсте) стали платными, что расценивается как движение в сторону централизации.
• Разработчики tldraw объясняют изменения необходимостью сделать проект устойчивым и коммерчески жизнеспособным.
• Обсуждаются технические аспекты: сравнение с Excalidraw и React Flow, поддержка iPad, обратная совместимость с версией 3.x.
• Высказываются предположения, что новая ценовая политика нацелена на хорошо финансируемые компании, особенно в сфере ИИ.
• Часть сообщества рассматривает переход на альтернативы или форки проекта из-за недовольства лицензией.

Разработчики часто тяготеют к сложности, хотя принцип KISS («будь проще») хорошо известен. Почему так происходит?

Маркетинг важнее простоты

Продать обычную ручку сложно, но если добавить ей множество функций — она станет «продаваемой». Так и в IT: простые инструменты вроде cat работают идеально, но маркетинг продвигает сложные аналоги с громкими названиями. Социальное доказательство и ощущение эксклюзивности заставляют нас воспринимать сложность как признак качества, хотя часто это просто иллюзия.

Что внутри «пирамид»?

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

React против ванильного JavaScript

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

Глубинные причины любви к сложности

1. Творческий соблазн: Создание сложных систем — интеллектуальный вызов, который приносит удовлетворение.
2. Технический долг: Наследие старых проектов вынуждает добавлять новые слои вместо упрощения.
3. Командная динамика: Разработчики добавляют абстракции для «универсальности», что усложняет систему.
4. Давление инноваций: Конкуренция подталкивает к созданию сложных решений, чтобы выделиться.

Стройте с умом

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

• Сложность часто возникает из-за добавления быстрых исправлений вместо переосмысления архитектуры с учетом новых требований.
• Простые решения требуют больше усилий для проектирования и поддержки, чем сложные, которые появляются быстрее.
• Реальность полна деталей, и простые решения редко охватывают всю сложность проблемы, что ведет к наращиванию сложности системы.
• Разработчики могут добавлять сложность для демонстрации навыков, интереса или ощущения достижения, что поощряется в индустрии.
• Долгоживущие кодобазы неизбежно накапливают сложность из-за постоянных изменений и адаптации к новым требованиям.
• Простота субъективна и требует глубокого понимания основ и дисциплины для достижения и поддержания.
• Бизнес-среда и отсутствие прямого контакта с пользователем могут способствовать выбору сложных решений вместо фокуса на ценности.
• Сложность иногда искусственно создается для обеспечения job security или из-за организационных проблем и политик.
• Эволюция технологий и библиотек часто следует за обобщением паттернов, что добавляет абстракции и сложности.

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

Dopeloop.ai — онлайн-барабанная машина для быстрого создания битов.
16 кнопок = 16 шагов. Жми, слышишь — сохраняй.
Библиотека сэмплов: хип-хоп, трап, хаус, драм-н-бейс.
Регулируй темп и громкость, мутируй треки в один клик.
Экспорт WAV или ссылка для шеринга.
Без установки, бесплатно, работает в браузере.

• Движок построен на декларативном аудио-графе (virtual-audio-graph), упрощающем Web Audio API; советуют дополнительно глянуть AudioWorklet.
• UX: кнопку Play просят сделать заметнее, добавить подсветку каждой четвёртой колонки и переключатель цвета фона под n-е доли.
• При генерации нового сэмпла во время воспроизведения нужен «тихий» режим замены, чтобы не сбивать ритм.
• Просят слайдер «вариативности» и возможность задавать нестандартные размеры тактов (например, 2-2-2-3).
• FX хотят, чтобы эффект оставался включённым и копировался в новые ячейки до ручного выключения.
• Интерфейс сделан на ClojureScript (через Reagent/React), код части аудио-утилит выложен: chr15m/cljs-dopeloop.

Reshaped стал полностью открытым

Пять лет назад я создал Reshaped — библиотеку компонентов для React и Figma, чтобы покрыть 80% типовых задач и оставить 20% на кастомизацию. Сделал её платной, чтобы углубленно поддерживать небольшое сообщество.

Два года назад React-пакет стал бесплатным. Сегодня открываю исходники всего:
React и Figma теперь в открытом доступе.

Что дальше:

• Базовая библиотека будет расти; лицензиаты продолжат получать обновления.
• Планирую премиум-компоненты сложной логики поверх ядра.

Прыжок в open-source после 5 лет закрытой разработки — пора отдать сообществу.

• Пользователи хвалят Reshaped за чистый код и бесплатную библиотеку, но жалуются на подвисание вкладок документации и задержки при навигации.
• Автор (blvdmitry) признал проблемы со скоростью сайта: сервер рендерит статику ~500 мс, обещает перевести документацию на статический экспорт.
• Некоторые просят улучшить микро-анимации и accessibility; автор собирает примеры и уже работает над новыми компонентами.
• Библиотека стала полностью бесплатной и open-source после 5 лет продаж; ядро React и Figma останутся бесплатными, премиум-компоненты возможны позже.
• Упоминаются мелкие баги: backspace в автокомплите, ссылка «Getting started» вела в changelog — уже пофикшено или в процессе.

Tailguard — Docker-контейнер, связывающий Tailscale и WireGuard.

• Поднимается одной командой, не требует root.
• Перенаправляет трафик Tailscale → WireGuard и обратно.
• Подходит для «проброса» Tailscale в сети, где нативный клиент не ставится.

• TailGuard — это контейнер, который автоматически берёт конфиг WireGuard и объявляет подсети из туннеля как Tailscale-subnet-router; остальному tailnet они сразу доступны.
• Проект начинался с «пары строк», но пришлось добавить переподключение при смене IP, DNS-ротацию и лёгкий React-UI; всё упаковано в Go-сервис + контейнер.
• Решение работает и с fly.io: вместо camellia.conf на клиенте поднимают TailGuard-контейнер рядом с их WireGuard-шлюзом и получают приватную сеть fly внутри Tailscale.
• На Android единовременно можно только один VPN, поэтому TailGuard удобнее «двойных» подключений; на iOS/WG-официальном клиенте можно выборочно маршрутизировать.
• Альтернатива — готовые 5G-роутеры GL.iNet (IMEI-клон, встроенный Tailscale/WireGuard), но у автора был опыт с TP-Link Deco X50-5G и он его «не особо рекомендует».

Next.js выводит из себя

Наконец-то написал пост: злость лучший мотиватор.
В $COMPANY упал сервис на Next.js, а логов в проде нет. Задача — добавить логирование.

Middleware
Дока обещает: «Middleware выполняется до рендера, удобно для логов».
Пробуем pino + AsyncLocalStorage:

// middleware.ts
export async function middleware(req: NextRequest) {
  LoggerStorage.enterWith(requestLogger());
  logger()?.debug({ url: req.url }, "start");
  return NextResponse.next();
}

Запускаем — логи летят в браузер. Почему? Runtime по умолчанию edge. Меняем на nodejs — в новом проекте работает, в боевом нет.

Страницы и layouts
Пишем в компоненте:

logger()?.info("from page");

Тишина. logger() возвращает null: рендер и middleware живут в разных async-контекстах.

Решение
Передаём requestId через заголовки:

// middleware.ts
const id = crypto.randomUUID();
loggerInstance.child({ requestId: id }).debug("start");
return NextResponse.next({ headers: { "x-request-id": id } });

// page.tsx
const id = headers().get("x-request-id");
loggerInstance.child({ requestId: id }).info("from page");

Итог: чтобы просто логировать, нужно городить костыли через заголовки.

• Пользователи жалуются на игнорирование сотен старых issue, перегруженность абстракциями и постоянные «канареечные» решения, которые не доходят до продакшена.
• Сообщество считает Next.js «самой худшей» технологией: сложно понять, где выполняется код, нельзя цепочкой middleware, а апи-шлюзы выглядят «как будто их писали выпускники буткемпа».
• Разработчики предлагают уходить на Remix, React Router v7, Nuxt, SolidStart, Deno Fresh или даже «чистый HTML/CSS» ради простоты и контроля.
• Представитель Vercel признаёт DX-проблемы и обещает улучшения, но многие уже мигрируют на Vite или Django/Rails/Phoenix.

• 20+ специалистов из 4 континентов ищут удалённую работу; большинство — full-stack, DevOps, ML/AI и мобильные разработчики.
• Регионы: США (Austin, SF, NYC, Florida), Латинская Америка (Буэнос-Айрес, Богота, Медельин), Европа (Лондон, Осло, Хорватия), Азия (Бангкок, Ханой), Африка (Лагос) и др.
• Ключевые стеки: Rust/Go/Python, React/Node, AWS/GCP, Docker/K8s, LLM/AI-инструменты, iOS/Android, а также редкие — DSP, C++, embedded.
• Готовность к релокации: ~30 % «да», ~60 % «только удалённо», остальные — «возможно при убедительном предложении».
• Уровни: от стажёров и new-grad до 20-летних ветеранов и CTO; многие предоставляют портфолио и рекомендательные письма.

Современный веб без 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 в Safari работает крайне медленно.
Описание: Страницы грузятся по 5–10 сек, анимации подвисают, прокрутка «рыхлая». В Chrome и Firefox всё нормально.

Версии:

• Safari 17.5 (macOS 14.5)
• Safari 16.6 (macOS 13.6) – та же картина

Что пробовали:

• Очистить кэш и куки
• Отключить все расширения
• Переключить DNS (Cloudflare, Google)
• Сменить сеть (домашний Wi-Fi, мобильный интернет)
• Включить/выключить «Разработка → Использовать WebKit Nightly»

Результат: ничего не помогло.

Симптомы:

• В Activity Monitor процесс «Safari Web Content» грузит CPU до 100 % при открытии любой страницы GitHub.
• В инструментах разработчика видно, что 80 % времени уходит на «Rendering».

Временное решение:

• Переключиться на Chrome/Firefox.

Просьба: Проверьте, не сломали ли вы что-то в CSS/JS для WebKit.

• GitHub стал критически медленным: Safari и Firefox тормозят даже на мощных М-системах, а большие PR (>1000 файлов) почти не открываются.
• Пользователи связывают падение производительности с переходом на React/SPA после покупки Microsoft и отказом от старого SSR.
• Предлагают мигрировать на Forgejo, Codeberg, SourceHut или возвращаться к простому HTML/CSS.
• Вопрошают, как в крупной компании могут пропустить такую регрессию и почему тесты не ловят разницу между Chrome и Safari.
• Ситуация повторяется и на других сайтах (Jira, Stripe, GCP), вызывая разговоры о «блоте» современных веб-приложений.

Суть проблемы
В npm-реестр попали вредоносные версии пакетов Nx и связанных плагинов. Злоумышленники использовали временный доступ к npm-аккаунту @nxscope и опубликовали поддельные версии 19.8.0–19.8.2.

Затронутые пакеты

• nx
• @nx/angular, @nx/cypress, @nx/detox, @nx/devkit, @nx/esbuild, @nx/eslint-plugin, @nx/expo, @nx/express, @nx/jest, @nx/js, @nx/nest, @nx/next, @nx/node, @nx/playwright, @nx/plugin, @nx/react, @nx/rollup, @nx/storybook, @nx/vite, @nx/web, @nx/webpack, @nx/workspace

Что делать

1. Удалить вредоносные версии.
2. Установить официальные 19.8.3 или выше.
3. Проверить lock-файлы и CI на наличие подозрительных версий.

• Уязвимость в пакетах Nx: токен npm скомпрометирован, злоумышленники внедрили вредоносный код через post-install скрипты.
• Малварь ищет Claude Code / Gemini CLI и использует их как «живые» инструменты для поиска криптокошельков, ключей и других секретов.
• Участники советуют отключать npm-скрипты (ignore-scripts true), использовать Bun (по умолчанию не запускает скрипты), Verdaccio для вендоринга и инструмент vet для сканирования.
• Рекомендуют разрабатывать в изолированных контейнерах/VM (cubbi, bubblewrap, firejail) и пересматривать каждую зависимость вместо «npm install наугад».
• Основной вывод: современные цепочки поставок и AI-агенты создают новый вектор атак «prompt-as-malware», а операционные системы всё ещё позволяют приложениям свободно читать весь диск.

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

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

Создал две карточные игры на Go: без LLM — 3 месяца, с LLM — 3 дня

Truco без LLM (3 месяца)

• Начал 18 июня 2024, выбрал Truco — любимая игра детства.
• Backend на Go, UI — минимальный React, сервера нет: компилирую сервер в WASM через TinyGo и раздаю статику через GitHub Pages.
• Без LLM пришлось всё выяснять вручную: 3 месяца экспериментов.
• Игра живёт без рекламы и денег, но люди всё ещё играют.

Escoba с LLM (3 дня)

• Через год решил проверить, как LLM ускорит процесс.
• Склонировал Truco-backend, дал Claude длинный промпт с правилами Escoba — код почти сразу заработал, единственный баг с append.
• Frontend всё равно занял несколько дней: React + WASM-отладка.

Как повторить

1. Backend
   • Структура GameState, CalculatePossibleActions, RunAction, бот.
   • Компилируй в WASM: tinygo build -o main.wasm -target wasm .
2. Frontend
   • Создай игру, отрендери состояние, дай игроку выбрать действие, вызови бота.
3. Шаблоны
   • Форкни Tic-Tac-Toe:
     backend | frontend
   • Демо: играть

• Основной тезис: «написание кода никогда не было узким местом» вызвал споры; кто-то считает, что сложная механика, баланс и полировка требуют больше времени, другие — что код всё же тормоз.
• Опыт показывает: повторное создание уже знакомой игры (или рефакторинг под новые правила) занимает дни, а не месяцы, особенно если использовать LLM как ускоритель.
• Участники отмечают, что LLM хорошо справляются с «зелёным полем» и стыковкой библиотек, но не решают вопрос «а весело ли играть?» — это всё ещё требует живых тестеров и дизайнерской интуиции.
• Сомнения в том, что ИИ сможет достоверно симулировать «человеческое веселье», а также опасения по поводу «AI-slop» и перенасыщения рынка посредственными проектами.

D3 кажется многословным, потому что каждая деталь визуализации описывается вручную.
Чтобы нарисовать простой boxplot, потребовалось 194 строки: указываются координаты каждой линии, прямоугольника, осей и подписей. В Excel это делается парой кликов, но D3 не «волшебная кнопка», а низкоуровневый инструмент для SVG.

Плюс такого подхода — абсолютная гибкость: можно создать любую визуализацию, не ограниченную шаблонами. Минусы — много кода и крутая кривая обучения.
Пока я учусь, пишу «вручную», чтобы не пропустить детали; позже код можно сжать собственными функциями или компонентами.

Итог: D3 длинный, потому что даёт полный контроль над каждым пикселем.

• D3 — это не «библиотека для графиков», а низкоуровневый инструмент для связывания данных с DOM/SVG через .data().enter/update/exit, что даёт максимальную гибкость, но требует особой ментальной модели.
• Из-за этого код получается многословным; кто-то считает это читаемостью и «мышечной памятью», кто-то — непреодолимым барьером.
• Чтобы уменьшить многословность, часть людей берёт лишь вычислительную часть D3 и рендерит через Solid/JSX, React или Observable Plot.
• Некоторые напоминают: если нужны только статические графики, можно обойтись вообще без JS, а для сложных анимаций и «не-стандартных» визуализаций D3 остаётся почти незаменимым.

Основы

• Определите цель: чётко сформулируйте задачу перед генерацией кода.
• Начинайте с README: описание проекта помогает ИИ и команде.
• Используйте шаблоны: готовые структуры (FastAPI, React) экономят время.

Промпты

• Контекст: указывайте язык, фреймворк, стиль (PEP8, camelCase).
• Мелкие задачи: дробите фичи на куски по 50–100 строк.
• Примеры: прикладывайте JSON-ответы или SQL-запросы.
• Итерации: улучшайте код по одному аспекту за раз.

Рабочий процесс

• Сессии: 30-минутные циклы «запрос-ревью-запуск».
• Git-коммиты после каждого шага для отката.
• Линтеры/тесты сразу: pytest, eslint, mypy.
• Code Review: проверяйте всё, даже «очевидное».

Инструменты

• Copilot Chat в IDE для быстрых правок.
• Cursor / Windsurf для многофайлового рефакторинга.
• Playwright для e2e-спек, сгенерированных из текста.
• Docker для воспроизводимого окружения.

Качество

• Типы: добавляйте аннотации (TypedDict, Pydantic).
• Док-строки: пишите для всех публичных функций.
• Тесты: покрывайте критические пути ≥80 %.
• Логи: структурированные (structlog) для отладки.

Безопасность

• Секреты: проверяйте .env и git history.
• OWASP Top 10: сканируйте зависимости (pip-audit, npm audit).
• RBAC: реализуйте роли и разрешения сразу.

Производительность

• Профилирование: cProfile, py-spy для горячих точек.
• Кеш: Redis для частых запросов.
• CDN для статики фронтенда.

Деплой

• CI/CD: GitHub Actions → Docker → ECS/Fargate.
• Feature flags для постепенного релиза.
• Мониторинг: CloudWatch + Grafana.

Советы

• Не доверяйте 100 %: всегда читайте сгенерированный код.
• Учитесь у ИИ: спрашивайте «почему так» для роста навыков.

• Подавляющее большинство участников считает «vibe-coding» либо вредным, либо вообще не тем, что описано в документе.
• Настоящий vibe-coding — это «не смотреть код, а принимать результат, если визуально работает»; любые советы «тщательно читайте код» противоречат самому термину.
• Многие предпочитают писать чёткие спецификации и использовать LLM как «парного программиста», но подчёркивают, что это уже не «vibe», а обычная работа с AI.
• Частый риск — накопление непонятного, неотрефакторенного кода и «отравление» контекста при изменении требований.
• Итоговый совет большинства: «Don’t go full vibe» — даже при активном использовании LLM нужно понимать и контролировать результат.

open-lovable — утилита от mendableai, клонирует любой сайт и превращает его в современное React-приложение за секунды.

Репозиторий публичный, доступен на GitHub.

• Проект называется «open-lovable», но не является ни клоном, ни открытой версией Lovable; требует внешние API-ключи (Firecrawl, e2b.dev) и не работает локально без них.
• Участники спорят о допустимости имени, считая его потенциальным нарушением товарного знака и маркетинговым «рост-хаком».
• Основная критика: жёсткая завязка на Firecrawl для скрапинга и отсутствие полностью FOSS-варианта всей цепочки.
• Предлагают альтернативы — bolt.diy, Modal, Daytona, freestyle.sh — и способы самостоятельно развернуть e2b/Firecracker.
• Некоторые хотели бы обратную задачу: превращение React-приложений в «нормальные» сайты без JS или в нативные веб-приложения.

Системный промпт GPT-5 (сокращённо)

Ты ChatGPT на базе GPT-5, обучён OpenAI. Знания до июня 2024 г.
Поддержка изображений: включена. Личность: v2.
Не цитируй тексты песен и защищённые материалы.
Стиль: проницательный, вдохновляющий, с ясностью, энтузиазмом и лёгким юмором.
Не заканчивай вопросами о продолжении; не предлагай «хотите, чтобы я…».
Очевидный следующий шаг — делай сразу.

Доступны: Deep Research, Sora (видео) в Plus/Pro.
GPT-4.5, o3, o4-mini — для залогиненных Plus/Pro.
GPT-4.1 только в API.

---

Инструмент bio (память)

Позволяет сохранять/удалять данные между диалогами.
Пиши to=bio только plain text, без JSON.
Примеры:

• «User любит краткие подтверждения».
• «Forget что пользователь ищет духовку».

Когда использовать:

• Пользователь просит «запомнить», «забудь», «добавь в память» и т.п.
• Делай это всегда, даже если факт мелкий.
• Перед фразами вроде «понял, запомню» — сначала вызови bio.

Когда не использовать:

• Случайные, чрезмерно личные или краткосрочные детали.
• Не сохраняй чувствительные данные (раса, религия, здоровье, политика и т.д.), если пользователь явно не попросил.

• Участники сомневаются в подлинности «слившегося» системного промпта GPT-5: нет подтверждения, он слишком короткий и выглядит как результат джейлбрейка.
• Промпт перегружен мелкими тех-инструкциями: React + Tailwind, запрет JSON в to=bio, шрифты Unicode для CJK, но не упоминает CSAM, порнографию и т. д.
• Люди удивлены, что React получил отдельный блок, а не Python или другие языки.
• Обнаружены явные ошибки: «korean -->» вместо «japanese -->» и противоречивые описания моделей.
• Общий вывод: похоже на набор «заплаток», а не полный системный промпт; управление поведением модели всё ещё требует prompt-инженерии, а не только fine-tuning.

Дебаунс — это техника ограничения частоты вызова функции. В течение заданной задержки все входящие вызовы игнорируются, а выполняется только один — либо первый (leading), либо последний (trailing), в зависимости от настроек. Это помогает оптимизировать производительность и избежать лишних вычислений при частых событиях.

Применение:

• Обработчики ввода: ждать паузы перед запросом автодополнения.
• События прокрутки/изменения размера: запускать вычисления после остановки действий пользователя.
• Клики и сабмиты: предотвращать множественные отправки.

Отличие от троттлинга: троттлинг гарантирует вызовы с фиксированным интервалом, а дебаунс — один вызов после серии событий (или сразу первый, если включен leading).

Ключевые параметры:

• delay: время ожидания.
• leading/trailing: когда вызывать — в начале или в конце паузы.
• maxWait (если предусмотрено): гарантирует вызов, даже если события не прекращаются.

• Обсуждение вращается вокруг корректности термина «debounce» в UI/FE-разработке и аналогии с электронным дебаунсом; часть участников считает аналогию неточной, другие — уместной как метафору, предлагая альтернативы: coalescing, edge detection, latch, request coalescing.
• Предупреждение: дебаунс/троттлинг с async-функциями может вести к неожиданному поведению (например, возврат предыдущего Promise); контраргумент — обычные async всегда возвращают новый Promise, проблемы чаще у мемоизации.
• Практика и инструменты: предлагают использовать AbortController для «debounced fetch», реактивные подходы (RxJS switchMap), а также отмечают, что ResizeObserver и события типа scrollend иногда снимают необходимость дебаунса.
• В бэкенде и других языках: в Java нет стандартной гибкой безопасной реализации дебаунса; в Kotlin помогают примитивы структурированной конкуррентности.
• Примеры применения/антипримеров: авто-сохранение по вводу, предотвращение многократных кликов; спор о поиске «на каждый ввод» как неудачном UX-примере.
• Технические нюансы из электроники: асимметричный дебаунс (быстрый «make», задержанный «break»), гистерезис через разные пороги, ссылки на материалы по контактному дребезгу.
• Метадискуссия: популярность темы в интервью, критика «модных терминов» во фронтенде и обсуждение ценности постов/ссылок.

As a Queenslander now living in the UK, seeing Bluey for the first time filled me with homesickness in a way that no other media has.Despite the huge media industry in SEQ, it's so rare to see it actually represented as itself (rather than dressed up as Manhattan, eg). I also rem