What Does "use client" Do?

Пост в блоге Дэна Абрамова про серверные компоненты. Точнее пост про концепцию use client и use server, но по факту это про концепцию серверных компонентов.

В посте Дэн рассказывает, какая идея вложена в use client и use server. Когда мы делаем приложение, которое имеет и бэк и фронт, то для взаимодействия между фронтом и беком необходимо использовать особые способы коммуникации, вместо простого вызова функции. Чтобы вызвать бэк с фронта - надо делать сетевой запрос, а чтобы бэку что-то сообщить для фронта - надо как-то передавать данные для рендера.

Намного круче было бы использовать функции напрямую. Именно это и позволяют делать директивы use client и use server. Они как бы обозначают для сборщика, что экспорты этого файла надо адаптировать для вызова в "другом" мире.

Статья интересная, с хорошими примерами кода и хорошими объяснениями.


https://overreacted.io/what-does-use-client-do/

#development #javascript #react #reactServerComponents #danAbramov

You can serialize a promise in React

Еще одна статья, связанная с серверными компонентами. Но на этот раз идеи из нее можно использовать и вне React. Легко передать данные между беком и фронтом, если они легко конвертируются в JSON. Но как передать Promise? Ведь он не сериализуется

const promise = new Promise((resolve) => {
  setTimeout(() => resolve("Hello!"), 1_000);
});

const json = JSON.stringify(promise); // => '{}'

Чтобы сериализовать Promise нужно придумать какой-то свой протокол передачи его состояния и значения.

Один из способов - использовать Stream. При создании промиса отправляем в поток сообщение promise:create, при резолве промиса отправляем в поток текстовое сообщение, содержащее результат промиса

function serializePromise(promise) {
  const stream = new ReadableStream({
    async start(controller) {
      controller.enqueue("promise:create");

      const value = await promise;
      controller.enqueue(`promise:resolve:${value}`);
      controller.close();
    },
  });

  return stream;
}

Теперь надо сделать функцию, которая будет считывать этот поток и преобразовывать его в Promise на принимающей стороне

function deserializePromise(stream) {
  const reader = stream.getReader();

  let promise;
  let resolver;
  let unlock;

  let didUnlock = false;
  const lockUntilReady = new Promise((resolve) => {
    unlock = (arg) => {
      resolve({ promise: arg });
      didUnlock = true;
    };
  });

  async function readStream() {
    const { done, value } = await reader.read();

    if (done) {
      if (!didUnlock) {
        unlock();
      }
      return;
    }

    if (value === "promise:create") {
      promise = new Promise((resolve) => {
        resolver = resolve;
      });
      unlock(promise);
    } else if (value.startsWith("promise:resolve:")) {
      const result = value.split(":")[2];
      resolver(result);
    }

    readStream();
  }

  readStream();

  return lockUntilReady;
}

Примерно так и работает сериализация промисов в серверных компонентах React. Сервер отсылает особые события и умеет сериализовывать много чего в строки, а клиент считывает поток и десериализует это в Promise и резолвит его десериализованным ответом.

Хорошая статья с интерактивными примерами. Рекомендую посмотреть т.к. сама задача передачи стейта промиса достаточно интересная.


https://twofoldframework.com/blog/you-can-serialize-a-promise-in-react

#development #javascript #react #reactServerComponents #Promise

Дайджест за 2025-05-12 - 2025-05-16

Giving V8 a Heads-Up: Faster JavaScript Startup with Explicit Compile Hints
В движок V8 добавили возможность указать хинт, что скрипт необходимо скомпилировать как можно быстрее. Это достаточно низкоуровневая оптимизация перформанса, которую нужно использовать осторожно.

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

Обзор на обучение в стратоплане
Продолжаем обзоры на обучение менеджменту в стратоплане. Модуль получился слишком расфокусированным, без единой линии повествования: было про типы команд и структур, было про целеполагание (OKR & KPI), про модели команд и роль лидера, про конфликты и поиск win-win решения.

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

Обзор на доклады Codefest 15
Скоро (31 мая - 1 июня) пройдет Codefest - разнонаправленная IT-конференция в Новосибирске. Если приедете на конференцию - можем там увидиться - буду присутствовать там оба дня. Обещаю интересные доклады и уютную атмосферу.

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

What Does "use client" Do?
Пост в блоге Дэна Абрамова про серверные компоненты. Точнее пост про концепцию use client и use server, но по факту это про концепцию серверных компонентов.

В посте Дэн рассказывает, какая идея вложена в use client и use server. Когда мы делаем приложение, которое имеет и бэк и фронт, то для взаимодействия между фронтом и беком необходимо использовать особые способы коммуникации, вместо простого вызова функции. Чтобы вызвать бэк с фронта - надо делать сетевой запрос, а чтобы бэку что-то сообщить для фронта - надо как-то передавать данные для рендера.

You can serialize a promise in React
Еще одна статья, связанная с серверными компонентами. Но на этот раз идеи из нее можно использовать и вне React. Легко передать данные между беком и фронтом, если они легко конвертируются в JSON. Но как передать Promise? Ведь он не сериализуется



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

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

TypeScript is Like C#: A Backend Guide

Если вы знаете Typescript, то вам легко будет научиться писать на C#. Что, в общем-то, не удивительно, т.к. один и тот же человек приложил свои руки и ум к созданию обоих языков.

По ссылке - гайд для тех разработчиков, которые знают TS и хотели бы научиться писать на С#.

https://typescript-is-like-csharp.chrlschn.dev/

#development #typescript #csharp

Storybook 9 is now in beta

Вышла бетка 9го Storybook. Прям новшеств мало т.к. команда Storybook презентует все заранее, но почитать интересно.

Что нового завозят в Storybook 9:

Новые возможности для автоматического тестирования в Storybook
Storybook поддерживает написание различных видов автотестов.
Для компонентных тестов (которые запускаются через vitest) появился виджет для их запуска из UI сторибука
Также из UI-сторибука можно запускать: interaction-тесты (грубо говоря, взаимодействие с компонентами в реальном браузере), accessibility тесты и визуальные тесты.

Кроме того, добавили возможность смотреть Coverage по тестам. Там обычный Coverage отчет, который вы уже видели, если когда либо занимались анализом тестового покрытия. Этот отчет доступен по кнопке из UI storybook.

Облегчение storybook в 2 раза
Про это они уже писали (а я публиковал в канале) - ребята оптимизировали собираемый нпм пакет и он теперь весит в 2 раза меньше

Тэги
Истории можно тегировать, а Storybook теперь умеет фильтровать истории по тегам, что удобно для поиска, но может быть использовано и для других фич.

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

https://storybook.js.org/blog/storybook-9-beta/

#development #javascript #storybook #releaseNotes

Parents & Owners in React: Context Providers

Статья про то, как правильное разделение ответственности компонентов в React может улучшить перформанс приложения.

В статье вводятся 2 понятия, относительно взаимодействия компонентов: родитель и владелец (Parent & Owner). Родитель-ребенок - достаточно очевидная связь - это когда один компонент является для другого родителем в дереве компонентов React. Владелец - это когда один компонент рендерит другой в коде.

Проще всего показать на примере из статьи

function App() {  
  const [count, setCount] = useState(0);  

  return (  
    <CounterContext.Provider value={count}>  
      <CounterDisplay />  
      <UnrelatedComponent />  
      <Toolbar />  
    </CounterContext.Provider>  
  );  
}

CounterDisplay имеет родителем CounterContext.Provider, но владельцем App. Этот компонент будет ререндерится в случаях, когда выполняется ререндер и родителя и владельца.

Например, при обновлении счетчика из useState, будут ререндерится все компоненты, даже те, которым счетчик не нужен. Чтобы этого избежать, надо правильно разделить ответственность между родителем и владельцем. В данном случае, достаточно вынести useState в кастомный провайдер, чтобы при обновлении счетчика обновлялись только нужные компоненты.

В статье крутая визуалиация Parent Tree, Owner Tree и хранителя состояния. Она простая и понятная. Такой тип визуализации можно использовать и в своих проектах, при обсуждении структуры компонентов и объяснении того, какой она должна быть


https://julesblom.com/writing/parent-owners-context

#development #javascript #react

Дайджест за 2025-05-19 - 2025-05-21

TypeScript is Like C#: A Backend Guide
Если вы знаете Typescript, то вам легко будет научиться писать на C#. Что, в общем-то, не удивительно, т.к. один и тот же человек приложил свои руки и ум к созданию обоих языков.

По ссылке - гайд для тех разработчиков, которые знают TS и хотели бы научиться писать на С#.

Storybook 9 is now in beta
Вышла бетка 9го Storybook. Прям новшеств мало т.к. команда Storybook презентует все заранее, но почитать интересно.

Что нового завозят в Storybook 9:

Parents & Owners in React: Context Providers
Статья про то, как правильное разделение ответственности компонентов в React может улучшить перформанс приложения.

В статье вводятся 2 понятия, относительно взаимодействия компонентов: родитель и владелец (Parent & Owner). Родитель-ребенок - достаточно очевидная связь - это когда один компонент является для другого родителем в дереве компонентов React. Владелец - это когда один компонент рендерит другой в коде.

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

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

ForesightJS

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

Наверное можно придумать и другие юзкейсы. В целом библиотека прикольная. Рекомендую зайти на сайт проекта и поиграться с предиктом, это достаточно забавно.

https://foresightjs.com

#development #javascript #library #mouse

Snapdom

Зумеры изобрели скриншоты страниц. Ну точнее компания Zumerlab, которые делают Zumly, выложили библиотеку SnapDOM, которая делает экспорт DOM-элементов в виде картинок. По ссылке есть демка, где наглядно показаны разные кейсы.

https://github.com/zumerlab/snapdom

#development #javascript #library #screenshot

6 Ways Slack, Notion, and VSCode Improved Electron App Performance

Статья про основные перформанс фишки приложений на Electron. Разобраны кейсы популярных приложений: Slack, Notion, VSCode, Atom и другие

Первый кейс как раз из Atom. Atom долгое время очень долго стартовал. Разраб из гугла решил разобраться, что является причиной долгого старта. Он обнаружил, что проблемой являются require. При каждом require необходимо:
- Зарезолвить модуль
- Считать контент файла
- Скомпилировать модуль
- Запустить модуль
Это блокировало основной тред. Поэтому одна из оптимизаций перформанса - бандлить код для электрон-приложения

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

Третья оптимизация - выносить сложные вычисления на WASM или в нативные модули.
Примеры нативных модулей в Electron-приложениях:
- Notion компилирует SQLite в WASM
- Figma полностью на WASM
- Signal использует WASM для криптографии
- 1Password использует WASM для криптографии

Следующая оптимизация - использовать снапшоты V8 для ускорения запуска. Эта фича позволяет сохранить снапшот памяти V8 и, вместо честной загрузки модулей, загружать снапшот памяти в процесс. У этого способа есть разные ограничения (не должно быть динамических данных, IO операций и все такое). Atom ускорил запуск приложения в 2 раза, использовав снапшоты. VSCode также использует снапшоты

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

Последний пункт также, скорее про инструмент мониторинга - это сбор инфы из профилировщика перформанса прямо с устройства пользователя. Первый раз о таком слышу, но в статье пишут, что Facebook начал такое популяризировать еще в 2021 году. Насколько я понял, в Electron есть API-доступ к DevTools, через которые уже можно снять полноценный замер перформанса при работе приложения. Мощный инструмент. Notion, используя эту технику, ускорил приложение на 15-20%, а также ускорил обнаружение и разбор проблем перформанса.

https://palette.dev/blog/improving-performance-of-electron-apps

#development #javascript #electron #performance

ESLint v9.0.0: A retrospective

В апреле прошлого года вышел Eslint 9.0.0 - мощный мажорный релиз. Команда Eslint выпустила ретроспективу по запуску новой версии eslint - выделили, что было сделано хорошо, а с чем вышли проблемки.

Что прошло хорошо:

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

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

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

Что пошло плохо

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

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

Экосистема медленно мигрировала на новую версию eslint. Ожидалось, что авторы плагинов и конфигов сделают миграцию более менее быстро, но это оказалось не так. В итоге сложилась такая ситуация, когда v8 все еще работает и получает обновления, а авторам пакетов надо опубликовать новую версию, которая будет совместима с v9, но не v8. Команда Eslint предполагала что все быстро переедут и поэтому не подготовила каких-то решений для того, чтобы авторы пакетов могли публиковать пакет, который будет совместим и с 8 и 9 версиями.

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




https://eslint.org/blog/2025/05/eslint-v9.0.0-retrospective/

#development #javascript #eslint

Announcing TypeScript Native Previews

Компилятор Typescript, написанный на Go, доступен для раннего использования. Говорят, что для большинства проектов компилятор ускорился в 10 раз. Компилятор доступен как npm-пакет и как расширение для vscode.

Играться уже можно, но следует помнить, что часть функционала еще не перенесена.

Со времени предыдущего поста про tsgo, перенесли поддержку JSX. Как пример ускорения приводят проверку Sentry. Typescript 5.8 проверяет проект за 72 секунды (9306 файлов), а tsgo за 6 секунд (9292 файлов). Выглядит мощно

Также перенесли поддержку JSDoc.

https://devblogs.microsoft.com/typescript/announcing-typescript-native-previews/

#development #typescript #go

Дайджест за 2025-05-26 - 2025-05-30

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

Наверное можно придумать и другие юзкейсы. В целом библиотека прикольная. Рекомендую зайти на сайт проекта и поиграться с предиктом, это достаточно забавно.

Snapdom
Зумеры изобрели скриншоты страниц. Ну точнее компания Zumerlab, которые делают Zumly, выложили библиотеку SnapDOM, которая делает экспорт DOM-элементов в виде картинок. По ссылке есть демка, где наглядно показаны разные кейсы.

https://github.com/zumerlab/snapdom

6 Ways Slack, Notion, and VSCode Improved Electron App Performance
Статья про основные перформанс фишки приложений на Electron. Разобраны кейсы популярных приложений: Slack, Notion, VSCode, Atom и другие

Первый кейс как раз из Atom. Atom долгое время очень долго стартовал. Разраб из гугла решил разобраться, что является причиной долгого старта. Он обнаружил, что проблемой являются require. При каждом require необходимо:

ESLint v9.0.0: A retrospective
В апреле прошлого года вышел Eslint 9.0.0 - мощный мажорный релиз. Команда Eslint выпустила ретроспективу по запуску новой версии eslint - выделили, что было сделано хорошо, а с чем вышли проблемки.


Announcing TypeScript Native Previews
Компилятор Typescript, написанный на Go, доступен для раннего использования. Говорят, что для большинства проектов компилятор ускорился в 10 раз. Компилятор доступен как npm-пакет и как расширение для vscode.

Играться уже можно, но следует помнить, что часть функционала еще не перенесена.

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

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

A Brief History of JavaScript

Javascript'у в этом году 30 лет! В честь этого Deno в своем блоге сделали блог-пост с короткой историей JS в виде таймлайна. Осторожно, от некоторых скриншотов в посте возникает приступ ностальгии (как, например, первая версия хрома в windows XP).

Достаточно интересное чтиво, хотя и не очень полезное.

https://deno.com/blog/history-of-javascript

#development #javascript #history

Progressive JSON

Статья от Дэна Абрамова про реализацию Progressive JSON, которая понадобилась в react server components. Это отсылка к Progressive JPEG - это jpeg, который закодирован так, что получив первые байты с данными, браузер уже может отрендерить что-то размытое. По мере дозагрузки данных картинка становится четче.

К сожалению, JSON такой формат, который не Progressive из коробки. Если вы получили первую порцию данных, то попытка сделать JSON.parse вызовет ошибку.

Например мы имеем такой json

{
  header: 'Welcome to my blog',
  post: {
    content: 'This is my article',
    comments: [
      'First comment',
      'Second comment',
      // ...
    ]
  },
  footer: 'Hope you like it'
}

Если с сервера успеет придти только

{
  header: 'Welcome to my blog',
  post: {
    content: 'This is my article',
    comments: [
      'First comment',
      'Second comment'

То мы можем предположить, что скобки необходимо закрыть

{
  header: 'Welcome to my blog',
  post: {
    content: 'This is my article',
    comments: [
      'First comment',
      'Second comment'
      // (The rest of the comments are missing)
    ]
  }
  // (The footer property is missing)
}

Но наш код может ожидать footer, и непонятно, будут ли еще какие-то данные или нет. Вместо такого подхода Дэн Абрамов предлагает реализовать стриминг JSON по уровням вложенности:
- Сначала отсылаем верхнеуровневую структуру полей
- Затем досылаем значения полей
- Если полученное поле само является объектом - данные по нему будут досланы позже

В данном примере это выглядит так
Первая отправка

{
  header: "$1",
  post: "$2",
  footer: "$3"
}

Вторая отправка

/* $1 */
"Welcome to my blog"
/* $3 */
"Hope you like it"

Теперь клиент может собрать

{
  header: "Welcome to my blog",
  post: "$2",
  footer: "Hope you like it"
}

Третья порция данных

/* $2 */
{
  content: "$4",
  comments: "$5"
}
/* $4 */
"This is my article"

Теперь клиент может собрать

{
  header: "Welcome to my blog",
  post: {
    content: "This is my article",
    comments: "$5"
  },
  footer: "Hope you like it"
}

Таким образом, можно досылать данные и делать прогрессивный JSON. И такой стриминг а) реализован в react server components; б) удобен для прогрессивного появления UI

В статье описано больше технических подробностей. Я лишь прошелся по верхам.

https://overreacted.io/progressive-json/

#development #javascript #JSON #abramov

Web Vitals: что это и как мы их собираем?

На выходных прошла конференция Codefest, на которой было много интересных докладов. Записей пока нет, но я опишу в канал свои заметки про пару докладов и скину пару полезных ссылок.

Доклад "Web Vitals: что это и как мы их собираем?", очевидно из названия, рассказывает про метрики производительности. Буквально на каждой конференции, где есть фронтенд, кто-то рассказывает про эти метрики. Тем не менее, хочется выделить этот доклад как очень хороший по подаче и качеству обзора метрик и инструментов

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

По поводу информации в докладе. Доклад делится на 2 части:
- Собственно про сами метрики Web Vitals - что это за метрики, какие есть рекомендации от гугла, из каких браузеров они собираются. Это ожидаемая общая часть всех докладов про перформанс
- Менее ожидаемая часть - про инструменты. Роман рассказал про то, как они в Дроме собирают эти метрики, как за ними следят и какие вообще есть инструменты для слежения за этими метриками

Расскажу подробнее про инструменты.

Самый очевидный инструмент - Lighthouse, который встроен в Chrome. Из плюсов: можно запускать локально, можно запускать в CI.
Примерно похожий отчет можно получить в Pagespeed Insights. Вставляете урл до вашего сайта и смотрите, что у него по метрикам.

Другой крутой инструмент - WebPageTest. Я им сам неоднократно пользовался. Можно использовать как облачный вариант, так и развернуть его у себя. WebPageTest - супер мощный инструмент.
Он позволяет:
- Посмотреть каждый запрос, отправляемый браузером и на что было потрачено время (установка соединения, ssl-handshake и тд)
- Вставить кастомные куки или параметры запроса
- Писать скрипты. Мы так замеряли скорость работы пользовательских сценариев
- Сравнивать несколько прогонов, причем как в виде метрик, так и в виде видео
Также есть супер похожий опенсорсный инструмент - https://www.sitespeed.io. Его я тоже использовал. Умеет практически все тоже самое что и webpagetest. Строго рекомендую

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

Первый из таких инструментов - Chrome UX report. Есть веб интерфейс, где можно вставить ссылку на сайт и посмотреть метрики реальных юзеров за большой срок. Показывается 75-й персентиль метрик.

Другой подходящий инструмент, внезапно, Sentry. Оказывается в Sentry есть модуль для сбора Web Vitals с пользователей и Sentry умеет строить графики по этим данным.

Третий путь - собирать метрики самому. Роман показывает, как их собирать, отсылать, агрегировать - все это можно делать по-разному. Например, можно самому собирать метрики с нужной точностью, а можно взять пакет web-vitals и получить метрики через функции пакета.

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

В общем, хороший доклад. Как будет доступна запись - обязательно скину.



#development #javascript #performance #note #codefest

Дайджест за 2025-06-02 - 2025-06-05

A Brief History of JavaScript
Javascript'у в этом году 30 лет! В честь этого Deno в своем блоге сделали блог-пост с короткой историей JS в виде таймлайна. Осторожно, от некоторых скриншотов в посте возникает приступ ностальгии (как, например, первая версия хрома в windows XP).

Достаточно интересное чтиво, хотя и не очень полезное.

Progressive JSON
Статья от Дэна Абрамова про реализацию Progressive JSON, которая понадобилась в react server components. Это отсылка к Progressive JPEG - это jpeg, который закодирован так, что получив первые байты с данными, браузер уже может отрендерить что-то размытое. По мере дозагрузки данных картинка становится четче.

К сожалению, JSON такой формат, который не Progressive из коробки. Если вы получили первую порцию данных, то попытка сделать JSON.parse вызовет ошибку.

Web Vitals: что это и как мы их собираем?
На выходных прошла конференция Codefest, на которой было много интересных докладов. Записей пока нет, но я опишу в канал свои заметки про пару докладов и скину пару полезных ссылок.

Доклад "Web Vitals: что это и как мы их собираем?", очевидно из названия, рассказывает про метрики производительности. Буквально на каждой конференции, где есть фронтенд, кто-то рассказывает про эти метрики. Тем не менее, хочется выделить этот доклад как очень хороший по подаче и качеству обзора метрик и инструментов

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

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

A new way to style gaps in CSS

Пост в блоге Хрома про новые возможности стилизации отступов в CSS. Раньше для решения адачи приходилось использовать разные обходные пути, которые ухудшали доступность, читаемость, перформанс и вообще были сложными. Теперь же браузеры в рамках экспериментальных фич завезли стилизацию отступов через column-rule и new-rule

Поиграться в песочнице можно тут. Также в посте указаны ссылки и скриншоты разных демок новой фичи. Выглядит очень круто.

https://developer.chrome.com/blog/gap-decorations/

#development #css

Jest 30: Faster, Leaner, Better

Анонсировал Jest 30. Обычно я про jest не пишу т.к. каждый раз сгораю от работы с ним, однако в 30 релиз завезли улучшения перформанса и несколько полезных плюшек

Остановлюсь на улучшении перформанса. Тот кто профилировал работу jest и пробовал выяснить, почему же сам describe отрабатывает за 100мс, а весь тест-ран за 10 секунд, примерно представляют насколько все плохо у jest с резолвом зависимостей. И вот в 30 jest завезли улучшения резолва модулей, который потребляет меньше памяти и ускоряет запуск тестов. На бенче от Jest сравниваются серверные и клиентские тесты. Серверные стали потреблять в 4 раза меньше памяти и ускорились на половину. Клиентские уменьшили потребление на 20% и ускорились где-то на 10. Итоговые цифры будут отличаться от проекта к проекту. Тесты в Happo ускорились с 14 минут до 9 при обновлении Jest

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

Что еще завезли, кроме перформанса
- Изоляция тест-файлов через VM Context
- Улучшенная поддержка ES Module
- Если запущена Nodejs с опцией вырезания типов, то Jest не будет тянуть ts компилятор для сборки файлов (когда прочел, понял, что это еще 1 пункт, который меня удивил в последней попытке профайлинга перформанса jest - чтобы загрузить конфиг jest.config.ts, jest подгружает tsc и инициализирует его)
- Поддержка using для spy. using spy = jest.spyOn(console, 'warn'); Такое использование автоматически подчистит spy в конце текущего блока
- Новая проверка - expect.arrayOf
- test.each поддерживает плейсхолдер %$ (читаемость, конечно, не учитывали. Спасибо что не эмоджи), который всталвяет порядковый номер текущего кейса.
- jest.advanceTimersToNextFrame() позволяет двинуть таймер для запуска следующих requestAnimationFrame
- Ретрай теперь конфигирируемый - можно указать время между ретраями
- setupFiles и setupFilesAfterEnv теперь умеют в асинхронные функции. Наконец-то!

https://jestjs.io/blog/2025/06/04/jest-30

#development #javascript #jest #release #performance

Part 7: Office Migration from Source Depot to Git, or how I learned to love DevEx.

История от Microsoft Office, как они мигрировали в Git. В статье очень мало технических подробностей. Тем не менее, её достаточно интересно почитать.

Почему вообще MS Office не в Git:
1. Когда MS Office переходил на систему контроля версий, git еще не существовало. Поэтому Microsoft реализовали свой CVS - Source Depot. В то время это был прорыв, но сейчас он неудобен в использовании.
2. MS Office огромный. 4000 инженеров, которые поддерживают кодовую базу на 200гб. Git не умеет или не умел работать с такими большими базами - любые изменения вносились очень долго

Почему переехать в Git сложно:
- Во первых, из-за размеров репозитория. Как я писал выше, git будет работать очень долго в таком огромном репозитории. Поэтому Microsoft в свое время сделала Virtual File System for Git - виртуальная файловая система, которая позволила клонировать не весь репозиторий, а только нужные файлы
- Переехать надо между мажорными релизами офиса - это достаточно жесткий дедлайн (я не до конца понял, откуда появилось это условие)
- Для плавной миграции необходимо уметь синхронизировать состояние кода в Source Depot и Git. Т.к. идеология систем отличается, то это нетривиальная задача. Ее решили только с 3го раза
- Надо переобучить всех разработчиков (самый легкий пункт)

Как состоялся переезд:
- Фаза 1: создали параллельный Git репозиторий, который синхронизировался с Source Depot. Работать можно было в любом из репозиториев
- Фаза 2: гарантия эквивалентности продукта. Нужно подтвердить, что сборка того, что хранится в Git, полностью эквивалентна сборке в Source Depot. Т.к. продукт старый, то у него было очень много своих нюансов при сборке, которые надо было исправить или повторить в git
- Были организованы общие каналы коммуникации и план "что делать если все пойдет не так"
- Провели обучение сотрудников, решая разные риски (страх все сломать, страх изменений и тд и тп)
- Дали возможность переехать в Git.

В итоге, почти все разработчики переехали в Git и продуктивность разработчиков (на основе внутренних опросов) стала лучше

https://danielsada.tech/blog/carreer-part-7-how-office-moved-to-git-and-i-loved-devex/

#development #git #migration #msoffice