[Перевод] Фронтендеры — герои. Yehuda Katz объясняет почему
Идея что фронтенд это «для джунов», расстраивает меня тем, что никто не скажет так про другие специализации.
Кто-то может сказать, что неплохо, если б автор компилятора был более «фуллстековым».
Но они не скажут, что «писать компиляторы это для джунов».
Это перевод треда Yehuda Katz из твиттера. Под фронтедом здесь подразумеваются именно браузерные приложения на JS (и, отчасти, вся JS-экосистема).
По сути, когда люди говорят «фронт для джунов», они делают несколько больших ошибок. Вот две из них:
Они недооценивают сложность работы.
Они переносят мемы про тулинг фронта на самих фронтендеров.
Фронтенд — это сложно в самой своей сути
Во-первых, это непростая техническая работа. Она включает асинхронный обмен данными с сервером в ситуации, которая часто связана с неожиданными ошибками в реальной жизни, когда при этом надо сохранить интерактивность интерфейса.
На самом базовом уровне это просто трудно. Эквивалент «пользователь закрыл свой ноутбук» — это «что, если случайные 5% моих SQL-запросов в Rails фейлятся».
Начинающие фронтендеры не думают об этом, но более опытные — точно учитывают такие кейсы.
Хотя бэкэнд в основном не имеет состояния (и это нам очень нравится), на фронте пользователь может запустить какие-то асинхронные запросы, а затем продолжить использовать приложение произвольным образом.
На бэкэнде вы получаете в значительной степени согласованное представление о мире, с которым можете работать (через ACID транзакции), на клиенте вы постепенно увеличиваете локальный кеш данных, который не имеет гарантий внутренней консистентности.
Опять же, если вы думаете, что «на самом деле никто не работает над этим, лол», вы сильно ошибаетесь.
Опытные фронтендеры МНОГО думают о том, как структурировать свои приложения так, чтобы минимизировать эти проблемы, да ещё и так, чтобы начинающие смогли всё это понять.
Фронтенд сложен ещё и с другой стороны: это место, где покрышки касаются дороги при работе с пользователем.
Требования пользователей накладывают больше ограничений на то, что вашему коду могут простить.
Интерфейс — это то, о чем думают руководители вашей компании, когда придумывают новые идеи для приложения.
И очень часто у них есть особое мнение о том, как должен выглядеть этот интерфейс и как он должен работать.
Мелкие ошибки в коде интерфейса заметны не только руководителям и менеджерам компании, но и пользователям.
Косяк в интерфейсе может быть вызван ошибкой стиля, из-за которой один блок перекрывает другой на каком-то экране случайного размера, который никто не тестировал.
На бэкэнде нет ничего похожего.
Вкратце: на фронтендеров возлагается задача реализовать ту часть приложения, о которой ваши пользователи и руководители могут составить своё мнение и, исходя из него, находить какие-то ошибки.
Фронтендеры должны реализовывать идеи (и адаптироваться к мнению руководителей и пользователей) во враждебной среде (глючный браузер привет Safari, блокировщики рекламы, расширения для перевода и т.д.), в которой пользователь может создать странное состояние приложения в любое время, просто перейдя в комнату с плохим Wi-Fi.
И это важно: опытные фронтендеры постоянно работают над этими сложными проблемами и стараются сделать их решения понятными для менее опытных разработчиков.
Некоторые эти проблемы решаются фреймворками, но многие из них трудно решить целиком и полностью.
И, наконец, так как на самом деле фронтенд — это вход в программирование для неопытных разработчиков, опытные фронтендеры работают над тем, чтобы их решения этих проблем были достаточно общими, чтобы кто-то прямо в учебке мог использовать их продуктивно и правильно.
Я видел это во многих, многих компаниях, включая Tilde. Опытные фронтендерынаставляют и направляют новых разработчиков.
Это все очень сложно и запросто может превратиться в отдельную специальность и карьеру. Бессмысленновыделять один только фронтенд и назвать все перечисленное чем-то только для джунов.
Но, я согласен с тем, что каждая техническая роль выиграет от большей «фуллстечности».
Лично я работаю над ядром Ember, бэкэнд-кодом Rails и бэкэнд-кодом Rust, когда работаю над Skylight.
Я считаю, что это хорошо.
Но никто никогда не скажет: «Специализация на Rust-бэкэнде у нас имеет смысл только для джунов». По сути, сказать так про фронт — значит сильно недооценить сложность задач, которые стоят перед фронтендерами.
Итак, это была первая часть.
Мемы про node_modules
Вторая часть — это (откровенно комичное) высмеивание инструментов фронта.
Скажу как человек, который в свое время создал много тулингов (bundler, cargo, инспектор Ember): тулинг фронта часто на голову лучше, чем тулинги, которые кто-то может самодовольно превозносить.
Не только JavaScript может получать пользу от транспайлеров. Разве плохо было бы, если б большинство фич C++ 20 работали с более старыми (и все еще широко использующимися) версиями компиляторов через транспиляцию?
Сделать подобное непросто, но в экосистеме JS вы можете использовать совершенно новые фичи (включая экспериментальные), даже если вы ориентируетесь на гораздо более старые браузеры.
И дело не только в том, что вы можете транспилировать код: инструменты вроде eslint, IDE language servers, syntax highlighters и TypeScript обычно поддерживают большую часть самой последней версии ECMAScript задолго до того, как она будет завершена.
Кстати, о TypeScript. TypeScript — лучшая в своем классе система постепенной типизации для динамического языка. Ничто другое (может, за исключением Racket) даже близко к подобному уровню не подбирается, особенно если учесть интеграцию в экосистему и проработанность тулинга.
И всё это довольно легко работает с популярным расширением JS (JSX), которое даже не входит в спецификацию ECMAScript.
Таким образом, вы можете написать свой код в TSX с помощью ES2020, получить отточенный линтинг и тулинг, а затем скомпилировать его за кулисами для старых браузеров.
И для этого не надо ручками указывать набор фич, которые нужны от браузера.
Стандартный способ указать, какие фичи необходимо транслировать — это browserslist, который позволяет вам сказать «последняя версия Chrome» или «браузеры с долей рынка в 1%».
Таким образом, вы просто используете ES2020 и TypeScript, указываете браузеры, которые вам нужно поддерживать (используя гибкое описание, основанное на данных, поддерживаемых caniuse.com), и легко получаете сборку, которая работает в поддерживаемых браузерах.
Если надо поддерживать Node — всё то же самое.
Вдобавок ко всему, девтулзы в браузере намного, намного лучше, чем любые отладчики, доступные для большинства языков — если, конечно, учесть, насколько легко их настроить и насколько они доступны для людей с любым опытом.
Насмехайтесь над npm сколько угодно, но отличия npm от Bundler сильно повлияли на мой дизайн Cargo, а экосистема Rust стала лучше из-за отсутствия ограничения «только одна копия вашей зависимости, даже если она используется только внутри пакета».
Конечно, npm мог бы быть лучше, но было впечатляюще (и вдохновляюще) наблюдать за медленным и неуклонным улучшением npm на протяжении многих лет (приличное разрешение зависимостей, файлы блокировки, йуху!).
Workspaces из Yarn перенимаются в npm и pnpm, что ставит фронт в высшую лигу языков с хорошей поддержкой монорепозиториев (поддержка не идеальна, но точно в высшей лиге).
Вдобавок ко всему, бандлеры JS должны (просто для выживания) поддерживать разделение кода и удаление мертвого кода, при этом понятное для неопытных разрабов.
Они также должны иметь возможность поддерживать динамическую загрузку частей приложения так, чтобы это было совместимо с оригинальной семантикой модулей, которую имел в виду программист.
Да, DLL не новы. Нет, они не работают запросто со всем вышеперечисленным, во всяком случае без познаний уровня волшебника.
И ни одно из этих ограничений не является случайным или «чрезмерно усложняющим проблему».
Фронтенд-разработка — сложная проблема по самой своей сути. Это расплата за то, что мы можем писать приложения, которые работают в любой операционной системе, на более старых машинах (и ОС), различных разрешениях (от маленьких телефонов до сверхшироких дисплеев), технологиях доступности и версиях всех этих вещей, которые даже не существует на момент написания кода (при этом ещё и продолжая постоянно работать вне зависимости от обновлений пользовательских устройств).
В заключение: я полностью согласен с тем, что люди должны стараться стать более универсальными в разработке и что чрезмерное внимание к одной специализации может скрыть от инженера какие-то важные детали в соседних областях.
Но это не делает фронтенд специализацией, подходящей только для «джунов».
По моему опыту, легче полностью погрузиться во фронтенд, нежели во что-то вроде Rails, и при этом всё ещё приносить огромную пользу по мере развития.
Это, кстати, вызвано (отчасти) тем фактом, что фронт достаточно прост для начинающих разработчиков.
Из-за этого опытные фронтендеры значимую часть времени обучают новых разработчиков.
Также поэтому опытные фронтендеры отвечают за создание абстракций, которые решают все вышеперечисленные проблемы способом, доступным для огромного круга разработчиков.
Если вы фронтенд-разработчик, не позволяйте никому высмеивать то, что вы делаете, и не позволяйте никому относиться к фронту как к чему-то «более легкому» или менее подходящему для специализации, нежели более традиционный бэк.
Думайте о себе как о герое, который несет прямую ответственность перед пользователем и руководителями, отвечает за то, чтобы ваше приложение работало в чрезвычайно враждебной и неизвестной среде (сравнивая с «запустить го в докере»).
Вы также несете ответственность за создание абстракций, которые может использовать весь спектр разработчиков в вашей компании, потому что начинающим нужна ваша помощь.
И мы все здесь, чтобы оформлять друг для друга полезные частички функциональности и даже целые фреймворки, которые позволяют не переизобретать велосипеды для очередного хелловорлда.
Мои друзья-фронтендеры: мне нравится быть с вами в одном сообществе.
Продолжим же доказывать, что ненавистники ошибаются, продолжим создавать классные вещи для пользователей самых разных девайсов. Продолжим удивлять людей тем, чего мы можем достичь вместе.
Мы круты! Мы зажигаем!
