какие технологии используются во фронтенде
Обзор 15 технологий в области фронтенд на 2021 год
Фронтенд. В статье поделимся нашим взглядом на 15 технологий в области фронтенда на 2021 год. К части технологий мы активно присматриваемся, некоторые начинаем применять, другие давно используем и рекомендуем вам, а есть и такие, от которых отказались, и расскажем вам, по какой причине.
За систему координат возьмем методологию «Технологический радар», которую распространяет компания ThoughtWorks. С деталями методологии, а также с актуальным радаром по всей ИT-индустрии можно ознакомиться на сайте ThoughtWorks.
Если вы еще не сталкивались с технологическим радаром, то далее коротко расскажем об основах методологии. Если сталкивались — смело переходите к разделу с технологиями.
Как и на настоящем радаре, точки (технологии) на радаре могут появляться и исчезать, а также перемещаться со временем. Радар делится на квадранты и кольца. Квадранты — это категории технологии, а кольца — определенный уровень адаптации технологии. Если представить, что мы в центре радара, то чем ближе технология к нам, тем она больше рекомендована.
Всего есть четыре уровня адаптации:
Цели, которые достигаются технологическим радаром, а также процесс сборки оставим для другой статьи, чтобы быстрее перейти к главной теме — технологиям.
1. JavaScript. Hold
JavaScript остается самым популярным языком программирования в мире, если судить по результату опроса Stack Overflow и исследования от GitHub. Это преимущество, за счет которого вы можете быстрее укомплектовать свою команду необходимой компетенцией или найти готовый модуль на нужном стеке в Open Source. На JavaScript проще начать программировать, хотя, чтобы стать Senior-разработчиком, нужно приложить столько же усилий, сколько в любом языке программирования. Если использовать транспилятор Babel, можно экспериментировать с последними спецификациями EcmaScript.
К сожалению, JavaScript — язык программирования с динамической типизацией и обладает связанными с этим недостатками. Основной из них — отсутствие контрактов. Код без контрактов сложнее развивать и сложнее проводить рефакторинг. Из-за динамической типизации JavaScript местами требует избыточных конструкций — к примеру, когда необходимо проверить, тот ли объект вам пришел, тот ли тип вы получили. В итоге получаем риск пропустить ошибку.
Мы рекомендуем отказаться от JavaScript и перейти на доступный для задач фронтенда типизированный язык программирования. Мы выбрали TypeScript, о котором дальше.
2. TypeScript. Adopt
Недавно мы провели внутренний опрос фронтенд-разработчиков (как State of Frontend, только по Тинькофф), который прошли 159 фронтенд-разработчиков. В опросе была секция про TypeScript, ответы на которые дали нам уверенность, что TypeScript стал стандартом разработки фронтенда, по крайней мере в Тинькофф.
TypeScript, как язык со статической типизацией, повышает надежность и расширяемость кода. Мы получаем самодокументированный код, интерфейсы, безопасный рефакторинг, короткий цикл обратной связи (узнаем об ошибке в IDE, а не в браузере).
Если у вас небольшой проект, который в будущем не будет развиваться, «сделал и забыл», то использование TypeScript может принести накладные расходы. На дальней перспективе, когда проект будут развивать несколько поколений разработчиков, — используйте и не сомневайтесь.
3. Vue.js. Hold
Vue.js — это мощный и современный фреймворк. Если вы находитесь на этапе выбора фреймворка, то обязательно должны рассмотреть все решения из большой тройки фреймворков (Angular, React, Vue.js) и подобрать оптимальный для ваших условий.
В нашем случае в компании развита компетенция по Angular и React. Каждый фреймворк появился для решения определенных задач. Сейчас эти два фреймворка покрывают 100% наших требований к разработке веб-интерфейсов. Vue.js не принесет ощутимых изменений, нам потребуются дополнительные затраты на обучение, на адаптацию инструментов. Если взвесить все «за» и «против» внедрения нового фреймворка — «против» больше.
В этой статье обойдем стороной сравнение особенностей фреймворков.
4. Disappearing Frameworks. Assess
В категорию «Исчезающие фреймворки» попадают фреймворки, выполняющую свою полезную работу на этапе компиляции, генерируя чистый JavaScript без тяжелых абстракций наподобие Virtual DOM. Такие фреймворки максимально легковесны, и их производительность на слабом железе заметно выше.
Кандидаты в эту категорию: Stencil, Svelte, Solid и Angular Elements.
Все из перечисленных решений позиционируют себя как совместимые или имеющие возможность компиляции в Web Components. Это отличная возможность, позволяющая создавать веб-приложения на базе универсальной веб-платформы. За этой группой фреймворков нужно следить и экспериментировать с ними.
Такие фреймворки потенциально могут быть использованы в решении задачи переиспользования UI-компонентов между разными большими фреймворками, что позволит, допустим, иметь одну общую кодовую базу UI Kit.
Более подробно познакомиться с подходом Disappearing Frameworks можно в статье Питера О’Шонесси.
5. Machine learning in Frontend. Trial
ML может применяться в задачах разработки веб-интерфейсов. Благодаря библиотеке Tensorflow, которая является одной из популярных библиотек для ML и имеет версию для Node.js и браузера, мы получаем возможность машинного обучения на известном стеке. Здесь JavaScript подтверждает свою универсальность.
Эти возможности позволяют решать задачи такими способами, о которых раньше не задумывались, но для этого необходимо теоретическое знание ML. Пример задач, где применим ML, — повышение скорости работы интерфейса.
Одна из наших команд экспериментировала и сделала сервис, предсказывающий вероятность посещения следующей страницы. Затем интегрировала этот сервис в стратегию предзагрузки одного из проектов — теперь в некоторых случаях пользователь при переходе на следующую страницу увидит ее моментально, без ожидания загрузки. Мы разработали свое решение на базе Tensorflow.js. Конкретно для этой задачи существует open-source-решение от Google — Guess.js, которое на основе данных из Google Analytics делает похожее. Советуем попробовать.
Еще из примеров использования ML в задачах фронтенда можно выделить анализ кода для выявления дубликатов, анализ верстки на соответствие гайдлайнам и даже возможность поправлять ее, распознавать документы в браузере, не передавая их по сети, генерировать пользователям индивидуально подстроенный интерфейс, повышать accessibility — допустим, голосовым управлением.
6. Backend for Frontend (BFF). Trial
Когда бэкенд использует микросервисную архитектуру, на фронтенде это может нести определенные накладные расходы в виде большего количества запросов на сервер или избыточного формата ответа сервера, что влияет на скорость работы интерфейса. Паттерн BFF призван решить эти проблемы.
BFF — это тонкий бэкенд для специализации ответа под конкретный клиент. Например, BFF может создаваться под отдельные пользовательские истории, чтобы они работали быстрее.
При использовании этого паттерна важно не размыть ответственность за бизнес-домен. Поэтому необходимо следить, чтобы сервис BFF оставался максимально тонким, соответствовал принципам отказоустойчивости и вся ответственность за бизнес-домен оставалась на исходном сервисе.
Подробней ознакомиться с паттерном Backend for Frontend можно в статье Сэма Ньюмана.
7. Dependency Injection. Adopt
Мы рекомендуем использовать паттерн DI и вместе с ним IoC-контейнеры. Кажется, что DI не сильно распространен во фронтенд-разработке за пределами Angular, но у нас в компании этот паттерн получил широкий охват, в том числе на проектах с React, где мы используем собственный фреймворк Tramvai.js, который построен на DI.
Этот паттерн позволяет уменьшить связанность вашего кода, за счет этого повышается поддерживаемость и расширяемость кодовой базы. При использовании DI зависимости передаются явно, модули зависят от абстракции, а не от конкретной реализации. Как пример, при таком подходе можем проще тестировать компоненты, легко подменяя имплементации зависимостей на необходимые при тестировании.
Нужно понимать, что DI повышает порог входа в проект. В некоторых случаях, особенно если у вас множество простых и уникальных задач, когда меньше возможности что-либо переиспользовать, смысл использовать DI уменьшается.
Наш коллега Сергей Нестеров сделал доклад Dependency injection в React-приложении — советуем посмотреть.
8. Micro frontends. Adopt
Основные цели, которые достигаются с помощью микрофронтендов: ускорение поставки изменений и повышение поддерживаемости кодовой базы. Ускорение поставки за счет инкрементальных, а не монолитных релизов. Кодовая база большого проекта, разделенная на микрофронтенды, удобнее в развитии, а код каждого отдельного микрофронтенда — целостней и компактней. Например, для обновления шапки сайта вам нужен релиз только одного модуля, а само приложение-контейнер не потребует обновления.
Если у вас крупный проект с множеством команд разработки, то микрофронтенды рекомендуются к использованию.
Более подробно ознакомиться с этим подходом можно в статье Мартина Фаулера, а также в докладе нашего коллеги Дмитрия Кузнецова Микрофронтенды на Tinkoff.ru.
9. Inner source. Assess
Если вы нацелены на ускорение поставки, распространение владения кодовой базы и межкомандное сотрудничество, то подход Inner Source может быть вам интересен.
Inner Source — это как Open Source, только внутри компании, который позволяет уменьшить зависимость от смежных команд разработки, что должно привести к ускорению выполнения задач.
Разберем на примере. Допустим, у вас есть две команды и первая команда хочет доработку от второй. Команда 1 приходит к команде 2, добавляет свою задачу в очередь бэклога и получает блокирующую зависимость в исполнении своего проекта. В случае с Inner Source все репозитории открыты внутрь компании. В таком подходе команда 1 может сделать pull request в целевую систему, а владелец системы — команда 2 — эти изменения проверит и вольет в основную ветку. Выходит, что первая команда получит свою доработку быстрее за счет использования собственного ресурса, чем если бы ждала, своей очереди в бэклоге другой команды.
Чтобы Inner Source работал, недостаточно просто открыть все репозитории — важно применять общие стандарты, такие как хорошая документация, понятный и прозрачный процесс контрибьютинга, качественная инфраструктура для развертывания изменений.
Эта практика может положительно повлиять на мотивацию вашей команды, благодаря возможности влиять на любую систему компании, а также улучшить горизонтальные связи — допустим, между всеми фронтенд-разработчиками компании.
Подробней ознакомиться с Inner Source можно на сайте комьюнити Inner Source.
10. Trunk based development (TBD). Assess
TBD — это модель ветвления, которая диктует частые интеграции и отсутствие долгоживущих веток.
Для реализации этих требований должны быть развиты процессы и инфраструктура разработки.
В TBD ветки с новым кодом вливаются в основную ветку не реже чем раз в 24 часа. С помощью этого команда получает ускоренный цикл обратной связи по задаче. В более распространенных моделях ветвления изменения дольше копятся, часто в момент попадания изменений в основную ветку объявляются неожиданные проблемы, исправление которых несет дополнительную сложность из-за позднего времени их обнаружения. В TBD все изменения делаются максимально атомарными, интегрируются с самой новой версией основной ветки как можно чаще, что создает определенные требования к архитектуре приложения, такие как поддержка Feature Flags, чтобы иметь возможность отключать из исполнения еще не завершенные задачи.
Частые интеграции с основной веткой требуют хорошего покрытия автоматизированными тестам. Если автоматизированное тестирование прошло ложно-успешно и некоторая функциональность сломалась, то команда, работающая над другими задачами, это заметит на раннем этапе, и исправления будут внесены быстро. Совместно с TBD ценность парного программирования возрастает за счет важности код-ревью прямо в моменте создания кода и стремления выявить ошибки в коде на ранних этапах. При использовании TBD участники команды лучше видят, кто над чем работает, а не ждут крупного логического этапа для ревью.
Модель TBD является более командной за счет атомарных изменений короткими циклами, что позволяет выявлять проблемы на самом раннем этапе работы, что в сумме повышает эффективность команды. TBD хорошо приживется в командах со зрелой инженерной культурой.
11. Общий монорепозиторий. Hold
Будем считать, что общий монорепозиторий — это глобальный репозиторий уровня компании или направления. Группы людей, работающие в таком репозитории, практически не связаны общими целями и могут иметь разные процессы.
С другой стороны — репозиторий уровня команды, где все участники репозитория объединены общими целями, имеют единые процессы, бизнес-контекст. В таком репозитории может находиться код нескольких приложений или пакетов, если над ними работает одна команда. Формально репозиторий останется моно, но меньшего масштаба. Все внешние зависимости, например core-код-компании, должны подключаться через пакетные менеджеры с версионированием.
Из плюсов глобальных репозиториев — возможность быстрее внедрять сквозные изменения, затрагивающие все команды. Из минусов — вероятна сложная модель ветвления, риск получить сильно связанный код, конфликты кода от разных команд.
Если у вас нет планов использовать глобальный монорепозиторий, то ограничьтесь репозиториями уровня одной команды и разделяйте репозиторий, когда текущая команда растет. В других случаях инвестируйте в инфраструктуру и инструментарий вокруг репозитория, чтобы поддерживать работу с глобальным репозиторием на эффективном уровне.
12. Semantic release. Trial
Подход Semantic Release позволяет автоматически назначать версии и публиковать пакеты. Мы используем несколько решений: lerna, semantic-release и собственную разработку pvm.
Для использования Semantic Release необходимо применять в сообщениях к коммитам спецификацию Conventional Commits. Она просит придерживаться определенного формата сообщений, чтобы на их основе можно было автоматизированно определить важность изменения и выставить версию в соответствии с semver, а также сгенерировать changelog.
13. Web performance. Adopt
Скорость работы веб-приложений с каждым годом становится важнее. Скорость первоначального запуска и последующей работы интерфейса является частью UX, от этого зависит ранжирование в поисковых системах, что в совокупности влияет на бизнес-конверсии и успешность вашего продукта. Важно, чтобы скорость интерфейсов была в культуре разработки.
Если вы раньше не думали о таком нефункциональном требовании, как скорость работы интерфейса, то начните с определения бюджета скорости: задайте те ограничения на performance-метрики, за пределы которых нельзя выходить. Важно согласовать эти бюджеты с владельцем продукта, чтобы было общее понимание ценности, бюджет учитывали при постановке задач и выделяли время на улучшение скорости.
Для контроля бюджета нужно иметь мониторинг скорости работы приложения на основе данных от настоящих пользователей (RUM), желательно с автоматическими уведомлениями при достижении критических значений. Также нужно иметь синтетические тесты, которые исполняются в тестовом окружении. Желательно, чтобы такие тесты были интегрированы в процесс CI/CD: это позволит на раннем этапе замечать потенциальные проблемы и решать их до того, как они попадут к пользователям.
Ввести бюджет и инструменты контроля может быть недостаточно. Вы должны обучать вашу команду современным практикам разработки быстрых веб-интерфейсов, следить и делиться новыми подходами. У нас есть регулярная встреча по Web performance, на которой обсуждаются новости и хорошие примеры оптимизации. Так мы распространяем культуру быстрых интерфейсов и обмениваемся опытом.
14. Snapshot-тестирование. Hold
Мы не рекомендуем snapshot-тесты компонентов, тесты, которые сверяют итоговый HTML компонентов. Наши команды постоянно сталкивались с ложными срабатываниями таких тестов, когда были изменены лишь атрибуты или другие свойства, которые не нарушали функциональность и вид компонента. При малой пользе такие тесты ухудшали Developer Experience.
Плюс, который можно отметить: snapshot-тесты довольно легко начать использовать. В остальном рекомендуем рассмотреть другие способы тестирования интерфейсов, допустим screenshot-тесты.
15. Cypress. Trial
В тестировании ПО рекомендуется использовать фреймворки, которые написаны на том же стеке, что и ваше приложение. Таким образом можно отойти от парадигмы, когда автотесты пишут отдельные люди, и разделить обязанность на всю команду разработки. Это ускорит качество и скорость поставки.
Что должен уметь фронтенд-разработчик
Разбираемся в том, кто такой фронтенд-разработчик, что он должен уметь (или не должен) и за что ему платят прекрасную зарплату (или не очень).
Кто такой фронтенд-разработчик
Согласно ежегодному исследованию StackOverflow, самая популярная профессия среди пользователей сервиса в 2017 году — это Web developer. Именно в эту категорию входят все фронтенд-разработчики.
Если зайти на первый попавшийся сайт по поиску работы, например, на hh.ru, создастся впечатление, что фронтенд-разработчик — это специалист-хамелеон.
Начинается всё с путаницы в названиях вакансий: можно встретить и «front-end developer», и «front end разработчик», и «фронтендщик», и «фронтенд девелопер», и «web developer», и «фронтенд-разработчик». Иногда даже можно увидеть «веб-верстальщика» с требованиями под фулстак-разработчика. Реакция на это одна: WTF?!
Беда в том, что часть работодателей не отличают (или не хотят отличать) верстальщика от фронтенд-разработчика, — это понятно по описанию вакансий.
Разберёмся, какие умения отделяют фронтенд-разработчика от «верстака» (верстальщики, не обижайтесь, вы тоже хорошие).
Верстальщик — боец узкого фронта. Его задача — сверстать полученный от дизайнера макет, используя HTML+CSS. Он, возможно, немного умеет в JavaScript, но чаще ограничивается умением прикрутить какой-нибудь плагин jQuery.
Фронтенд-разработчик не просто верстает макеты.
Он хорошо знает JavaScript, разбирается во фреймворках и библиотеках (и активно юзает часть из них), понимает, что находится «под капотом» на серверной стороне. Его не пугают препроцессоры и сборщики LESS, SASS, GRUNT, GULP, он умеет работать с DOM, API, SVG-объектами, AJAX и CORS, может составлять SQL-запросы и копаться в данных. Получается сборная солянка навыков, к которым добавляется понимание принципов UI/UX-проектирования, адаптивной и отзывчивой вёрстки, кросс-браузерности и кросс-платформенности, а иногда и навыков мобильной разработки.
Фронтендщик в обязательном порядке умеет работать с контролем версий (Git, GitHub, CVS и т. д.), использовать графические редакторы, «играть» с шаблонами различных CMS.
Ещё крайне желательно знать английский язык, чтобы не переводить спецификацию в Гугл-переводчике, уметь работать в команде, иногда мультиязычной, разбираться в веб-шрифтах, ну и понимать тестировщиков и сам процесс тестирования.
Итак, какие технологии должен освоить фронтенд-разработчик:
В чём должен разбираться:
Конечно, это всё в идеале. Не обязательно досконально знать все эти технологии — это под силу далеко не всякому, да и нецелесообразно. Лучше выбрать себе стек навыков по душе и развиваться в более узком направлении.
Что говорит статистика
Какие технологии и инструменты чаще всего используют фронтенд-разработчики? Во-первых, трудно представить фронтендщика, не умеющего в JavaScript. Это подтверждают опросы:
Далее идут различного рода фреймворки и библиотеки, самые популярные из которых Angular, Node.js, React. Кроме обязательного JavaScript, фронтенд-разработчики также используют и другие языки, хоть и не так часто. Лидируют PHP, SQL, Java и С#. И, конечно же, не обойтись фронтендщику без навыков работы с CMS. Самый популярный выбор — WordPress.
Если сгруппировать самые популярные инструменты в стеки, то получим такую ситуацию:
А набор самых популярных фреймворков и библиотек всех разработчиков выглядит следующим образом (см. иллюстрацию). Приятно видеть среди этого списка инструменты фронтенда:
Карьерный путь и зарплата фронтенд-разработчика
Карьерный пусть фронтендера обычно начинается с верстальщика — это самый логичный и общепринятый вариант. Сначала изучается связка HTML+CSS, затем на неё наслаиваются знания JavaScript, библиотек и фреймворков. Будущий специалист также изучает ключевые понятия построения серверной части, добавляет сюда инструменты, необходимые для выбранной специализации. Затем всё это шлифуется умением работать с контролем версий, графическими редакторами и пониманием принципов UI/UX-дизайна.
Бывают и иные варианты. Если начинающий программист изначально знает, в какой сфере планирует развиваться, ничто не мешает ему изучать ключевой стек технологий сразу, а не по частям. Всё зависит от целей и времени, которыми располагает будущий фронтендщик. Любой вариант приемлем, лишь бы на выходе получился толковый специалист.
У готового фронтенд-разработчика в целом есть три основных варианта развития:
Сервис PayScale наглядно проиллюстрировал все возможные пути карьерного развития фронтенд-разработчика:
Какой из них выбрать — зависит лишь от самого специалиста и его пожеланий или навыков.
Касаемо зарплат фронтенд-разработчиков, здесь, как и во всей IT-индустрии, нет единого стандарта оплаты. Всё зависит от навыков и умения подать себя. Ну и от везения иногда 🙂
Средняя зарплата фронтенд-специалиста по России, рублей/месяц:
Средняя зарплата фронтенд-специалиста по Москве, рублей/месяц:
Традиционно годовая зарплата фронтенд-разработчиков в США чуть выше, чем по России. Однако, если вы работаете в филиале иностранной компании, вам такой разрыв, скорее всего, не страшен.
Как стать фронтенд-разработчиком
Для начала снять розовые очки. Обучение — это труд и самодисциплина. Большинство начинающих айтишников отсеиваются на этапе «хочу стать программистом и получать зарплату в долларах, но не думал, что придётся так много учиться».
Уникальность программирования и вообще любой айтишной специальности ― в постоянном самообучении. В этом и сложность, и прелесть IT-сферы. Если вас это не пугает — круто! У вас есть все шансы стать отличным специалистом.
Главное правило будущего специалиста — ставить реальные цели в процессе обучения. В этом поможет планирование. Составьте список инструментов, которые планируете изучить, и держите его перед глазами.
Тем, кто стартует с нуля, надо начинать с HTML и CSS и освоить их на уровне идеальной верстки PSD-макетов. На этом этапе также надо научиться работать с текстовыми и графическими редакторами и знать основные принципы дизайна (как плюс).
Затем взяться за JavaScript: синтаксис, архитектура и возможности языка. Освоить популярные фреймворки и библиотеки, параллельно полюбить системы контроля версий и какой-нибудь из популярных таскраннеров. Добавить препроцессоры и фреймворки CSS, разобраться в серверных технологиях. А дальше можно пить смузи на Бали и шлифовать полученные знания до бесконечности.
Пройти этот путь можно как в одиночку, так и с наставниками (вузы, курсы). Вот какие самые популярные форматы обучения разработчиков по версии StackOverflow:
На первом месте находятся онлайн-курсы, за них проголосовали 64,7% опрошенных разработчиков. Затем идут самообучение по книгам, офлайн-курсы, опенсорс-разработка и лагери программирования. Интересно, что высшее образование (Master’s degree) стоит практически на последнем месте.
Резюмируем
Фронтенд-разработчик — это универсальный солдат. Он и макет заверстает, и веб-приложение построит, и серверную часть, если надо, освоит.
Знать надо немало: HTML, CSS, JavaScript, библиотеки и фреймворки JS, препроцессоры и фреймворки CSS, системы контроля версий и таскраннеры, технологии бэкенда, юнит-тестирование и многое другое.
Кроме того, нелишними будут soft skills: взаимодействие с людьми и работа в команде, умение наладить эффективный workflow и решать поставленные задачи наиболее оптимальным способом. Не обойтись без уверенных знаний английского языка.
Оплата труда фронтенд-специалиста вполне себе достойная, и чем больше навыков — тем выше шансы получить «жирный» оклад.
Стать фронтенд-разработчиком может каждый, кто не пасует перед самообучением: как мы выяснили, полагаться на вузовское образование сложно. Идеальный вариант — различные онлайн- и офлайн-курсы + литература по теме, практика и великий Гугл.
Хотите написать колонку для Нетологии? Читайте наши условия публикации. Чтобы быть в курсе всех новостей и читать новые статьи, присоединяйтесь к Телеграм-каналу Нетологии.
Увидеть интерфейс «глазами дизайнера»: о взаимодействии фронтендера с дизайнером
Из железнодорожника в программисты — история Максима Багаева