с чего начать фронтенд разработку
Работать по 12 часов в сутки и не спать по 3 дня кряду, или как я стал frontend-разработчиком
Как парень из города Камешково прокладывает себе путь в IT и доказывает, что было бы желание, а возможности всегда найдутся
Привет! Меня зовут Артем, я frontend-разработчик в аутсорс-продакшене Hawking Bros. Сейчас я уже middle и еще параллельно учусь в колледже по специальности «Программирование в компьютерных системах».
Я родом из Камешково — это под Владимиром. Население — 12 496 человек. Такой маленький незаметный городок на карте, который начинался как поселок для рабочих при ткацкой фабрике. Как вы уже поняли, в моем родном городе не сильно развито IT, хотя следует отметить — местной молодежи интересны технические учебные заведения.
Это Камешково. Привет, малая родина
В этой статье я расскажу, как выглядел мой путь попадания в IT. Может быть, ее прочтет кто-то еще из маленьких региональных городков и поселков и поймет, что для работы в нашей индустрии не нужны связи или деньги, нужно лишь желание хорошо и много работать.
Первый компьютер, игры и отсутствие интереса к веб-разработке
Лет в 13 у меня появился первый компьютер, и я уже тогда начал изучать, как он устроен. Собственно, это можно считать точкой отсчета моего пути в IT. Я занимался этим самостоятельно и было трудно — у меня не было специализированной литературы, а мой уровень английского оставлял желать лучшего. Поэтому часто я «бил наугад» и таким образом учился. Спустя некоторое время я пошел в школьный кружок программирования. Спасибо ему за то, что у меня хотя бы появились материалы для более глубокого изучения предмета. И тогда же я уже точно решил, что хочу связать с IT жизнь.
В то время я уже более-менее освоил C++: делал на нем небольшие калькуляторы для себя и друзей, которые, например, считали проценты в играх. Это было классное чувство: придумывать какие-то приложения и пытаться их реализовывать своими силами, думать над логикой работы, исправлять какие-то ошибки с учетом того, что тебе никто не давал готовых решений и уж тем более не подсказывал.
В то время я и представить себе не мог, что стану именно веб-разработчиком. Классе в 9 нам преподавали HTML и немного JavaScript, я тогда вообще подумал, что это слишком «изи» для меня. Но спустя несколько лет, углубившись в веб-разработку, я изменил свое мнение…
Я узнал, что есть большие веб-приложения и как они разрабатываются и понял, что это круто и в эту сторону следует двигаться. Кроме того, в 2016-2017 годах веб-разработка выстрелила — появилось множество технологий, стала расти популярность существующих решений за счет выпуска новых версий. Заговорили о ботах, motion UI, многом другом.
Примерно в это же время, когда я был на 2 курсе колледжа, нас приглашали участвовать в чемпионате молодых профессионалов «WorldSkills Russia» (Владимирская область). Мне предложили попробовать поучаствовать в компетенции «Веб-дизайн и разработка». Я согласился, но в тот раз пролетел: моих знаний не хватило и место участника ушло другому человеку. Как ни странно, это меня не расстроило. Совсем наоборот, у меня появилась цель — принять участие в чемпионате в следующем году, и всем показать, на что я способен.
Мое развитие стали замечать наставники в колледже. И вдруг в один день мне заявляют, что участник, который должен был выступать на чемпионате, снят, и на его место берут меня. Как бы цинично это ни звучало, но я был рад. Осталось лишь выиграть и открыть двери в новую жизнь. Так чего же я жду? Вперед!
План — работать больше, работать лучше. Сон для слабаков
А теперь ложка дегтя: когда я узнал об этом, до чемпионата оставалась всего пара месяцев, и мне нужно было срочно подтягивать свои навыки и знания. Я понимал, что при текущем уровне развития вряд ли добьюсь хороших результатов, так как чемпионат подразумевал знания по backend, frontend и при этом еще по дизайну. Если в дизайне и фронтенде у меня еще что-то получалось — был опыт работы с Photoshop, с версткой, то backend давался очень сложно.
Я пересмотрел свой график. План был прост: упороться и вкалывать каждый день, но победить. Никакого work-life balance, только хардкор. Для этого я стал заниматься в среднем по 12 часов в день. Иногда мог несколько суток без сна готовиться (мой рекорд — 3 дня, но повторять никому не советую. И лучше не спрашивайте, как я выжил).
Вообще, эти несколько месяцев выглядели так: я приезжал после бессонных ночей на очередную тренировку в колледже, которая длилась почти 12 часов, сидел с огромными синяками под глазами, потом тратил час на дорогу в электричке, где тоже сидел, уткнувшись в ноутбук. Дома мог разве что минут 20 передохнуть, и дальше опять за работу. Не знаю, сколько бы я так еще выдержал. Но меня поддерживало то, что я занимался делом, которое мне действительно нравилось и нравится. И я понимал, что победа в этом конкурсе сильно поспособствует моему дальнейшему развитию.
К чемпионату я буквально заново изучил верстку, JavaScript. В школе я работал на нем, но использовал старый синтаксис. В 2016 синтаксис полностью переработали, сделали его более human-oriented. Это было здорово, но мне в итоге пришлось учить язык заново. Еще я прокачивался в PHP и WordPress. С таким стеком технологий я и вышел на чемпионат.
Сосредоточено иду к победе на чемпионате под номером 4
Мои усилия оправдались: по итогу 3 чемпионатных дней я занял первое место с сильным отрывом от остальных участников. Так что синяки под глазами и ненормированный день были оправданы.
После чемпионата я решил не тратить свои навыки впустую. Понемногу стал фрилансить. Выполнял небольшие заказы на WordPress или верстку на Bootstrap. До нормального трудоустройства приходилось непросто: я переехал в общежитие во Владимире из Камешково. Особой поддержки в своих начинаниях я не нашел. На первые деньги было тяжело жить, приходилось во многом себя урезать. Но бросать задуманное не хотелось. Может, сейчас тяжело. Может, чего-то не хватает. Это нормально, когда ты в начале пути. Да и в профессию я шел в первую очередь не за «золотыми горами», а потому, что хотелось.
Будни джуна, а затем уже миддла
После фриланса я устроился в диджитал-агентство junior backend-разработчиком. На этой работе в основном занимался бэком лендингов и интернет-магазинов на Битриксе. В целом, мне все нравилось, но в какой-то момент я стал перерастать в full-stack разработчика. Это был первый тревожный звонок. Но на самом деле это распространенная история в регионе: сильных команд не так уж много, да и об оттоке специалистов в столицу и города-миллионники не стоит забывать. К тому же, через 8 месяцев работы я понял, что backend мне в принципе и не нравится. Терять время на этой работе и дальше не было смысла.
Я начал поиски и вскоре уволился. К этому моменту я хорошо знал backend, сдал экзамен и стал аттестованным разработчиком Битрикса. Думаю, я мог бы продолжать работу с бэком. Но все-таки фронтенд привлекает меня сильнее. Это ни с чем несравнимые ощущения: круто, когда ты видишь свой продукт, можешь им воспользоваться. Чистый кайф: видеть внедренные тобой фичи — анимации, какую-то сложную фронтовую бизнес-логику, калькуляторы.
Так что я стал искать вакансии frontend-разработчика. На hh я наткнулся на Hawking Bros, где работаю уже почти год. Первый раз меня собеседовал наш техдир. Он проверял меня на общую адекватность и оценивал уровень знаний. Второе собеседование проходило с тимлидом frontend-отдела, его вопросы были уже более предметными — об общем понимании JavaScript, знании его новых стандартов и узких мест. По итогам меня взяли.
Где я сейчас?
Я думал, что сначала буду работать на мелких проектах и задачах. Ничего подобного. Как только я вышел в Hawking Bros, я стал работать на крупном проекте, где применялся React. Только тогда я почти ничего не знал о React и пришлось срочно изучать его. Мне частично пригодилось и знание Vue.
Здесь я работаю уже почти год. Мой рабочий день начинается с того, что я открываю наш таск-менеджер, смотрю свои задачи и начинаю их выполнять. Чаще всего я занимаюсь React-разработкой, поддержкой на разных проектах, разработкой новых интерфейсов. С недавнего времени выполняю и некоторые задачи по бэку. Сейчас уже даже помогаю нашим джунам, которые только-только пришли в профессию.
Сегодня frontend — действительно крутая ниша, в которой можно развиваться как горизонтально, так и вертикально. Благодаря тимлиду мы сильно расширяем наш стек технологий, в дальнейшем, я думаю, количество крутых проектов, с которыми мы работаем, будет только увеличиваться.
Я более-менее быстро выучил React, до сих пор продолжаю углубляться в него. Уже могу взять практически любой фреймворк, разобраться за несколько часов и сделать неплохую фичу. Стараюсь развиваться именно в этом и дальше, больше вникать в архитектуру сайтов и приложений.
И напоследок
Мне интересна моя работа, и я получаю от нее удовольствие. Становиться веб-разработчиком нужно, только если ты реально горишь этим, но тут я ничего нового не скажу. В любой сфере так. Не стоит идти в профессию из-за хайпа или золотой IT-лихорадки. Иначе выгорание настигнет вас через полгода-год.
Я стараюсь придерживаться и всем советую следовать мотивационным словам, написанным на плакате в нашем офисе — «ДЕЛАЙ ХОРОШО, ***ВО И САМО ПОЛУЧИТСЯ».
В общем, если вы решили встать на усыпанный гвоздями и алмазами путь веб-разработчика, нужно иметь огромную силу воли, самодисциплину и постоянно прокачиваться в проф. плане. Еще лучше, если вы посвящаете обучению хотя бы пару часов в день.
Как стать фронтенд-разработчиком: детальный роадмап для начинающих
Рассказываю о том, с чего начать изучение программирования, чтобы стать фронтенд-разработчиком, пишущим сайты и приложения на JavaScript.
Предисловие
Обычно подобные инструкции и роадмапы начинаются с такого обширного понятия, как интернет, а от него отходят в разные стороны ветви с вопросами: «Что такое HTTP?», «Как работает интернет?», «Что такое доменное имя?», «Что такое браузер и как он работает?».
Но давайте начистоту: если вы задумываетесь о том, чтобы стать фронтенд-разработчиком, то вы 100% имеете представление о браузерах и их назначении, а вникать в технические особенности DNS-серверов на ранних этапах необязательно. Поэтому в этом роадмапе будет меньше теории и больше практики.
И еще момент. В этой статье предполагается, что вы умеете создавать файлы в текстовом редакторе и знаете английский на уровне B2. Придется много читать на иностранных ресурсах и работать с программами в духе Sublime Text или VS Code.
Этап 1: Верстка HTML
Начинать будем с верстки, то есть создания структуры страницы. Некоего скелета для будущего приложения или веб-ресурса.
Перед тем как лезть в изучение JavaScript, нужно сделать пару статичных страничек и придумать юзкейсы для будущего программного кода. Это важно, потому что, начав с JavaScript (или любого другого языка), многие разработчики теряются из-за тотального погружения в логические задачки и нехватки фантазии. Потенциальные фронтендеры попросту не осознают, как применить полученные знания на практике.
Наличие сверстанной страницы частично решает эту проблему, позволяя работать с «реальными» объектами разработки, а не просто решать логические задачки и общаться с голой математикой (оставьте это бэкендерам).
Заодно вы освоите навыки по созданию классов и правильному оформлению HTML в соответствии с правилами валидаторов. Это будет полезно и при стилизации сайта, и при добавлении логики в приложение.
Так что учим семантику HTML, запоминаем базовые теги и принципы оформления блоков с текстом, изображениями и другим контентом. Учимся подключать внешние документы (с программным кодом и стилями) и т.п.
Используемые технологии:
Ссылки:
Этап 2: Стилизация при помощи CSS
Следующим этапом станет освоение CSS – каскадной таблицы стилей, отвечающей за расположение объектов на странице и их внешнее оформление.
Суть в том, что в пределах HTML все файлы и блоки текста следуют друг за другом сверху вниз, а шрифты и цвета соответствуют тем, что по умолчанию выставлены в браузере. Если применить CSS, то расположение и внешний вид элементов на странице можно изменить.
Нужно выучить основы оформления стилей и применить их к элементам в HTML-файле, научиться корректно располагать их по отношению друг к другу и сделать так, чтобы сайт был адаптивным для всех разрешений экрана.
Используемые технологии:
HTML с классами и ID
Полезные ссылки:
Подробный гайд по Flexbox и лучший гайд по Grid
Этап 3: Базовые аспекты JavaScript
Теперь перейдем к настоящему языку программирования (до этого были языки разметки). У нас на руках уже есть статичные стилизованные страницы, теперь мы можем придумать, что с этими страницами сделать (добавить интерактива, кнопок и т.п.).
Сначала придется учить JavaScript в отрыве от HTML и CSS, чтобы понять, как работает программирование в целом и JavaScript в частности. Надо ознакомиться с типами данных, понять, что такое консоль, редакторы кода, переменные, операторы и т.д.
Обучение может проходить параллельно в двух направлениях:
Чтение учебников, изучение алгоритмов и проверка своих навыков в сервисах наподобие Codewars. Тут вам поможет ресурс Javascript.info и куча полезных книжек в духе «Грокаем алгоритмы».
Работа над собственным сайтом. Надо придумать какой-нибудь алгоритм. Пусть это будет даже простенький калькулятор, главное, чтобы это было нечто свое, что можно «пилить» по ходу самообразования. Тут вам поможет Google и Stack Overflow.
Используемые технологии:
Полезные ссылки:
Этап 4: GitHub и пакетные менеджеры
Во многих школах по изучению JavaScript и программирования в целом этот этап становится первым. Но на онлайн-курсах в этом есть необходимость (нужно проверять задания и где-то хранить код). Я же решил перенести этот этап сюда, потому что работать с git трудно. Он запутанный, и пока в нем не освоишься, все дико раздражает. Если начать с git, то может и вовсе пропасть желание работать с кодом.
Но совсем без git нельзя. Важно где-то хранить код и контролировать версии приложения, чтобы каждый этап разработки был «задокументирован».
А еще нужно научиться работать с менеджерами пакетов, потому что мы начнем скачивать уже готовые модули для ускорения разработки или для добавления новых функций, которые слишком сложны для самостоятельной реализации.
Так что наберитесь терпения и вперед читать git-how-to.
Используемые технологии:
Менеджер пакетов npm (или yarn)
Полезные ссылки:
Этап 5: Вспомогательные инструменты
Я в одну главу объединил несколько очень полезных, но необязательных вещей, которые понадобятся для работы с JavaScript, CSS и HTML. Эти инструменты сделают код в разы качественнее и надежнее.
Бандлер – это программа, собирающая несколько частей программы в единый проект, попутно обрабатывая код, добавляя в него какие-то свойства и минимизируя его.
Prettier – утилита, которая автоматически корректирует форматирование страницы, чтобы код выглядел симпатично и аккуратно.
ESLint – плагин, заставляющий программиста писать код в соответствии с определенными правилами (например, используя только современный синтаксис).
TypeScript – позволяет обозначать тип используемых в коде данных, чтобы избегать ошибок типизации и сделать код гораздо более надежным.
DevTools – браузерные инструменты, которые упростят верстку и позволят проверять гипотезы в отношении CSS, не покидая браузер.
Хочу стать frontend разработчиком: базовые знания и план обучения
Авторизуйтесь
Хочу стать frontend разработчиком: базовые знания и план обучения
Итак, друзья, вы решили встать на путь программирования? Жму руку, это решение изменит вашу жизнь. Это всегда интересная и востребованная работа на стыке интеллекта и творчества, работа о том, как принести пользу людям, сделать мир чуточку лучше. Возможности реализации в ней бесконечны.
В программировании много разных областей: веб-разработка, мобильная, десктопные приложения, разработка ОС, драйверов для железа. Веб-разработка — одна из самых интересных и востребованных областей. К её плюсам можно отнести то, что ваш продукт лежит в Интернете, и чтобы его увидеть, достаточно набрать адрес в браузере любого устройства, не нужно ничего качать и устанавливать. К тому же, с помощью современных инструментов, зная веб, можно разрабатывать сразу и мобильные, и десктопные приложения. Веб состоит из frontend (то, что видит клиент в браузере) и backend (серверная часть, занимается хранением, обработкой и выдачей данных). Я предлагаю начать знакомство с вебом именно с фронтенда.
Да, кстати, меня зовут Роман Латкин, я почти 10 лет варюсь в веб-разработке. Когда я начинал, всё было одновременно просто и сложно. Просто, потому что для построения приложения много знать было не нужно: вот HTML, немного CSS, чуть-чуть JavaScript — и готово. Сложно, потому что разработка велась через боль. Сейчас множество этой боли вылечено с помощью громадной экосистемы инструментов, но она очень пугает новичков, они не знают, как подступиться к фронтенду, с какой стороны подойти. Мне повезло, я наблюдал развитие фронтенда почти с начала, и у меня в голове всё неплохо уложилось. И я хочу в помощь начинающим разработчикам передать это понимание. Надеюсь, после прочтения этой статьи, вы будете чётко знать, каким путём идти, куда копать и по какому плану развиваться.
Три составляющих фронтенда
25–27 ноября, Онлайн, Беcплатно
Если вам придётся как-нибудь вручную использовать эти средства, чтобы сделать более-менее сложный проект, то вам предстоит испытать много боли. К счастью, мир развивается, сложные вещи упрощаются, люди придумывают всё новые и новые инструменты и технологии, которые делают этот созидательный процесс более приятным и быстрым.
Любой процесс познания можно представить в виде буквы «Т», где горизонтальная линия — широкое понимание, вертикальная — глубокое. У идеального специалиста буква Т большая и красивая, равномерная. Если она вытянута в одну сторону, она некрасива, уродлива; такой специалист мало полезен в боевых делах. Он может либо глубоко разбираться в чём-то одном, но чуть шаг в сторону, и он непригоден; либо поверхностно разбираться во всём, но при этом ничего не уметь. В первую очередь необходимо максимально развить широкую составляющую, чем мы сейчас и займёмся — постараемся максимально широко охватить все аспекты фронтенда, не углубляясь. А потом вы займётесь углублением, которое останется вам на самостоятельную работу.
Чтобы хорошо представлять причины текущего положения вещей, нужно хотя бы чуть-чуть знать историю пути развития фронтенда, да и вообще веб-приложений в целом. Инструментов сейчас столько, что не только новичок, сам чёрт ногу сломит. Поэтому, чтобы в этом всём хорошо ориентироваться, начнём именно с истории, с короткой экскурсии, как всё начиналось, а затем плавно перейдём к современным подходам.
Первые сайты
Вначале люди писали на чистом HTML, рисовали внешний вид на чистом CSS, делали логику на чистом JavaScript. Типичное старомодное приложение — это когда серверная логика генерирует HTML (отвечая на запрос посетителя, сервер берёт данные из базы данных и вставляет их в HTML) и отдаёт его вместе со статическими файлами стилей и клиентской логики на JavaScript, которой в то время (около 10 лет назад) было немного. При совершении перехода на другую страницу весь этот процесс повторялся. То есть раньше как такового разделения на фронтенд и бэкенд не было, было одно цельное приложение, которое одновременно и работало с базой данных, и генерировало HTML.
jQuery
Писать на чистом JavaScript надоедало и появился хороший инструмент — jQuery, который с помощью удобного синтаксиса позволял обращаться к элементам страницы и выполнять с ними какие-то действия. Появлялись различные плагины, готовые решения, стало проще и интереснее.
Но приложения развивались, объём клиентской логики рос, и постепенно всё это превращалось в большую лапшу. Чтобы её распутать, нужна была какая-то форма, архитектура.
Умные Парни попробовали перенести на фронтенд архитектурный шаблон с серверной части — MVC (модель-представление-контроллер). Этот шаблон диктует правило, что есть модель, которая описывает данные. Например, модель пользователя, модель фильма, модель отзыва. Есть контроллер, который обрабатывает запросы, например «показать по такому-то адресу страницу со списком фильмов». И есть представление, которое отвечает за отображение данных в HTML, в которое контроллер передаёт готовые данные, полученные из базы данных/API.
Здесь началась история single page application, SPA — приложений, которые загружаются один раз, а затем при переходе по страницам обращаются к серверу за данными по API. Этот подход называется AJAX. Вместо того, чтобы генерировать HTML на стороне сервера, сервер отдаёт клиентскую логику приложения один раз. Переходя на другую страницу, например с главной страницы на страницу поиска отелей, приложение запрашивает с сервера данные в чистом виде (к примеру, информацию об отелях), без тегов HTML (как правило в формате JSON), и самостоятельно генерирует представление.
Шаблон MVC на фронтенде был хорош, прекрасно работал, но было излишне сложно. Angular, Backbone — представители этой вехи истории. Они, к слову, живут и сейчас, но я в них глубоко не разбирался.
Процессоры и сборщики
Приложения начали расти в размере, и тут пришло время рассказать о сборщиках, препроцессорах и пакетных менеджерах. Постараюсь вкратце по ним пробежаться, несмотря на то, что они заслуживают отдельной статьи.
В вебе важна скорость, поэтому нельзя просто так отдавать посетителю большие файлы, они будут идти по сети слишком долго. Поэтому все ресурсы сжимаются с помощью разных минификаторов. JavaScript чаще всего с помощью uglify (он удаляет пробелы, делает названия переменных короче и ещё много чего интересного). В CSS удаляются пробелы и могут ещё объединяться некоторые свойства. И всё это собирается в один или несколько файлов вместо 10-20, один файл скачать гораздо быстрее, и на сервер нагрузка меньше.
Что касается CSS, появлялись так называемые препроцессоры. Они расширяют синтаксис CSS, добавляют туда кучу разных возможностей — вложенные блоки, переменные, циклы. Даже просто отсутствие точек с запятой очень помогает и ускоряет написание кода?.
Препроцессор — это такая программа, которая запускается и компилирует этот сахарный синтаксис в чистый CSS. Использование препроцессоров позволяет избежать повторного использования кода, выстраивает архитектуру, и по сути превращает язык описания стилей в язык программирования. Изучите какой-либо инструмент, и вы поймете. Я для себя сейчас выбрал Stylus; есть ещё несколько, например — LESS, SASS.
Чуть позже придумали постпроцессоры. Они, в отличие от препроцессоров, обрабатывают уже готовый CSS, модифицируя его: например, добавляя дополнительные свойства к уже существующим, или изменяя названия классов, делая их уникальными, чтобы ничего не сломалось. Их чаще всего используют для поддержки кроссбраузерности, о которой мы ещё поговорим ниже. PostCSS — вот этот самый постпроцессор, он ещё обладает большой библиотекой плагинов, упрощающих жизнь.
JavaScript
Насчёт JavaScript: исторически так сложилось, что этот язык изначально был слишком простой и сейчас постоянно развивается, обрастая новыми инструментами. Основная его версия, которая работает во всех современных браузерах, называется ES5. В 2015-м году появился усовершенствованный стандарт JavaScript ES2015, или ES6, который даёт много новых инструментов упрощённого описания логики. Только он не работает в старых браузерах, поэтому используют препроцессор Babel для компиляции его в ES5. То есть код пишется с помощью современного синтаксиса ES6, а для работы в браузере сразу компилируется в ES5.
Есть ещё разные способы писать нормальный код, которые сводятся к тому же: код пишется на своём «особом» языке (как в случае с ES6), а потом транслируется в JavaScript. Вот некоторые из этих «особых» языков программирования:
Чтобы удобно вставлять динамические данные в HTML, отделяя данные от разметки, придумали шаблонизаторы. Например, в разметке пишется
Менеджеры пакетов
Чтобы не изобретать велосипеды, разработчики давно научились делиться между собой готовыми участками кода, модулями. Во фронтенде для этого активно используется менеджер зависимостей npm. На npmjs.com можно найти огромное количество модулей, плагинов, библиотек на все случаи жизни. Прежде чем писать что-то своё, поищите там.
Позже появился усовершенствованный менеджер зависимостей Yarn, он делает всё быстрее и стабильнее, не буду сейчас углубляться, почему.
Менеджеры задач
Для того, чтобы централизованно управлять всем этим зоопарком, появлялись менеджеры задач. Они позволяют в одном месте описать все процессы и этапы сборки приложения. Это Grunt, Gulp, Webpack. Последний — наиболее подходящий для сборки веб-приложения. Он может взять на себя много забот, легко и просто компилировать все ресурсы, будь то скрипты, стили, разметка, картинки — в любом формате (Stylus, Less, Sass, ES6, TypeScript, jpg, png) из любых исходников — в единые бандлы, сборки файлов js, CSS, HTML, которые будут работать в браузере.
Компонентная архитектура
Итак, можно продолжить: сложное начали упрощать, и в ходе упрощения, большого упрощения, Умные Парни решили — всё есть компонент. Кнопка — это компонент, шапка — компонент, выбор города — компонент. Страница — тоже компонент. Компонент может содержать в себе другие компоненты. Получилось крайне просто: такая концепция, как оказалось, пришлась как родная к построению клиентских приложений.
Что такое компонент? Это самостоятельный и независимый участок разметки со своей логикой и стилями. У компонента есть свое текущее состояние. Открыто ли меню, активна ли вкладка, и т.п. Состояние всего приложения можно представить как дерево состояний различных компонентов.
Разметка HTML зависит от текущего состояния, изменилось состояние — изменилась разметка. Это реализуется с помощью технологии Virtual Dom — когда DOM (дерево HTML-элементов страницы) рассчитывается сначала виртуально и в конце расчёта отображается в реальном DOM, в разметке. За счёт этой идеи достигли более высокой производительности приложений, ведь одна из самых тяжёлых частей работы браузера — операции с DOM (работа с деревом объектов HTML).
Здесь важно ввести ещё одно понятие — реактивные приложения. Это, упрощённо говоря, когда вместо прямого изменения DOM/Virtual Dom при изменении данных, вводится объект состояния, модель данных, и на её изменения подписывается обработчик, который уже меняет DOM. То есть чтобы что-то поменять в представлении, HTML (например, таблица со списком пользователей), нам достаточно изменить свойство модели (добавить в массив нового пользователя), всё остальное произойдет само (пользователь появится в html-таблице). Вы, наверное, замечали, что некоторые сайты медленно работают, а другие молниеносны. Скорее всего, первый на jQuery и работает с реальным DOM, второй — на одном из реактивных инструментов, с которыми мы познакомимся далее.
React
Итак, эти концепции (Virtual Dom, компоненты, реактивность) улеглись в новом инструменте создания клиентских приложений от Facebook — React. На текущий момент он является одним из лидеров индустрии, наиболее часто используемым во фронтенде. Он обладает развитой экосистемой — можно найти огромное количество готовых компонентов и дополнений.
Управление состоянием
Но между компонентами нужно было наладить связь, им нужно общаться между собой. Нажали на кнопку — изменился цвет. Можно строить эту взаимосвязь напрямую, но это быстро может превратиться в кашу. Тут придумали шаблон централизованного управления состоянием, когда есть одно место, где хранится состояние всего приложения в текущий момент времени. Это, сильно упрощая, такой JavaScript-объект со свойствами. Это состояние изменяется с помощью вызова действий и мутаций, но не будем сейчас так углубляться. Паттерн называется Flux. Самая популярная имплементация управления состоянием для React — Redux.
Vue.js
Тут появился Vue.js — гибкий, эффективный и простой в освоении веб-фреймворк, который несёт в себе всё те же концепции, но они в нём выглядят гораздо удачнее. Он объединил в себе всё лучшее из Angular и React, более чётко ответил на вопрос «что есть что». Из коробки Vue содержит уже большое количество инструментов и возможностей, которые в несколько строк позволяют писать объёмную логику. Разработка значительно упростилась.
Vue принёс ещё несколько интересных концепций, как, например, однофайловые компоненты — файлы, которые содержат в себе сразу логику, разметку и стили, и они там не переплетаются, как в случае с React и JSX. Vue из коробки позволяет использовать любые препроцессоры, которые очень органично вписываются в однофайловые компоненты. И имеет множество готовых встроенных решений, даже свою имплементацию Flux. Vue обладает отличной документацией на русском языке, которая научит вас лучшей практике во фронтенде, от сборки приложения до автотестов.
Изоморфные приложения, SSR
В разговоре об одностраничных приложениях мы упустили одну важную деталь: когда поисковый робот обращается к одностраничному приложению, он ничего не видит — только пустую страницу с тегами body без контента. В старомодных приложениях сервер обратился бы к базе данных, сгенерировал представление и отдал бы готовый HTML с текстом страницы. В случае с одностраничным приложением сервер отдаёт пустую страницу, которая лишь после инициализации подтягивает данные и показывает представление, чего конечно же поисковый робот не сделает. Таким образом, использовать одностраничные приложения для сайтов, ориентированных на контент, SEO, недопустимо.
Это недопущение обходилось множеством хаков и костылей, пока не появилась концепция SSR — Server-Side Rendering. Умные Парни научили весь JavaScript, который работал в браузере, выполняться на сервере с помощью NodeJS (технология создания серверных приложений с помощью браузерного языка JavaScript). Это, конечно, ввело свои ограничения, но жить стало легче. Теперь можно было написать логику один раз на одном языке, и она сразу же работала и на сервере (при первом обращении посетителя/робота генерировался HTML с контентом страницы) и в браузере (последующие переходы посетителя). Это и называется изоморфное, универсальное приложение.
Схема простая: при первом заходе посетитель отправляет запрос на сервер NodeJS, который обращается к API-серверу, берёт данные в виде JSON и отрисовывает их в HTML, возвращая посетителю. Дальше уже приложение живёт в браузере, при последующих переходах по страницам оно напрямую обращается к API-серверу за данными и уже непосредственно в браузере отрисовывает представление.
В React имплементация этой схемы делается разными и сложными путями. В качестве готовых решений есть для этого, например, фреймворк Next.js. В документации Vue есть целый раздел, посвященный SSR. Там указан фреймворк Nuxt — Vue + SSR. С его помощью можно довольно легко писать такие универсальные приложения.
CSS-фреймворки, адаптивность
Теперь мы сменим тему на попроще и поговорим о вёрстке.
В настоящее время всё упрощается, уже почти все браузеры поддерживают Flexbox и CSS Grid — современные удобные способы верстать сетку страницы. Их умелое сочетание позволяет в несколько свойств добиваться таких положений контейнеров, над которыми пришлось бы старыми методами изрядно попотеть, позволяя с лёгкостью выполнить практически любые дизайнерские изыски.
Адаптивность — это способность страницы выглядеть одинаково хорошо на всех устройствах, будь то ноутбук, планшет или мобильный телефон. Адаптивность достигается с помощью медиа-запросов — блоков условий в CSS, при каких разрешениях экрана какие CSS-свойства должны работать. Её можно также добиться с помощью умелого применения flexbox-контейнеров.
Все веб-приложения в основном типичны, состоят из строк, колонок, таблиц, кнопок и других UI-элементов. Чтобы не писать их каждый раз, в помощь сайтостроителям создавались CSS-фреймворки, где вся разметка уже продумана — достаточно применить нужный класс. Они содержат в себе множество готовых UI-элементов. Самый популярный — конечно же Bootstrap, сейчас уже 4-я версия. Есть ещё Bulma, тоже довольно хороший. И ещё множество менее популярных. Обычно в CSS-фреймворках адаптивность идёт из коробки, важно лишь правильно пользоваться предлагаемыми инструментами. CSS-фреймворки станут отличной основой практически в любом вашем веб-приложении и хорошим началом освоения навыков правильной вёрстки. Их стоит использовать, когда нужны типичные элементы пользовательского интерфейса, адаптивность, а это 99% кейсов в вебе.
Кроссбраузерность
Методологии
Чтобы вёрстка не превратилась в суп, ничего внезапно не ехало, всё было чётко и красиво — существуют специальные подходы, сборники правил о том, как называть тот или иной класс. Они очень вписываются в компонентную архитектуру, надо сказать, с них она и началась. Правило то же — всё есть компонент, или по-другому «блок». У блока есть свои элементы, мини-блоки, из которых и состоит блок. Изменяют отображение блока модификаторы, применяя к нему то или иное свойство. Изучите БЭМ от Яндекса или SUIT CSS, прежде чем начинать заниматься верстанием.
В путь!
Надеюсь, к концу статьи у вас уже сложилось более-менее полное и широкое понимание всех аспектов фронтенда. Теперь вам остаётся лишь его углублять, следуя шаг за шагом. Предложу вам план этих шагов, как стать профессиональным фронтендером:
Готово! Дальше только практика, вернее, она должна была начаться с первого пункта, а сейчас достигнуть своего апогея. Теперь вы мастер фронтенда! Хотя кто знает, может, к тому времени опять выйдет в свет какой-нибудь инструмент, который всё перевернёт во фронтенде, и придётся полностью менять свои понимания?
Глубоко в каждой теме не закапывайтесь, не старайтесь всё сразу запомнить. Главное — помнить, где и что посмотреть. Никогда не будет лишним повторить основы. Полезно общаться в комьюнити и желательно иметь живого, пусть даже удалённого, наставника, который поможет направить в случае застоя. Помните, что лучшее понимание приходит в процессе решения задач.