что нужно знать frontend разработчик в 2021
Фронтенд-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 может принести накладные расходы. На дальней перспективе, когда проект будут развивать несколько поколений разработчиков, — используйте и не сомневайтесь.
В нашем блоге вы можете найти пару полезных статей про 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
В тестировании ПО рекомендуется использовать фреймворки, которые написаны на том же стеке, что и ваше приложение. Таким образом можно отойти от парадигмы, когда автотесты пишут отдельные люди, и разделить обязанность на всю команду разработки. Это ускорит качество и скорость поставки.
🕸 Как стать веб-разработчиком в 2021 году
furry.cat
Практически каждый человек, гуляя по просторам интернета, хотя бы раз в жизни мечтал о собственном сайте – блоге, портфолио с примерами работ или же сайте для стартапа/бизнеса.
Веб-разработка сейчас – невероятно востребованная специальность. С активным развитием цифрового мира спрос на веб-разработчиков растет.
Если вы не знаете, с чего начать карьеру в вебе, эта статья для вас! В ней вы найдете базовый road map со основными навыками и технологиями, которые помогут вам стать веб-разработчиком в 2021 году!
Как работает интернет
Обычно создавая веб-сайт, вы планируете опубликовать его в интернете. А значит, нужно иметь базовое представление о том, как интернет работает, как происходит взаимодействие браузера пользователя и сервера, где лежит ваш сайт.
Интернет – это большая сеть компьютеров, которые могут общаться друг с другом. Мы можем получить доступ к ресурсам, которые на них хранятся. Для этого нужно открыть браузер и ввести правильный URL-адрес.
Что почитать о клиентах и серверах:
Хорошая новость для новичков – хостинг (размещение в интернете) сайтов сегодня стал очень простым делом. Вам не нужно собственноручно настраивать сервер и привязывать к нему домен – все это сделает провайдер. Кроме того существует много сервисов, на которых можно разместить свой сайт бесплатно, например, GitHub Pages или Netlify.
Три типа веб-разработчиков
Создание сайта – комплексный процесс, состоящий обычно из нескольких стадий. Он начинается с дизайна и создания макета, определяющего, как сайт будет выглядеть. Затем картинку нужно перевести в код – адаптивно сверстать, разработать пользовательский интерфейс, добавить функциональные возможности. И наконец, нужно написать серверный код и развернуть сайт на сервере.
Обычно этими задачами занимаются разные люди:
Что почитать о фронтенде и бэкенде:
Front-end разработка
Фронтендеры отвечают за внешний вид сайта. Основные технологии, которыми они должны владеть, – HTML, CSS и JavaScript.
HTML нужен для создания основной разметки, CSS управляет стилями (оформлением), а JavaScript добавляет динамику и различную функциональность.
Тонкости
Верстка сайта – весьма сложный и комплексный процесс. Пользователь видит ваш сайт через браузер, а браузеры бывают разные. Некоторые вещи могут работать в одном, но не работать в другом – и хороший фронтенд-разработчик должен знать об этом.
При разработке важно учитывать, как сайт выглядит на экранах разных размеров. Люди все чаще и чаще заходят в интернет с мобильных устройств, нужно позаботиться, чтобы у них все отображалось правильно. Это называется адаптивной или отзывчивой версткой. Для обеспечения адаптивности используются медиа-запросы CSS и подход mobile first.
Что почитать о фронтенд-разработке:
Фреймворки
Когда вы разобрались в основах, можно переходить к освоению каких-нибудь фронтенд-фреймворков. Фреймворки – это специальные инструменты, облегчающие работу фронтендера. Они избавляют от необходимости писать один и тот же код много раз и предлагают удобные решения часто встречающихся задач.
Существуют CSS-фреймворки, например, Bootstrap, Material CSS, Tailwind. Они предоставляют сетку для разметки сайта и множество вспомогательных классов для стилизации элементов.
Есть также и JS-фреймворки, предназначенные для удобного создания динамических интерфейсов. Самые популярные из них – React, Vue и Angular, реализующие компонентный подход.
Что почитать о фронтенд-фреймворках:
Back-end разработка
Бэкенд нужен не для каждого сайта. Если вы создаете простую статичную страницу, то ее можно разместить на бесплатном хостинге Github или Netlify и обойтись без серверной части. Однако более сложные приложения обычно используют базу данных или аутентификацию пользователей – для всего этого требуется бэкенд.
Основные задачи бэкендера:
Кроме того, бэкендер должен уметь работать с базами данных – реляционными (MySQL) или нереляционными (MongoDB).
Фреймворки
Для бэкенда тоже существуют фреймворки и платформы. Например, если вы хотите использовать один язык во всех частях приложения, начните изучать Node.js. Это платформа для серверного JavaScript.
Подготовка к интервью
Популярное
Наиболее востребованным навыком на рынке на текущий момент является знание фреймворков JavaScript, как клиентских (React, Vue), так и серверных (Node.js). Больше всего вопросов на собеседованиях веб-разработчиков затрагивают именно эти темы. Разумеется, вы также должны хорошо разбираться в «ванильном» JavaScript.
Специфика позиции
Обычно вы претендуете или на позицию фронтендера, или бэкендера. Реже – фуллстека. Выбранное направление во многом определяет, что будет на интервью. Например, фронтендера скорее будут спрашивать про верстку и особенности разных браузеров, а бэкендера – про базы данных.
Очень часто компании хотят, чтобы претендент имел некоторый опыт работы с указанными технологиями, поэтому новичку имеет смысл начать с фриланса или вклада в open source проекты, чтобы прокачать скиллы и получить кейсы для портфолио.
Что почитать о прохождении интервью на веб-разработчика:
🕸 16 шагов к профессии: дорожная карта фронтенд-разработчика в 2021 году
Юлия Ильюшкина
Чтобы стать классным специалистом и начать хорошо зарабатывать, вам придется постараться и потратить немало времени. Создавать визуальную часть сайта ничуть не проще чем серверную, а знать для этого нужно очень много. Предлагаем вашему вниманию актуальную в 2021 году дорожную карту фронтендера. Следуйте этому плану, и вы сможете освоить популярную профессию, не пополнив ряды программистов за еду.
Обязанности фронтенд-разработчика
Список задач, которые решает Front-end developer, меняется в зависимости от специфики проекта и уровня подготовки разработчика. В него могут входить следующие позиции:
1. Изучите HTML, JavaScript и CSS
Веб-разработчикам никуда не деться от изучения трех «китов»: разметки (HTML), каскадной таблицы стилей (CSS) и языка программирования JavaScript. С этим помогут материалы на CodeAcademy и YouTube: HTML Full Course, CSS Tutorial и CSS Crash Course for Absolute Beginners, Object-oriented Programming in JavaScript.
2. Изучите несколько фреймворков
Для работы потребуется использовать один/несколько фреймворков: ReactJS, AngularJS, VueJS, Bootstrap. Разобраться с React JS поможет ролик freeCodeCamp на YouTube, там же можно найти курс по VeuJS.
3. Освойте работу с генераторами статических сайтов
Примеры статических сайтов: визитки, лендинги, справочники, каталоги продукции. Упростить их создание помогут: Next (React-based), Nuxt (Vue-based), Gatsby (React-based), Gridsome (Vue-based).
4. Научитесь работать с JAMstack
Расшифровка акронима JAM: JavaScript, API and Markup. Архитектура JAMStack основана на клиентском JavaScript, повторно используемых API и предварительно созданной разметке. Что такое JAMStack и как с ним работать можно почитать здесь и на snipcard. Дополнительно в стеке используют CDN и Git.
5. Освойте Progressive web apps (PWA)
Знания PWA (англ. progressive web app или мобильное приложение в браузере) потребуются опытным разработчикам. Прогрессивные приложения направлены на надежность и быстроту работы с технологиями Push Notifications, Service Worker, Web App manifest, App shell, HTTPS.
6. Освойте GraphQL
Этот язык запросов и манипулирования данными для API (а также среда выполнения запросов) является основным для каждого фронтендера, который не хочет работать за еду. Обрабатывающий запросы сервер GraphQL находится между клиентом и источниками данных.
Ресурсы для изучения GraphQL:
7. Научитесь выполнять тестирование и чистить код
Веб-программисту на коммерческом или корпоративном проекте стоит уметь выполнять:
Основы чистого кода:
8. Запаситесь книгами по основам фронтенда
Дэвид Флэнаган, «JavaScript. Подробное руководство».
Кайл Симпсон: cерия книг «Вы не знаете Javascript».
Натан Розенталс, «Изучаем TypeScript 3».
Доминик Майерс, «Front-End Developer».
Карлос Сантана Рольдан, «React Cookbook: Create Dynamic Web Apps with React».
Крис Акино и Тодд Ганди, «Front-End Web Development: The Big Nerd Ranch Guide».
Джон Дакетт, «HTML & CSS: Design and Build Web Sites».
9. Просмотрите туториалы на YouTube
10. Изучите работу с командной строкой
Если вы используете Windows, не стоит полагаться только на графический интерфейс. Чтобы упростить работу с файлами и каталогами (найти, открыть, закрыть, удалить и пр.), а также использовать неочевидные возможности ОС, потребуется знание базовых команд. Кроме старого доброго CMD рекомендуется освоить более прогрессивный PowerShell, а использующим один из дистрибутивов GNU/Linux разработчикам стоит изучить bash.
11. Изучите систему контроля версий Git и хостинг GitHub
Онлайн-хостинг для контроля версий GitHub позволяет людям по всему миру совместно работать над проектами. К тому же в репозиториях можно найти много бесплатных решений для собственных разработок.
12. Следите за событиями кибербезопасности
Открытый проект OWASP собирает статистику, необходимую для обеспечения безопасности веб-приложения. Для изучения основ необходимо понимать отличия HTTPS и HTTP, какова политика защиты контента (CSP) и принципы работы с CORS.
13. Практикуйтесь как можно больше
В процессе изучения теории важно сразу применять знания на практике. Писать фрагменты кода, собирать их в единый проект (можно в выдуманный) – это поможет при трудоустройстве после обучения. Если вы создадите что-то полезное и выложите это на GitHub, всегда можно показать свои наработки потенциальному работодателю. Даже если сразу не получится пойти на позицию джуниора, не пренебрегайте бесплатной стажировкой. Начинающих специалистов на рынке труда более чем достаточно, так что стоит пользоваться любым шансом.
14. Постоянно повышайте уровень знаний
Оставаться востребованным фронтенд-разработчиком можно только если вы все время учитесь. В этом вам помогут freeCodeCamp, Codecademy.
Перечень недостающих знаний можно проверить по чек-листам:
15. Нарабатывайте софт-скилы
Продвижение по карьере, особенно в сторону менеджмента, предполагает развитие софт-скилов. Вот их примерный список:
17. Пройдите курсы
Если вы знаете английский, можно пройти курс w3wschhools по HTML, CSS и JavaScript, или по программе Мичиганского университета заняться на coursera веб-дизайном и программированием. Популярная международная платформа предлагает множество аналогичных позиций, включая курс Duke university по основам JavaScript, HTML и CSS.
Если вас больше привлекает обучение на русском языке, обратите внимание на факультет frontend-разработки GeekBrains. В программе российской образовательной онлайн-платформы есть все необходимое: