Дайджест за 2025-04-21 - 2025-04-25

Introducing Zod 4 beta
Спустя несколько лет с выхода Zod v3 выпустили бетку Zod v4. Zod - библиотека для валидации объектов на мэтч с переданной схемой.

В 4-м релизе увеличили скорость работы валидации и работы TS по валидации типов, уменьшили размер бандла, добавили новые удобные API. Если вы используете Zod - рекомендую запланировать обновление.

The new Cookie Store API
Внезапно узнал, что уже 4 года как существует новое API для работы с куками, которое давно доступно в Chrome, недавно стало доступно в Safari и все еще недоступно в Firefox - Cookie Store API

Новое API намного удобнее. Хотя любое API, по сравнению со старым, будет удобнее.

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

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

Impossible Components

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

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

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

Строго рекомендую к прочтению

https://overreacted.io/impossible-components/

#development #javascript #react #reactServerComponents #danAbramov

Spectacle

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

https://nearform.com/open-source/spectacle/

#development #javascript #react #library #presentations

Advanced React in the Wild: Часть №1

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

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

Итак, первый кейс - компания Vio.com. Компания имела плохой скор Interaction to Next Paint (INP). Т.е. было большое время между взаимодействимем с элементов на странице и перерисовкой интерфейса. Рекомендация от гугла - 200ms. Цифра Vio - 380ms. Google в марте 2024 официально заявила, что INP является одним из фактором для ранжирования в поисковой выдаче

Что сделали в Vio

Провели анализ перформанса с помощью Chrome DevTools и Lighthouse, обнаружили проблемы, разметили код кастомными User Timing метками и поработали с React профайлером и обнаружили ключевые ботлнеки в перформансе приложения. В частности, обнражили reflow, из-за которого браузер ререндерил слишком много элементов

Более агрессивно разделили код на асинхронные чанки с помощью React.lazy и Suspense. Таким образом, они уменьшили код, необходимый для первоначальной работы страницы.

Также они обнаружили, что слишком частая обработка некоторых событий блокировала главный тред. Добавили дебаунсы.

Также обнаружили лишние ререндеры в React'е. Ререндерелись те части приложения, которые не должны были ререндерится. Добавили React.memo и useMemo в критичные места.

Обновили React до React18, что позволило перейти на concurrent rendering - это улучшило INP в 2 раза: на десктопе 450ms=>240ms, на мобилке: 1100ms => 500ms (хотя в начале исследования писалось что INP - 380ms. Откуда взялось такое разночтение (450 и 1100 vs 380) - я не понял).

Еще из интересных хаков - прерывание некритичной логики долгих обработчиков для освобождения main thread. При этом пример приведен немного странный - отправка аналитики. Отправка аналитики, по идее, и не должна блокировать основной поток, но да ладно. Одно из классических решений - перенести логику в воркер или сервис-воркер. Что сделали в Vio: откладывают выполнение части кода на другой тик с помощью промиса

async function yieldToMain() {
 return new Promise((resolve) => {
  setTimeout (resolve, 0);
 });
}
// Usage in tracking middleware
case trackEvent.type: {
 await yieldToMain();
 trackAnalyticsEvent();
 await yieldToMain();
 logEvent();
}

Решение максимально простое, но это позволило улучшить INP на 19% (улучшили на 120ms, и тут опять расхождения с заявляемыми в начале значениями)

Как улучшили ререндеры React'а:
- Разделили сложные кастомные хуки на маленькие
- Заменили React Router API на window.location везде где смогли
- Улучшили мемоизацию Redux селекторов

Это позволило ускорить INP еще на 45% (снова не могу не пожаловаться, но непонятно от чего считалось ускорение т.к. по тексту суммарное ускорение уже больше 100%, поэтому это явно не от начальных цифр, а от одной из предыдущих итераций)

Каких результатов достигли:
- INP улучшился с 380ms до 175ms
- Загружаемый JS уменьшили на 60%
- Уменьшили количество ненужных ререндеров
- Интерфейс стал отзывчивее

Что здесь важного:
- Не какая-то абстрактная теория, а практические советы
- Даны, с одной стороны, простые советы, а с другой стороны - действенные
- Перформанс улучшается не просто так, а для достижения целей бизнеса - необходимо предоставлять хороший сервис и встать выше в поисковой выдаче гугла
- Хорошая инженерная работа - провели анализ перформанса, нашли ботленки и проблемы, сделали улучшения, замерили метрики "до" и "после". Это перекликается с книгой, обзор на которую я кидал в канал - "Современная программная инженерия" - вместо того, чтобы сразу делать улучшения, необходимо собрать метрики и провести анализ, чтобы принять правильное решение о необходимых улучшениях и оценить результат

Продолжение будет завтра

https://largeapps.dev/case-studies/advanced/

#development #javascript #performance #research

Advanced React in the Wild: Часть №2

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

Что они сделали:

Во первых, начали переходить на Next.js для серверного рендеринга. Переход не моментальынй, а по-страничный.

Ключевые поинты при миграции:
- Использование ленивой гидрации. Чтобы оптимизировать скорость отдачи первого байта, некритичные компоненты подгружались лениво во время SSR. Это позволило ускорить отдачу первого контента + уменьшило нагрузку на CPU
- Сделали единый контекст для SSR и CSR. Оттуда следует доставать куки, урл и все другое, что зависит от окружения. Также в контексте присутствует флаг isSSR, что позволяет инкрементально подготавливать необходимые фичи на SSR.

Результаты:
- +12-15% ускорения загрузки страницы
- LCP улучшился на 65%
- Все это без глобальных переписываний - делали инкрементально и по шагам

Следующая компания - Preply
Проблема - плохой INP. Они посчитали, что улучшение INP может сохранить $200k в год. При этом приложение написано на старом Next.js, где нет серверных компонентов.

Что сделали:
- Провели анализ код с помощью девтулов и react-профайлера. Главная задача - разгрузить главный поток, поэтому оптимизировали ререндеры, рекомпозировали большие функции, оптимизировали циклы
- Завернули некритичные части интерфейса в Suspense, сделав гидрацию неблокирующей (фича React18)
- Оптимизировали тяжелые обработчики событий, которые делали сложные обновления стейта. Добавили к ним startTransition (React18 API для конкурентного режима), что пометило обработку как low-priority и React не забивал основной поток для обработки события. Также подключили дебаунс и тротлинг для частых событий
- Применили агрессивный код-сплиттинг
- Подключили CDN для асетов и части API, которое можно кешировать (если я правильно понял). Это позволило уменьшить сетевую задержку с 1.5s => 0.5s

Результаты:
- Улучшили INP 250ms=>175ms, перейдя в "зеленую" зону, с точки зрения оценки метрикой гуглом.

Следующая компания - GeekyAnts
Сайт компании имел Lighthouse скор около 50. Для консалтинговой компании это такое себе.

Что сделали:
- Обновили Next.js, перешли на серверные компоненты. Все неинтерактивное перенесли на сервер, что ускорило отдачу конента и уменьшило размер JS в браузере.
- Перенесли загрузку данных с браузера на сервер, что также значительно все ускорило
- Подключили оптимизации Next.js - код-сплиттинг, Image компонент, стриминг при SSR

Результат:
- Lighthouse скор улучшился до 90+
- Улучшился SEO

Последний кейс: Inggest
Проблема: белый экран при открытии сайта

Что сделали:
- Статичный пререндер + стриминг - позволили добиться хорошего UX. Там где можно пререндерить - они пререндерили. Там где нужны динамические данные - подключили стриминг
- Тюнили кэширование в Next.js. Добились мгновенного отображения некоторых страниц
- Улучшили DX за счет Next.js

Результаты:
- Вместо белого экрана при смене роута - шапка и футер стали отображаться моментально, а контент подгружался прогрессивно
- Улучшили UX и DX одновременно

https://largeapps.dev/case-studies/advanced/

#development #javascript #performance #research

Advanced React in the Wild: Часть №3

Заключительная часть. Какие итоги можно вынести из этих кейсов?

Оптимизация перформанса - крайне важна
- Оптимизируя Core Web Vitals вы улучшаете как опыт пользователя, так и свои позиции в поисковой выдаче гугла. Вместе это ведет к экономии денег на привлечение и удержание клиентов
- Уменьшение JS-бандов значительно ускоряет работу страницы
- Нужно уметь разгружать основной поток. Либо руками (как делали в первом кейсе), либо используя фишки React18 и других фреймворков, либо используя доступное браузерное API для подобных оптимизаций

Необходимо найти баланс между SSR и CSR
- Нет единственно верного решения по выбору между SSR и CSR. Разные компании выбрали разные решения для оптимизации своих приложений.
- SSR нужен для ускорения первоначальной загрузки сайта и SEO
- CSR нужен для интерактивности и логики на UI. Например, используя CSR с правильными стратегиями кэширования и подзагрузки чанков, пользователи будут ощущать более высокую работу сайта при переходе в навигации сайта
- Прогрессивная гидрация и островная архитектура берут лучшее из SSR и CSR, давай оптимальный опыт всем
- SSR легко сделать неправильно, что приведет к плохим метриками
- Совет от авторов: используйте SSR чтобы сайт хорошо работал (быстро отдавать контент, лучший SEO), затем сделайте его быстрым, подтюнивая и включая CSR там, где это улучшит UX.

Применяйте кэширование правильно
- Кэширование на edge и CDN ускоряют загрузку ресурсов пользователями и улучшают их опыт
- Оптимизация кэширования в Next.js (и других фреймворках) может значительно улучшить UX
- С кэшированием нужно быть осторожным. Ошибка в кэшировании может дорого стоить

Улучшайте работу со стейт-менеджерами
- Не перемудрите с глобальным состоянием. Глобальное состояние - это всегда сложно. Используйте то, что проще (в том числе встроенные в фреймворк средства).
- Используйте те инструменты, которые умеют в модульность и которые хорошо выполняют свою часть работы. Например, React Query + Zustand намного проще, чем Redux.
- Чем проще - тем лучше. Сложные решения - сложно поддерживать. Сделать правильно, но на redux может быть намного дольше и сложнее, чем заиспользовать Context + useState

Улучшайте опыт разработчика (DX)
- Используйте бест-практисы вашего фреймворка. Например, гайды от Next.js, если вы используете Next.js
- Используйте те инструменты, которые позволяют делать быстрые и мелкие итерации. Если у вас хот-релоад занимает 30 секунд, то ни о какой быстрой разработке не может быть и речи
- Улучшайте CI CD и релизный процесс. Чем лучше у вас настроеная непрерывная интеграция и выкладка, тем проще вам идти небольшими итерациями и тем больше уверенности в этих итерациях
- Используйте React-примитивы по назначению. Suspense и Error Boundaries значительно улучшают как DX, так и UX
- Вкладывайтесь в обучение и образование. Читайте, смотрите, экспериментируйте.

Доступность из коробки
- Используйте семантичный HTML и ARIA атрибуты
- Вложитесь в корректную работу навигации с клавиатуры и управление фокусом
- Постоянно проверяйте сайт на доступность

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

Советы от авторов
- Замеряйте и оптимизируйте то, что вам нужно оптимизировать (разным сайтам важны разные аспекты перформанса)
- Адоптируйте новые фичи Next.js и React18 (или ваших инструментариев). Это улучшит и перформанс и DX
- Кэшируйте агрессивно, но осторожно
- Сделайте менеджмент состояния простым
- Инвестируйте в DX и архитектуру
- Делайте хорошо для юзера сразу


https://largeapps.dev/case-studies/advanced/

#development #javascript #performance #research

Дайджест за 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