Любовь и ненависть фронтенда

В одном из наших чатов фронтендер попросил помочь с кодом. Показал небольшой фрагмент, в котором была сборка на Gulp. Дальше разговор пошёл по двум направлениям: как вообще можно пользоваться Gulp в 2024 году и на что ему срочно нужно перейти. Обсудили webpack, Vite, Parcel, Rollup и esbuild. До самого вопроса так и не добрались.

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

Сначала помочь с задачей

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

Я для себя давно определил последовательность: уточнить детали, прямо ответить на вопрос, расширить контекст и добавить информацию на будущее.

Это кажется простой вещью, но нам почему-то сложно её делать. Мы много говорим о нехватке разработчиков и о том, как нужны новые люди. Откуда они появятся? Кто-то должен впервые прийти с вопросом, получить ответ и разобраться. Если его первый опыт общения с нами сводится к обсуждению того, насколько устарел его сборщик, мы сами усложняем ему вход.

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

Мы делаем разный фронтенд

За время работы HTML Academy наши выпускники успели вырасти из начинающих разработчиков в руководителей и архитекторов. Для «Фронтенд-инженерии» я прихожу к ним с довольно простым вопросом: что интересного у вас происходит во фронтенде?

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

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

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

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

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

Мнение меняется медленнее браузера

С браузерами эта инерция особенно заметна. Несколько лет назад одновременно обсуждали два тезиса: Chrome превращается в Internet Explorer, а Safari уже стал новым Internet Explorer. Для обоих были основания. Кто-то делал сайты только под Chrome и прямо писал, что в других браузерах они не работают. Safari редко обновлялся и не спешил внедрять новые возможности.

В итоге звание нового Internet Explorer закрепилось за Safari. Мне кажется, техномаркетинг Google в этом соревновании сработал хорошо. Но за прошедшие годы изменилось довольно много, а привычный ярлык остался.

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

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

А в очередном обсуждении всё равно появляется: «Safari — новый Internet Explorer». Знакомое утверждение не требует заново проверять, что происходит с браузером. Оно уже объясняет нам, кто виноват.

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

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

Браузерные ошибки и наша работа

Я против одного браузера и одного движка. За свои 24 года в вебе я видел достаточно странных периодов, но именно конкуренция помогала платформе двигаться дальше. Она предполагает разные решения и несогласие. Если все участники заранее согласны друг с другом, спорить и искать другой подход уже незачем.

Разумеется, разные реализации приносят ошибки. Только ошибки были всегда и во всех браузерах. Если мы ругаем Safari за несовместимость, почему нас меньше интересует регрессия в Chrome, которая ломает SVG? Известная нам марка браузера не делает конкретную ошибку менее существенной.

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

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

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

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

Новичкам снова трудно найти работу

В 2016 году мы с Олегом Моховым делали «Старикам тут не место?». Тогда компании тоже не хотели брать начинающих: зачем выращивать джуна, если можно нанять готового мидла? Многие люди в сообществе пытались изменить это отношение. Какое-то время мне казалось, что положение стало заметно лучше.

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

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

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

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

Открытость, которую легко потерять

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

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

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

Поэтому резкость в чате для меня не отдельная неприятная мелочь. Если мы перестаём слушать вопрос, за ним постепенно перестаём видеть и человека. А он мог бы разобраться, вырасти и принести в сообщество что-то своё. Нам самим будет полезно, если у него это получится.

Сообщество взрослеет

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

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

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

И при этом сохранить открытость к людям, которые только приходят. Возможно, они никогда не пользовались Internet Explorer и пока не понимают, о чём мы столько лет спорим. Зато у них будут свои вопросы и свои решения. Мне интереснее помочь им разобраться, чем доказывать, что мой способ писать фронтенд единственно верный.