Меня расстраивает мысль о том, что фронтенд — это «для джуниоров», потому что о других специализациях этого никто не скажет. Некоторые могут сказать, что неплохо , лишь бы автор компилятора был более «фулстековым».
Но они Нет Они скажут, что «написание компиляторов — для юниоров».
Это перевод нить Иегуда Кац из Твиттера.
Под фронтендом мы подразумеваем браузерные приложения, использующие JS (и, частично, всю экосистему JS).
По сути, когда люди говорят «младший фронт», они совершают большие ошибки.
Вот два из них:
- Они недооценивают сложность работы.
- Мемы про фронтенд-тюнинг они переносят на самих фронтенд-разработчиков.
Фронтенд сложен по своей сути
Во-первых, это непростая техническая работа.Он предполагает асинхронную связь с сервером в ситуации, которая часто связана с непредвиденными ошибками в реальной жизни, когда необходимо сохранить интерактивность интерфейса.
На самом базовом уровне это просто сложно.
Эквивалент фразы «пользователь закрыл свой ноутбук» — это «что, если случайные 5% моих SQL-запросов Rails завершатся неудачей».
Начинающие фронтенд-разработчики об этом не задумываются, но более опытные такие случаи обязательно учитывают. Хотя серверная часть в основном не сохраняет состояние (что нам очень нравится), на внешней стороне пользователь может выполнять некоторые асинхронные запросы, а затем продолжать использовать приложение произвольным образом.
На серверной стороне у вас есть в значительной степени согласованное представление о мире, с которым вы можете работать (посредством транзакций ACID), на клиенте вы постепенно увеличиваете локальный кэш данных, который не имеет никаких гарантий внутренней согласованности.
Опять же, если вы думаете, что «на самом деле никто над этим не работает, лол», вы глубоко ошибаетесь.
Опытные фронтендеры МНОГО думать о том, как структурировать свои приложения таким образом, чтобы свести к минимуму эти проблемы и чтобы новички могли их понять.
Фронтенд сложен и с другой стороны: это место, где шины соприкасаются с дорогой при взаимодействии с пользователем.
Требования пользователя накладывают больше ограничений на то, что можно простить вашему коду.
Интерфейс — это то, о чем думают руководители вашей компании, когда придумывают новые идеи для приложения.
И очень часто у них есть особое мнение о том, как должен выглядеть этот интерфейс и как он должен работать.
Небольшие ошибки в коде интерфейса заметны не только руководителям и менеджерам компании, но и пользователям.
Ошибка в интерфейсе может быть вызвана ошибкой стиля, когда один блок перекрывает другой на экране произвольного размера, который никто не проверял.
На бэкэнде нет ничего подобного.
Вкратце: перед фронтенд-разработчиками стоит задача реализовать ту часть приложения, о которой ваши пользователи и менеджеры могут составить мнение и на его основе найти какие-то ошибки.
Фронтендеры должны реализовывать идеи (и адаптироваться к мнению менеджеров и пользователей) во враждебной среде (глючный браузер hello Safari, блокировщики рекламы, расширения перевода и т. д.), в которой пользователь может в любой момент создать странное состояние приложения, просто собираюсь в комнату с плохим Wi-Fi. И это важно: опытные фронтенд-разработчики постоянно работайте над этими сложными проблемами и старайтесь сделать их решения понятными менее опытным разработчикам.
Некоторые из этих проблем решаются с помощью фреймворков, но многие из них сложно решить полностью.
И, наконец, поскольку интерфейсный интерфейс на самом деле является воротами в программирование для неопытных разработчиков, опытные интерфейсные разработчики работают над тем, чтобы их решения этих проблем были достаточно общими, чтобы кто-то прямо в классе мог использовать их продуктивно и правильно.
Я видел это во многих, многих компаниях, включая Тильду.
Опытные фронтендеры наставляйте и направляйте новых разработчиков.
Это все очень сложно и легко может превратиться в отдельную специальность и карьеру.
Нет смысла выделять только переднюю часть и называть все перечисленное чем-то только для юниоров.
Но я согласен, что каждая техническая роль выиграет от большей гибкости.
Лично я работаю над ядром Ember, серверным кодом Rails и серверным кодом Rust, когда работаю над Небесный свет .
Я думаю, это хорошо.
Но никто никогда не скажет: «Специализироваться на бэкенде Rust имеет смысл только джуниорам».
На самом деле, говорить такое о фронтенде — значит сильно недооценивать сложность задач, стоящих перед фронтенд-разработчиками.
Итак, это была первая часть.
Мемы про node_modules
Вторая часть представляет собой (откровенно комичную) насмешку над орудиями фронта.Скажу как человек, создавший в свое время множество инструментов (бандлер, карго, Ember инспектор): фронтальная оснастка зачастую на голову лучше тех инструментов, которые кто-то может самодовольно нахваливать.
Транспиляторы могут принести пользу не только JavaScript. Было бы плохо, если бы большинство функций C++20 работали со старыми (и все еще широко используемыми) версиями компиляторов посредством транспиляции? Сделать это непросто, но в экосистеме JS вы можете использовать совершенно новые функции (в том числе экспериментальные), даже если вы ориентируетесь на гораздо более старые браузеры.
И дело не только в том, что вы можете транспилировать код: такие инструменты, как eslint, языковые серверы IDE, средства подсветки синтаксиса и TypeScript, обычно поддерживают большую часть последней версии ECMAScript задолго до ее завершения.
Кстати, о TypeScript. TypeScript — лучшая в своем классе система инкрементальной типизации для динамического языка.
Ничто другое (возможно, за исключением Racket) даже близко не приближается к этому уровню, особенно с учетом интеграции в экосистему и сложности инструментов.
И все это довольно легко работает с популярным расширением JS (JSX), которое даже не является частью спецификации ECMAScript. Таким образом, вы можете написать свой код в TSX, используя ES2020, получить отточенный анализ и инструменты, а затем незаметно скомпилировать его для старых браузеров.
И для этого вам не придется вручную указывать набор необходимых возможностей браузера.
Стандартный способ указать, какие функции необходимо транслировать, — это список браузеров, который позволяет вам сказать «последняя версия Chrome» или «браузеры с долей рынка 1%.
Таким образом, вы просто используете ES2020 и TypeScript, указываете браузеры, которые вам необходимо поддерживать (используя гибкое описание, основанное на данных, поддерживаемых caniuse.com), и легко получаете сборку, которая работает в поддерживаемых браузерах.
Если вам нужна поддержка Node, все то же самое.
Вдобавок ко всему, инструменты разработчика в браузере намного лучше, чем любые отладчики, доступные для большинства языков — учитывая, насколько легко их настроить и насколько они доступны для людей любого происхождения.
Издевайтесь над npm сколько хотите, но отличия npm от Bundler сильно повлияли на мой дизайн Cargo, а экосистема Rust лучше, поскольку у нее нет ограничения «только одна копия вашей зависимости, даже если она используется только в составе пакета».
Конечно, npm мог бы быть лучше, но было впечатляюще (и вдохновляюще) наблюдать, как npm медленно и неуклонно улучшается с годами (достойное разрешение зависимостей, блокировка файлов, ура!).
Рабочие пространства из Yarn перенимаются npm и pnpm, что ставит перед собой высшую лигу языков с хорошей поддержкой монорепозиториев (поддержка не идеальна, но определенно в высшей лиге).
Вдобавок ко всему, сборщики JS должны (просто для того, чтобы выжить) поддерживать разделение кода и удаление мертвого кода таким образом, чтобы это было понятно неопытным разработчикам.
Они также должны иметь возможность поддерживать динамическую загрузку частей приложения способом, совместимым с исходной семантикой модуля, которую имел в виду программист. Да, библиотеки DLL не новы.
Нет, им нелегко справиться со всем вышеперечисленным, по крайней мере, без знаний уровня волшебника.
И ни одно из этих ограничений не является случайным или «чрезмерно усложняющим проблему».
Фронтенд-разработка — сложная проблема по самой своей природе.
Это цена, которую приходится платить за тот факт, что мы можем писать приложения, которые работают в любой операционной системе, на старых машинах (и ОС), с разными разрешениями (от маленьких телефонов до сверхшироких дисплеев), технологиями доступности и версиями всего этого.
вещи, которых даже не существует на момент написания кода (при этом продолжая работать постоянно, независимо от обновлений пользовательских устройств).
Окончательно
Я полностью согласен с тем, что людям следует стараться стать более универсальными в разработке и что слишком большой акцент на одной специализации может скрыть от инженера некоторые важные детали в соседних областях.Но это не делает фронтенд специализацией, подходящей только для «джуниоров».
По моему опыту, легче полностью погрузиться во фронтенд, чем в что-то вроде Rails, и при этом приносить огромную пользу по ходу работы.
Это, кстати, вызвано (отчасти) тем, что интерфейс довольно прост для начинающих разработчиков.
По этой причине опытные интерфейсные разработчики тратят значительную часть своего времени на обучение новых разработчиков.
Именно поэтому опытные фронтенд-разработчики отвечают за создание абстракций, которые решают все вышеперечисленные проблемы способом, доступным огромному кругу разработчиков.
Если вы фронтенд-разработчик, не позволяйте никому высмеивать то, что вы делаете, и не позволяйте никому относиться к фронтенду как к чему-то «более простому» или менее подходящему для специализации, чем к более традиционному серверному интерфейсу.
Подумайте о себе как о герое, который несет прямую ответственность перед пользователем и руководством, ответственным за то, чтобы ваше приложение работало в крайне враждебной и неизвестной среде (по сравнению с «запуском Go в докере»).
Вы также несете ответственность за создание абстракций, которые может использовать весь спектр разработчиков в вашей компании, поскольку новичкам нужна ваша помощь.
И мы все здесь для того, чтобы разрабатывать друг для друга полезные элементы функциональности и даже целые фреймворки, которые позволят нам не изобретать велосипед для следующего helloworld. Мои коллеги-фронтендеры: мне нравится быть с вами в одном сообществе.
Давайте продолжим доказывать, что хейтеры не правы, продолжим создавать крутые вещи для пользователей самых разных устройств.
Давайте продолжим удивлять людей тем, чего мы можем достичь вместе.
Мы крутые! Мы зажигаем! Теги: #программирование #разработка сайтов #JavaScript #интерфейсы #front-end #yehuda katz #rock
-
Страсть — Ключ К Успеху В Ведении Блога
19 Oct, 24 -
Спутниковая Связь
19 Oct, 24 -
Ненужные Отступы В Списках
19 Oct, 24 -
Опыт Сборки Goog-411 [От Первого Лица]
19 Oct, 24 -
Телевидение Black Messa Представляет…
19 Oct, 24
