GitHub’s internal playbook for building an AI-powered workforce

Статья от Github про сложности внедрения AI в работу. Основная проблема - не купить инструменты, а внедрить их использование в рабочий процесс.

В статье описывается модель, по которой Github масштабирует применение AI.

Основные столпы, которые необходимы для масштабирования внедрения AI:
1. AI-адвокаты — внутренняя сеть добровольцев‑чемпионов для распространения практик (как через вебинары, так и через совместную работу).
2. Понятные политики и безопасность — правила, чтобы сотрудники уверенно и безопасно использовали AI.
3. Возможность обучаться применению AI и возможность применять его в работе
4. Метрики на основе данных — система метрик по адопшену, вовлечённости и бизнес‑эффекту.
5. Ответственный, управляющий масштабированием
6. Поддержка руководства — стратегическое видение, ресурсы и тд
7. Использование подходящих инструментов — набор проверенных инструментов, подходящих под роли и задачи.
8. Внутренние сообщества (Communities of Practice) — форумы и сообщества для обмена знаниями и опытом.


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

В статье делается большой уклон на вовлечение людей в интеграцию с AI. Не "мы придумали для вас инструменты и практики, используйте", а "индустрия меняется, будьте теми, кто участвует в ее изменении". Люди сами найдут оптимальные способы использования AI в своей работе, если их правильно вовлечь.

Также делается большая ставка на AI-адвокатов - людей, которые уже активно используют AI в работе и могут помогать внедрению AI в работу других коллег.

Также предлагается создание живого сообщества по AI-практикам - чаты, вебинары, воркшопы, где люди будут делиться своими юзкейсами и примерами.

В статье хорошо расписана ответственность того, кто отвечает за масштабирование, и за какими метриками он должен следить - начиная от "пользователи AI-инструментов в день или месяц" и до "насколько ускоряется выполнение задач с AI". Также в статье представлен чеклист внедрения модели.

Рекомендую внимательно прочитать, если вам интересна тема масштабирования использования ИИ.

https://resources.github.com/enterprise/ai-powered-workforce-playbook/

#development #ai #github

Part 1: Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity

Недавно во многих каналах и форумах разошлись результаты исследования влияния использования на производительность разработчиков. Результаты следующие: ожидали ускорение на 20%, а по факту замедлились на 19%. Давайте погрузимся в исследование и поймем его ограничения и выводы

Чем это исследование примечательно (ну кроме неожиданного результата) - оно проводится на реальных эадачах и замеряется время выполнения задач. Другие исследования обычно замеряют скорость написания строчек кода или открытия пул реквестов, или измеряют производительность на синтетических задачах (напишите свой веб сервер который отдает hello world)

В этом исследовании решили взять разработчиков крупных опен сорс проектов (миллионы строчек кода), которые неопытны в AI и которые очень опытны в своих репозиториях (годы опыта работы в этих репозиториях). Для замеров взяли их обычные задачи в их репозиториях и поделили их на 2 типа: те, в которых нельзя использовать AI, и те, в которых можно (но необязательно) использовать AI. Разработчикам дали доступ к платному cursor. У Разработчиков трекали активность экрана, чтобы точно разметить, на что уходит время при выполнении разных задач. Как целевую метрику трекали время от начала работы над задачей до влития в мастер

Всего в исследовании приняли участие 16 разработчиков, и они завершили 246 задач. По итогам исследования исследователи выделили 21 фактор, которые могут объяснять влияние или влиять на производительность разработчиков.

Давайте посмотрим цифры в исследовании, а именно куда уходит время.

Категории активностей
- Активный кодинг: 24 минуты в задачах без AI, 20 минут в задачах с AI
- Чтение и поиск: 15 минут без AI, 14 минут с AI
- Тестирование и дебаг: 8 минут без AI, 10 минут с AI
- Git и окружение: 7 минут без AI, 6 минут с AI
- Ожидание (Idle, overhead): 3 минуты без AI, 7 минут с AI
- Ревью вывода AI: 7 минут с AI
- Промптинг: 5 минут с AI
- Ожидание AI: 4 минуты с AI

Как видите, при использовании AI ускоряется кодинг, но при этом добавляются большие накладные расходы на ожидание ответа AI, промптинг и ревью результата от AI. Причем ожидание ответа от AI ведет к дополнительному ожиданию - кто-то ходит за кофе, чтоб не ждать у монитора, кто-то читает твиттер (кейс из исследования), что дополнительно увеличивает время выполнения задачи (тот самый Idle)

С чем связано увеличение времени в ожидании и ревью? В исследовании выделяют несколько причин.

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

Во вторых, в исследовании принимали участие разработчики опен-сорса, в репозиториях которых очень строгие гайды по разработке. Вас банально не пропустят в основной бранч, если вы где-то не там поставите запятую или фигурную скобку, или выделите сущности не так, как принято в проекте, или напишете тесты не так, как принято впроекте. Поэтому разработчики буквально просматривали каждую строчку, которую выводил AI.

В третьих, часть разработчиков неопытны в использовании AI (мое субъективное мнение). Когда AI выдавал им неидеальный ответ, они, вместо того, чтоб его подредактировать, удаляли весь ответ и меняли промпт

Как итог, разработчики зарепортили следующее:
- В 100% отчетах разработчики исправляли код после AI
- В 56% отчетах - это были большие изменения
- В 75% отчетах разработчики читали каждую строчку, которую сгенерировали ИИ

В следующем посте разберем факторы, влияющие на скорость разработки, которые выделили исследователи.

В комментарии скину интересные графики.

https://arxiv.org/abs/2507.09089

#development #ai #performance #research #openSource

Part 2: Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity

Как я говорил в предыдущем посте, исследователи выделили 21 фактор, который виляет или может влиять на производительность разработчиков. Давайте их разберем.

Я не буду рассматривать факторы as is как в исследовании, я их переструктурирую в более широкие факторы

Фактор №1: применение AI в сложном контексте снижает скорость разработки

Основные тейки из исследования следующие:
- Репозитории, в которых работал AI - гигантские.
- Кроме этого, некоторые знания в них - неявные, и существуют только в головах разработчиках.
- Так как это опен-сорс, в репозиториях очень строгие стайл-гайды и правила написания кода и оформления пул реквестов.

Как следствие - разработчики тратили много времени на ревью и исправление кода. Часто AI не мог предложить адекватного (или идеального) решения


Фактор №2: применение AI не помогает тем, кто уже эксперт в текущем контексте
В исследовании принимали участие разработчики, которые годами работают в их репозиториях (5+ лет). Чем лучше разработчики понимали область задачи, тем сильнее было замедление скорости разработки.

С другой стороны, разработчики отметили, что в задачах, где у них не было опыта, AI сильно ускорил их т.к. не потребовалось тратить время на самостоятельное изучение чего-либо для небольших правок. В качестве примера в статье приводится кейс, когда разработчик не знал ничего про фронтовые тесты, а AI помог ему их сделать очень быстро.

Фактор №3: применение AI замедляет, пока у вас нет навыков работы с AI
Опытные в AI разработчики не были мотивированы участвовать в исследовании. Исследователи провели обучение по работе cursor (что может говорить о низком уровне навыка работы с AI)

Исследователи искали кореляцию между опытом работы с AI и ускорением (предполагали что AI сначала замедляет, а затем ускоряет), но не нашли такой кореляции. Хотя в их же графике есть всего 1 разработчик, который провел в курсоре более 50 часов и выполнил после этого 24 задачи и получил ускорение (график в комментариях)

Фактор №4: применение AI увеличивает скоуп задач
Это немного ставит под сомнение тезис "применение AI замедляет разработку" т.к. разработчики выполняют основную задачу и что-то еще рядом с ней.

Ситуация, на самом деле, обычная, с которой сталкивался, наверное, каждый, кто пробовал использовать агентский режим. Вы хотите просто сделать фичу, а агент:
- Провел рефакторинг
- Поправил gitlab-ci.yml
- Дописал JSDoc там, где его не хватало
Иногда эти правки полезные, иногда - нет. Но факт - если они полезные, то у вас дилема - или расширить скоуп задачи и принести еще пользы, влив еще немного времени на задачу, или потратить время на удаление лишних правок.

Фактор №5: Применение AI в другом инструментарии замедляет разработку
Тут надо сказать, что я говорю ровно противоположное тому, что написано в исследовании. В исследовании говориться, что такой фактор есть, но они считают, что он, скорее всего, не повлиял, т.к. cursor сопоставимая IDE с IDE участников, а также у 3 разработчиков cursor был одной из основных IDE до исследования.

Из 16 разработчиков, учатсвующих в исследовании, 12 согласились открыть свои данные по репозиториям, в которых они работают:
- 7 python
- 2 haskell
- 2 js
- 1 rust

Я могу предположить, что у большинства разработчиков (python + haskell) основная IDE - не vscode и, соответственно, переход на cursor для них далеко не бесплатный.

Теперь представьте, что вы 50% задач делаете в вашей любимой IDE, в которой вы работаете годами, а другие 50% задач делаете в IDE, в которой другие инструментарий и возможности (скорее всего меньший по сравнению с профильными IDE), другие хоткеи, другое поведение. Логично ожидать, что ваша производительность просядет при работе в новой IDE.

В следующем посте расскажу еще немного про исследование, подведу итог и выскажу свое мнение по результатам исследования.

https://arxiv.org/abs/2507.09089

#development #ai #performance #research #openSource

Part 3: Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity

Завершающий пост про исследование.

Давайте коротко вспомним, что было в предыдущих постах:
- Сильные разработчики в сложных опен-сорс проектах для 50% задач начали использовать AI
- Скорость выполнения задач с использованием AI оказалась на 19% ниже
- Достаточно большое количество времени разработчики либо промптили, либо ждали ответа AI, либо ревьюили AI-код
- При этом сам кодинг с AI идет быстрее
- Текущий AI-инструментарий не может реализовать сложных решений (по крайней мере при заходе в эту степь с двух ног без подготовки и сложных паттернов)
- Текущий AI-инструментарий - медленный
- Использование AI расширяет скоуп задачи
- Чем более экспертен разработчик в какой-то области, тем сильнее замедление в разработки при использовании AI в этой области
- В областях, где разработчики были новичками AI очень сильно им помог
- Разработчики, принимающие участие в исследовании, были не очень опытны в AI, а часть разработчиков не могли воспользоваться AI-тулингом в их "родной" IDE

Не смотря на то, что AI-замедляет, код от AI часто приходилось удалять или изменять, в отчетах, которые заполнялись после завершения задачи, разработчики указывали, что AI их ускорил. То есть, не смотря на то, что по факту задача делалась дольше, разработчики ощутили ускорение своей работы.

Почему так? Потому что при разработке с AI, во первых, код пишется быстрее, а во вторых - мыслетопливо (концепт из книжки Максима Дорофеева "Джедайские техники" про ресурс мозга на обдумывание чего-либо - книжку, кстати, рекомендую к прочтению абсолютно всем) тратиться намного меньше. Как следствие - его можно потратить на что-то другое. Кто-то в исследовании читал твиттер, но можно потратить и на что-то полезное.

Когда исследование завершилось и разработчики выполнили все свои задачи, им не стали отключать cursor. После того, как уже не требовалось использовать AI для 50% задач, 69% разработчиков продолжили использовать cursor. Невероятный retention!

Подведем общий итог. Вместо "Исследование говорит о том, что AI замедляет разработку на 19%" я бы сформулировали итог так:
- Если вы супер-опытный разработчик
- Вы разрабатываете в очень сложном репозитории со строгими гайдлайнами (опен-сорс)
- Вы постоянно переключаетесь в другую IDE для использования AI
- И вы не опытны в AI-кодинге
- То при применении AI вы замедлитесь на 19%

Но при этом можно сделать еще выводы:
- Разработчикам нравится упрощение работы с AI (снижение когнитивное нагрузки)
- Текущий AI инструментарий замедляет работу в сложных контекстах. В частности, если у вас большие требования к коду - вы замедлитесь. Поэтому при применении AI хорош принцип - следить за тем как выделены функции (ответственность, SOLID, композируемость и тд) и забить на то, что написано внутри функций, пока проходят тесты
- Текущий AI инструментарий уже ускоряет вас в областях, в которых вы не эксперт
- AI расширяет скоуп задач - это и благо и проклятье одновременно

https://arxiv.org/abs/2507.09089

#development #ai #performance #research #openSource

Дайджест за 2025-08-25 - 2025-08-29

GitHub’s internal playbook for building an AI-powered workforce
Статья от Github про сложности внедрения AI в работу. Основная проблема - не купить инструменты, а внедрить их использование в рабочий процесс.

В статье описывается модель, по которой Github масштабирует применение AI.

Part 1: Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity
Недавно во многих каналах и форумах разошлись результаты исследования влияния использования на производительность разработчиков. Результаты следующие: ожидали ускорение на 20%, а по факту замедлились на 19%. Давайте погрузимся в исследование и поймем его ограничения и выводы

Чем это исследование примечательно (ну кроме неожиданного результата) - оно проводится на реальных эадачах и замеряется время выполнения задач. Другие исследования обычно замеряют скорость написания строчек кода или открытия пул реквестов, или измеряют производительность на синтетических задачах (напишите свой веб сервер который отдает hello world)

Part 2: Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity
Как я говорил в предыдущем посте, исследователи выделили 21 фактор, который виляет или может влиять на производительность разработчиков. Давайте их разберем.

Я не буду рассматривать факторы as is как в исследовании, я их переструктурирую в более широкие факторы

Part 3: Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity
Завершающий пост про исследование.

Давайте коротко вспомним, что было в предыдущих постах:

——————————————

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

Mediabunny - Complete media toolkit

Mediabunny - тулкит для работы с медиа прямо в браузере. Склеивание, перекодирование, комбинирование и тд и тп. В общем, ffmpeg но только в браузере и в виде библиотеки для JS.

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


https://mediabunny.dev/

#development #javascript #media #library

Why do browsers throttle JavaScript timers?


Хорошая статья, рассказывающая про особенности работы setTimeout. Вы знали, что setTimeout(0) вызовется не сразу, а через 4мс? А все потому что, когда-то разработчики слишком активно использовали setTimeout(0) где надо и где не надо, а разработчики браузеров решили защитить пользователей и сделали минимальный лимит в 4мс.

Описал достаточно утрировано, но тем не менее - можете рассчитывать на 4мс вместо 0мс задержки в современных браузерах.

Зачем браузеры делают такое? Они оптимизируют использование батарейки и сети на устройствах пользователей. Иногда браузеры делают это более агрессивно. Например, safari задерживает выполнение колбека на 26 секунд, а для неактивных вкладок хром задерживает выполнение колбека на одну секунду

Что же делать, если вы хотите выполнить колбек после выполнения всех микротасок? Автор задался тем же вопросом т.к. делает JS-имплементацию indexeddb и ему нужно комитить транзакции.

Автор провел простые бенчмарки и сделал следующие выводы:
- scheduler.postTask имеет минимальную задержку (0.00-0.01 мс), но не реализован в safari
- window.postMessage имеет задержку чуть больше (0.01-0.03мс), но поддерживается в safari
- MessageChannel.postMessage имеет задержку еще чуть больше (0.02-0.05мс), но в safari значительно больше (0.52мс)

Когда нибудь и текущие API могут замедлить (когда разработчики станут ими слишком активно злоупотреблять), но пока так.


https://nolanlawson.com/2025/08/31/why-do-browsers-throttle-javascript-timers/

#development #javascript #timers #setTimeout

Fresh 2.0 Graduates to Beta, Adds Vite Support

Fresh - веб-фреймворк в deno - зарелизился в бетке 2.0.

Главные изменения:
- Интеграция с Vite
- HMR в islands-компонентах
- Ускорение инициализации приложения в браузере в 10 раз
- Вернули компонент Head. Убирали, потому что была кривая реализация, ухудшающая перформанс. Теперь хорошая реализация

https://deno.com/blog/fresh-and-vite

#development #javascript #deno #vite

You no longer need JavaScript

Очередная статья про то, что слишком много Javascript грузится на сайтах, а ведь можно делать интерфейсы без Javascript. Отличие этой статьи от многих таких же - очень крутые примеры и демки того, что позволяют сделать современные веб-стандарты без использования JS.

Какие приколы рассмотрены в статье:
- Вложенные css-селекторы (пример & > .buttons)
- Колор пикер на чистом css
- transitioning + @starting-style
- nesting + :has для выбора темы сайта
- radio-group и radio tabs
- Акордеон
- Валидация инпутов с использованием regexp-шаблона и :has
- Использование lvh, svh, dvh вместо vh
- Получение высоты экранной клавиатуры (актуально для мобильных девайсах) в css (пока только для хрома)

Горячо рекомедую статью и демки к просмотру.

https://lyra.horse/blog/2025/08/you-dont-need-js/

#development #javascript #css

Deriving Client State from Server State

Частый паттерн - использовать useEffect для синхронизации состояния двух стейтов. В рамках статьи обсуждается синхронизация стейта react-query и zustand. Вместо использования useEffect предлагается высчитывать состояние, вместо его синка

Пример проблемы:

const useSelectedUser = () => {
  const { data: users } = useQuery({
    queryKey: ['users'],
    queryFn: fetchUsers,
  })
  const { selectedUserId, setSelectedUserId } = useUserStore()

  // If the selected user gets deleted from the server,
  // Zustand won't automatically clear selectedUserId
  // You have to manually handle this:
  useEffect(() => {
    if (!users?.some((u) => u.id === selectedUserId)) {
      setSelectedUserId(null) // Manual sync required
    }
  }, [users, selectedUserId])

  return [selectedUserId, selectedUserId]
}

Пример предлагаемого решения

const useSelectedUser = () => {
  const { data: users } = useQuery({
    queryKey: ['users'],
    queryFn: fetchUsers,
  })
  const { selectedUserId, setSelectedUserId } = useUserStore()

  const selectedId = users?.some((u) => u.id === selectedUserId)
    ? selectedUserId
    : null

  return [selectedId, setSelectedUserId]
}

Соглашусь с автором. Если вы можете не использовать 2 стейта, которые надо синхронизировать - не надо их использовать т.к. синхронизация стейтов это а) кривое решение б) хрупкое решение. У меня до сих пор есть въетнамские флешбеки от синхронизации rxjs-like стейта (какой-то самописный стор на обсерваблах) с redux-like стором.

https://tkdodo.eu/blog/deriving-client-state-from-server-state

#development #javascript #react #reactQuery #zustand

Дайджест за 2025-09-08 - 2025-09-12

Mediabunny - Complete media toolkit
Mediabunny - тулкит для работы с медиа прямо в браузере. Склеивание, перекодирование, комбинирование и тд и тп. В общем, ffmpeg но только в браузере и в виде библиотеки для JS.

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

Why do browsers throttle JavaScript timers?

Хорошая статья, рассказывающая про особенности работы setTimeout. Вы знали, что setTimeout(0) вызовется не сразу, а через 4мс? А все потому что, когда-то разработчики слишком активно использовали setTimeout(0) где надо и где не надо, а разработчики браузеров решили защитить пользователей и сделали минимальный лимит в 4мс.


Fresh 2.0 Graduates to Beta, Adds Vite Support
Fresh - веб-фреймворк в deno - зарелизился в бетке 2.0.


You no longer need JavaScript
Очередная статья про то, что слишком много Javascript грузится на сайтах, а ведь можно делать интерфейсы без Javascript. Отличие этой статьи от многих таких же - очень крутые примеры и демки того, что позволяют сделать современные веб-стандарты без использования JS.


Deriving Client State from Server State
Частый паттерн - использовать useEffect для синхронизации состояния двух стейтов. В рамках статьи обсуждается синхронизация стейта react-query и zustand. Вместо использования useEffect предлагается высчитывать состояние, вместо его синка


——————————————

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

Introducing Next-Generation Flamegraph Visualization for Node.js

Название статьи говорит само за себя - представлен инструментарий для профилирования nodejs приложений. Фишки, в общем-то, две: а) крутая визуализация б) профилирование замедляет fastify всего на 5%

Рекомендую открыть статью и посмотреть демки и скриншотики. Решение очень хорошее и удобное:
- Можно использовать без конфига
- Задизайнено для удобной интеграции в приложения и тулы автоматизации
- Можно стартовать и стопать профилирование с помощью SIGUSR2 сигналов (отдельный лайк)
- Програмное АПИ
- Кросс-платформенное cli
- Стандартный формат вывода результата профилирования

В статье приводится несколько примеров использования (типичный сценарий: запустить сервер, сделать запросы, остановить профилирование) и различные бенчмарки

https://blog.platformatic.dev/introducing-next-gen-flamegraphs-for-nodejs

#development #javascript #nodejs #performance #flamegraph #profiling

MCP-UI - Interactive UI Components for MCP

Если вы более менее активно используете AI, то вы наверняка знаете, что такое MCP. Это протокол для интеграции инструментария в ИИ-агенты. MCP-UI предлагает решение для mcp с интерактивным UI. Т.е. у вас в чате не просто "был вызван тул такой-то", а показывается полноценный UI, который наглядно показывает результат, позволяет с ним повзаимодействовать и доуточнить (что приведет еще к одному вызову тула)

Демка выглядит интересно. Возможно когда нибудь увидим что-то такое в ИИ-чатах и агентах

https://mcpui.dev/

#development #javascript #mcp #ai

Дайджест за 2025-09-15 - 2025-09-16

Introducing Next-Generation Flamegraph Visualization for Node.js
Название статьи говорит само за себя - представлен инструментарий для профилирования nodejs приложений. Фишки, в общем-то, две: а) крутая визуализация б) профилирование замедляет fastify всего на 5%

MCP-UI - Interactive UI Components for MCP
Если вы более менее активно используете AI, то вы наверняка знаете, что такое MCP. Это протокол для интеграции инструментария в ИИ-агенты. MCP-UI предлагает решение для mcp с интерактивным UI. Т.е. у вас в чате не просто "был вызван тул такой-то", а показывается полноценный UI, который наглядно показывает результат, позволяет с ним повзаимодействовать и доуточнить (что приведет еще к одному вызову тула)


——————————————

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

React Won by Default – And It's Killing Frontend Innovation

Статья о том, как выбор React дефолтным инструментом для проектов убивает фронтенд. Можно по-разному относится к тому факту, что React сегодня является стандартным инструментом для создания веб-приложений - это одновременно и благо и проклятье.

Автор рассматривает, какие альтернативы есть у React и в чем они лучше React:
1. в SolidJS реактивность сделана лучше чем в React. Бенчмарки говорят о 2-3х кратном различии в производительности
2. Svelte ближе к идеям web'а и имеет мощный компилятор, который позволяет делать аналогичные решения, которые весят в десятки раз меньше
3. Qwik со своей моделью постепенной интерактивности позволяет загружать пользователям минимальный объем кода и максимально быстро отдавать интерактивные сайты

Тем не менее, ни одна из альтернатив не может стать достаточно популярной из-за использования React как стандарта.

React, тем временем, не приносит ничего нового и замыкает веб-разработку на себе: чтобы делать приложения на React, необходимо знать особые паттерны, которые применимы только в React. React, к тому же, не прост. Жизнь react-разработчика это история про борьбу с react'ом: с хуками, с серверным рендером, с strict-режимом

Автор призывает всех использовать объективные подходы к выбору инструментов и выбирать наиболее подходящий инструмент для задачи, нежели выбирать только React. Но, честно сказать, даже не представляю что может заставить крупные компании переходить на другой стек: React-разработчиков можно буквально нанимать вагонами и они будут способы поддержать react-приложение, которое было написано почти 10 лет назад.


https://www.lorenstew.art/blog/react-won-by-default

#development #javascript #react #svelte #qwik #solidjs

The expert Guide to Next.js Performance Optimization

Электронная книга от blazity про оптимизацию производительности в next.js приложениях. Книга бесплатная, чтобы получить - достаточно указать свою почту. Книжка не только про Next.js (хотя, конечно, большая часть связана с Next.js), рассказывается также и про шрифты, web vitals, инструменты измерения производительности, загрузку изображений и 3rd-party скрипты

В общем, неплохой сборник решений для оптимизации производительности в одном pdt-файле

https://blazity.com/the-expert-guide-to-nextjs-performance-optimization

#development #javascript #nextjs #book #performance

Wasm 3.0 Completed

Вышел wasm 3.0! Основные фичи направлены на то, чтобы открыть возможность компилироваться в wasm различным языкам программирования. В частности, одна из фичей - встроенный сборщик мусора, который необходим языкам со сборщиком мусора. Это открывает возможность компиляции в Wasm для java-языков, Dart, Go

https://webassembly.org/news/2025-09-17-wasm-3.0/

#development #javascript #wasm

Updated and Ongoing Supply Chain Attack Targets CrowdStrike npm Packages

Снова крупный инцидент безопасности в npm-экосистеме. На этот раз злоумышленники получили доступ к публикации популярных пакетов и встроили туда червя, который заражает соседние пакеты и встраивает код, который крадет креды и крипту.

Атаке подверглись более 500 пакетов, в том числе крупные пакеты с десятками миллионов скачиваний в неделю

https://socket.dev/blog/ongoing-supply-chain-attack-targets-crowdstrike-npm-packages

#development #javascript #npm #security

Fetch streams are great, but not for measuring upload and download progress

Хорошая заметка от Джейка Арчибальда про потоковую загрузку данных в JS. Если коротко: потоковая загрузка поддерживается через fetch, но вы не сможете корректно посчитать прогресс. А если будете делать запрос через XHR - сможете!

Честно говоря, удивительно, что fetch уже давно стандартизирован, но до сих пор в некоторых банальных моментах XHR все еще впереди.

Итак, как же все таки выполнить потоковую загрузку. В целом, все просто и не меняется давно: получаем Reader, и читаем из него куски данных

const response = await fetch(url);
const reader = response.body.getReader();

while (true) {
  const { done, value } = await reader.read();
  if (done) break;
  console.log(value);
}

console.log('Done!');

Можно даже использовать итераторы (но не в сафари)

const response = await fetch(url);

for await (const chunk of response.body) {
  console.log(chunk);
}

console.log('Done!');

Но, однако, вы не сможете корректно посчитать прогресс скачивания т.к. content-length, отдавемый сервером и длина контента, которую вы получаете в JS может отличаться из-за сжатия (по сети отправляются сжатые данные, а в JS вы получаете уже сырые данные)

Также можно использовать потоки и для загрузки данных на сервер. Например, у вас веб-приложение, которое обрабатывает видео на клиентском устройстве и только потом загружает его на сервер. В этом случае можно передать поток в body fetch'а

// Get a video from disk, or from the camera
const videoStream = getVideoStreamSomehow();
// Process it in some way, e.g. editing or transcoding
const processedVideo = videoStream.pipeThrough(new SomeVideoProcessor());

// Upload the stream
await fetch(url, {
  method: 'POST',
  body: processedVideo,
  duplex: 'half',
  headers: {
    'Content-Type': 'video/mp4',
  },
});

Но корректно замерять прогресс загрузки также не получится.

Единственный способ измерять прогресс сегодня - использовать XHR

const xhr = new XMLHttpRequest();

// Upload progress
xhr.upload.onprogress = (event) => {
  if (event.lengthComputable) {
    console.log(
      `Uploaded ${((event.loaded / event.total) * 100).toFixed(2)}%`,
    );
  }
};

// Download progress
xhr.onprogress = (event) => {
  if (event.lengthComputable) {
    console.log(
      `Downloaded ${((event.loaded / event.total) * 100).toFixed(2)}%`,
    );
  }
};

xhr.open('POST', url);
xhr.send(blobOrWhatever);

Но, уже ведутся обсуждения по добавлению такой возможности и в fetch

https://jakearchibald.com/2025/fetch-streams-not-for-progress/

#development #javascript #fetch #jakeArchibald #stream

Дайджест за 2025-09-22 - 2025-09-26

React Won by Default – And It's Killing Frontend Innovation
Статья о том, как выбор React дефолтным инструментом для проектов убивает фронтенд. Можно по-разному относится к тому факту, что React сегодня является стандартным инструментом для создания веб-приложений - это одновременно и благо и проклятье.


The expert Guide to Next.js Performance Optimization
Электронная книга от blazity про оптимизацию производительности в next.js приложениях. Книга бесплатная, чтобы получить - достаточно указать свою почту. Книжка не только про Next.js (хотя, конечно, большая часть связана с Next.js), рассказывается также и про шрифты, web vitals, инструменты измерения производительности, загрузку изображений и 3rd-party скрипты

Wasm 3.0 Completed
Вышел wasm 3.0! Основные фичи направлены на то, чтобы открыть возможность компилироваться в wasm различным языкам программирования. В частности, одна из фичей - встроенный сборщик мусора, который необходим языкам со сборщиком мусора. Это открывает возможность компиляции в Wasm для java-языков, Dart, Go


Updated and Ongoing Supply Chain Attack Targets CrowdStrike npm Packages
Снова крупный инцидент безопасности в npm-экосистеме. На этот раз злоумышленники получили доступ к публикации популярных пакетов и встроили туда червя, который заражает соседние пакеты и встраивает код, который крадет креды и крипту.

Fetch streams are great, but not for measuring upload and download progress
Хорошая заметка от Джейка Арчибальда про потоковую загрузку данных в JS. Если коротко: потоковая загрузка поддерживается через fetch, но вы не сможете корректно посчитать прогресс. А если будете делать запрос через XHR - сможете!

——————————————

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