Frontend Good Reads – июль 2025

Ежемесячный дайджест моего телеграм-канала Frontend Good Reads, где я делюсь интересными статьями, видео и новостями из мира фронтенда и моими мыслями о них. Иногда бывают оффтопы: UX, обучение, технологии и тд.

Vite vs Webpack

Vite догнал webpack по количеству скачиваний, заслуженно 👏

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

Разработка, ориентированная на пользователя

Долго жил с мыслью о том, что всем очевидно, для чего инженеры проектируют системы и пишут код: чтобы разработать продукт, решить проблемы пользователя, а вместе с этим и помочь бизнесу заработать денег, ведь так?

Но чем больше общаешься с людьми из индустрии и смотришь на реализацию некоторых проектов, понимаешь, что мысли о чистом и правильном коде зачастую вытесняют всю эмпатию к пользователю. Да, продуманная архитектура и поддерживаемый код – это очень важно, но надо находить находить баланс с опытом пользователя, иначе зачем это всё?

Несколько примеров из статьи Addy Osmani User-centric engineering того, как инженер может больше думать о пользователе:

• Оптимизировать производительность, воспринимаемую пользователем, а не сырые цифры. Как раз недавно столкнулся с тем, что оптимизация Web Vitals ухудшала воспринимаемую производительность. Со старой версией Lighthouse такое было повсеместно, но сейчас гораздо лучше.

• Проектировать системы так, чтобы при отказе части их функционала переставала работать не вся система, а только затронутая её часть. Самый наглядный пример – использование React Error Boundary для изолированных частей приложения.

• Приоритизировать технический долг исходя из влияния на пользовательский опыт.

“You’ve got to start with the customer experience and work backwards to the technology - not the other way around” — Steve Jobs

Еще несколько случайных мыслей о тезисах статьи:

• Важно проводить интервью с пользователями. Тут все не так очевидно, как кажется на первый взгляд. На эту тему можно почитать книжку The Mom Test. Может быть когда-то опубликую свою заметку по этой книге, если дойдут руки.

• Работа над продуктом должна руководствоваться данными. Мне нравится использование термина data-informed, вместо популярного data-driven. Такое отличие принципиально: data-informed предпологает, что решения принимаются с учётом данных, но при этом с учётом остального контекста. data-driven же, в свою очередь, звучит как слепое следование метрикам, которые сами по себе могут быть сломанными, неправильно интерпретируемы или вообще бессмысленны.

Вайб-кодинг – не оправдание для низкокачественной работы

Я бы подумал, что подобное оправдание плохо выполненной работы – это что-то выдуманное, если бы один раз мне коллега на вопрос: “почему код выбивается стилистически, не соответствует style-гайду и, в принципе, не решает проблему, которую должен был?” – не ответил: “Его написал ChatGPT, не хочу в нём разбираться” 🫣

Статью написал Addy Osmani и она продолжает раскрывать тему осознанного использования AI в работе.

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

speed means nothing if the wheels fall off down the road

AI will do exactly what you ask, which might not be exactly what you truly need.

⚠️ vibe responsibly

Легковесное управление состоянием в JavaScript

Building a Lightweight Reactive State Manager with JavaScript Proxies

Объяснение “на пальцах” одного из подходов реализации реактивности в JavaScript, который лежит в основе Vue 3.

Но если и брать для реактивности что-то простое для небольших проектов, как советует автор, то, по-моему, лучше присмотреться к signal-like паттернам. Например можно посмотреть его реализацию в nanostores.

Может быть однажды дождемся нативной реализации Signal в JavaScript.

Веб-компоненты в реальном мире

You’re Overthinking Web Components

Подробная статья про использование Web Components с примерами из реального проекта.

Честно говоря, начинал читать с очень большим скепсисом, который со временем сформировался из-за того, как технологию преподносит основной костяк медийных фронтенд-деятелей:

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

Только вот реальность такова, что один инструмент не может покрыть все задачи. И не должен.

Хоть примеры автора мне и показались отчасти искусственными – использование Web Components на своём сайте, разрабатываемом на одном стеке, на мой взгляд только усложняет разработку (API выглядит слишком императивным, все еще есть нюансы работы в разных браузерах) – в голову пришли несколько сценариев, когда технология и правда может упростить задачу:

• (50/50) С использованием Shadow DOM: для создания виджета, встраивающегося в чужие сайты. Но работа с состоянием и коммуникацией с внешним приложением выглядит оочень неудобно.
• Без использования Shadow DOM: Для создания универсальных компонентов в приложениях с микрофронтендами, где разные команды могут писать на разных фреймворках.

Зонтик для фронтенд мета-фреймворков

NuxtLabs joins Vercel

Таким образом, Vercel собрал под своим козырьком все 3 основных мета-фреймворка для работы с SSR/SSG в вебе: Next.js, Nuxt и SvelteKit.

Если смотреть поверхностно, то выглядит как взаимовыгодное сотрудничество: Open-source проекты активно развиваются благодаря деньгам от Vercel, а Vercel зарабатывает на инфраструктуре, предоставляя удобные способы развернуть эти проекты. Наверняка есть подводные камни, но как пишет основатель NuxtLabs:

The project stays MIT-licensed. The roadmap stays public. The community stays at the center.

Интересно, ждёт ли схожая судьба Astro? Выглядит логичным продолжением, и это дало бы толчок развитию, но, почему-то, не хочется такого исхода.

Капитальная переработка системы интернационализации

4 Untranslatable Words Behind Patreon’s Internationalization Overhaul

Интересно написанная статья про то, как Patreon мигрировал со своего внутреннего инструмента для локализации на open-source решение.

Все идеи статьи сформулированы вокруг четырех слов, непереводимых на английский, одно из которых русское – Почемучка, которому дано забавное определение:

A person, often a child, who asks a lot of questions. The word was inspired by a well-known Russian children’s book titled Что я видел (Što ja vídel, “What I saw”), which tells the story of a highly inquisitive five- or six-year-old boy.

Несколько интересных тезисов из статьи:

• Не составляйте предложения из параметрических частей, а лучше подготовьте по предложению для каждого из нужных вариантов. Нужно это из-за того, что в английском порядок слов Subject–verb–object, но так далеко не во всех языках. Например, в японском Subject–object–verb, а в русском вообще нет жесткого фиксированного порядка, его можно менять, а с ним зачастую меняется и смысл. Как тут можно быть уверенным, что в собранном тобой предложении мысль донесена правильно?
• Используйте стандартный объект Intl для форматирования данных под нужный язык: цифры, даты, названия месяцев и др. (но стоит проверять поддержку, пока что не у всех методов она идеальная)
• Если хотите отнять у даты месяц, то не стоит делать date.setMonth(month - 1), так как результат вызова setMonth зависит от текущего дня месяца, и результат может оказаться совсем не таким, как вы ожидаете (подробнее в статье). 🤯
• Переход от динамической подгрузки переводов к хранению их в репозитории с кодом оптимизирует многие аспекты: появляется единый источник правды, ревью становится удобнее, нет зависимости от базы данных с переводами, улучшается опыт локальной разработки.

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

К слову, про глобальный объект Date – нашел квиз, который проверяет, насколько ты понимаешь механику его работы: jsdate.wtf. Но на мой взгляд подобные квизы носят больше развлекательный характер, чем образовательный. Если при написании UI или бизнес-логики приходится задумываться о том, что вернёт new Date("wtf"), то значит, есть проблемы, которые явно даже не в коде 🌚

WebAssembly, 10 лет после анонса

WebAssembly: Yes, but for What?

Статья с рассуждениями о том, для чего оказался полезным WebAssembly (Wasm) спустя 10 лет после своего анонса. Не очень задумывался о его применениях за пределами браузера, а их, оказывается, очень много.

В браузере

• Портирование полноценных десктоп-приложений. Например Adobe, который в 2023 году представил портированный в веб Adobe Photoshop.
• Реализация компонентов с очень высокими требованиями к производительности. SQLite на Wasm, который стал альтернативой WebSQL (выпелен из браузеров в 2024 году), или расчет формул ячеек в Google Sheets, что стало особенно актуально после появления несколько лет назад WasmGC (версия Wasm со сборщиком мусора).

За пределами браузера

• Плагины и расширения для десктопных приложений. Firefox использует Wasm для компиляции небезопасных C/C++ библиотек (например Expat XML) в Wasm, полностью их изолируя без необходимости запускать в контейнерах или использовать другие тяжеловестные решения.
• Internet of Things и легкая виртуализация. Основными плюсами Wasm для этих целей являются изоляция памяти, как в прошлом примере, а также почти мгновенный холодный старт. Например можно быстро и изолированно запускать Linux-утилиты.
• Безопасное исполнение пользовательского кода. Shopify дает возможность пользователям предоставлять код в Wasm, к примеру для расчета скидок.
• Облачные функции. Если представить, что сервис поднимает по виртуалке на сервер, для обработки запросов, то очевидной становится проблема: при добавлении каждого нового сервера на нем надо запустить виртуалку, из-за чего возникает весьма продолжительный (от 100ms и более) холодный старт. У Wasm же холодный старт чрезвычайно быстрый, а его можно ещё и значительно оптимизировать.

Темная энергия

А что там с темной энергией? (оффтоп)

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

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