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

Impossible Components
Статья от Дэна Абрамова про новые возможности, которые открываются при использовании Server Components. А именно - возможность писать единый код, часть которого исполняется на сервере, а часть на клиенте. Бесшовная интеграция значительно повышает DX и выразительность решений.

Дэн доходчиво показывает основные возможности и объясняет концепции серверных компонентов, раскрывая эти идеи последовательно и с хорошими примерами кода.

Spectacle
Библиотека для создания презентаций на React. Выглядит неплохо, надо будет попробовать как нибудь. Большой плюс - наличие готовых лейаутов для слайдов (список, колонки, картинка справа, картинка сверху и другие базовые лэйауты).


Advanced React in the Wild: Часть №1
Большой пост про исследование перформанса больших веб приложений. В статье рассмотрены варианты улучшения перформанса для разных приложений - кому-то важно SEO, кому-то скорость переключения роутов. Все кейсы - кейсы реальных компаний с замерами.

Обзор всех кейсов не влезет в 1 пост в телеге, поэтому будет целых 2 поста

Advanced React in the Wild: Часть №2
Продолжаем читать большое исследование перформанса веб-проектов. Следующая компания - DoorDash. Приложение рендерится только на клиенте и оно очень большое - долго грузится, огромный JS-бандл, плохие SEO-метрики. При загрузке сайта пользователи долго наблюдают белый экран.


Advanced React in the Wild: Часть №3
Заключительная часть. Какие итоги можно вынести из этих кейсов?


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

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

proposal Composites

TC39 - комитет стандартизации ES - дропнул пропозал Tuple & Records в пользу Composites

Composites - это сущность, которая
- Оборачивает объект и дает доступ к его свойствам
- Неизменяема (нельзя добавлять, удалять, менять свойства)
- 2 композита, имеющие одинаковые свойства и значения - идентичны

Проще, конечно, показать примером

const pos1 = Composite({ x: 1, y: 4 });
const pos2 = Composite({ x: 1, y: 4 });
Composite.equal(pos1, pos2); // true

const positions = new Set(); // the standard ES Set
positions.add(pos1);
positions.has(pos2); // true

const c = Composite({ x: 1, y: 2 });
Object.keys(c); // ["x", "y"]
c.x; // 1
c.y; // 2

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

https://github.com/tc39/proposal-composites

#development #javascript #tc39 #proposal

Scale Your Project with Layered React Structure

Еще одна рекомендация по организации файлов и сущностей в React-проектах. В целом, конечно, ничего нового - есть сущности, у каждой сущности своя папка. Сущность-интегратор (в данном случае View) может содержать свою под-структуру с папками-сущностями более низкого порядка. Все то что мы и так делали без FSD и других рекомендаций.

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

Что же предлагает автор в своем гайде:

Компоненты деляться на умные и глупые. Глупые - содержат только верстку и другие глупые компоненты. Умные - содержат бизнес-логику и не содержат никакой верстки. Это позволяет отделить бизнес-логику от верстки, а также закинуть все глупые компоненты в сторибук. Умные компоненты тестируются с помощью vitest и testing-library

Функции делятся на утилки и сервисы. Принцип делениz меня, прямо скажем, удивил. Если функция возвращает промис - это сервис. Если функция синхронная - это утилка.

Если есть какая-то сущность в коде - ей нужна отдельная папка. Автор, в дополнении к уже указанным мной сущностями, выделил еще хуки, асеты, типы. Но суть тут в принципе - если вы выделяете какую-то сущность, для нее нужна папка. Например, вы делаете проект где много валидаций - выделите функции-валидации в отдельную папку Validators.

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

https://playfulprogramming.com/posts/layered-react-structure

#development #javascript #react #fileStructure

Custom CSS Functions in the Browser

В хром 136+ за экспериментальным фиче-флагом доступна новая крутая фича - определение собственных функций в CSS. Это тот кейс, когда лучше 1 раз увидеть код, чем 10 раз про него прочесть

Функция возвращает dark, если юзер предпочитает темную тему, и light, если это не так

@function --media-scheme() {
  result: light;
  @media (prefers-color-scheme: dark) { result: dark; }
}

:root {
  --color-scheme: --media-scheme();
}

Добавляет прозрачность цвету

@function --transparent(--color, --alpha: 0.8) {
  result: oklch(from var(--color) l c h / var(--alpha);
}

dialog {
  background: --transparent(black); /* black at default 0.8 opacity */
}

Во первых: выглядит круто! И одновременно немного пугающе - нам хватает дебагинга JS, а css воспринимается как код, который просто работает и в него редко надо залезать и там сложно накосячить - в будущем это может быть не так.
Во вторых: возможно снова увидим вакансии на css-программиста и css-архитектора (это, конечно же, шутка. Но, как известно, в каждой шутке есть доля правды)

https://www.oddbird.net/2025/04/11/custom-functions/

#development #javascript #react #fileStructure

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

proposal Composites
TC39 - комитет стандартизации ES - дропнул пропозал Tuple & Records в пользу Composites


Scale Your Project with Layered React Structure
Еще одна рекомендация по организации файлов и сущностей в React-проектах. В целом, конечно, ничего нового - есть сущности, у каждой сущности своя папка. Сущность-интегратор (в данном случае View) может содержать свою под-структуру с папками-сущностями более низкого порядка. Все то что мы и так делали без FSD и других рекомендаций.

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

Custom CSS Functions in the Browser
В хром 136+ за экспериментальным фиче-флагом доступна новая крутая фича - определение собственных функций в CSS. Это тот кейс, когда лучше 1 раз увидеть код, чем 10 раз про него прочесть



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

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

Giving V8 a Heads-Up: Faster JavaScript Startup with Explicit Compile Hints

В движок V8 добавили возможность указать хинт, что скрипт необходимо скомпилировать как можно быстрее. Это достаточно низкоуровневая оптимизация перформанса, которую нужно использовать осторожно.

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

Ключевой вопрос в том, как выбрать те самые функции, которые необходимо компилировать сразу. Команда провела исследование, что при корректном выборе функции для компиляции на старте, то 17 из 20 популярных веб сайтов ускорятся на 630мс - звучит достойно.

Поэтому команда V8 разрабатывает возможность управлять этим поведением. На данный момент сделали возможность указать весь скрипт как критичный к компиляции. Делается это с помощью комментария

//# allFunctionsCalledOnLoad
function testfunc2() {  
   console.log('testfunc2 called!');
}

testfunc2();

Ожидаем развития этого функционала и разбора реальных кейсов в статьях и докладах.

https://v8.dev/blog/explicit-compile-hints

#development #javascript #v8 #performance

Обзор на обучение в стратоплане

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

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

В данном посте расскажу про то, как разные концепции по-разному смотрят принципы объединения людей в команды. Рассматриваемые концепции: PMBoK, Spotify Model и Team Topologies

Начнем с PMBoK. PMBoK - это "библия" проектного менеджмента. Огромный труд про то, как вести проекты. Периодически он обновляется и выпускается новая редакция.

Основные типы орг структур по PMBoK

Проектно-ориентированная структура:
- Команды собираются вокруг проектов
- Менеджер проекта имеет полную власть в рамках своего проекта
- По завершении проекта команды распускаются или переходят в другой проект

Функциональная структура:
- Команды собираются вокруг функций (например отдел разработки, отдел тестирования, отдел маркетинга)
- Менеджер проекта выполняет координирующую роль и имеет мало полномочий.

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

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

Как мы видим, PMBoK выделяет типы орг структур на основе роли проджект менеджера и управления ресурсами для достижения проектов.

Основная проблема при выборе орг структуры: у нас есть центры компетенций (отвечают за скилы) и центры по проектам (делают бизнес вэлью)

Что говорит об организации команд Spotify Model
В Spotify Model выделяются следующие типы структур:
- Squad (отряд) - небольшие (6-12 человек) команды, которые доставляют какую-то ценность.
- Tribe (племя) - объединение отрядов в нечто большее, объединенное общей целью
- Chapter (собор или церковь) - сбор людей в рамках профессии или компетенции для обмена опытом
- Guild (гильдия) - объединение людей по интересам. Например, гильдия перформанса

Spotify Model в первую очередь фокусируется на автономности команд и обмене знаний. Но, как и у матричной структуры в PMBoK, можно выделить 2 независимых направления: squad&tribe - проектные, а chapter&guild - функциональные

Team Topologies
Здесь буду краток т.к. недавно уже был обзор на книгу ( ищется по тегам #teamTopology #конспект). Team Topologies близок по духу к Spotify Model и акцентируется на командах по доставке ценности, но выделяет и другие типы команд, перенося некоторые функциональные вещи в полноценные команды (команда по развитию автоматизированного тестирования), но также оставляя простор для сообществ по компетенциям.

Итог
Нужно уметь балансировать между двумя крайностями в структуре управления и коммуникаций: вокруг бизнес ценности и вокруг компетенций. Нежелательно впадать только в 1 крайность, нужно уметь держать баланс

---

17 мая в 11:00 по МСК будет проходить бесплатный воркшоп "Сложные переговоры" от Стратоплана. Кажется, там ещё дадут скидку на полноценное обучение. В начале поста я жаловался на расфокусированное обучение, но практические занятия по переговорам и решению конфликтов от Стратоплана строго рекомендую - материал дают хорошо + дают инструкцию, как применять на практике.



#note #stratoplan #managment

Обзор на доклады Codefest 15

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

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

Канал про веб, поэтому в первую очередь глянем доклады по вебу.

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


AI-ассистенты: как начать использовать сегодня, а не с понедельника (и не бросить после релиза)
AI это хайп. Но если раньше доклады были в стиле "залетайте в этот хайп-трейн, тут класно", то теперь появляются доклады в стиле "как использовать правильно и не попасть в ловушку". Этот доклад про правильное использование и ловушки.

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


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


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

Используем различные архитектуры внутри FSD
Из названия и тезисов непонятно, про что будет доклад, но будет что-то про архитектуру (в каком-то её понимании) и FSD. Есть шансы что будет хорошо, есть шансы что будет что-то странное. В любом случае, интересно посмотреть.

Конкурентоспособность: начало
Много внимания уделяем перформансу, но, как правило, не можем сформулировать, какие показатели скажут, что все хорошо, а какие - что все плохо. Один из интересных подходов - сравнивать свой продукт с конкурентами. Если он быстрее - значит перформанс хороший. Если нет - значит плохой. Доклад про то, как Лавка сделала такой мониторинг

Математика в CSS: что и зачем считать для стилей
Никита Дубко покажет приколюхи из CSS, которые позволяют сделать wow-интерфейсы. Никита всегда делает классные доклады, поэтому уверен в качестве и материала и подачи.

Есть еще несколько докладов по вебу, но хочется еще показать 2 доклада с QA-трека
Почему разработчики не доверяют AI свои тесты?
Как нейросети обещали ускорить тестирование, а сделали только хуже
Оба доклада про анти-паттерны и бест-практисы при написании автотестов. Т.к. автотесты - это, имхо, неотъемлемая часть работы разработчика, а AI - новый базовый инструмент, то оба доклада могут забустить вашу продуктивность.

https://15.codefest.ru/program

#note #codefest

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