Телеграм

Dev News от Максима Соснова

@msosnovfeed Программирование и разработка
РКН: проверяем Иноагент: проверяем
Привет! Меня зовут Максим Соснов и по утрам я читаю всякие разные дайджесты про фронтенд, разработку и управление разработкой. Самые интересные, по моему мнению, ссылки из этих дайджестов я кидаю в этот канал с небольшим описанием.

Контакт: @msosnov

Статистика обновлена 12.11.2026 в 21:54 · 1 просмотр страницы · Хотите больше просмотров?

Подписчики2 774
Охват поста820 30% от подписчиков
ERR за месяц29,56%
ERR за 24 часа24,73%

Динамика за 30 дней

Рекламные публикации

Рекламных публикаций не найденоЗа последнее время мы не нашли на площадке ни одного рекламного поста.

Последние публикации

Все посты канала →
Dev News от Максима Соснова tg2.8 тыс. подписчиков
Открыть пост ↗
Migrating the Shop app from React Native to native

Shopify переписали приложение Shop с React Native на Swift и Kotlin. От прототипа до публикации в сторах — 12 недель.

Shop на RN с запуска в 2020 году. С натива ушли по трём причинам:
- реализовывать фичу один раз
- не требовать для этого бэкграунда мобильной разработки под конкретную ОС
- за счёт этого ускорить доставку и держать паритет фичей

Однако оказалось, что RN тоже не без греха. Налог на обновления RN оказался большим. Я не до конца понял, что там было, но упоминаются переход на New Architecture, проблемы с анимациями и библиотеками.

В итоге прототип переезда делал один iOS-инженер одну неделю. По готовому коду RN собирались нативные экраны. Это оказалось далеко не идеальным решением, но оно показало, что переписывание в короткие сроки в целом реально.

Как и все современные миграции, конечно же делали через AI-агентов.

Процесс такой:
- Сделали расширение для Pi
- Субагенты разбирают RN-исходники экрана, декомпозируют их на стейт, UI, навигацию и т. д. и пишут план миграции
- Человек принимает план
- Далее агенты переписывают экран на нативные технологии и проверяют, что логи, стейт и скриншоты на чекпоинтах не изменились

Какие итоги.

Холодный старт, от тапа по иконке до ленты на главной:
- iOS: 3200 → 2466 мс (−23%)
- Android: 4433 → 2233 мс (−50%)

Стабильность сессий 99,5% → 99,95%.

Размер релиза: Android 293 → 184 МБ, iOS 67 → 68 МБ.

Релизный билд Android быстрее примерно на 75%, на iOS время то же.

Лента на Pixel идёт в 120 FPS, отдельных оптимизаций почти не было.

А главное, что блокер, который был актуален в 2020 году, а именно необходимость писать и поддерживать 2 версии кода, более не актуален, т.к. код пишут ИИ-агенты. Достаточно сделать одно работающее решение, а далее ИИ-агенты, если сделать им хороший процесс вокруг разработки, спокойно его адаптируют под любую платформу.

Если раньше узким горлышком было написание кода, то теперь — его ревью и проверка решения.

Я не уверен, что это так классно в реальности, как это звучит в статье. Как минимум видна очень большая подготовительная работа для этого процесса: свои инструменты, пайплайны. Но даже с ним не уверен, что всё идёт вот так вот гладко.

С другой стороны, кейсов переписывания приложения на другой стек становится всё больше и больше. Недавно читал даже кейс, где чел писал софт под железки и подумал «а зачем мне код на читаемом языке, если его всё равно генерирует агент» и заставил агента писать сразу на самом низком уровне (то ли ассемблер, то ли сразу инструкции).

https://shopify.engineering/shop-app-migration
https://shopify.engineering/back-to-native

#development #react-native #shopify #mobile #ai
👁 686 ❤ 6👍 3 💬 2 ↻ 12 23 октября
Dev News от Максима Соснова tg2.8 тыс. подписчиков
Открыть пост ↗
Fixing INP in a Massive React Dropdown

В Subito был дропдаун, в котором 1175 пунктов, и он рендерился оооооооочень долго (1256 мс), что, естественно, негативно влияло на метрику INP. Решение простое и очевидное — использовать виртуальный скролл.

Меню на react-select при открытии монтировало все 1175 опций, хотя на экране помещается около шести. Написали хук useVirtualScroll на 90 строк: меряют высоту одной строки и рисуют видимое окно плюс буфер в 5. После этого вместо 1175 элементов в DOM стало 13, а INP упал до 96 мс.

Простая проблема, достаточно очевидное решение через виртуализацию.

https://dev.to/subito/from-1256ms-to-96ms-fixing-inp-in-a-massive-react-dropdown-16l7

#development #react #performance #inp
👁 750 😁 7👍 1 💬 3 ↻ 5 21 октября
Dev News от Максима Соснова tg2.8 тыс. подписчиков
Открыть пост ↗
Why (and How) GitHub Ported Copilot's Runtime from Node to Rust

Огромная статья от GitHub про переписывание рантайма Copilot (800 тысяч строк кода) с TypeScript на Rust.

Рантайм GitHub Copilot — это по сути SDK для запуска agent harness, который используется в GitHub Copilot CLI, GitHub Copilot App, VS Code, Visual Studio и ещё куче приложений. Все они вынуждены были тащить Node.js-рантайм для запуска agent harness.

Это означает и потребление избыточной памяти на движок V8 (около 100 МБ), и жёсткую зависимость от Node.js: падает Node.js — падает весь агент.

Каким требованиям должна была удовлетворять целевая платформа:
- минимум зависимостей и оверхеда от языка и экосистемы
- возможность встроиться в процесс
- язык, на котором проще сделать быстрое, масштабируемое и отказоустойчивое решение
- лёгкий интероп с C#, TypeScript, Python, Rust, Go, Java
- современный тулинг, который учитывает безопасность

По итогу выбрали Rust.

Миграция проходила покомпонентно. Берётся TS-код, переписывается на Rust, подключается через napi и прогоняются все e2e-тесты. Если тесты проходят, компонент на Rust вливается в main.

Как проходило переписывание: автор запускал рой агентов и с мая по 21 августа открыл 128 пул-реквестов. Каждый агент работал в своём worktree. Крупные задачи делили на более мелкие и запускали в отдельных сессиях.

Проверка результата также была по максимуму автоматизирована:
- Сначала агенты проводят код-ревью: построчно сравнивают обе версии кода, e2e-тесты менять нельзя, должна остаться только тонкая TS-прослойка
- Далее человек смотрит, что агент всё верно сделал. Были кейсы, когда агенты пытались обмануть систему

Всё переписывание заняло 3,5 месяца. Автор оценивает свою занятость в 3 недели, т.к. параллельно занимался ещё другими задачами. Счёт за токены моделей составил $120 тысяч. При этом 96% токенов прочитаны из кеша. Боюсь представить цифру без такого эффективного cache read.

Какой по итогу результат.

Скорость работы без сети и без инференса. Старт клиента, сессия и один ход:
- Node: 5,25 с
- Rust отдельным процессом: 1,33 с
- Rust внутри процесса: 292 мс

Потребление памяти на десятке клиентов, пик сверх базового:
- Node: +1383 МБ
- Rust отдельным процессом: +247 МБ
- Rust внутри процесса: +126 МБ

Также в статье куча графиков и таблиц: таймлайны, размеры пул-реквестов, скорость изменения кода. Очень крутая инфографика.

Важные уроки, которые выделяет автор этой миграции:
- Нужно задавать цель целиком: рантайм на 100% Rust, без оставшегося TypeScript. Изначально агенты решали задачу «переписать код на Rust», и получалось плохо.
- Агентам нельзя менять e2e-тесты, т.к. это единственный способ понять, что всё действительно работает как раньше.
- Сначала код переписывается as is, а только потом меняются подходы и алгоритмы под новый язык. Нарушение этого правила приводило к проблемам.
- Повторяющиеся проблемы надо уносить в скиллы и инструкции, чтобы они не всплывали в следующих PR.
- С агентами узким местом становится не написание кода, а сборка проекта и запуск автотестов. Агент очень быстро пишет код и потом долго ждёт результатов запуска тестов.


https://github.blog/ai-and-ml/generative-ai/migrating-the-github-copilot-runtime-to-rust-using-copilot

#development #rust #nodejs #copilot #ai #performance
👁 835 👍 14🔥 4❤ 2 ↻ 11 19 октября