Практическое руководство как стать senior frontend developer

Trunk based development (TBD). Assess

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

В TBD ветки с новым кодом вливаются в основную ветку не реже чем раз в 24 часа. С помощью этого команда получает ускоренный цикл обратной связи по задаче. В более распространенных моделях ветвления изменения дольше копятся, часто в момент попадания изменений в основную ветку объявляются неожиданные проблемы, исправление которых несет дополнительную сложность из-за позднего времени их обнаружения. В TBD все изменения делаются максимально атомарными, интегрируются с самой новой версией основной ветки как можно чаще, что создает определенные требования к архитектуре приложения, такие как поддержка Feature Flags, чтобы иметь возможность отключать из исполнения еще не завершенные задачи.

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

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

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

API

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

Цели для нового API сформировались из ежедневных трудностей в реализации новых продуктовых и дизайнерских идей. Нам были нужны:

1. Слабая связанность компонентов системы, чтобы бэкенд и фронтенд можно было развивать параллельно.
2. Высокая масштабируемость, чтобы новый API не мешал наращивать функциональность.
3. Стабильность и согласованность.

Поиск решения для API начали не с бэкенда, как это обычно принято, а, наоборот — подумали, что нужно пользователям.

Наиболее распространены разного рода REST API. В последние годы к ним добавляют описательные модели через инструменты типа swagger, но нужно понимать, что это тот же REST. И, по сути, его главный плюс и в то же время минус — это правила, которые носят исключительно описательный характер. То есть никто не запрещает создателю такого API отклоняться от постулатов REST при реализации отдельных частей.

Другим распространённым решением является GraphQL. Он тоже не идеален, но в отличие от REST, GraphQL API — это не просто описательная модель, а настоящие правила.

Выше я говорил про систему, которая должна была согласовывать работу фронтенда и бэкенда. Прослойка (interlayer) — это именно тот промежуточный уровень. Рассмотрев возможные варианты работы с сервером, мы остановились на GraphQL в качестве API для фронтенда. Но, так как бэкенд написан на C++, то реализация GraphQL-сервера оказалась нетривиальной задачей. Не буду здесь описывать все возникшие сложности и ухищрения, на которые мы шли, чтобы их преодолеть, реального результата это не принесло. Посмотрели на проблему с другой стороны и решили, что простота — залог успеха. Поэтому остановились на проверенных решениях: отдельный Node.js сервер с Express.js и Apollo Server.

Далее нужно было решить, как обращаться к API бэкенда. Сначала смотрели в сторону поднятия REST API, потом пробовали использовать аддоны на C++ для Node.js. В итоге поняли, что это всё нам не подходит, и после подробного анализа для бэкенда выбрали API на базе gRPC-сервисов.

Собрав воедино полученный опыт использования C++, TypeScript, GraphQL и gRPC, мы получили архитектуру приложения, позволяющую гибко развивать бэкенд и фронтенд, продолжая при этом создавать единый программный продукт.

Получилась схема, где фронтенд общается с промежуточным сервером с помощью GraphQL-запросов (знает, что спросить и что получит в ответ). GraphQL-сервер в резолверах вызывает API функции gRPC-сервера, при этом для связи они используют Protobuf-схемы. API-сервер на базе gRPC знает, у какого микросервиса взять данные, или кому передать полученный запрос. Сами микросервисы при этом тоже построены на gRPC, что обеспечивает скорость обработки запросов, типизацию данных и возможность использования различных языков программирования для их разработки.

Общая схема работы после изменения архитектуры

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

Чем отличается frontend от backend’a?

Чтобы понять, чем отличаются backend— и frontend-разработка, разберемся, за что они отвечают. Допустим, пользователь нажимает кнопку «Подробнее» на сайте музыкального фестиваля. Сразу после этого загружается новая страница, на которой в нужном порядке и с заданным дизайном отобразилась информация о программе мероприятия. Верстку и взаимодействие с backend настроил frontend-разработчик.

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

Читайте больше: Рассказ о профессии backend-разработчика.

Выходите из своей зоны комфорта

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

Выход из своей зоны комфорта позволит вам объективно взглянуть на различия фреймворков и понять, что весь холивар, о том что лучше, бессмысленен.

Также, вы сможете почерпнуть некоторые концепции и ваша способность переключаться между фреймворками станет для вас реактивной силой. Так что отправляйтесь изучать, будь то React, Angular, Vue или Stencil, их целая куча. Я уверен, что вы отыщете себе фреймворк по душе.

Перспективы в профессии

Веб — перспективная отрасль для роста: профессионального и финансового. Даже новички могут претендовать на достойную зарплату. По состоянию на 26 апреля 2021 года на HeadHunter опубликовано 183 вакансии для фронтендеров без опыта работы. В 58-и из них предлагают от 65 000 рублей в месяц. Есть и более высокооплачиваемая работа. Специалист с опытом 3-6 лет может получать 300 000 — 400 000 рублей в месяц.

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

Что должен уметь джуниор? Ему понадобятся отличные знания HTML и CSS, а также уверенное владение JavaScript и знакомство с одним из его фреймворков.

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

Сеньор мастерски владеет всеми инструментами, при этом он сосредоточен не столько на деталях, сколько на проекте в целом, его планировании и реализации. Он распределяет работу, следит за качеством ее исполнения.

Доход фронтендера, выбравшего «узкий» путь развития, растет в соответствии с категориями.

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

В чем преимущества? В более полном понимании всех процессов и возможности самому создать сайт от и до. В чем минусы? Широта познаний порой исключает их глубину. Вы можете овладеть множеством инструментов, но не будете управлять в совершенстве ни одним из них. Это отразится в том числе на зарплате. Узкому специалисту доверят трудный, высокобюджетный проект с большей вероятностью, чем широкому. Чтобы стать дорогим фулстэкером, необходимо по-настоящему круто разбираться в нескольких технологиях.

Пользовательский опыт

▍Поддержка устаревших браузеров (полифиллы)

полифиллыэтомCan I Use

• Angular. В документации к Angular есть особый раздел, посвящённый браузерной поддержке.
• React. Проекты, создаваемые с помощью Create React App, поддерживают, как и ReactDOM, браузеры, начиная с IE 9. Эта поддержка основана на использовании полифиллов.
• Vue. Здесь особенности поддержки устаревших браузеров описаны в к CLI.

▍Локализация и интернационализация

• Использование на сайте выпадающего списка с перечнем языков, поддерживаемых проектом.
• Доступ к сведениям о географическом местоположении пользователя (с помощью браузерного API Geolocation) и адаптация веб-сайта в соответствии с полученными данными.
• Указание сведений о языке в URL. Например, это может выглядеть так: , или так: , или даже так: .

• Angular. Angular, повторюсь, это полноценный фреймворк, он даёт разработчику готовое решение.
• React. Задачи интернационализации проектов можно решать с помощью популярной в React-среде библиотеки react-i18next.
• Vue. В решении рассматриваемых нами задач очень хорошо показывает себя библиотека vue-i18n.

▍Доступность контента

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

a11yproject.com

Angular. В документации к этому фреймворку есть особый раздел. Разработка доступных проектов поддерживается и на уровне Angular CDK.
React. Речь о доступности ведётся и в документации к библиотеке React. Существует и специальная библиотека — react-a11y

Но эта библиотека больше не поддерживается, поэтому пользуйтесь ей с осторожностью и учитывайте то, что её планируется заменить на библиотеку react-axe.
Vue. Разрабатывать доступные проекты на Vue поможет плагин vue-a11y

При создании библиотеки vuetify тоже учтены соображения доступности.

Как стать front-end разработчиком

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

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

1. Совершенствовать свои навыки как специалиста, занимаясь различными проектами в роли фрилансера – это горизонтальный путь развития.
2. Устроиться в компанию и расти по карьерной лестнице – это вертикальный путь развития.

Основное правило в процессе обучения и совершенствования – ставить реальные цели и постоянно заниматься практикой

Важно изучать не только необходимый набор инструментов, но и хорошо разбираться в смежных профессиях

Dependency Injection. Adopt

Мы рекомендуем использовать паттерн DI и вместе с ним IoC-контейнеры. Кажется, что DI не сильно распространен во фронтенд-разработке за пределами Angular, но у нас в компании этот паттерн получил широкий охват, в том числе на проектах с React, где мы используем собственный фреймворк Tramvai.js, который построен на DI.

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

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

Наш коллега Сергей Нестеров сделал доклад Dependency injection в React-приложении — советуем посмотреть.

Результат

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

1. За отображение отвечает фронтенд, а за данные — бэкенд.
2. На фронтенде сохранилась гибкость в плане запросов и получения данных. Интерфейс знает, что можно попросить у сервера и какие ответы должны быть.
3. На бэкенде появилась возможность менять код с уверенностью, что интерфейс у пользователя продолжит работать. Стал возможным переход на микросервисную архитектуру без необходимости переделывать весь фронтенд.
4. Появилась возможность использования mock-данных для фронтенда, когда ещё не готов бэкенд.
5. Создание схем совместной работы исключило проблемы взаимодействия, когда команды понимали одну и ту же задачу по-разному. Сократилось количество итераций по переделке форматов данных: действуем по принципу «семь раз отмерь, один раз отрежь».
6. Появилась возможность планировать работы на спринт параллельно.
7. Для реализации отдельных микросервисов теперь можно набирать разработчиков, не знакомых с C++.

Из всего этого главным достижением я бы назвал возможность осознанно развивать команду и проект

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

Стать профессионалом во всём невозможно, но для нас это теперь и не нужно.

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

Inner source. Assess

Если вы нацелены на ускорение поставки, распространение владения кодовой базы и межкомандное сотрудничество, то подход Inner Source может быть вам интересен.

Inner Source — это как Open Source, только внутри компании, который позволяет уменьшить зависимость от смежных команд разработки, что должно привести к ускорению выполнения задач.

Разберем на примере. Допустим, у вас есть две команды и первая команда хочет доработку от второй. Команда 1 приходит к команде 2, добавляет свою задачу в очередь бэклога и получает блокирующую зависимость в исполнении своего проекта. В случае с Inner Source все репозитории открыты внутрь компании. В таком подходе команда 1 может сделать pull request в целевую систему, а владелец системы — команда 2 — эти изменения проверит и вольет в основную ветку. Выходит, что первая команда получит свою доработку быстрее за счет использования собственного ресурса, чем если бы ждала, своей очереди в бэклоге другой команды.

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

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

Подробней ознакомиться с Inner Source можно на сайте комьюнити Inner Source.

Лучшие книги и средства обучения

• Стив Макконнелл «Совершенный код». Просто читайте эту книгу и впитывайте то, что там написано. Вы сразу (нет, не сразу) поймёте, что такое грамотная разработка, и чем она отличается от говнокода.
• htmlbook.ru — просто добавьте этот сайт в закладки, закреплённое и в своё сердце. Это великолепная энциклопедия веб-разработчика на русском языке с адекватной и удобной структурой. 
• Книги Кайла Симпсона — ищите то, что вам нужно и то что актуальной даты издания. Он очень круто пишет и структурирует информацию о JavaScript.
• Хавербеке Марейн «Выразительный JavaScript. Современное веб-программирование» — практически ценная книга от настоящего профессионала. Если не ошибаюсь, у «Питера» пережила издание в 2019 году, свежак.
• webref.ru — очень классный сайт для разработчиков веба, разбирайтесь, обучайтесь. 
• Книги по вашей технологии — переводные или в оригинале (ищите O’Reilly).
• codecademy.com — люблю этот сайт и иногда использую для поддержания мозгов в порядке. Интерактивный сайт для обучения разработке на разных языках программирования на английском, с самого низкого, нулевого, уровня. Есть базовый бесплатный курс, есть платный — 15$ в месяц. Нравится общая интерактивность, значки, ачивки и постепенное нарастание сложности задач. 
• htmlacademy.ru — есть бесплатные курсы, части курсов и блог. Берите все знания, что сможете унести.
• Бесплатные курсы и видео, которых бесконечно много на Youtube на русском и английском языках. Просто слушайте, повторяйте, систематизируйте знания. Для начала подойдут любые, очень скоро вы научитесь отличать крутые вещи от дилетантских. 
• Ну и конечно — не бойтесь и не стесняйтесь коммитить в open source проекты (начните с небольших, а там и до библиотек, и до фреймворков дойдёте), ковыряйте чужой код, изучайте принципы и алгоритмы.
• Хорошая статья с очень простым английским и подсказками для начинающих свой путь в JavaScript.
• Конечно же Хабр. Одна команда RUVDS сколько крутого по JavaScript и фронтенду перевела!

Аналитика

▍Наблюдение за поведением пользователей и A/B-тестирование

• Google Analytics (GA). Существуют руководства по использованию GA в Angular, React и Vue.
• Kameleoon. Это — основанный на технологиях искусственного интеллекта фреймворк для персонализации и A/B-тестирования веб-проектов.

▍SEO

• Angular. Вот интересная статья по поисковой оптимизации, которая применима к Angular- и к Angular Universal-проектам.
• React. Вот материал об общих проблемах SEO в React-проектах. Вот — статья об улучшении поисковой оптимизации React-приложений.
• Vue. Вот подробная статья о поисковой оптимизации Vue-приложений.

Будущее бэкендера

• Стандартный путь внутри своего стека: junior с односложными задачами и запросами, middle с глубокими навыками программирования и отличным владением стеком, senior с проектированием, архитектурами, высокими нагрузками и прочим кубернетесом, team lead с управленческими навыками т.д. Это хороший корпоративный путь, внутри которого можно менять компании, проекты, отрасли, расти и быть востребованным.
• Переход на другой стек и выход из веба: нередко именно бэкенд-разработчики осваивают Java, С/С++ и уходят в «кровавый энтерпрайз», десктопные приложения, разработку средств разработки, нейросети, компьютерное зрение и т.д. Действительно, бэкендеру проще осваивать эти трудные технологии и ЯП.
• Переход в фуллстек-разработку: бэкендер ближе к фуллстеку и совершить такую трансформацию можно совершенно незаметно.
• Переход в DevOps, DevSecOps, информационную безопасность — когда знаешь веб-приложения изнутри как свои пять пальцев, этот путь оказывается логичным и весьма доходным.
• Переход на менеджерские позиции, если есть желание и склонность к управленческим задачам. 
• Фриланс и своё программное агентство — для смелых и в меру азартных ребят. Можно неплохо зарабатывать на аутсорс-разработке (особенно если идти в сторону фуллстек-разработки).

Препроцессоры и постпроцессоры CSS

C момента своего появления в 1990-х, CSS проделал огромный путь. Поскольку пользовательские интерфейсы становятся все сложнее, разработчики придумывают инструменты, позволяющие облегчить работу над их созданием. Для этого и предназначены пре- и постпроцессоры.

Препроцессоры представляют из себя расширения для языка CSS, которые добавляют наворотов типа переменных, миксинов и наследования. Два самых главных препроцессора Sass и Less. На 2016 год Sass более распространен. Bootstrap, популярный CSS фреймворк, переключился с Less на Sass. К тому же когда большинство людей заводят речь о Sass, то они на самом деле говорят о SCSS (рус.).

Постпроцессоры CSS вносят изменения в код после того, как он был написан или после компиляции препроцессора. Например, некоторые постпроцессоры, тот же PostCSS, имеют плагины для автоматического добавления префиксов.

Когда вы впервые открываете для себя препроцессоры и постпроцессоры, появляется соблазн использовать их везде. Тем не менее начните с простого и добавляйте переменные, миксины только там, где это действительно необходимо. Статья, о которой я упоминал ранее, (англ.), так же рассказывает о том, какие возможны излишки при работе с препроцессорами.

Сеть и производительность

▍Размер бандла приложения

Использование интернета в мире (источник — broadbandsearch.net)

• Angular. Бандлы Angular-приложений легко и удобно исследовать с помощью webpack-bundle-analyzer. Более того, CLI Angular даёт в наше распоряжение опцию , которая позволяет сформировать отчёт после сборки бандла.
• React. В документации к Create React App есть страница, посвящённая анализу размеров бандлов.
• Vue. Во Vue, как и в Angular, есть опция , которая позволяет формировать отчёты по бандлам.

▍Сервис-воркеры и прогрессивные веб-приложения

• Angular. В Angular предусмотрены механизмы для использования сервис-воркеров.
• React. Вот руководство по разработке PWA с помощью Create React App.
• Vue. Возможность создания PWA во Vue поддерживается на уровне CLI.

▍Серверный рендеринг

• Улучшение SEO сайтов.
• Ускорение вывода сайтов в браузере.

• Angular. Тут используется Angular Universal.
• React. Для серверного рендеринга React-приложений применяется Next.js.
• Vue. Серверный рендеринг Vue-приложений выполняют с помощью фреймворка NuxtJS.

▍Генераторы статических сайтов

Jamstack

• Скорость: генераторы статических сайтов создают страницы сайтов во время сборки проекта, а не тогда, когда эти страницы запрашиваются клиентом.
• Безопасность: применение SSG позволяет отказаться от систем управления контентом (CMS, Content Management System), которые часто оказываются целями хакерских атак.
• Упрощение масштабирования: веб-проект при применении SSG представляет собой набор файлов, который можно передать клиенту откуда угодно. Это значительно упрощает хранение подобных файлов в CDN. В результате оказывается, что статические сайты очень хорошо масштабируются.
• Упрощение процесса разработки: SSG-проектам не нужна серверная часть и база данных. Это облегчает труд разработчиков.

• Angular. Scully.
• React. Gatsby (React + GraphQL), Next.js.
• Vue. Gridsome, Nuxt.

11tyHugoJekyll

Преимущества и недостатки профессии

К плюсам относится:

1. Профессия доступна и новичкам в программировании.
2. Должность имеет востребованность на рынке услуг.
3. Имеются перспективы карьерного роста.
4. Возможность взяться за крупные проекты и работать с зарубежными компаниями.
5. Высокая зарплата.

Минусы профессии:

1. Постоянное развитие и освоение новых технологий.
2. Отсутствие четкой границы и описания обязанностей. Руководитель может сам назначить функции и задачи работника. И это может стать для фронтенд-разработчика проблемой.
3. Зависимость от других специалистов и постоянное взаимодействие с ними. Не всегда получается все согласовать с первого раза, что приводит к замедлению процесса работы.

Чем занимаются фулстек-разработчики

Фулстек-разработчик — это специалист, который сочетает в себе навыки фронтендера и бэкендера. Он может разрабатывать как клиентское, так и серверное ПО. 

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

В разрезе веб-разработки клиентское ПО — это те программы, которые выполняются в браузере. Например, браузер рисует весь интерфейс, реализует его анимацию, отправляет какие-то данные на сервер. Серверное ПО — это те программы, которые выполняются на сервере. Например, сервер может отфильтровать данные миллионов пользователей Яндекса по году рождения и отправить клиенту только рожденных в 1990 году.

Фулстек-разработчик может создать графический интерфейс, запрограммировать всю необходимую логику, выполняемую на сервере, а потом построить связь между этими двумя частями, чтобы получить единое приложение. Помимо работы с HTML и CSS он также знает, как писать программы, которые исполнит браузер, — и то, как запрограммировать сервер. Фулстек может сам создать форму регистрации и дописать к этой задаче весь серверный код, который проверит, не был ли зарегистрирован такой пользователь ранее. Если человек уже есть в базе, то сервер отправит сообщение об ошибке в браузер, если нет — сохранит данные в базу данных, а браузеру отправит ответ об успешной регистрации пользователя.

Что нужно знать фронтенд разработчику?

Front-end разработка требует знание обширного набора инструментов и технологий. Каждый из них является неотъемлемой частью современной фронтенд-разработки.

К ним относятся:

1. HTML и CSS

Без HTML и CSS разработка внешнего интерфейса невозможна. Эти две технологии обеспечивают строение основополагающей части любого сайта.

Язык разметки HTML отвечает за то какие элементы должны находится на сайте. Например: кнопки, ссылки, формы заполнения полей, заголовки и т.д.

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

Без CSS и HTML не может быть веб-дизайна, форматированного текста, мультимедиа и даже простых изображений. Создание даже самых простых веб-сайтов требует хорошего знания CSS и HTML.

Любой человек, стремящийся стать первоклассным веб-разработчиком, должен иметь глубокое понимание и серьезный опыт работы с CSS и HTML. Эти две технологии просты для понимания и на youtube например, существует множество видеоуроков по ним.

2. JavaScript

Несмотря на то, что для бэкенд разработки доступно несколько языков программирования, для фронтенд разработки веб-сайтов, единственным популярным стандартом сегодня выступает язык JavaScript.

Использование CSS, HTML и JavaScript позволяет разрабатывать как простые, так крупные продвинутые веб-приложения.

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

Несмотря на то, что это язык веб-сценариев, такие технологии, как Node.js, позволяют разрабатывать серверные приложения. Это один из самых популярных языков программирования, поэтому, независимо от вашего карьерного видения, изучение JavaScript выгодно любому программисту, разрабатывающие веб-приложения.

3. Frontend фреймворки (на JavaScript)

Фреймворки упрощают и ускоряют процесс создания крупных веб-приложений. Frontend фреймворки созданы специально для разработки на стороне клиента, поэтому экономят ваше время и усилия.

Одни из самых популярных фреймворков это:

• ReactJS
• Vue.js
• Angular

Самым популярным из них является фреймворк ReactJS, поэтому, думаю изучив её, вы значительно сможете улучшить свои навыки во фронтенд разработки.

4. jQuery

jQuery — это JS библиотека, которая упрощает обработку событий, а также обход и манипулирование DOM элементом веб-сайта.

Почти 3 из 10 миллионов веб-сайтов используют jQuery. Это набор расширений и плагинов, которые ускоряют разработку с помощью JavaScript. jQuery обычно используется для:

• Манипуляции и событий с HTML тэгами
• Автоматической перестановки и изменение размеров макетов сетки
• Создания счетчика обратного отсчета
• Автозаполнение формы поиска

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

5. CSS препроцессор

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

Как следует из названия, препроцессоры обрабатывают CSS код перед его публикацией на веб-сайте, а также преобразуют его в кроссбраузерный и хорошо отформатированный формат.

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

На сегодняшний день доступны 2 популярных CSS препроцессоров. Это SASS и LESS. Оба отличаются синтаксисом

SASS гораздо более популярен среди веб-дизайнеров. Это может быть связано с тем, что SASS немного старше. Изначально LESS поддерживался хорошо зарекомендовавшим себя фреймворком Bootstrap. Но с версией 4 проект Bootstrap официально перешел на SASS, что еще больше повысило его популярность.

6. API-интерфейсы и службы RESTful

Другой набор передовых концепций, относящихся к frontend разработке — это API-интерфейсы и службы RESTful.

Интерфейсы программирования или API позволяют добавлять функциональные возможности веб-сайтам.

Стиль взаимодействия компонентов REST, представляет собой облегченную архитектуру для упрощения сетевого взаимодействия через интернет.

По сути REST — это набор руководящих принципов и практик, которые закладывают основу для эффективного взаимодействия веб-сервисов. То есть когда фронтенд разработчик делает запрос по определенному URL, получает от него ответ и обрабатывает полученные данные.

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

Disappearing Frameworks. Assess

В категорию «Исчезающие фреймворки» попадают фреймворки, выполняющую свою полезную работу на этапе компиляции, генерируя чистый JavaScript без тяжелых абстракций наподобие Virtual DOM. Такие фреймворки максимально легковесны, и их производительность на слабом железе заметно выше.

Кандидаты в эту категорию: Stencil, Svelte, Solid и Angular Elements.

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

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

Более подробно познакомиться с подходом Disappearing Frameworks можно в статье Питера О’Шонесси.

Важные личные качества

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

И если кривая навигация от фронтендера приведёт к паре злобных вскриков пользователей, то ошибка бэкендера может стоить очень дорого — в прямом смысле (например, если бизнес-данные по какой-то причине перестанут сохраняться или не сработает разделение прав доступа в какой-нибудь CRM-системе).
Внимательность и внимание к мелочам. Опять же, мелочей в бэкенде не бывает, поэтому необходимо тщательно проектировать связность работы всех компонент и не упустить ничего.
Трудоспособность

Прокрастинация — опасный враг бэкендера, он должен уметь сосредоточенно работать, иногда в крайне сжатые сроки, поэтому «пилить код с ленцой» это, пожалуйста, в пет-проект или уже в состоянии тимлида (там других задач хватает).
Логическое мышление и аналитический склад ума. Оно и понятно.
Умение доводить дело до конца, нацеленность на результат. В бэкенде важен результат — корректно и ожидаемо работающее приложение.
Способность переключаться на макрозадачах. Нередко бывает, что нужно оставить код одной части проекта и реализовать довольно крупную функцию. Это непросто, потому что программист уже погружён в архитектуру и логику. Способность переключаться без особых проблем для задач — практически джедайская. 
Навыки планирования и исполнения плана. Бэкенд любого проекта — это сборник разноплановых задач. И если вы единственный бэкендер проекта или у вас с коллегами слабо реализовано разделение труда, только планирование и спасёт от авралов, факапов и срыва дедлайнов. Жёсткое к себе и времени планирование — залог спокойной работы практически без переработок (которые у бэкендеров случаются чаще остальных).
Умение работать в команде. Вам нужно будет взаимодействовать с единой командой разработки единого же приложения, а значит, дискуссии, но не конфликты, рефакторинг, но не оскорбления, отстаивание своей позиции, но не бойкоты. Если злой интровертный бэкендер отлично сделает свою работу, закоммитит и умоет руки, его труд пользователи ещё долго не смогут оценить — потому что нужно «собирать» проект в составе всей команды, а не отгораживаться по принципу «к фронтенду ни ногой».