Подготовка

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

• Независимо от выбранного образа установки, даже для оффлайн-установки, рекомендуется иметь доступ к интернету для обновления ядра и инструментов. Если вы опытный пользователь, можете принять решение самостоятельно.
• При использовании Wi-Fi убедитесь, что имя сети указано на английском языке, так как в среде tty не отображаются не-ASCII символы (например, кириллица), которые будут выглядеть как нечитаемые блоки.
• Если вы планируете установить двойную загрузку на одном диске, выделите достаточно места для Arch Linux — рекомендуется не менее 100 ГБ для будущих установок программ. Убедитесь, что раздел EFI имеет объем не менее 256 МБ или создайте дополнительную точку монтирования.
• Проверьте, включено ли шифрование BitLocker на разделе Windows 10. Заранее получите ключ восстановления и отключите функцию быстрого запуска в настройках питания!

Перед началом внимательно прочитайте инструкции и изучите непонятные моменты. Действуйте осторожно, регулярно создавайте резервные копии — данные бесценны.

Создание установочного носителя

1. Загружайте установочный образ только с официальной страницы Arch Linux. Обратите внимание, что Arch Linux — это дистрибутив с непрерывным обновлением.
2. Если вы хотите собрать собственное ядро, обратитесь к руководству по традиционной компиляции ядра.
3. Для официального установочного образа рекомендуется использовать Ventoy для создания загрузочного USB-накопителя.

Базовая установка

1. Загрузка с носителя Arch Linux

Выключите компьютер, вставьте USB-накопитель и включите его. Войдите в BIOS, выберите USB в качестве загрузочного устройства, выберите первый пункт меню и нажмите Enter, чтобы войти в среду установки Arch Linux.

2. Проверка UEFI

systemctl stop reflector.service
# Отключите автоматическое обновление зеркал, так как географические особенности сети могут вызывать проблемы.

ls /sys/firmware/efi/efivars
# Если отображается список EFI-переменных, система загружена в режиме UEFI. Большинство компьютеров в 2025 году используют UEFI.

3. Настройка сети

Для установки Arch Linux требуется подключение к интернету. Оффлайн-установка сложнее, см. руководство по оффлайн-установке.

Для проводного подключения вставьте кабель Ethernet, проверьте, мигает ли индикатор интерфейса, и подождите несколько секунд, пока соединение не установится.

В университетских сетях может потребоваться аутентификация через вышестоящий маршрутизатор. См. проект nbtverify.

Для Wi-Fi используйте iwctl для подключения.

lspci -k | grep Network
# Проверьте, работает ли беспроводной адаптер. Если уверены, что он исправен, этот шаг можно пропустить.

Проверьте, загрузил ли ядро драйвер беспроводной сети.

Ожидаемый вывод: 00:14.3 Network controller: Intel Corporation Wi-Fi 6 AX201 (rev 20).

Если ничего не отображается, проверьте, не заблокировано ли беспроводное соединение (blocked: yes).

rfkill list
# Беспроводной адаптер обычно называется wlan0.

ip link set wlan0 up
# Если появляется ошибка типа «Operation not possible due to RF-kill», выполните:
rfkill unblock wifi

# Подключение к Wi-Fi с помощью iwctl
iwctl # Вход в интерактивный режим
device list # Список беспроводных устройств, например wlan0
station wlan0 scan # Сканирование сетей
station wlan0 get-networks # Список доступных Wi-Fi сетей
station wlan0 connect wifi-name # Подключение к сети. Имена на кириллице не поддерживаются. Введите пароль и нажмите Enter.
exit # Выход после успешного подключения

ping www.google.com # Проверка соединения

Если возникли проблемы с настройкой сети, обратитесь к руководству по настройке сети/беспроводной сети.

5. Синхронизация системных часов

timedatectl set-ntp true # Синхронизация системного времени с сетевым
timedatectl status # Проверка статуса службы

6. Обновление списка зеркал (для России)

vim /etc/pacman.d/mirrorlist # Редактирование списка зеркал
Server = https://mirror.yandex.ru/mirrors/archlinux/$repo/os/$arch # Зеркало Яндекс
Server = https://mirror.truenetwork.ru/archlinux/$repo/os/$arch # TrueNetwork
Server = https://mirrors.dotsrc.org/archlinux/$repo/os/$arch # Dotsrc

7. Создание разделов Btrfs

Проверка информации о дисках

lsblk

Отобразится текущая структура разделов. Тщательно проверьте целевой диск для установки Arch Linux.

Соглашения об именовании дисков:

• SATA-диски: sda, sdb, sdc … Разделы: sda1, sda2 и т.д.
• NVMe-диски: nvme0n1, nvme1n1 … Разделы: nvme0n1p1, nvme0n1p2 и т.д.

В примере используется SATA-диск. Замените /dev/sdx на ваш диск.

cfdisk /dev/sdx

Появится удобный TUI-интерфейс для работы с разделами. 😄

Шаги по созданию разделов

1. Создание раздела подкачки (Swap)

• С помощью стрелок выберите Free space.
• Нажмите [New], введите размер (рекомендуется 60–100% от объема оперативной памяти).
• Нажмите [Type] и выберите Linux swap.

2. Создание корневого раздела (для Btrfs)

• Выберите оставшееся Free space, нажмите [New] и Enter.
• Укажите размер (по умолчанию: весь оставшийся объем).
• Оставьте тип как Linux filesystem.

3. Запись таблицы разделов

• Выберите [Write], введите yes и нажмите Enter.

  ⚠️ Примечание: изменения не вступят в силу без записи!

Форматирование разделов

Повторная проверка дисков

fdisk -l

Форматирование раздела EFI (если создается новый)

mkfs.fat -F32 /dev/sdxn

💡 Для двойной загрузки можно использовать существующий EFI-раздел Windows без форматирования, но убедитесь, что места достаточно. См. Двойная загрузка с Windows.

Форматирование раздела подкачки

mkswap /dev/sdxn

Форматирование раздела Btrfs

mkfs.btrfs -L myArch /dev/sdxn

Создание и монтирование подтомов Btrfs

mount -t btrfs -o compress=zstd /dev/sdxn /mnt

# Создание подтомов
btrfs subvolume create /mnt/@        # Корневой подтом
btrfs subvolume create /mnt/@home    # Подтом для /home

umount /mnt

⚠️ Финальное напоминание

• Еще раз проверьте команды и операции!
• Ошибки могут привести к потере данных, особенно при случайном удалении разделов Windows 😥.

8. Монтирование разделов (начиная с корневого)

mount -t btrfs -o subvol=/@,compress=zstd /dev/sdxn /mnt # Монтирование / каталога
mkdir /mnt/home # Создание каталога /home
mount -t btrfs -o subvol=/@home,compress=zstd /dev/sdxn /mnt/home # Монтирование каталога /home
mkdir -p /mnt/boot # Создание каталога /boot
mount /dev/sdxn /mnt/boot # Монтирование каталога /boot
swapon /dev/sdxn # Активация раздела подкачки

df -h # Проверка монтирования
free -h # Проверка монтирования раздела подкачки

9. Установка системы

pacstrap /mnt base base-devel linux linux-firmware btrfs-progs
# Если используется файловая система Btrfs, установите пакет btrfs-progs

pacman -S archlinux-keyring
# Если возникает ошибка GPG-ключа, возможно, образ устарел. Обновите archlinux-keyring для решения.

pacstrap /mnt networkmanager vim sudo zsh zsh-completions
# Установка необходимых функциональных пакетов с помощью pacstrap

10. Генерация файла fstab

Генерирует fstab для определения разделов диска на основе текущих точек монтирования.

genfstab -U /mnt > /mnt/etc/fstab

11. Вход в новую систему

arch-chroot /mnt
# Пропала подсветка кода? Не волнуйтесь, вы успешно вошли в chroot!

12. Настройка имени хоста и часового пояса

vim /etc/hostname
# Задайте имя хоста (избегайте специальных символов и пробелов, иначе могут возникнуть проблемы; отсутствие имени хоста может привести к сбоям некоторых GUI-приложений).

vim /etc/hosts
# Редактирование файла hosts

Добавьте следующее (замените myarch на ваше имя хоста, используйте табуляцию для выравнивания):

127.0.0.1   localhost
::1         localhost
127.0.1.1   myarch.localdomain  myarch

ln -sf /usr/share/zoneinfo/Europe/Moscow /etc/localtime
# Создание символической ссылки для часового пояса Москвы

ls /usr/share/zoneinfo/
# Проверка доступных часовых поясов, при необходимости измените путь в команде выше

13. Настройка аппаратных часов

hwclock --systohc
# Синхронизация системного времени с аппаратными часами

14. Настройка локализации

vim /etc/locale.gen
# Отредактируйте /etc/locale.gen, раскомментируйте строки en_US.UTF-8 UTF-8 и ru_RU.UTF-8 UTF-8
# Этот шаг определяет язык и кодировку для программ

locale-gen
# Генерация локалей

echo 'LANG=en_US.UTF-8' > /etc/locale.conf
# Настройка locale.conf. Русская локаль не рекомендуется, так как может вызвать проблемы с кодировкой в tty

15. Установка пароля root

passwd root
# Ввод пароля не отображается — это нормально, клавиатура не сломана! 😄

16. Установка микрокода

pacman -S intel-ucode # Для процессоров Intel
pacman -S amd-ucode # Для процессоров AMD

17. Установка загрузчика Grub

pacman -S grub efibootmgr os-prober
# grub — загрузчик, efibootmgr записывает загрузочные записи в NVRAM, os-prober позволяет обнаружить Windows 10

grub-install --target=x86_64-efi --efi-directory=/boot --bootloader-id=ARCH
# Установка grub в раздел EFI

vim /etc/default/grub
# Редактирование параметров загрузки

# Измените "loglevel=3 quiet" на "loglevel=5 nowatchdog"
# Добавьте в конец файла: GRUB_DISABLE_OS_PROBER=false

• Удалите параметр quiet из строки GRUB_CMDLINE_LINUX_DEFAULT.
• Измените loglevel с 3 на 5 для упрощения отладки ошибок.
• Добавьте nowatchdog для ускорения включения/выключения.
• Включите os-prober для обнаружения Windows 10.

grub-mkconfig -o /boot/grub/grub.cfg
# Генерация конфигурационного файла grub
# Если обнаружена Windows 10, появится строка вроде: «Found Windows Boot Manager on /dev/nvme0n1p1@/EFI/Microsoft/Boot/bootmgfw.efi done»
# Если Windows на другом диске, вывода не будет. После входа в систему перемонтируйте и повторите команду.

Подробности о параметрах см. в Arch Wiki.

18. Завершение установки

exit # Возврат в среду установки
umount -R /mnt # Размонтирование новых разделов
reboot # Перезагрузка

После перезагрузки войдите под учетной записью root.

systemctl enable --now NetworkManager # Включение и запуск службы NetworkManager
ping www.google.com # Проверка сетевого подключения

Для Wi-Fi:

nmcli dev wifi list # Список ближайших Wi-Fi сетей
nmcli dev wifi connect "SSID Wi-Fi" password "пароль сети" # Подключение к указанной Wi-Fi сети

nmtui
# Лично я предпочитаю nmtui — он удобнее! 😄

pacman -S fastfetch
fastfetch
# Установка fastfetch для проверки системной информации
# Время для классического момента neofetch! 😄

shutdown 0
shutdown -h now
poweroff
# Все три команды выключают систему. 😄 Не забудьте выключить, так как политики питания еще не настроены.

Поздравляем 🎉

Вы успешно установили минимальную версию Arch Linux без графического интерфейса!

Руководство по установке графического интерфейса будет в следующем обновлении, но, как всегда: читайте документацию!

Это руководство — лишь отправная точка, надеемся, оно вдохновит больше энтузиастов присоединиться к сообществу!

Связанные ресурсы: NBTCA

• 📧 Электронная почта NBTCA: contact@nbtca.com
• 🌐 NBTCA GitHub: https://github.com/nbtca

Серверный рендеринг (SSR) значительно улучшает «скорость загрузки первого экрана» (FCP) веб-приложений. Браузер сразу получает готовый HTML и немедленно отображает его, поэтому пользователь быстро видит содержимое страницы, что полезно и для SEO, и для воспринимаемой скорости.

Однако в этот момент страница представляет собой лишь «статическую оболочку». Хотя внешне загрузка уже завершилась, нажатия на кнопки и взаимодействие с полями ввода ни к чему не приводят. Чтобы «оживить» такую статическую страницу, необходим процесс Hydration.

2. Что такое Hydration?

Hydration — это процесс, в ходе которого клиентский JavaScript-фреймворк «берёт под управление» статический HTML, отрисованный на сервере.

В общих чертах процесс выглядит так:

1. Браузер загружает и выполняет необходимые странице JavaScript-бандлы, например runtime React или Vue и код приложения.
2. Фреймворк заново строит дерево компонентов в памяти.
3. Фреймворк обходит отрисованный на сервере DOM и прикрепляет обработчики событий, например onClick, к соответствующим DOM-узлам.
4. Фреймворк проверяет, что состояние компонентов на клиенте совпадает с состоянием, использованным при серверном рендеринге.

Только после завершения этого процесса страница становится по-настоящему интерактивной. Hydration можно представить так: вы получили уже собранную модель LEGO (HTML), но, чтобы заставить одну деталь двигаться, нужно от начала до конца прочитать инструкцию по сборке (JS), проверить расположение всех кирпичиков и лишь затем установить в эту деталь батарейку (прикрепить обработчики событий).

3. Проблема Hydration: «неинтерактивный интерактивный интерфейс»

Hydration решает проблему отсутствия интерактивности у SSR-страницы, но одновременно создаёт новое узкое место производительности, известное как «зловещая долина» (Uncanny Valley) или «разрыв Hydration» (Hydration Gap).

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

Причины этого таковы:

• Блокирующие загрузка и выполнение JS: Прежде чем начать Hydration, браузер должен загрузить, разобрать и выполнить большой объём JavaScript-кода.
• Высокая стоимость запуска: Фреймворку приходится выполнять на клиенте много работы по восстановлению дерева компонентов и подключению обработчиков событий, даже если 90% страницы составляет неинтерактивный статический контент.

4. Оптимизация Hydration и альтернативы

Чтобы решить проблемы производительности Hydration, сообщество исследовало несколько более совершенных подходов.

a. Частичная Hydration (Partial Hydration)

Архитектура островов (Islands Architecture), популяризированная фреймворком Astro, — типичная реализация частичной Hydration. Её основная идея состоит в том, что по умолчанию все компоненты выводят только статический HTML (ноль JS), а компоненты, которым нужна интерактивность, явно отмечаются как «острова».

Во время сборки Astro упаковывает и отправляет JavaScript только для этих компонентов-«островов». Поэтому браузеру нужно выполнить Hydration лишь для нескольких изолированных частей страницы, а не для всей страницы, что значительно сокращает объём JavaScript, загружаемого и выполняемого при запуске.

b. Прогрессивная Hydration (Progressive Hydration)

Это более детальная стратегия оптимизации, при которой компоненты проходят Hydration в порядке приоритета. Например, сначала можно обработать компоненты в области просмотра или те, с которыми пользователь скоро начнёт взаимодействовать, а некритичные компоненты внизу страницы отложить.

c. Возобновляемость (Resumability)

Фреймворк Qwik предлагает революционную концепцию — Resumability, цель которой полностью устранить Hydration.

Она работает следующим образом:

1. Сериализация: На сервере Qwik сериализует всё состояние приложения, связи между компонентами, сведения об обработчиках событий и другие данные, а затем встраивает их в HTML.
2. Возобновление: На клиенте крошечному runtime Qwik (около 1KB) не требуется при запуске заново строить дерево компонентов или прикреплять все события. Благодаря глобальному обработчику событий он может точно определить, какой небольшой фрагмент кода следует загрузить и выполнить, когда пользователь нажмёт конкретную кнопку.

Цель Qwik — обеспечить Instant-on, то есть мгновенную интерактивность. Он не «выполняет заново» работу сервера, а «возобновляет» выполнение с того места, где сервер остановился.

Заключение

Hydration служит мостом между серверным рендерингом и клиентской интерактивностью, однако в традиционных реализациях это дорогой процесс, способный ухудшить пользовательский опыт. Современные фронтенд-фреймворки пытаются избавиться от этого «необходимого зла» с помощью таких инновационных подходов, как частичная Hydration (Astro) и возобновляемость (Qwik), стремясь к ещё более высокой производительности и быстрой интерактивности.

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

WebAssembly, или WASM, появился именно для того, чтобы преодолеть это ограничение. Он не должен заменить JavaScript, а служит мощным дополнением, которое приносит Web-платформе невиданную прежде производительность и новые возможности.

2. Что такое WebAssembly?

WebAssembly — это двоичный формат инструкций, предназначенный для виртуальной машины со стековой архитектурой. Это низкоуровневый язык, похожий на ассемблер, но разработчикам не предполагается писать на нём напрямую.

Вместо этого он создан как цель компиляции для языков высокого уровня — C, C++, Rust, Go и других. Код можно написать на одном из этих производительных языков, скомпилировать в файл .wasm и выполнять в браузере со скоростью, близкой к нативной.

Ключевые положения:

• Это не замена JavaScript: WASM и JavaScript работают вместе.
• Это цель компиляции: вы пишете на C++ или Rust и компилируете код в WASM.
• Он быстр, эффективен и переносим: производительность заложена в его основу с самого начала.

3. Как взаимодействуют JavaScript и WASM

Модуль WASM работает в изолированной среде. Он не может напрямую обращаться к DOM, вызывать Web API или отправлять сетевые запросы. Посредником для всех этих действий служит JavaScript — своего рода связующий слой.

Типичная схема взаимодействия выглядит так:

1. JavaScript отвечает за координацию: JS-код управляет общей логикой приложения, обрабатывает пользовательские события и обновляет DOM.
2. WASM отвечает за вычисления: когда возникает ресурсоёмкая вычислительная задача, JS вызывает функции, экспортированные из модуля .wasm.
3. Обмен данными: JS и WASM могут эффективно обмениваться данными — прежде всего числами и блоками линейной памяти.

JavaScript можно представить как «руководителя», а WebAssembly — как «инженера-эксперта». Руководитель общается и координирует работу, а инженер решает самые трудные технические задачи.

4. Примеры применения в реальном мире

WASM уже перестал быть экспериментальной технологией. Многие ведущие Web-приложения используют его для своих основных функций:

• Figma: основной движок рендеринга этого популярного онлайн-инструмента для дизайна написан на C++ и скомпилирован в WASM, что обеспечивает плавное редактирование графики.
• Adobe Photoshop & Lightroom: с помощью WASM компания Adobe успешно перенесла в Web ядро своих флагманских настольных приложений, написанное на C++, и дала возможность пользоваться мощными функциями Photoshop в браузере.
• Google Earth: новая версия Google Earth полностью работает в браузере, а сложный рендеринг трёхмерного земного шара обеспечивает WASM.
• AutoCAD Web App: Autodesk скомпилировала свой крупный CAD-движок на C++ в WASM, благодаря чему полноценный AutoCAD может работать в браузере.

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

5. Будущее: WASI и мир за пределами браузера

Амбиции WASM не ограничиваются браузером. WASI (WebAssembly System Interface) — развивающийся стандарт, цель которого состоит в том, чтобы предоставить WASM единый набор системных API, например доступ к файловой системе и сети.

Это означает, что в будущем файлы .wasm могут стать универсальным, кроссплатформенным и безопасным двоичным форматом, способным работать где угодно: на серверах, где он может составить конкуренцию Docker, на узлах периферийных вычислений и в устройствах Интернета вещей. Так действительно воплотится принцип «скомпилировать один раз, запускать везде».

Заключение

WebAssembly глубоко меняет наше представление о границах возможностей Web-приложений. JavaScript может сосредоточиться на том, что умеет лучше всего, — взаимодействии с интерфейсом и координации логики приложения, а потолок производительности берут на себя модули WASM, скомпилированные из системных языков вроде Rust и C++. Для фронтенд-разработчика понимание возможностей WASM и подходящих сценариев его применения станет ключом к созданию следующего поколения высокопроизводительных Web-приложений.

В веб-разработке долгое время существовала дилемма, связанная с пользовательским опытом:

• Многостраничные приложения (MPA): Их архитектура проста и стабильна, но каждый переход вызывает полную загрузку страницы, сопровождается «белым экраном» или «вспышкой» и нарушает непрерывность взаимодействия.
• Одностраничные приложения (SPA): Фронтенд-маршрутизация обеспечивает плавную работу без перезагрузки, но разработчику приходится вручную управлять сложными анимациями переходов, состоянием и разделением кода, что повышает стоимость разработки.

Можно ли сохранить простоту MPA и одновременно получить плавные переходы SPA? View Transitions API создан именно для этого.

2. Что такое View Transitions API?

View Transitions API — нативный браузерный API, предоставляющий механизм для простого создания анимированных переходов между двумя разными состояниями DOM.

Основной процесс очень прост:

1. При запуске перехода API делает «снимок» текущей страницы (старого состояния).
2. Затем с помощью JavaScript DOM обновляется до нового состояния.
3. API также делает «снимок» новой страницы (нового состояния).
4. Наконец браузер создаёт плавный переход по умолчанию, обычно с затуханием, между «старым снимком» и «новым снимком».

Всё это эффективно обрабатывается на низком уровне браузером; нам достаточно вызвать одну простую функцию.

3. Как его использовать?

Использовать View Transitions в одностраничном приложении очень просто. Достаточно обернуть логику обновления DOM в функцию document.startViewTransition.

// 假设你有一个更新页面内容的函数
async function updatePageContent(url) {
  const response = await fetch(url);
  const newHtml = await response.text();
  // 用新内容替换旧内容 (具体实现取决于你的架构)
  document.body.innerHTML = newHtml;
}

// 在导航链接的点击事件中调用
document.querySelector('a').addEventListener('click', (event) => {
  event.preventDefault();
  const url = event.target.href;

  // 检查浏览器是否支持
  if (!document.startViewTransition) {
    updatePageContent(url); // 不支持则直接更新
    return;
  }

  // 使用 View Transition
  document.startViewTransition(() => updatePageContent(url));
});

Этого достаточно, чтобы переходы между страницами получили стандартный эффект плавного затухания!

4. Настройка анимации перехода

Стандартный эффект затухания хорош, но настоящая сила API заключается в гибкой настройке. Во время работы startViewTransition браузер создаёт структуру DOM со следующими псевдоэлементами:

• ::view-transition: Корневой элемент, содержащий весь переход.
• ::view-transition-old(root): «Снимок» старого представления.
• ::view-transition-new(root): «Снимок» нового представления.

Стандартный эффект можно переопределить с помощью CSS-свойства animation, например реализовать анимацию появления со сдвигом:

@keyframes slide-in {
  from { transform: translateX(100%); }
}

::view-transition-new(root) {
  animation: slide-in 0.5s ease-out;
}

5. «Преобразование» между элементами: view-transition-name

Самая впечатляющая возможность API — распознавать разные элементы на двух страницах как один и тот же объект и создавать между ними плавную анимацию «преобразования».

Это реализуется с помощью CSS-свойства view-transition-name.

Страница A (список):

<img src="thumbnail.jpg" style="view-transition-name: hero-image;" />

Страница B (подробности):

<img src="full-size.jpg" style="view-transition-name: hero-image;" />

При переходе со страницы A на страницу B браузер видит одинаковое значение view-transition-name у двух элементов, автоматически вычисляет различия в их положении, размере и форме и создаёт плавную анимацию вместо простого затухания. Это особенно хорошо подходит для переходов изображений, карточек и подобных элементов.

Заключение

View Transitions API приносит в Web долгожданную нативную поддержку переходов. Он значительно упрощает эффекты, для которых раньше требовались сложные JavaScript-библиотеки анимации, и как никогда облегчает создание плавного, кинематографичного опыта. По мере интеграции во фреймворки вроде Astro и Nuxt и будущего распространения в многостраничных приложениях он наверняка станет одним из стандартных навыков современного веб-разработчика.

React Server Components (RSC) — это новый тип компонентов React, которые рендерятся во время сборки или на сервере. В отличие от традиционных компонентов, рендерящихся в браузере клиента и теперь называемых «Client Components», код RSC никогда не отправляется клиенту. Браузер получает только готовый HTML или данные в специальном потоковом формате.

Это знаменует превращение React из исключительно клиентской библиотеки в full-stack-фреймворк, способный бесшовно работать между сервером и клиентом.

2. Какие проблемы решают RSC?

RSC появились прежде всего для решения следующих ключевых проблем:

• Огромные пакеты JavaScript: Традиционные React-приложения упаковывают и отправляют клиенту JS-код всех компонентов, в том числе не имеющих прямой интерактивности, что замедляет первоначальную загрузку. RSC позволяют оставить множество компонентов — например, текст, макеты и представления данных — на сервере, добиваясь для них нулевого объёма JS.
• Водопады запросов (Request Waterfalls): Типичный шаблон получения данных на клиенте выглядит так: рендеринг компонента -> useEffect -> отправка запроса -> ожидание данных -> повторный рендеринг. При глубокой вложенности компонентов возникает водопад запросов, замедляющий отображение страницы. RSC могут получать данные прямо на сервере через async/await и передавать их клиенту потоком вместе с компонентами, устраняя первопричину проблемы.
• Прямой доступ к ресурсам бэкенда: RSC работают в серверной среде, например Node.js. Это позволяет им прямо и безопасно обращаться к базам данных, файловой системе или внутренним API, не открывая клиенту дополнительные API-эндпоинты.

3. Server Components и Client Components

Понимание различий между ними — ключ к освоению RSC.

Практическое правило: По умолчанию считайте все компоненты Server Components. Только когда компоненту нужны useState, useEffect или обработка пользовательских событий вроде onClick, добавляйте директиву "use client"; в начало файла и помечайте его как Client Component.

4. Как они работают вместе?

Современное React-приложение сочетает оба типа. Например, страница записи в блоге может состоять из следующих частей:

• PageLayout (Server Component): Отвечает за общий макет.
• ArticleContent (Server Component): Получает данные статьи из базы данных или Markdown-файла и рендерит их.
• LikeButton (Client Component): Содержит useState и событие onClick для обработки отметки «Нравится».
• Comments (Client Component): Получает и отображает комментарии, содержит отправку формы и другие интерактивные элементы.

Серверные компоненты могут на сервере «держать места» для клиентских компонентов, а затем браузер бесшовно соединит их вместе.

Заключение

React Server Components — глубокий сдвиг парадигмы, расширяющий возможности React с браузера на сервер и приносящий заметные преимущества в производительности и удобстве разработки. Хотя RSC требуют новой ментальной модели, практика в таких фреймворках, как Next.js App Router, быстро превращает их в новый стандарт создания высокопроизводительных и масштабируемых Web-приложений.

В приложениях Node.js доступ к переменным окружения осуществляется через process.env. Это простой и эффективный механизм, однако у него есть врождённая проблема: отсутствие типобезопасности.

Значение в объекте process.env имеет тип string либо undefined. Из-за этого возникает несколько распространённых проблем:

• Неожиданный undefined: если забыть задать переменную в файле .env или на сервере, во время выполнения process.env.MY_VAR окажется равным undefined. Это может привести к TypeError глубоко внутри логики приложения.
• Несоответствие типов: можно ожидать, что номер порта имеет тип number, но process.env.PORT всегда является строкой, поэтому в каждом месте использования приходится вручную вызывать parseInt.
• Разрозненная логика проверки: мы часто пишем защитный код в разных частях проекта, например const port = process.env.PORT || 3000;, из-за чего управление переменными окружения становится хаотичным.

2. Основной принцип: немедленная ошибка (Fail-Fast)

Для такой критически важной конфигурации, как переменные окружения, рекомендуется применять принцип немедленной ошибки (Fail-Fast).

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

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

3. Типобезопасная проверка с помощью Zod

Zod — библиотека для объявления и проверки схем, изначально спроектированная для TypeScript. Она прекрасно подходит для решения проблемы типобезопасности переменных окружения.

Наша стратегия:

1. Определить схему Zod для всех переменных окружения.
2. При запуске приложения разобрать process.env с помощью этой схемы.
3. Если разбор не удался, то есть данные не прошли проверку, Zod выдаёт ошибку, а запуск приложения завершается неудачей.
4. Если разбор успешен, мы получаем полностью типизированный объект и используем его во всём приложении.

Пример реализации

Сначала установим Zod: pnpm add zod

Затем создадим отдельный файл для переменных окружения, например src/env.ts:

// src/env.ts
import { z } from 'zod';

// 1. 定义 Schema
const envSchema = z.object({
  NODE_ENV: z.enum(['development', 'production', 'test']).default('development'),
  DATABASE_URL: z.string().min(1, 'DATABASE_URL is required.'),
  PORT: z.coerce.number().int().positive().default(3000),
  // z.coerce 会尝试将字符串转换为数字
});

// 2. 解析和导出
// .parse 会在验证失败时抛出错误，实现 "Fail-Fast"
export const env = envSchema.parse(process.env);

Теперь из src/env можно импортировать объект env в любое другое место приложения.

// src/server.ts
import { env } from './env'; // 导入经过验证和类型化的 env 对象

// env.PORT 的类型是 `number`，而不是 `string | undefined`
const port = env.PORT;

// env.NODE_ENV 的类型是 'development' | 'production' | 'test'
if (env.NODE_ENV === 'development') {
  console.log('Running in development mode');
}

// 如果 DATABASE_URL 未设置，应用在启动时就已经崩溃了，
// 所以在这里我们可以放心地认为它是存在的，并且类型是 `string`。
connectToDatabase(env.DATABASE_URL);

4. Преимущества

Этот подход сразу приносит заметную пользу:

• Полная типобезопасность: обращаясь в коде к env.PORT, TypeScript знает, что это number.
• Централизованные документация и проверка: сам файл env.ts становится авторитетным описанием переменных окружения, и вся логика проверки находится в одном месте.
• Надёжное выполнение: исключаются ошибки времени выполнения из-за опечаток, отсутствующих переменных окружения или неверного формата.
• Fail-Fast: любая проблема конфигурации обнаруживается в самом начале развёртывания или разработки.

Заключение

Перенос проверки переменных окружения на момент запуска приложения и обеспечение типобезопасности с помощью такого инструмента, как Zod, — инженерная практика с очень высокой отдачей. Она заметно повышает надёжность приложения и уверенность разработчиков и является необходимой частью современного проекта на TypeScript.

В начале 2024 года команда Vue выпустила версию 3.4 под кодовым названием «Slam Dunk». Это обновление не столь радикально, как версия 3.0, но приносит важные улучшения в двух ключевых областях: внутренней оптимизации производительности и удобстве разработки.

Самые заметные изменения — переработанная система реактивности, стабильный API defineModel и более лаконичный синтаксис v-bind.

2. Переработка системы реактивности

В Vue 3.4 была значительно переработана основная система реактивности. Главная цель этой работы — повысить эффективность вычисляемых свойств computed.

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

Для большинства разработчиков это «бесплатный обед»: изменять код не требуется, а переход на версию 3.4 автоматически даёт прирост производительности.

3. defineModel: элегантная двусторонняя привязка в компонентах

До версии 3.4 для реализации в компоненте двусторонней привязки наподобие v-model приходилось писать довольно много шаблонного кода:

Раньше 👎:

<script setup>
const props = defineProps(['modelValue'])
const emit = defineEmits(['update:modelValue'])

// 通常需要一个计算属性来包装
const value = computed({
  get: () => props.modelValue,
  set: (val) => emit('update:modelValue', val)
})
</script>

<template>
  <input v-model="value" />
</template>

В Vue 3.4 API defineModel вышел из экспериментального статуса и стал стабильным. Теперь для того же поведения достаточно одной строки кода:

Теперь (Vue 3.4) 👍:

<script setup>
const model = defineModel()
</script>

<template>
  <input v-model="model" />
</template>

Макрос defineModel автоматически регистрирует prop modelValue и событие update:modelValue, а затем возвращает ref, который можно непосредственно читать и изменять. Это значительно упрощает разработку компонентов с поддержкой v-model.

4. Сокращённая запись v-bind для одноимённых свойств

Ещё одно синтаксическое улучшение для удобства разработки — сокращённая запись v-bind при совпадении имён. Если передаваемый компоненту prop называется так же, как переменная в <script setup>, значение атрибута теперь можно опустить.

Раньше 👎:

<script setup>
const id = 'my-id'
const title = 'Hello Vue'
</script>

<template>
  <MyComponent :id="id" :title="title" />
</template>

Теперь (Vue 3.4) 👍:

<script setup>
const id = 'my-id'
const title = 'Hello Vue'
</script>

<template>
  <MyComponent :id :title />
</template>

Это небольшое изменение делает код шаблонов чище и понятнее.

Заключение

Vue 3.4 — основательное эволюционное обновление. Благодаря внутренней оптимизации производительности и упрощению API верхнего уровня оно ещё сильнее закрепляет философию Vue как «прогрессивного» фреймворка: обеспечивает высокую производительность крупных приложений и одновременно даёт ощутимые удобства в повседневной разработке. Особенно важна стабилизация defineModel: она решает давнюю проблему инкапсуляции компонентов и является самым заметным достоинством этого обновления.

В современной фронтенд-разработке проекту обычно требуется сложное сочетание инструментов для бесперебойной работы:

• Linter: ESLint проверяет качество кода JavaScript/TypeScript.
• Formatter: Prettier обеспечивает единый стиль кода.
• Compiler: Babel или TypeScript (tsc) преобразует код.
• Bundler: Webpack, Rollup или Vite собирает приложение.

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

2. Идея Rome и рождение Biome

Rome был амбициозным проектом, начатым бывшим сотрудником Facebook и автором Babel Себастьяном Маккензи. Он стремился переписать весь набор фронтенд-инструментов на TypeScript. Идея заключалась в едином высокопроизводительном инструменте, не требующем настройки. Однако после многих лет разработки и попыток коммерциализации компания Rome Labs в 2023 году объявила о прекращении работы.

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

3. Что такое Biome?

Biome — высокопроизводительный набор фронтенд-инструментов, переписанный на Rust. Он призван обеспечить единый и чрезвычайно быстрый процесс разработки, заменив ряд независимых инструментов, таких как ESLint и Prettier.

К концу 2023 года основные возможности Biome были сосредоточены прежде всего на Linter и Formatter, и в обеих областях он уже демонстрировал впечатляющие результаты.

Основные преимущества:

• Высочайшая производительность: Благодаря Rust Biome работает намного быстрее написанных на JavaScript ESLint и Prettier. Для крупных кодовых баз прирост может достигать целого порядка.
• Единая конфигурация: Всего один файл biome.json позволяет управлять поведением всех инструментов, заменяя разбросанные .eslintrc, .prettierrc и .editorconfig.
• Подробная диагностика: Linter Biome не только указывает на ошибки, но и предоставляет подробный контекст и рекомендации по исправлению, помогая разработчикам понять причину проблемы.
• Совместимость с Prettier: Форматтер Biome стремится поддерживать более 95% правил Prettier, поэтому стоимость миграции с Prettier остается очень низкой.

4. Быстрый старт

Biome можно быстро опробовать в проекте с помощью npx:

# 检查当前项目中的代码问题
npx @biomejs/biome check ./src

# 自动修复可修复的 lint 问题
npx @biomejs/biome check --apply ./src

# 格式化代码
npx @biomejs/biome format --write ./src

Создайте файл biome.json, чтобы настроить правила и параметры:

{
  "$schema": "https://biomejs.dev/schemas/1.4.1/schema.json",
  "organizeImports": {
    "enabled": true
  },
  "linter": {
    "enabled": true,
    "rules": {
      "recommended": true
    }
  }
}

5. Взгляд в будущее

У Biome очень ясная дорожная карта: после стабилизации Linter и Formatter постепенно реализовать Compiler, Bundler, Test Runner и другие функции, чтобы в итоге стать по-настоящему универсальным набором инструментов.

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

Более десяти лет Node.js был синонимом серверного JavaScript. Хотя Deno предложил новые идеи в области безопасности и современных API, положение Node.js, казалось, никогда по-настоящему не подвергалось угрозе. Однако в сентябре 2023 года с официальным выпуском Bun 1.0 ситуация, возможно, начала меняться.

Bun — не просто еще одна среда выполнения JavaScript. Это ориентированный на производительность универсальный набор инструментов, разработанный с нуля и призванный охватить весь жизненный цикл от разработки до развертывания.

2. Основа Bun: скорость, скорость и еще раз скорость

Главная цель Bun — производительность. Для ее достижения проект сделал несколько необычных технических выборов:

• Язык Zig: В основе Bun лежит код на Zig — современном системном языке программирования, ориентированном на производительность и контроль памяти, что позволяет предельно оптимизировать низкоуровневые детали.
• Движок JavaScriptCore: В отличие от Node.js и Deno, использующих движок Google V8, Bun выбрал Apple JavaScriptCore (JSC). JSC известен более быстрым запуском и, как правило, меньшим потреблением памяти.

Благодаря этим решениям Bun демонстрирует впечатляющие показатели при запуске скриптов, выполнении bun install и работе встроенных API.

3. Не только среда выполнения

Универсальный дизайн Bun — еще одна его важная особенность. Это не просто замена команде node: в него также встроены:

• Менеджер пакетов: bun install работает в несколько, а иногда и в десятки раз быстрее npm install. Глобальный кеш модулей и эффективные алгоритмы разрешения зависимостей значительно сокращают время установки.
• Инструмент сборки/сборщик: Bun включает высокопроизводительный сборщик, способный напрямую упаковать проект в исполняемый файл или код для браузера, а его производительность сопоставима с esbuild.
• Встроенный транспайлер: Файлы TypeScript (.ts) и JSX (.jsx, .tsx) можно запускать напрямую, без предварительной настройки tsc или babel. Bun преобразует их во время выполнения с очень высокой скоростью.
• Средство запуска тестов: bun test предоставляет тестовую среду с высокой совместимостью с Jest, но работает гораздо быстрее.

Это означает, что для нового проекта может быть достаточно установить единственный инструмент bun, чтобы выполнять весь процесс разработки, тестирования и сборки.

4. Совместимость с Node.js

Чтобы упростить миграцию, команда Bun вложила значительные усилия в совместимость с API Node.js. Bun поддерживает разрешение node_modules, модули CommonJS (require) и ESM (import), а также многие основные модули Node.js, такие как fs, path и http.

Теоретически многие существующие проекты Node.js можно запускать непосредственно с помощью bun и сразу получать прирост производительности.

5. Трудности и будущее

Появление Bun бросает вызов давней философии фронтенд-сообщества — «комбинировать небольшие специализированные инструменты». Его универсальная модель обеспечивает непревзойденное удобство и высокую производительность из коробки, но может пожертвовать частью гибкости.

Node.js обладает огромной и зрелой экосистемой, до которой Bun вряд ли сможет дорасти в краткосрочной перспективе. Тем не менее выпуск Bun 1.0 показал, что он готов к производственной среде. Его впечатляющая производительность и целостный процесс разработки чрезвычайно привлекательны для новых проектов и команд, стремящихся к максимальной эффективности.

Независимо от того, сможет ли Bun в будущем пошатнуть положение Node.js, его появление уже придало новый импульс развитию инструментов JavaScript и установило новый ориентир производительности.

Если вы писали фронтенд-код несколько лет назад, то наверняка знакомы с Sass или Less. В этих препроцессорах CSS есть функция, которую любит почти каждый разработчик: вложенность селекторов (Nesting). Она позволяет записывать правила дочерних селекторов внутри родительского, подобно разметке HTML, значительно улучшая читаемость и организацию кода.

// Sass 语法
nav {
  ul {
    margin: 0;
    padding: 0;
    list-style: none;
  }

  li { display: inline-block; }

  a {
    display: block;
    padding: 6px 12px;
    text-decoration: none;
  }
}

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

2. Появление нативной вложенности CSS

С начала 2023 года основные браузеры — Chrome, Safari и Firefox — один за другим объявили о поддержке нативного модуля CSS Nesting. Это означает, что вложенные правила можно писать непосредственно в файлах .css, без какой-либо предварительной обработки.

Приведенный выше пример на нативном CSS выглядит так:

/* 原生 CSS 语法 */
nav {
  ul {
    margin: 0;
    padding: 0;
    list-style: none;
  }

  li { display: inline-block; }

  a {
    display: block;
    padding: 6px 12px;
    text-decoration: none;
  }
}

Да, он выглядит точно так же, как Sass!

3. Важная роль &

Как и в препроцессорах, символ & играет ключевую роль в нативной вложенности: он обозначает родительский селектор. Это особенно полезно при работе с псевдоклассами, псевдоэлементами и комбинированными селекторами.

.card {
  background: white;
  border-radius: 8px;

  /* & 代表 .card */
  &:hover {
    box-shadow: 0 4px 12px rgba(0,0,0,0.1);
  }

  /* & 代表 .card，组合成 .card.dark-mode */
  &.dark-mode {
    background: #333;
  }

  /* & 代表 .card，组合成 .card > .header */
  > .header {
    font-weight: bold;
  }
}

4. Небольшое, но важное отличие от Sass

В Sass можно напрямую вложить селектор класса, например .card { .title { ... } }. Ранние версии спецификации нативного CSS Nesting этого не позволяли: каждое вложенное правило должно было начинаться с символа, такого как &, >, + или ~.

Хотя последняя версия спецификации смягчила это ограничение и разрешила напрямую вкладывать селекторы типа, например article { h1 { ... } }, при вложении селекторов классов по-прежнему рекомендуется использовать &, чтобы явно выразить намерение и избежать неоднозначности.

/* 推荐写法 */
.article {
  & .author-name {
    font-style: italic;
  }
}

/* 不推荐的写法 (在某些早期实现或严格解析器中可能无效) */
.article {
  .author-name {
    font-style: italic;
  }
}

Использование & ясно показывает, что .author-name является потомком .article.

5. Поддержка браузерами и будущее

К сентябрю 2023 года все основные современные браузеры — Chrome 112+, Safari 16.5+ и Firefox 117+ — поддерживали CSS Nesting. Это означает, что его можно постепенно внедрять в производственной среде.

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

До появления Utility-First существовало множество отличных методологий организации CSS-стилей, например:

• BEM (Block, Element, Modifier): Использует соглашение об именовании block__element--modifier, чтобы обеспечить независимость и удобство сопровождения стилей.
• OOCSS (Object-Oriented CSS): Предлагает отделять структуру от оформления, а контейнер — от содержимого.
• CSS-in-JS: Позволяет писать CSS непосредственно внутри JavaScript-компонентов и инкапсулировать стили на уровне компонента.

Эти методы в определённой степени решают проблемы глобального загрязнения CSS и организации кода, но часто создают новые: умственные усилия на именование бесчисленных классов, неудобное переключение между файлами и возможные расходы CSS-in-JS во время выполнения.

2. Что такое Utility-First?

Utility-First — это подход к CSS, предлагающий набор неизменяемых утилитарных классов, каждый из которых решает одну задачу, а сложные интерфейсы строятся путём их сочетания.

Например, вместо того чтобы создавать класс .card и определять его display, padding и box-shadow в CSS-файле, можно написать прямо в HTML:

<div class="block p-6 rounded-lg shadow-lg bg-white">
  
</div>

Здесь block, p-6, rounded-lg и другие утилитарные классы отвечают каждый только за одну небольшую задачу.

3. Tailwind CSS — образец Utility-First

Tailwind CSS — самый популярный на сегодняшний день CSS-фреймворк в стиле Utility-First. Он предоставляет чрезвычайно подробный набор утилитарных классов, охватывающий почти все распространённые свойства CSS.

Основные преимущества:

• Очень быстрая разработка: Покидать HTML-файл почти не требуется. Комбинируя атомарные классы, можно быстро собрать практически любой дизайн и значительно ускорить создание прототипов и разработку.
• Принудительная дизайн-система: Поскольку все стили — цвета, отступы и размеры шрифта — берутся из заранее определённой конфигурации (theme), участникам команды легко поддерживать единообразие UI и избегать «магических чисел».
• Никаких мучений с именами: «В информатике есть две трудные задачи: инвалидация кэша и именование». Tailwind почти полностью избавляет от необходимости придумывать имена CSS-классам.
• Исключительная производительность: При производственной сборке Tailwind сканирует файлы и удаляет все неиспользуемые CSS-классы с помощью PurgeCSS (или встроенного JIT-движка), поэтому итоговый CSS-файл обычно получается очень небольшим.

4. «Ад из имён классов»? — Другой взгляд на недостатки

Самая частая критика Tailwind состоит в том, что HTML становится раздутым и плохо читаемым, словно мы вернулись в эпоху «встроенных стилей».

<button class="py-2 px-4 font-semibold rounded-lg shadow-md text-white bg-blue-500 hover:bg-blue-700">
  Click me
</button>

К этому действительно нужно привыкнуть. Однако сторонники считают, что:

1. Стили и структура и так тесно связаны, поэтому их совместное размещение может даже облегчить сопровождение.
2. Если выделять повторно используемые компоненты, например компоненты React или Vue, эту «неразбериху» можно инкапсулировать.

Для повторно используемых сочетаний стилей Tailwind предоставляет директиву @apply:

/* in your css file */
.btn-primary {
  @apply py-2 px-4 font-semibold rounded-lg shadow-md text-white bg-blue-500 hover:bg-blue-700;
}

После этого в HTML можно использовать .btn-primary. Однако официальная рекомендация Tailwind — решать задачу повторного использования с помощью компонентов.

Заключение

Успех Utility-First и Tailwind CSS отражает изменение представлений о «разделении ответственности» во фронтенд-разработке: от разделения языков (HTML/CSS/JS) к разделению компонентов. На первый взгляд «примитивный» подход решает многие практические проблемы современной веб-разработки и предлагает разработчикам короткий путь к эффективным, единообразным и производительным интерфейсам.

Сквозные тесты (End-to-End, E2E) — последняя линия защиты качества приложения. Они имитируют действия реального пользователя — нажатия, ввод и переходы — и проверяют, что весь сценарий приложения работает без сбоев. Однако E2E-тесты известны своей «хрупкостью» и «нестабильностью»:

• Асинхронность: во время выполнения сценария элементы DOM могут ещё не загрузиться, из-за чего тест завершается ошибкой. Разработчикам приходится вручную добавлять множество wait и sleep, а тесты становятся ненадёжными.
• Кроссбраузерная совместимость: добиться стабильного выполнения тестов во всех основных браузерах — Chrome, Firefox и Safari — очень трудно.
• Сложная отладка: когда тест падает в среде CI/CD, воспроизвести и найти проблему сложно из-за отсутствия снимков состояния и сетевых журналов.

Для решения этих проблем появилось новое поколение инструментов тестирования, и Playwright — один из его лучших представителей.

2. Что такое Playwright?

Playwright — разработанная Microsoft библиотека Node.js для автоматизации браузеров Chromium (Chrome и Edge), Firefox и WebKit (Safari). Её создали ключевые участники команды, которая ранее разработала Google Puppeteer. Playwright можно считать духовным наследником Puppeteer, но с более современным и мощным устройством.

3. Основные преимущества Playwright

a. Настоящее кроссбраузерное тестирование

Это самое заметное преимущество Playwright. Единый API позволяет писать тесты для всех трёх основных браузерных движков. Благодаря этому легко находить и исправлять ошибки, которые проявляются только в определённом браузере, например Safari.

b. Автоматическое ожидание (Auto-Waits)

Playwright решает проблему асинхронности на фундаментальном уровне. Перед выполнением действия, например page.click(), он автоматически проводит ряд проверок доступности элемента для взаимодействия:

• Ждёт появления элемента в DOM.
• Ждёт, пока элемент станет видимым.
• Ждёт, пока анимация перестанет перекрывать элемент.
• Ждёт, пока элемент сможет принимать события.

Поэтому вручную писать код ожидания почти не требуется, а стабильность тестов значительно возрастает.

c. Мощные сопутствующие инструменты

• Codegen (генератор кода): революционная возможность. Можно выполнить pnpm exec playwright codegen example.com, и Playwright откроет окно браузера. Все действия в нём будут автоматически записаны и преобразованы в код теста. Это значительно снижает порог входа в E2E-тестирование.

• Trace Viewer (просмотр трассировки): «машина времени» Playwright. При падении теста можно создать полный файл трассировки. Открыв его в Trace Viewer, можно:

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

Благодаря этому отлаживать падения в CI стало проще, чем когда-либо.

4. Простой пример теста

API Playwright устроен очень понятно.

import { test, expect } from '@playwright/test';

test('页面应有正确的标题', async ({ page }) => {
  await page.goto('https://playwright.dev/');

  // 断言页面的 title 包含 "Playwright"
  await expect(page).toHaveTitle(/Playwright/);
});

test('点击 "Get started" 链接应跳转到介绍页', async ({ page }) => {
  await page.goto('https://playwright.dev/');

  // 通过角色和名称定位并点击链接
  await page.getByRole('link', { name: 'Get started' }).click();

  // 断言 URL 包含 "intro"
  await expect(page).toHaveURL(/.*intro/);
});

Заключение

Благодаря превосходной кроссбраузерной поддержке, надёжному автоматическому ожиданию и непревзойдённым средствам отладки — особенно Trace Viewer — Playwright устанавливает новый стандарт E2E-тестирования современных Web-приложений. Он не только повышает стабильность и надёжность тестов, но и значительно улучшает процесс их написания с помощью таких средств, как Codegen. Если вашему проекту нужен современный и мощный инструмент автоматизации тестирования, Playwright определённо заслуживает места среди основных кандидатов.

Суть фронтенд-разработки заключается в том, чтобы «отобразить состояние в пользовательский интерфейс». За многие годы мы стали свидетелями непрерывной эволюции реактивных моделей: от ручных операций с DOM через модели MVC/MVVM к виртуальному DOM (Virtual DOM), популяризированному React. Благодаря пакетной обработке изменений состояния и сравнению на уровне компонентов VDOM значительно упростил разработку интерфейсов.

Однако VDOM — не универсальное решение. Затраты на повторный рендеринг и сравнение на уровне компонентов в некоторых высокодинамичных сценариях могут стать узким местом производительности. В последние годы более старая парадигма, оптимизированная современными компиляторами, — мелкогранулярная реактивность (Fine-Grained Reactivity) — вновь оказалась в центре внимания, а её основным носителем стали Signals.

2. Что такое Signals?

Signal — это реактивный примитив (Reactive Primitive), который инкапсулирует значение и автоматически уведомляет все его зависимости при изменении этого значения. В отличие от VDOM-фреймворков, отслеживающих изменения на уровне компонентов, Signal автоматически создаёт граф зависимостей на уровне чтения данных.

При обновлении значения Signal повторно выполняются только те вычисления (Memo) или побочные эффекты (Effect), которые прямо или косвенно зависят от этого Signal. Так достигается точечное, «хирургическое» обновление DOM без необходимости сравнивать VDOM.

Обычно его основу составляют три примитива:

• createSignal(value): Создаёт реактивную единицу состояния.
• createEffect(() => {}): Создаёт побочный эффект, который автоматически отслеживает зависимости и реагирует на изменения.
• createMemo(() => {}): Создаёт производное кэшируемое реактивное вычисление.

// SolidJS 语法示例
const [count, setCount] = createSignal(0);

const doubleCount = createMemo(() => count() * 2);

createEffect(() => {
  console.log(`The double count is: ${doubleCount()}`);
});

setCount(1); // 这将触发 memo 重新计算，并触发 effect 重新执行

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

3. Широкое распространение в экосистеме

Signal — не совершенно новая концепция: её идеи восходят к ранним фреймворкам вроде Knockout.js. Однако современные компиляторы JavaScript дали ей новую жизнь, и сегодня её широко применяют крупные фреймворки:

• SolidJS & Qwik: Полностью построены на Signal и служат эталонными реализациями этой парадигмы.
• Preact: Добавил официальную поддержку через пакет @preact/signals, который можно интегрировать в существующие проекты Preact/React.
• Vue: ref и computed из Composition API, по сути, представляют собой одну из реализаций Signal.
• Svelte 5: Грядущее обновление «Runes» перестраивает реактивную модель Svelte, опираясь в своей основе на идеи и реализацию парадигмы Signal.
• Angular: В недавних версиях также появились Signals как новые реактивные примитивы.

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

4. Преимущества и компромиссы

Преимущества:

1. Выдающаяся производительность: Отказ от VDOM и повторного рендеринга на уровне компонентов обычно обеспечивает отличные результаты в тестах производительности.
2. Предсказуемость: Поток обновлений состояния прозрачен, его легко понимать и отлаживать.
3. Низкое потребление памяти: Не требуется хранить виртуальное представление всего дерева компонентов.

Компромиссы:

1. Смена ментальной модели: Разработчикам, привыкшим к циклу рендеринга React, нужно освоить новую модель, в которой «компонент выполняется только один раз».
2. Интеграция с экосистемой: Хотя Signals сами по себе обладают высокой производительностью, глубокая интеграция с обширной VDOM-экосистемой React — например, с некоторыми UI-библиотеками — может потребовать дополнительной адаптации.

Заключение

Возрождение Signals знаменует важный этап эволюции парадигм управления состоянием во фронтенде. Оно возвращает внимание разработчиков от вопроса «как рендерится компонент» к более фундаментальному вопросу «как движется состояние». Благодаря глубокой интеграции с компиляторами Signal обеспечивает отличный опыт разработки и одновременно открывает новые возможности на границах производительности Web-приложений.

При традиционной раздельной разработке фронтенда и бэкенда API служит «контрактом» между ними. Обычно этот контракт поддерживают следующими способами:

• RESTful API: с помощью таких инструментов, как OpenAPI (Swagger), которые создают и поддерживают подробную документацию API.
• GraphQL: с помощью строгого Schema Definition Language (SDL), определяющего структуры данных и операции.

Эти подходы работают, но у них есть общая проблема: контракт отделён от реализации. Вызывая API, фронтенд-разработчик верит, что тот вернёт структуру данных, описанную в документации или схеме. Если реализация бэкенда изменилась — например, было переименовано поле, — а документация или схема не обновились вовремя, несоответствие проявится только во время выполнения и приведёт к ошибке.

Можно ли автоматически синхронизировать этот «контракт» с реализацией и даже выявлять несоответствия во время компиляции?

2. Главная идея tRPC: общие типы вместо схем

tRPC (TypeScript Remote Procedure Call) предлагает радикальное, но крайне простое решение: если и фронтенд, и бэкенд написаны на TypeScript, почему бы не использовать типы напрямую?

tRPC позволяет писать обычные функции TypeScript в качестве API бэкенда и непосредственно вызывать их во фронтенде с полной поддержкой вывода типов и автодополнения — словно это функции локального модуля.

Ни схемы, ни генерация кода не требуются. Единственный «контракт» — сами типы TypeScript.

3. Как это работает?

Магия tRPC основана на выводе типов и небольшой хитроумной обёртке.

a. Бэкенд: определяем API Router

На бэкенде — обычно в сервисе Node.js — с помощью функций tRPC создаётся один или несколько «Router». Каждый Router представляет собой набор доступных для вызова «Procedure», то есть конечных точек API.

// server/router.ts
import { initTRPC } from '@trpc/server';
import { z } from 'zod'; // 使用 Zod 进行运行时校验

const t = initTRPC.create();

export const appRouter = t.router({
  // 定义一个名为 `getUser` 的查询 procedure
  getUser: t.procedure
    .input(z.object({ userId: z.string() }))
    .query(({ input }) => {
      // 在这里查询数据库或执行其他逻辑
      const user = { id: input.userId, name: 'Alex' };
      return user;
    }),

  // 定义一个名为 `createUser` 的变更 procedure
  createUser: t.procedure
    .input(z.object({ name: z.string() }))
    .mutation(({ input }) => {
      const user = { id: `${Math.random()}`, name: input.name };
      return user;
    }),
});

// 导出 router 的类型定义
export type AppRouter = typeof appRouter;

b. Фронтенд: создаём клиент и вызываем API

Во фронтенде достаточно импортировать из бэкенда AppRouter как тип. Обратите внимание: импортируется только тип, а не серверный код.

// client/trpc.ts
import { createTRPCReact } from '@trpc/react-query';
import type { AppRouter } from '../server/router'; // 只导入类型

export const trpc = createTRPCReact<AppRouter>();

Теперь API можно вызывать из компонента React словно локальную функцию, пользуясь полной типобезопасностью и автодополнением.

// client/components/UserInfo.tsx
import { trpc } from '../trpc';

function UserInfo({ userId }: { userId: string }) {
  // `useQuery` 的第一个参数是 procedure 的路径
  // 你输入 `trpc.` 时，IDE 会自动提示 `getUser` 和 `createUser`
  const userQuery = trpc.getUser.useQuery({ userId });

  if (userQuery.isLoading) {
    return <div>Loading...</div>;
  }

  // `userQuery.data` 的类型被自动推断为 { id: string; name: string }
  return <div>User: {userQuery.data?.name}</div>;
}

Если теперь разработчик бэкенда переименует поле, возвращаемое getUser, с name на fullName, выражение userQuery.data?.name во фронтенде немедленно вызовет ошибку компиляции TypeScript, а не обнаружится лишь во время выполнения.

4. Почему стоит выбрать tRPC?

• Абсолютная сквозная типобезопасность: в этом заключается его основная ценность. Устраняется целый класс ошибок, вызванных несовпадением контрактов API.
• Превосходный процесс разработки: благодаря автодополнению IDE больше не нужно сверяться с документацией или угадывать структуру API. Рефакторинг становится исключительно простым и безопасным.
• Без генерации кода: дополнительных этапов сборки нет, поэтому обратная связь поступает очень быстро.
• Лёгкость и гибкость: сам tRPC очень мал и может интегрироваться с любым фронтенд-фреймворком и бэкенд-сервисом.

Заключение

tRPC делает full-stack-разработку на TypeScript беспрецедентно плавной. Отказ от зависимости от документации API и схем обеспечивает бесшовное и крайне безопасное взаимодействие фронтенда с бэкендом. В архитектуре монорепозитория эти преимущества становятся ещё заметнее. Если вы создаёте full-stack-приложение на TypeScript, tRPC — революционный инструмент, которому определённо стоит уделить время.

Современные фронтенд-фреймворки, такие как React, Vue и Svelte, значительно улучшили процесс разработки сложных веб-приложений. Но когда мы используем их для создания блогов, портфолио, документации или маркетинговых сайтов, возникает вопрос: действительно ли сайтам, предназначенным прежде всего для представления контента, нужно загружать всю страницу как одностраничное приложение (SPA)?

Обычно ответ — «нет». Для таких сайтов главная потребность пользователя заключается в быстром доступе к контенту. Избыток JavaScript, напротив, замедляет время до интерактивности (TTI), ухудшая пользовательский опыт и SEO.

Astro появился именно для решения этой проблемы.

2. Основная идея Astro: сначала контент, по умолчанию без JS

Astro — современный генератор статических сайтов (SSG), основная идея которого заключается в подходе сначала контент. Он стремится выполнить как можно больше работы во время сборки и отправить в браузер как можно меньше JavaScript.

Для этого Astro предложил два ключевых нововведения:

• По умолчанию без JavaScript (Zero-JS by Default): Astro во время сборки преобразует все ваши UI-компоненты, независимо от того, написаны они на React, Vue или Svelte, в чистый HTML. Поэтому браузер получает статическую страницу и не должен загружать JS-среду какого-либо фреймворка, что обеспечивает очень быструю загрузку.
• Островная архитектура (Islands Architecture): В этом заключается суть Astro. В «океане» статического HTML любой компонент, которому нужно взаимодействие на стороне клиента, можно отметить как «остров». Astro отдельно упаковывает и загружает JavaScript, необходимый этим островам, а остальная часть страницы остается полностью статической.

3. Как работают «острова»?

В Astro компонент можно отметить как интерактивный остров, добавив директиву client:*.

Например, предположим, что у нас есть написанный на React компонент счетчика Counter.jsx. На странице Astro его можно использовать так:

---
// src/pages/index.astro
import Counter from '../components/Counter.jsx';
---
<html>
  <body>
    <h1>Astro 示例</h1>
    <p>这是一个静态的段落，它不会加载任何 JS。</p>

    {/* 这个组件是一个交互式岛屿 */}
    <Counter client:load />

    <p>这是另一个静态段落。</p>
  </body>
</html>

Директива client:load сообщает Astro:

1. Отобразить начальный HTML компонента Counter на сервере.
2. Создать отдельный JS-пакет для компонента Counter.
3. Автоматически загрузить этот JS-пакет при загрузке страницы и «активировать» (hydrate) компонент, сделав его интерактивным.

Astro также предлагает более точные директивы загрузки, например client:idle (загрузка во время простоя браузера) и client:visible (загрузка, когда компонент появляется в области просмотра), позволяя еще лучше оптимизировать производительность.

4. Независимость от фреймворка

Еще одно важное достоинство Astro — его открытость к UI-фреймворкам. В одном проекте Astro можно одновременно использовать компоненты из разных фреймворков, таких как React, Vue, Svelte, SolidJS и Lit. Это дает командам огромную гибкость в совместной работе и выборе технологий.

Заключение

Astro не стремится заменить React или Vue, а предлагает более подходящее решение для определенных сценариев. Если ваш проект — сайт, сосредоточенный на контенте и предъявляющий очень высокие требования к производительности и SEO (например, сам этот блог построен на Astro), то Astro, несомненно, является отличным выбором, который стоит изучить глубже. Он прекрасно сочетает преимущества производительности статических сайтов с удобством разработки на современных фреймворках.

В декабре 2022 года команда Svelte официально объявила о выпуске SvelteKit 1.0. Это стало важной вехой не только для сообщества Svelte, но и для всей фронтенд-разработки. SvelteKit больше нельзя считать всего лишь «Next.js или Nuxt.js для Svelte». Он обладает собственной уникальной философией и стремится предложить более простой, гибкий и производительный способ создания Web-приложений.

Что такое SvelteKit?

Если вы знакомы со Svelte, то, вероятно, знаете, что сам Svelte — это компонентный фреймворк. Его радикальный компилятор во время сборки преобразует файлы .svelte в эффективный императивный JavaScript-код, обеспечивая впечатляющую производительность и чрезвычайно малые накладные расходы во время выполнения.

SvelteKit же представляет собой фреймворк приложений, построенный поверх Svelte. Он берёт на себя всё необходимое для создания полноценного приложения: маршрутизацию, серверный рендеринг (SSR), загрузку данных, адаптацию к среде развёртывания и многое другое, позволяя сосредоточиться на бизнес-логике.

Обзор основных возможностей

1. Маршрутизация на основе файловой системы

Подобно Next.js, SvelteKit автоматически создаёт маршруты на основе структуры файловой системы. Структура файлов в каталоге src/routes напрямую соответствует URL приложения.

• src/routes/+page.svelte -> /
• src/routes/about/+page.svelte -> /about
• src/routes/blog/[slug]/+page.svelte -> /blog/some-post

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

2. Гибкие режимы рендеринга

SvelteKit позволяет точно управлять способом рендеринга на уровне отдельных страниц. В одном приложении можно реализовать серверный рендеринг (SSR), генерацию статического сайта (SSG) или сочетание обоих способов. Можно даже отключить SSR для отдельной страницы, превратив её в полностью клиентское одностраничное приложение (SPA).

3. Универсальная функция load

SvelteKit унифицирует модель загрузки данных. Рядом с каждой страницей или макетом можно создать файл +page.js либо +page.server.js и экспортировать из него функцию load.

• В +page.js функция load выполняется и на сервере, и на клиенте.
• В +page.server.js функция load выполняется только на сервере, поэтому там можно безопасно обращаться к базе данных или закрытому API.

Данные, возвращённые функцией load, автоматически передаются соответствующему компоненту +page.svelte.

// src/routes/blog/[slug]/+page.server.js
import * as db from '$lib/server/database';

export async function load({ params }) {
  const post = await db.getPost(params.slug);
  return { post };
}

4. Адаптеры

«Написать один раз, развернуть где угодно» — одно из главных обещаний SvelteKit. С помощью адаптеров SvelteKit может упаковать приложение в формате, подходящем для любой целевой платформы.

• @sveltejs/adapter-node: Для развёртывания на традиционном сервере Node.js.
• @sveltejs/adapter-vercel: Адаптация к платформе Vercel.
• @sveltejs/adapter-static: Предварительный рендеринг всего приложения в статические файлы, подходящие для любого статического хостинга.
• Существуют и другие официальные и созданные сообществом адаптеры для Netlify, Cloudflare Workers и прочих платформ.

Заключение

Выпуск SvelteKit 1.0 ознаменовал зрелость экосистемы Svelte. Он объединяет исключительную производительность компилятора Svelte с тщательно продуманным фреймворком приложений и даёт разработчикам мощный и приятный опыт работы. Если вам нужен универсальный фреймворк, способный создавать как простые статические страницы, так и сложные динамические приложения, SvelteKit определённо стоит попробовать.

«Как элегантно управлять состоянием?» Это ключевой вопрос, с которым по мере роста проекта сталкивается каждый React-разработчик. От простого состояния внутри компонента до сложного глобального состояния, общего для многих компонентов, — сообщество React изучило множество решений. Их эволюция также отражает то, как углублялось наше понимание компонентной разработки.

Первый этап: простая эпоха — useState и Props Drilling

Вначале в нашем распоряжении был только useState (или this.state в классовых компонентах). Когда одно состояние требовалось нескольким компонентам, официальной рекомендацией React было «поднятие состояния» (Lifting State Up). Состояние переносили к ближайшему общему родительскому компоненту, а затем передавали его и функцию обновления вниз через props.

При глубокой иерархии компонентов этот подход приводил к «протаскиванию props» (Props Drilling): некоторые промежуточные компоненты получали props лишь для передачи их более глубоким потомкам, не используя эти данные сами. Это усиливало связанность компонентов и усложняло рефакторинг и сопровождение.

Второй этап: официальный ответ — Context API

Для решения проблемы Props Drilling React официально предоставил Context API. Он позволяет создать «контекст», предоставить (Provide) значение на верхнем уровне дерева компонентов, а затем напрямую использовать (Consume) это значение в дочернем компоненте на любой глубине без ручной передачи через каждый уровень.

// 1. 创建 Context
const ThemeContext = React.createContext('light');

// 2. 在顶层提供值
<ThemeContext.Provider value="dark">
  <App />
</ThemeContext.Provider>

// 3. 在子组件中消费
const theme = useContext(ThemeContext); // 'dark'

Однако у Context API есть «ловушка»: проблемы с производительностью. При любом изменении Provider, а именно его value, повторно рендерятся все компоненты, использующие этот Context, даже если им нужна лишь небольшая часть объекта value. Поэтому Context API не подходит для управления сложным глобальным состоянием, которое часто меняется.

Третий этап: эпоха объединения — Redux

Когда Context API ещё не достиг зрелости, стремительно появился Redux и быстро стал фактическим стандартом управления состоянием в больших и сложных приложениях. Заимствуя идеи архитектуры Flux и функционального программирования, он принёс следующие принципы:

• Единственный источник истины (Single Source of Truth): State всего приложения хранится в едином store.
• State доступен только для чтения: Единственный способ изменить state — выполнить dispatch для action.
• Изменения выполняются чистыми функциями: Reducer получает предыдущий state и action, а возвращает новый state.

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

Четвёртый этап: возрождение — лёгкие решения в стиле Hooks-First

С распространением React Hooks и переосмыслением сложности Redux в сообществе стало появляться новое поколение более лёгких библиотек управления состоянием. Их объединяли лаконичные API, простые ментальные модели и полноценное использование возможностей Hooks.

Zustand — один из ярких представителей. Он предоставляет чрезвычайно простую функцию create для создания store, а также:

• Не требует Provider: Store существует вне дерева компонентов React, поэтому его можно импортировать и использовать где угодно.
• Минимальный API: Для доступа к состоянию и его обновления достаточно одного Hook.
• Избирательные подписки и лучшая производительность: Компонент может подписаться только на нужную ему часть state, избегая проблем производительности Context API.

const useStore = create(set => ({
  count: 0,
  inc: () => set(state => ({ count: state.count + 1 })),
}));

function Counter() {
  // 只订阅 count 的变化
  const count = useStore(state => state.count);
  return <h1>{count}</h1>;
}

Заключение: серебряной пули нет — выбирайте по потребностям

История развития управления состоянием в React показывает, что универсального «лучшего решения» не существует: есть лишь решение, которое лучше всего подходит для текущей ситуации.

• useState: Всегда первый выбор для локального состояния компонента.
• Context API: Подходит для глобальных данных, которые меняются нечасто, например темы или сведений об аутентификации пользователя.
• Zustand / Jotai: Для большинства приложений, которым требуется глобальное клиентское состояние, они обеспечивают превосходный баланс между производительностью и удобством разработки.
• Redux (Redux Toolkit): По-прежнему надёжный выбор для сверхкрупных приложений, которым нужны строгие правила потока данных, сложное промежуточное ПО и мощные возможности отладки.

Webpack — чрезвычайно мощный и гибко настраиваемый сборщик модулей, который много лет оставался основой фронтенд-проектов. Но по мере роста проектов его основная идея, основанная на сборке, создает узкие места производительности:

• Медленный холодный запуск: При каждом запуске сервера разработки (dev-server) Webpack должен обойти весь граф зависимостей и собрать все модули в памяти. В крупных проектах этот процесс может занимать несколько минут.
• Медленное горячее обновление (HMR): При изменении файла Webpack должен заново вычислить и заменить связанные модули. Это быстрее полной перезагрузки страницы, но в крупных проектах задержка может достигать нескольких или даже более десяти секунд, прерывая рабочий ритм.

2. Как Vite решает эти проблемы?

Vite, название которого по-французски означает «быстро», идет другим путем. Он использует поддержку нативных модулей ES (ESM) современными браузерами и делит процесс сборки на две части:

• Во время разработки: Vite запускает сервер, но не собирает заранее все модули. Вместо этого он перехватывает запросы модулей от браузера, преобразуя и отдавая исходный код по требованию. Например, браузер запрашивает main.js, и Vite отдает его; main.js импортирует Button.vue, браузер отправляет новый запрос, и Vite отдает преобразованный Button.vue. Благодаря этому сервер разработки запускается почти мгновенно.
• В производственной среде: Vite использует Rollup, еще один эффективный сборщик, чтобы создавать хорошо оптимизированные статические ресурсы.

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

3. Практические шаги миграции

Миграция существующего проекта с Webpack на Vite обычно включает следующие шаги:

a. Установить зависимости и создать файл конфигурации

Сначала установите Vite:

pnpm add -D vite @vitejs/plugin-react # 或 @vitejs/plugin-vue

Затем создайте vite.config.js в корне проекта:

import react from '@vitejs/plugin-react'
import { defineConfig } from 'vite'

export default defineConfig({
  plugins: [react()],
})

b. Переместить index.html

Webpack обычно размещает index.html в каталоге public и автоматически добавляет собранный JS. Vite считает index.html точкой входа приложения. Нужно переместить его в корень проекта и вручную добавить ссылку на скрипт:

<body>
  <div id="root"></div>
  <script type="module" src="/src/main.jsx"></script>
</body>

c. Заменить плагины Webpack

Нужно найти плагины Vite, соответствующие Loaders и Plugins из Webpack. Экосистема сообщества очень богата, и решение найдется для большинства задач.

d. Обработать переменные окружения

В Webpack мы привыкли использовать process.env.NODE_ENV. В Vite доступ к переменным окружения осуществляется через import.meta.env, например import.meta.env.VITE_API_URL.

e. Настроить псевдонимы путей

Псевдонимы путей в vite.config.js настраиваются очень просто:

import path from 'node:path'
// vite.config.js
import { defineConfig } from 'vite'

export default defineConfig({
  // ...
  resolve: {
    alias: {
      '@': path.resolve(__dirname, './src'),
    },
  },
})

4. Результаты после миграции

После миграции на Vite самое заметное впечатление — скорость.

• Время запуска сервера разработки сократилось с 50 секунд до 2 секунд.
• Время горячего обновления уменьшилось со средних 3–5 секунд до почти незаметных десятков миллисекунд.
• Файл конфигурации (vite.config.js) стал значительно проще, чем webpack.config.js.

Заключение

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

Решения CSS-in-JS, такие как styled-components и Emotion, радикально изменили управление стилями в компонентной разработке, позволив писать CSS в JavaScript- или TypeScript-файлах. Они дают множество преимуществ:

• Область видимости компонента: Стили по умолчанию привязаны к компоненту, что решает проблему глобальных конфликтов имён CSS.
• Динамические стили: Динамические стили можно легко создавать на основе props или state компонента.
• Совместное размещение кода: Стили и логика компонента находятся в одном файле, что упрощает сопровождение и организацию.

Однако за эти удобства приходится платить. Основа традиционных библиотек CSS-in-JS — runtime. Когда компонент монтируется в браузере, JavaScript runtime библиотеки CSS-in-JS:

1. Разбирает CSS в шаблонных строках или объектах.
2. Генерирует уникальные имена классов.
3. Динамически внедряет стили в <head> документа, в теги <style>.

Этот процесс увеличивает размер JavaScript-бандла и создаёт дополнительные вычислительные расходы при запуске и рендеринге приложения, что влияет на производительность.

2. Выход с помощью «нулевого runtime»

Чтобы решить проблему производительности во время выполнения, сообщество предложило новый подход: CSS-in-JS без runtime (Zero-Runtime).

Основная идея — сохранить удобство разработки CSS-in-JS, но выполнить всю работу во время сборки (build time). Инструмент сборки, обычно плагин Babel или Vite, сканирует код, находит все случаи использования CSS-in-JS, а затем:

1. Извлекает текст CSS.
2. Создаёт статические файлы .css.
3. Заменяет исходный код CSS-in-JS сгенерированными уникальными именами классов.

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

3. Основные решения без runtime

a. Linaria

Linaria — один из пионеров CSS-in-JS без runtime. Она позволяет использовать знакомый синтаксис тегированных шаблонных строк styled.

// YourComponent.js
import { styled } from '@linaria/react';

const Title = styled.h1`
  font-size: 2rem;
  color: tomato;
`;

// 构建时，这会被转换为：
// <h1 class="Title_a1b2c3d">...</h1>
//
// 并在一个静态 .css 文件中生成：
// .Title_a1b2c3d {
//   font-size: 2rem;
//   color: tomato;
// }

b. vanilla-extract

Разработанный командой SEEK vanilla-extract идёт дальше и использует TypeScript для создания полностью типобезопасных стилей. Все определения стилей представлены экспортируемыми переменными в файлах .css.ts, что обеспечивает мощный вывод типов и автодополнение.

// styles.css.ts
import { style } from '@vanilla-extract/css';

export const title = style({
  fontSize: '2rem',
  color: 'tomato',
});

c. Panda CSS

Panda CSS — более новый конкурент. Он заимствует идеи Tailwind CSS, предлагает опыт разработки со «Style Props» и при этом гарантирует вывод без runtime.

import { css } from '../styled-system/css';

function MyComponent() {
  return <div className={css({ fontSize: '2rem', color: 'tomato' })} />;
}

4. Преимущества и компромиссы

Преимущества:

• Максимальная производительность: Конечный результат представляет собой статический CSS без расходов JavaScript runtime.
• Меньший размер бандла: На клиенте не нужно загружать библиотеку CSS-in-JS.
• Мощный опыт разработки: Сохраняются область видимости компонента, типобезопасность TypeScript и совместное размещение кода.

Компромиссы:

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

Заключение

CSS-in-JS без runtime — это корректировка курса традиционной парадигмы CSS-in-JS. Он грамотно разделяет «опыт во время разработки» и «производительность во время выполнения», избавляя от необходимости выбирать между ними. Для современных веб-приложений, стремящихся к максимальной производительности и меньшему размеру бандла, это почти идеальное решение.

Благодаря ежегодному циклу релизов комитета TC39 язык JavaScript продолжает развиваться каждый год. ECMAScript 2022 (ES2022) принёс ряд новых возможностей, призванных улучшить опыт разработчиков и читаемость кода. Рассмотрим самые яркие из них.

1. await на верхнем уровне

Это одна из самых ожидаемых возможностей ES2022. Раньше ключевое слово await можно было использовать только внутри функции async. Из-за этого асинхронные операции в области видимости верхнего уровня модуля было неудобно обрабатывать: обычно асинхронный код приходилось оборачивать в IIFE (немедленно вызываемое функциональное выражение).

Раньше 👎:

// data.js
import { fetchData } from './api.js';

let data;
(async () => {
  data = await fetchData();
  // ... 只能在这里使用 data
})();

export { data }; // 导出时 data 还是 undefined

Теперь (ES2022) 👍:

// data.js
import { fetchData } from './api.js';

const data = await fetchData();

export { data }; // 模块会等待 await 完成后再被其他模块评估

Top-level await значительно упрощает динамическую загрузку модулей, инициализацию зависимостей и другие подобные сценарии, делая асинхронный код более интуитивным.

2. Метод индексирования массивов и строк .at()

Чтобы получить последний элемент массива в JavaScript, обычно приходится писать arr[arr.length - 1], что многословно и чревато ошибками. ES2022 вводит метод .at(), унифицирующий работу с прямыми и обратными индексами.

Метод .at() принимает целое число. Положительное число возвращает элемент с соответствующим индексом, а отрицательное отсчитывает элементы с конца.

Раньше 👎:

const arr = [1, 2, 3, 4, 5];
const lastElement = arr[arr.length - 1]; // 5
const secondToLast = arr[arr.length - 2]; // 4

Теперь (ES2022) 👍:

const arr = [1, 2, 3, 4, 5];
const lastElement = arr.at(-1); // 5
const secondToLast = arr.at(-2); // 4

// 同样适用于字符串
const str = 'hello';
console.log(str.at(-1)); // 'o'

3. Object.hasOwn(obj, prop)

Чтобы проверить, есть ли у объекта собственное, а не унаследованное свойство, обычно используют Object.prototype.hasOwnProperty.call(obj, prop). Такая запись очень громоздка и в некоторых случаях, например с объектами, созданными через Object.create(null), может привести к ошибке.

Object.hasOwn() предлагает более короткий и надёжный статический метод.

Раньше 👎:

const obj = { a: 1 };
console.log(Object.prototype.hasOwnProperty.call(obj, 'a')); // true
console.log(Object.prototype.hasOwnProperty.call(obj, 'toString')); // false

Теперь (ES2022) 👍:

const obj = { a: 1 };
console.log(Object.hasOwn(obj, 'a')); // true
console.log(Object.hasOwn(obj, 'toString')); // false

4. Другие примечательные возможности

• Error Cause: Конструктор Error теперь может принимать второй аргумент, указывающий «причину» ошибки, что облегчает создание более понятных цепочек ошибок.

  try {
    // ...
  } catch (err) {
    throw new Error('New error message', { cause: err });
  }
  

• Индексы совпадений RegExp (флаг /d): При использовании флага /d результат регулярного выражения дополнительно содержит начальный и конечный индексы каждой группы захвата.

Заключение

Хотя новые возможности ES2022 не принесли революционных изменений, они дорабатывают JavaScript в деталях, решают многие давние проблемы разработчиков и делают код более кратким и надёжным.

Redux, без сомнения, является самой известной и мощной библиотекой управления состоянием в экосистеме React. Однонаправленный поток данных, отладка с путешествием во времени и другие возможности делают его надёжным выбором для больших и сложных приложений. Однако во многих небольших и средних проектах «шаблонный код» (Boilerplate) Redux часто доставляет немало хлопот:

• Actions & Action Creators: Необходимо определять множество типов action и функций их создания.
• Reducers: Приходится писать большие конструкции switch для обработки разных action.
• Dispatch & Selectors: В компонентах action отправляются через dispatch, а подписка на изменения состояния выполняется через useSelector.
• Context Provider: Корень приложения необходимо обернуть в <Provider>.

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

2. Zustand — глоток свежего воздуха

Zustand («состояние» по-немецки) — это лёгкая библиотека управления состоянием, разработанная командой Poimandres, создавшей react-three-fiber. Её философия — минимализм и ненавязчивость.

Основные особенности:

• Очень мало кода: Для реализации одной функции Zustand обычно требует лишь малую долю кода, необходимого Redux.
• Основан на Hooks: Всё строится вокруг одного пользовательского Hook, что соответствует привычкам современной React-разработки.
• Не требует Context Provider: Верхний уровень приложения не нужно оборачивать в Provider. Store не зависит от дерева компонентов, поэтому его можно импортировать и использовать где угодно.
• Легко освоить: API предельно прост, основные приёмы можно изучить за несколько минут.

3. Основы использования

Работа с Zustand делится на два шага: создание Store и его использование в компоненте.

a. Создание Store

Store можно определить в любом файле .js или .ts.

// src/store.js
import { create } from 'zustand';

const useBearStore = create((set) => ({
  bears: 0,
  increasePopulation: () => set((state) => ({ bears: state.bears + 1 })),
  removeAllBears: () => set({ bears: 0 }),
}));

export default useBearStore;

Функция create принимает callback, аргументом которого является функция set, похожая на setState в React. Здесь определяются состояние и методы его обновления.

b. Использование в компоненте

Используйте его в любом компоненте как обычный Hook.

// src/components/BearCounter.jsx
import useBearStore from '../store';

function BearCounter() {
  const bears = useBearStore((state) => state.bears);
  return <h1>{bears} around here ...</h1>;
}

Обратите внимание: через функцию-селектор (state) => state.bears мы подписываемся на состояние bears. Это важно, поскольку компонент будет повторно рендериться только при изменении bears, что предотвращает ненужные затраты производительности.

// src/components/Controls.jsx
import useBearStore from '../store';

function Controls() {
  const increasePopulation = useBearStore((state) => state.increasePopulation);
  return <button onClick={increasePopulation}>one up</button>;
}

Получить action так же просто.

4. Асинхронные Action

Zustand также естественно работает с асинхронными операциями. Никакое промежуточное ПО вроде redux-thunk или redux-saga не требуется.

const useAsyncStore = create((set) => ({
  data: null,
  fetchData: async (url) => {
    const response = await fetch(url);
    const data = await response.json();
    set({ data });
  },
}));

Заключение

Zustand не стремится полностью заменить Redux. У Redux по-прежнему есть преимущества в строгих правилах, отслеживаемости и огромной экосистеме.

Однако для подавляющего большинства React-приложений Zustand предлагает более простой и быстрый вариант с меньшей когнитивной нагрузкой. Если вы устали от формальностей Redux или следующему проекту нужен лёгкий и гибкий менеджер состояния, Zustand определённо заслуживает внимания.

Monorepo, или единый репозиторий кода, — это стратегия хранения нескольких независимых проектов или пакетов в одном репозитории. По сравнению с моделью Polyrepo, где у каждого проекта отдельный репозиторий, Monorepo дает несколько заметных преимуществ:

• Совместное использование кода: Обмен компонентами, вспомогательными функциями и определениями типов между разными проектами становится очень простым.
• Атомарные коммиты: Если изменение одной функции затрагивает несколько пакетов, его можно выполнить одним коммитом, обеспечив согласованность версий.
• Упрощенное управление зависимостями: Все проекты используют общий node_modules или оптимизируют его через workspace pnpm/yarn, что уменьшает конфликты зависимостей и расхождения версий.

Однако по мере роста репозитория Monorepo приносит и новую проблему: производительность сборки.

2. Проблемы Monorepo

Представьте, что в репозитории есть docs, webapp и общая библиотека UI-компонентов ui. Если вы исправили только одну опечатку в docs, меньше всего хочется, чтобы все проекты репозитория, включая webapp и ui, заново собирались и тестировались.

Традиционным инструментам управления Monorepo, таким как Lerna, не хватает возможностей оркестрации задач и кеширования сборки, что приводит к следующим проблемам:

• Повторная работа: При каждом запуске CI/CD все собирается и тестируется с нуля, даже если большая часть кода не изменилась.
• Долгая сборка: Невозможно эффективно использовать несколько ядер CPU для параллельного выполнения задач.
• Сложные скрипты: Для ручного управления порядком выполнения задач приходится писать сложные скрипты package.json.

3. Turborepo: создан для скорости

Turborepo — высокопроизводительная система сборки для Monorepo на JavaScript/TypeScript, позднее приобретенная Vercel. Она решает описанные проблемы с помощью двух ключевых технологий: инкрементальной сборки и удаленного кеширования.

a. Инкрементальная сборка и конвейеры задач

Turborepo позволяет определять зависимости между задачами в файле turbo.json в корне проекта.

// turbo.json
{
  "$schema": "https://turbo.build/schema.json",
  "pipeline": {
    "build": {
      "dependsOn": ["^build"],
      "outputs": ["dist/**", ".next/**"]
    },
    "test": {
      "dependsOn": ["build"],
      "outputs": []
    },
    "lint": {
      "outputs": []
    },
    "dev": {
      "cache": false
    }
  }
}

• dependsOn: ["^build"]: Символ ^ означает, что задача build пакета зависит от задач build всех пакетов, от которых он зависит. Turborepo выполняет задачи в наиболее эффективном параллельном порядке на основе этого графа.
• outputs: Сообщает Turborepo, какие выходные файлы создает задача.

При запуске pnpm turbo build Turborepo вычисляет, какие файлы изменились, и заново собирает только затронутые пакеты. Если исходный код и зависимости пакета не изменились, Turborepo напрямую использует результат предыдущей сборки, что происходит мгновенно.

b. Удаленное кеширование

Это «главная особенность» Turborepo. Система не только кеширует результаты сборки на локальном компьютере, но и может загружать кеш на общий удаленный сервер, например Vercel или в собственный бакет S3.

Это означает:

• Ваш коллега, получив свежий код, может напрямую скачать кеш, если вы уже собрали нужную ему часть, и не выполнять локальную сборку заново.
• Сервер CI/CD также может подключаться к этому удаленному кешу. После сборки и кеширования PR в CI другие разработчики и последующие задачи CI смогут немедленно использовать результат.

Это способно сократить время сборки для всей команды с десятков минут до нескольких минут или даже десятков секунд.

Заключение

Turborepo не изобрел Monorepo, но благодаря передовым системам кеширования и планирования задач значительно улучшил разработку в Monorepo и устранил его главный узкий момент производительности. Если вы используете или планируете внедрить архитектуру Monorepo, Turborepo — мощный инструмент, способный сэкономить вам и вашей команде много времени.

С тех пор как React популяризировал виртуальный DOM (Virtual DOM), VDOM словно стал обязательной частью современных фронтенд-фреймворков. Он хранит в памяти виртуальное представление UI и с помощью алгоритма diff вычисляет минимально необходимые обновления DOM, улучшая опыт разработки и производительность в большинстве сценариев.

Но VDOM не обходится бесплатно. Он занимает память, а процесс diff требует вычислительных ресурсов. Отсюда возникает вопрос: можно ли обойти VDOM и точно применять изменения состояния непосредственно к DOM, сохранив при этом декларативный, похожий на React опыт разработки?

SolidJS даёт свой ответ.

2. Основа SolidJS: мелкозернистая реактивность (Fine-Grained Reactivity)

SolidJS — декларативный реактивный JavaScript-фреймворк. Он использует JSX и внешне очень похож на React, однако его внутренние принципы совершенно иные.

Компилятор SolidJS преобразует JSX-код в оптимальные нативные операции с DOM. Вместо VDOM он создаёт граф зависимостей из реактивных «сигналов» (Signals). Когда значение сигнала меняется, повторно выполняются только подписанные на него «эффекты» (Effects) или вычисления (Memos).

Модель, меняющая привычное мышление: компонент выполняется только один раз!

В React при изменении state или props вся функция компонента выполняется повторно. В SolidJS функция компонента выполняется от начала до конца только один раз.

import { createSignal } from 'solid-js';

function Counter() {
  console.log('Component function runs!'); // 这句话只会在组件挂载时打印一次

  const [count, setCount] = createSignal(0);

  const increment = () => setCount(count() + 1);

  return (
    <button type="button" onClick={increment}>
      Count: {count()}
    </button>
  );
}

При нажатии на кнопку обновляются только считыватель сигнала count() и зависящий от него текстовый DOM-узел. Сама функция Counter повторно не запускается. Такие «хирургически точные» обновления и обеспечивают исключительную производительность SolidJS.

3. Основные API

Реактивная система SolidJS в основном состоит из трёх базовых примитивов:

• createSignal(initialValue): Создаёт реактивный сигнал и возвращает getter и setter: [count, setCount].
• createEffect(() => {}): Создаёт «эффект», который автоматически отслеживает все прочитанные внутри него сигналы и выполняется снова при изменении любого из них. Отлично подходит для побочных эффектов, например ручной работы с DOM.
• createMemo(() => {}): Создаёт кэшируемое производное вычисляемое значение. Оно пересчитывается только при изменении внутренних зависимостей-сигналов.

import { createSignal, createEffect } from 'solid-js';

function App() {
  const [firstName, setFirstName] = createSignal('John');
  const [lastName, setLastName] = createSignal('Smith');

  // createEffect 会在 firstName 或 lastName 变化时自动运行
  createEffect(() => {
    console.log(`Full name: ${firstName()} ${lastName()}`);
  });

  // ...
}

4. Почему стоит выбрать SolidJS?

• Исключительная производительность: SolidJS часто занимает верхние позиции в независимых тестах, а его производительность очень близка к нативному JavaScript-коду.
• Очень маленький размер пакета: Благодаря отсутствию VDOM runtime основной пакет имеет небольшой размер.
• Знакомый опыт разработки: Если вы знакомы с React Hooks, то сможете быстро освоить SolidJS. Сочетание JSX и реактивных примитивов одновременно мощное и понятное.
• Настоящая реактивность: Его модель ближе к MobX или Composition API во Vue, но компилятор позволяет реализовать её без затрат во время выполнения.

Заключение

SolidJS представляет важное направление развития фронтенд-фреймворков: компилятор выполняет больше работы во время сборки, чтобы сократить объём кода во время выполнения и повысить производительность. Он доказывает, что от ограничений виртуального DOM можно полностью отказаться, не жертвуя декларативным опытом разработки. Для приложений, стремящихся к максимальной производительности, SolidJS предлагает крайне привлекательный вариант.

Fetch API пришёл на смену устаревшему XMLHttpRequest и стал стандартным способом выполнения HTTP-запросов в браузере. Он основан на Promise и предоставляет более простой и мощный механизм запросов.

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

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

2. AbortController — универсальный сигнал отмены

AbortController — это универсальный Web API, предоставляющий механизм для прерывания одного или нескольких Web-запросов. Он не зависит от Fetch API, но прекрасно работает вместе с Fetch.

Основная идея AbortController такова:

1. Создать экземпляр AbortController.
2. Получить из него объект AbortSignal.
3. Передать AbortSignal Web API, поддерживающему прерывание, например fetch.
4. Когда потребуется отмена, вызвать у экземпляра AbortController метод abort().

3. Совместное использование AbortController и Fetch

Рассмотрим на примере, как с помощью AbortController отменить запрос Fetch.

const controller = new AbortController();
const signal = controller.signal; // 获取信号对象

async function fetchDataWithCancellation(url) {
  try {
    console.log('Fetching data...');
    const response = await fetch(url, { signal }); // 将信号传递给 fetch
    const data = await response.json();
    console.log('Data received:', data);
    return data;
  } catch (error) {
    if (error.name === 'AbortError') {
      console.log('Fetch request was aborted.');
    } else {
      console.error('Fetch error:', error);
    }
  }
}

// 示例用法
const promise = fetchDataWithCancellation('https://jsonplaceholder.typicode.com/posts/1');

// 假设在 500 毫秒后，我们决定取消这个请求
setTimeout(() => {
  controller.abort(); // 调用 abort() 方法取消请求
  console.log('Request aborted by timeout.');
}, 500);

При вызове controller.abort() запрос fetch немедленно прерывается и выбрасывает AbortError. Эту ошибку нужно перехватить в блоке catch и проверить error.name === 'AbortError', чтобы отличить отмену от других сетевых ошибок.

4. Практические сценарии

a. Поиск по мере ввода (Search-as-you-type)

Когда пользователь быстро печатает в строке поиска, каждый ввод может запускать новый запрос. Можно отменить предыдущий незавершённый запрос и оставить только самый новый.

let currentController = null;

document.getElementById('searchInput').addEventListener('input', (event) => {
  if (currentController) {
    currentController.abort(); // 取消上一个请求
  }
  currentController = new AbortController();
  const signal = currentController.signal;

  const query = event.target.value;
  if (query.length > 2) {
    fetchDataWithCancellation(`/api/search?q=${query}`, signal);
  }
});

b. Отмена запроса при размонтировании компонента

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

// React 示例
useEffect(() => {
  const controller = new AbortController();
  fetchDataWithCancellation('/api/data', controller.signal);

  return () => {
    controller.abort(); // 组件卸载时取消请求
  };
}, []);

Заключение

AbortController — незаменимый инструмент современной Web-разработки. Он предоставляет нативный механизм отмены для Fetch API и других асинхронных операций, помогая создавать более надёжные и эффективные приложения с лучшим пользовательским опытом. Умение пользоваться AbortController — один из необходимых навыков хорошего фронтенд-разработчика.