Инструменты меняются. Что происходит с опытом разработчика

Разработчики большой дизайн-системы впервые открывают документацию к datalist и обнаруживают, что браузер уже умеет часть того, что им нужно. Они не пробовали этот элемент и не отвергли его из-за ограничений. Просто не знали о нём.

Эта история вспомнилась мне в пятисотом выпуске «Веб-стандартов», в ноябре 2025 года. Мы с Вадимом Макеевым, Андреем Мелиховым, Никитой Дубко и Полиной Гуртовой говорили о том, как теперь пишем код и что нас по-прежнему раздражает в профессии. Инструменты за эти годы заметно изменились. Привычка однажды освоиться и перестать смотреть по сторонам — гораздо меньше.

Знать о возможности и пользоваться ею — разные вещи

Вадим сразу возразил против моего примера. У datalist хватает недостатков: ограничения стилизации, не самое удобное поведение и API. Браузеры понемногу исправляют его, но наличие элемента в HTML ещё не делает его хорошим выбором для каждого интерфейса.

Он напомнил и наши давние споры про input type="date". Когда я не мог привести поле к нужному дизайну, сам не хотел его использовать. С нативными компонентами такое бывает: идея полезная, а конкретная реализация не подходит.

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

От сеньора, архитектора или технического руководителя я жду не только умения вовремя написать работающий код. За его решениями должна стоять достаточно широкая картина того, что можно сделать. И её приходится обновлять.

Читать всё необязательно

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

Никита рассказал, как изменился подход к новостям «Веб-стандартов». Раньше можно было дать ссылку с короткой затравкой. Теперь Вадим старается передать и суть: где описанный приём пригодится, какие у него ограничения. Подготовить такую заметку труднее — приходится внимательно прочитать материал и разобраться в нём.

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

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

Редактор, который хочется открыть

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

После закрытия Atom я перешёл на VS Code и поймал себя на том, что не особенно хочу его открывать. С Zed это ощущение изменилось. Мне нравится само взаимодействие с редактором: я захожу в него не только ради кода, но даже чтобы быстро набросать текст, который потом удалю. Когда-то для этого открывал iA Writer или заметки.

Вадим заметил, что тоже стал иногда запускать Zed: современный CSS там подсвечивался лучше, чем в его VS Code. Мне же редактор просто вернул желание сесть за работу.

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

Не каждому сайту нужно приложение на клиенте

Мои собственные проекты не требуют большого клиентского приложения. Обычно хватает HTML, CSS и небольшого количества JavaScript для интерактивности. Разворачивать всё я тоже привык сам.

Это не мешает интересоваться фреймворками. На момент разговора я собирался попробовать SvelteKit: хотелось проверить, насколько обещанная простота сохраняется в настоящей работе. Next.js ощущался для меня слишком большой чёрной коробкой, а здесь была надежда на более понятное устройство.

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

Полина привела хороший пример из Astro. Она забыла добавить директиву, которая отправляет клиентский код для нескольких компонентов, а страница продолжила нормально работать. Оказалось, что JavaScript там и не требовался. Её удивило собственное удивление: мы настолько привыкли к большому клиентскому пакету, что обычный работающий HTML снова кажется открытием.

Вадим считал, что хороший инструмент должен по умолчанию давать быстрый и доступный результат. Я добавил к этому роль самого разработчика. Фреймворк задаёт основу, но дальше приложение пишем мы. С удачным инструментом можно собрать неудобный продукт, а с ограниченным — сделать хороший, если понимать его устройство и свою задачу.

Мне хотелось бы, чтобы фреймворк давал понятное направление работы. У React, который сам по себе библиотека, таких общих рамок меньше: разработчик собирает их из множества рекомендаций, причём следующий месяц приносит новые «правильные» способы. Даже разобравшись с отдельными инструментами, приходится выяснять, как соединить их между собой.

Может ли у веба быть свой UI-кит

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

На круглом столе о будущем фронтенда мы с Алексеем Назаренко обсуждали похожий вопрос. Я сравнивал веб с мобильной разработкой: к новой версии iOS Apple выпускает набор компонентов для дизайнера, а у разработчика есть их реализация. Между макетом и кодом уже существует связь.

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

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

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

При этом не каждый компонент обязательно встраивать в браузер. Часть можно собрать поверх существующих стандартов и распространять отдельно. Я предложил Полине посмотреть Web Awesome, выросший из Shoelace: там как раз работают над веб-компонентами с доступностью и настройкой оформления. Часть компонентов платная, и это тоже придётся учесть при выборе.

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

Что успеет измениться за сто выпусков

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

Я скорее согласился с Андреем: срок небольшой, и заметнее будут последовательные улучшения уже существующего. Хочется, например, дождаться согласованного синтаксиса masonry — раскладки элементов разной высоты без пустот между ними. И более спокойной жизни с модулями в Node.js. Эти изменения могут не выглядеть переворотом, но именно из них складывается ежедневная работа.

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