Социальная сеть для разработчиков под названием /dev/null строится вокруг коммитов вместо постов: вход только через GitHub, а сообщения — это простой текст до 4000 символов. Лента работает без алгоритмов, строго по времени публикации, а профили полностью повторяют данные GitHub и редактируются там же. Первые коммиты проходят ручную модерацию, после чего автоматический модератор проверяет и одобряет их сам.

Тон площадки — шутливый и «свой»: в трендах шутки про Laravel, команды вроде php artisan make:friends и composer require followers, а также жалобы на внезапную нагрузку («нужно масштабировать сервер», «они деплоят прямо с телефона, помогите»). Упоминаются разработчики Нуну Мадуру и Николя Грекас, а число пользователей предлагают оценивать по счётчику подписок одного из участников. Есть и опрос о кроссплатформенной разработке с вариантами React Native, Flutter, SuperNative (NativePHP) и Kotlin Multiplatform. Всё остальное, по ироничному девизу проекта, уходит в /dev/null.

Сообщество разработчиков скептически относится к /dev/null. Обязательный вход через GitHub считается ограничением аудитории и связью с Microsoft, противоречащей идее независимой соцсети. Модерация постов (ручная проверка первых коммитов, затем автоматическая) вызывает опасения по поводу задержек и цензуры. Заявленные новшества воспринимаются как переупаковка существующих решений вроде Mastodon и Solid, без значимых отличий от других соцсетей для разработчиков. Технические проблемы: непонятный выбор домена (dev-null.sh), простои, отсутствие ясности о стеке технологий. Предложения: добавить публичный просмотр ленты и подробную информацию о платформе до регистрации, улучшить онбординг и визуальные метафоры (git‐аналогии, подсказки). Отмечается плюс: открытый исходный код и быстрый отклик сообщества — более 200 pull‐request'ов за 48 часов. Спор о будущем: некоторые видят в /dev/null потенциал для децентрализованного обмена файлами (сравнение с Solid), другие считают его обычным хостингом с альтернативами вроде tilde.town.

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

Масштаб проблемы шире одного человека: шестеро или семеро знакомых из группы по «DevOps» потеряли работу или получили уведомление за последний месяц, включая сотрудника одной из FAANG-компаний, которому выдали шесть месяцев выходного пособия и уничтожили личные вещи. Другой нанимающий менеджер лишился должности через неделю после того, как генеральный директор запоздало опубликовал статью о том, что «ИИ меняет разработку». Автор подчёркивает: корректнее говорить не «ИИ забрал мою работу», а «ИИ поспособствовал упразднению моей роли».

При этом модели, по его мнению, всё ещё не заменяют опытного инженера: им не хватает вкуса в продуктовых решениях и предвидения последствий — роста издержек, сложности, доступности. Но они уже достаточно хороши, чтобы под присмотром переносить проверенное поведение между платформами: «Shopify» переписал приложение с «React Native» на нативный код, а порт «TypeScript» на «Rust» воспроизвёл даже исходные баги. В итоге модели не заменили людей — они убедили тех, у кого есть деньги, тратить их иначе.

Тред подтверждает, что компании увольняют инженеров ради экономии, заменяя их дешевыми подписками на AI-модели (например, Fable), или используют ИИ как предлог для сокращений ради краткосрочной прибыли (@glimshe, @philipodonnell). Это напоминает прошлый опыт замены сотрудников дешевым аутсорсингом (@voidifremoved, @TrackerFF). Мнения о возможностях LLM разделились. @gregwebs и @echelon считают, что модели уже способны генерировать готовый код, поэтому роль инженера трансформируется в техническое руководство и управление ИИ. Другие (@dofm, @TrisEck) уверены, что моделям не хватает вкуса и продуктового чувства. @jdw64 приводит пример приложения на моделях Astra и Fable, которое оказалось полно багов, что доказывает невозможность полной замены квалифицированного программиста. Пострадавшим инженерам советуют создавать собственные проекты с помощью тех же моделей для сохранения дохода (@laylower), а также относиться к работе как к средству, а не центру жизни (@sajithdilshan, @danw1979).

Shopify переходит обратно на нативную разработку мобильных приложений после пяти лет успешного использования React Native. В 2020 году выбор фреймворка был обусловлен необходимостью избегать дублирования функций, расширить круг разработчиков и снизить затраты на поддержание паритета между iOS и Android. Эти преимущества реализовались: команда экономила время, привлекала специалистов без мобильного опыта и сосредотачивалась на доставке ценности. Однако к концу 2025 года фундаментальное предположение о стоимости дублирования труда изменилось благодаря прогрессу больших языковых моделей (LLM). Shopify начал использовать ИИ с 2021 года, и к 2025-м агенты стали способны не только ускорять написание кода, но и выполнять перевод функций между платформами, помогать в наboardingе разработчиков и обеспечивать проверку кода и тестов на основе общих спецификаций. Это снизило нагрузку по поддержанию паритета до уровня, когда нативная разработка перестала быть непрактичной.

Теперь Shopify считает, что преимущества нативной разработки — близость к платформенным возможностям, доступ к первым-party инструментам и меньшее количество абстракционных слоёв — вновь перевешивают выгоды от共享 кода. Компания не отказывается от React Native резко: она планирует чистый переход, продолжая поддерживать свои открытые библиотеки (например, Reanimated и React Native Skia), которые стали лидерами в своих нишах. Одновременно Shopify активно нанимает мобильных инженеров и специалистов на стыке ИИ и разработки. Переход не отрицает прошлых успехов: React Native был правильным выбором в 2020 году благодаря усилиям сотен инженеров и поддержке сообщества, включая Meta, Software Mansion и Уильяма Кандильона. Накопленный опыт и инструменты останутся фундаментом для будущей мобильной стратегии Shopify.

Переход Shopify на нативную разработку обусловлен ростом сложности React Native, нестабильностью библиотек, проблемами с обновлениями и несоответствием с платформенными фреймворками, что повышает стоимость поддержки. LLM значительно снижают стоимость генерации и поддержки нативного кода, делая миграцию экономически целесообразной даже для крупных продуктов — даже без глубокого знания Swift или Kotlin. Нативная разработка обеспечивает лучшую производительность, стабильность и контроль над платформой, особенно в сложных сценариях отладки. Отказ от React Native устраняет угрозы цепочек поставок npm. Даже без LLM миграция оправдана из-за высокой стоимости поддержки абстракции, что подтверждается опытом команд до 2026 года. Споры остаются: отказ от OTA-обновлений критичен для быстрорастущих компаний; сложность отладки крашей в JS, C++ и нативных потоках не устраняется LLM и может быть дороже поддержки двух кодбаз. Рекомендации: стартапам React Native и Flutter остаются разумными для MVP; после зрелости — переход на нативный код для контроля качества и производительности. При миграции важно отделить бизнес-логику от UI, чтобы LLM могли тестировать состояние через CLI. Использование агентов требует строгого контроля зависимостей и тестов — иначе компания рискует стать зависимой от нестабильных LLM. Нативные инструменты (Jetpack Compose, SwiftUI) становятся более предсказуемыми, а LLM эффективнее работают с прямым доступом к платформе, чем через слои абстракции. Ранее привлекательный аргумент «React Native для веб-разработчиков» устарел: LLM позволяют генерировать нативный код без знания платформенных языков. Опыт показывает, что React Native-проекты часто превращаются в «junk show» из-за нестабильности и низкого качества библиотек. Снижение стоимости генерации кода LLM меняет баланс: дублирование кода теперь дешевле, чем поддержка абстракции без полного контроля. Индустрия движется к отказу от высокоуровневых абстракций в пользу нативного кода.

Snapchat представил Valdi — кроссплатформенный UI-фреймворк, который обеспечивает нативную производительность без потери скорости разработки. Решение ориентировано на создание высокопроизводительных интерфейсов для мобильных и десктопных приложений, используя единый кодовый баз.

Ключевая особенность Valdi — способность достигать производительности, сопоставимой с нативными решениями, при этом сохраняя преимущества кроссплатформенности. Фреймворк призван решить проблему компромиссов между производительностью и эффективностью разработки, с которой сталкиваются команды при создании сложных UI. Snapchat позиционирует Valdi как инструмент для ускорения цикла разработки без ущерба для качества пользовательского опыта.

• Разочарование в существующих кроссплатформенных решениях (React Native, WebView) и надежды на Valdi как альтернативу с нативной производительностью.
• Критика Valdi: сложность, отсутствие поддержки Linux/Windows, сомнения в качестве кода Snapchat и его Android-приложения.
• Альтернативные подходы: нативная разработка, Kotlin Multiplatform, PWA, а также сомнения в необходимости кроссплатформенности при наличии AI.
• Технические вопросы: отсутствие поддержки Swift, сложность нативной интеграции, сравнение с другими фреймворками (Boden, Lynx.js).
• Философский спор: стоит ли жертвовать нативным UX ради кроссплатформенности или писать UI отдельно для каждой платформы.

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

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

Кратко:
С декабря 2026 г. CocoaPods Trunk станет только для чтения — новые версии и pod-ы добавлять нельзя. Существующие сборки продолжат работать, пока живы GitHub и jsDelivr.

Что меняется:

• Подачи новых Podspec будут отклоняться на уровне сервера.
• Репозиторий CocoaPods/Specs пометят как archived.
• Использование prepare_command в новых Podspec запрещено (май 2025).

График:

• май 2025 — блок prepare_command.
• конец 2025 — массовое письмо всем авторам Podspec.
• сен–окт 2026 — повторное уведомление.
• 1–7 ноя 2026 — тестовое отключение.
• 2 дек 2026 — финальный переход на read-only.

Обратная связь:

• Команда: [email protected]
• Orta: [email protected] или Bluesky @orta.io

• CocoaPods официально уходит в историю: мейнтейнеры решили прекратить развитие, признав превосходство Swift Package Manager.
• Пользователи благодарны за годы поддержки, но многие рады избавиться от «захвата» проекта xcworkspace и постоянных проблем с CDN.
• Критика SPM: не хватает команды outdated, баги в Xcode, плохие сообщения об ошибках; до 30 % пакетов ещё не перенесены.
• React Native, Flutter, Unity, Capacitor пока тесно зависят от CocoaPods; переход на SPM только в зачаточном состоянии.
• ~100 k старых pod-ов рискуют остаться без обновлений: придётся форкать и мигрировать вручную или ждать сообщества.