От идеи до релиза. Детальный опыт фронтенда Маркета / Яндекс corporate blog / Habr
Всегда хочется придумать что-то новое и нужное в своём сервисе. Особенно, если этот сервис любят пользователи. Но откуда брать идеи? Как выделить приоритетные? И как быстро довести идею до продукта, не потеряв ничего важного по пути?
Меня зовут Александр, я руковожу одной из групп разработки интерфейсов в Яндекс.Маркете. Сегодня я расскажу читателям Хабра о нашем опыте решения этих задач. Также рассмотрим пример доставки фичи в продакшн.
Команда
Яндекс.Маркет — крупнейший в России ресурс подбора товаров и сравнения цен. Каждый день им пользуются 3,5 миллиона человек — они планируют здесь свои будущие покупки, обсуждают товары и помогают другим людям сделать правильный выбор.
Сейчас в Яндекс.Маркете работают 40 фронтенд-разработчиков, и их число растёт. Да-да, 40 человек — это только фронтенд Маркета, а ведь есть ещё и фронты двух других наших проектов — маркетплейсов Беру и Bringly. В 2005 году в Маркете было всего 5 разработчиков, представляете?
Идеи рождаются в наших контурах. Так мы называем команды, состоящие из разных специалистов. Обычно в контур входят: проджект (он же продуктолог), бэкендеры, фронтендеры, аналитики, дизайнеры и тестировщики. Такая команда может самостоятельно развивать что-то в сервисе и решать задачи любой сложности. При этом у каждого контура есть чёткий периметр ответственности — некий «контур функционала» в продукте, над которым он работает.
У нас есть, например:
— контур коммуникаций — работает над рассылками и акциями для наших пользователей;
— контур выгоды — занимается скидками, кэшбеком, промокодами;
— контур комьюнити — отвечает за отзывы, обзоры, обсуждения, ачивки, игровые механики и прочий UGC.
Идеи
Идею может предложить любой член контура. Мы приветствуем все варианты, даже банальные или абсолютно сумасшедшие. Обычно ребята генерируют идеи на общих встречах — это заряжает на работу всю команду.
Чтобы ничего не потерять, все мысли мы заносим в отдельную очередь в Трекере — наш банк идей. Собранные идеи проходят оценку по фреймворку GIST + ICE. Мы оцениваем потенциал каждой идеи и трудозатраты на реализацию, чтобы решить, за что стоит браться в первую очередь. Подробнее об этом методе рассказал мой коллега.
Идеи, набравшие больше всего очков, превращаются в проекты с заказчиком и исполнителями. В Трекере появляется развесистый набор проектных задач. Задачи распределяются тим-лидом контура по спринтам и поступают в работу команде.
Важный момент заключается в том, что идею реализует контур, который её предложил. То есть авторы идеи являются и её исполнителями. Попробуйте поработать над своей задачей, а не над задачей, спущенной сверху — разницу будет легко почувствовать.
Процесс
Допустим, мы решили разработать карусель товаров для пользователя с учётом его интересов.
Предположим, что бэкендеры контура уже сделали свою работу, нейросеть обучена, API готов, проверен и развёрнут в тестовом окружении. Макеты от дизайнера контура получены и выглядят как-то так:
Осталось сделать работу на фронтенде и доставить нашу карусель пользователю.
Фронтенд Маркета представляет собой web-клиент и stateless NodeJS-сервер, за которым расположены десятки других бэкендов: поиск, рекомендательные сервисы, аналитика, UGС-контент и прочее. Фронтенд живёт в облаках Яндекса в нескольких ДЦ. NodeJS-приложение исполняется в контейнерах, а благодаря его stateless-природе его можно масштабировать горизонтально как нам нужно:
Фронтендеры Маркета разрабатывают и серверную часть — на NodeJS, и клиент — на React + Redux. Вести разработку на одном языке и в одной экосистеме — очень эффективно. Если вы ещё думаете над унификацией своего стека технологий между сервером и клиентом, попробуйте — в этом есть смысл.
Чтобы доработать карусель, нам нужно дописать код получения товаров на сервере и реализовать клиентскую часть. Можно сделать карусель ленивой — загружать её перед самым появлением на экране. Для этого придётся дополнительно реализовать endpoint в клиентском API.
Когда это сделано, разработчик создаёт пул-реквест и отправляет свой код на код-ревью. Код-ревью у нас является обязательным процессом. Чтобы он не зависал, у нас даже есть рекомендованный SLA на его проведение. О том, как мы ускоряли код-ревью, можно почитать здесь.
Разработку фронтенда мы ведём на GitHub Enterprise, доступном только во внутренней сети. На нашем Github живёт бот, который помогает организовать ревью кода. Бот сам находит ревьюеров, связывается с ними в мессенджере, добавляет их на GitHub, управляет статусом тикета в Трекере и, если нужно, призывает автора кода.
В момент создания пул-реквеста на GitHub происходит очень многое: в тестовом окружении поднимается демо-стенд с обновлённым Маркетом, а в тикет задачи доставляются ссылки доступа к этому стенду. Проходит масса автоматизированных проверок: линтеры, форматеры, unit-тесты. Прогоняются E2E-тесты, автоматически анализируются клиентские метрики приложения. Если обнаруживается какая-либо деградация, детальный отчёт о ней сразу же доставляется в тикет задачи:
Если все проверки прошли штатно, тикет автоматически переводится в статус «Можно проверять», и задача появляется на дашборде у QA-команды.
После того, как в тикет задачи пришёл QA-инженер и убедился в том, что новый функционал готов к дальнейшему путешествию, тикет помечается тегом релиза. В следующий релиз попадут все тикеты с этим тегом.
Маркет релизится часто, 1-2 раза в день, и мы работаем над увеличением частоты наших релизов. Подготовкой и выпуском релиза занимается дежурный из команды QA, а процесс релиза полностью автоматизирован. Раньше релизный пакет собирался руками, это занимало много времени. Сейчас разработчики могут потратить это время на развитие продукта. Это ускоряет доставку нового функционала к нашим пользователям.
Итак, наша карусель рекомендованных товаров едет в релиз. Как это происходит?
Дежурный QA-инженер жмёт релизную кнопку. Начинает работать релизный пайплайн. Презентацию доклада о релизных процессах можно посмотреть здесь. В Трекере создаётся релизный тикет, а на GitHub — релизная ветка. В неё автоматически вливаются все пул-реквесты, прошедшие проверки. В тестовом окружении поднимается стенд с новой версией Маркета. На этом стенде проходят все упомянутые выше автоматизированные проверки плюс масса дополнительных. Например, нагрузочное тестирование постоянной нагрузкой и нарастающей до разладки тестируемого приложения. Все логи проверок анализируются на лету, формируются понятные отчёты, которые сразу же доставляются в релизный тикет:
QA-инженер видит все стадии, одним взглядом может оценить результаты массы проверок. В тестовом окружении на стенде с новым релизом QA проходит и ручное тестирование. Мы часто проводим A/B-тестирование нового функционала и не пишем на него E2E-тесты.
Так выглядит релизный пайплайн (кликабельно):
Когда релиз прошёл все проверки в тестовом окружении, он доставляется в престейбл. Престейбл — ещё одно окружение, но уже с боевыми бэкендами, закрытое от реальных посетителей Маркета. В некоторых компаниях его называют стейджингом. В этом окружении тоже проходит серия специфичных проверок и ручное тестирование функционала. Если проблем не обнаружено, новая версия Маркета отправляется к нашим пользователям, начинает раскладываться по продакшн-кластеру.
В момент раскладки на бой работа роботов продолжается. Они самостоятельно анализируют логи приложения, ищут в работе сервиса аномалии и деградации, следят за клиентскими метриками. Мониторинг логов продолжается ещё некоторое время после релиза, а в тестовом окружении уже проходит проверки следующая версия Маркета.
За здоровьем Маркета после релиза следит и сам дежурный QA. В его распоряжении большое количество графиков — мы используем Graphit и Grafana. На графиках есть всё: от общего фона 500-к до ошибок NodeJS-приложения при общении с различными бэкендами в разрезе по ДЦ. У нас также есть и отдельная группа людей — группа здоровья Маркета. Она 24/7 следит за метриками боевого кластера Маркета.
Если обнаружена проблема, релиз в автоматическом режиме откатывается с боевого кластера. Проблему разбирают и релиз возвращают в бой. Если же проблем нет, релиз завершается, код вливается в master, попавшие в релиз тикеты закрываются, а проектные ветки удаляются. Всё это также происходит автоматически.
В этот момент наши пользователи уже видят подобранные для них товары, а контур работает над новой идеей.
Вот так выглядит наша карусель на сервисе:
Вместо заключения
Делайте ваши команды гибкими и самостоятельными, позвольте им генерировать идеи, берегите эти идеи, анализируйте их — среди них точно есть алмазы. Помните, что идея, высказанная чьим-то неуверенным тихим голосом во время встречи, может стать ключевой для вашего продукта и его пользователей.
Пусть идеи по возможности воплощают их авторы — так работа идёт быстрее и качественнее. Автоматизируйте рутину. Тратьте время на воплощение идей в жизнь, остальным пусть займутся роботы.
Если читателю интересно поговорить о чём-то более подробно, пишите в комментариях, я с удовольствием отвечу, а может быть опишу это в новой статье.
многообразие фреймворков и недостаток миддлов / Конференции Олега Бунина (Онтико) corporate blog / Habr
Frontend — довольно конкурентная среда. Здесь легко начинать карьеру, но сложно перейти в разряд middle. Вдобавок возникает вопрос, в каком направлении развиваться, если каждый день появляются новые фреймворки и темы для холиваров?
— Что для тебя frontend?
— Для меня frontend — это не только JavaScript, но и верстка интерфейсов. Ко всему, что не касается хардкорного программирования, зачастую формируется несколько снисходительное отношение. Но без решения таких задач не будет никаких сайтов (как и без бэкенда). Я как раз в большей степени отвечаю за интерфейсную часть, в частности за верстку, а не за хардкорный JavaScript.
— Что сейчас происходит в этом сегменте?
— Все составляющие фронтенда сегодня очень активно развиваются. Существует огромное количество фреймворков и подходов к решению задач. В последние годы этот «зоопарк» уже достигает абсурда — люди начинают выбирать технологии просто потому, что у них больше звездочек на GitHub. В решении технологических задач весомую роль начинает играть понятие моды (в первую очередь, на названия тех же фреймворков). Но такова отрасль. Во фронтенде только один язык — JavaScript. Мы, в отличие от бэкенда, не можем пользоваться другими языками (у них есть PHP, Python, Ruby; они могут использовать Node.js как серверный язык программирования и тому подобное). И нам приходится разрабатывать надстройки — фреймворки, позволяющие писать на JavaScript проще и лучше.— Многообразие фреймворков — одна из базовых особенностей фронтенда?
— Мне кажется, да. Но сложно говорить, хорошо это или плохо. Мы же никогда не жили с фронтендом, для которого есть несколько языков или только один фреймворк. Возможно, если бы выбор был меньше, с разработкой было бы проще, потому что весь сегмент общался бы на одном «наречии». Но с точки зрения сообщества множество интересных мнений по разным фреймворкам — это даже хорошо. Есть о чем поговорить.
Раз фреймворки появляются, а люди переходят с одного фреймворка на другой, отталкиваясь не от моды, а от своей задачи (бизнесу ведь всегда нужно обоснование таких преобразований), значит все это многообразие действительно кому-то нужно.
— А ты сам сталкивался с необходимостью перехода с одного фреймворка на другой?
— Почти. На предыдущем месте работы мы в какой-то момент просто уперлись в производительность. Изначально все было написано на нативном JavaScript, но с выходом очередной фичи мы поняли, что дальше развивать продукт на этом ядре мы не можем. Инициировали диалог с руководством, объяснили, во что уперлись; что должны сделать, чтобы решить проблему, как именно это поможет. В итоге все ядро переписали на React. Все заняло примерно три-четыре месяца при мне и еще около полугода после моего ухода, и в конечном счете стоило затраченных усилий.
— Заметны ли какие-нибудь тенденции в развитии фреймворков в целом?
— Честно говоря, я не слежу за мелкими фреймворками. Из крупных у нас были Angular и React; появился Vue. Поначалу к нему отнеслись скептически, но потом он начал набирать популярность. Если бы все, кто его изучал, сейчас писали бы именно на Vue, у этого фреймворка была бы самая большая доля на рынке.
Но другие фреймворки тоже не стоят на месте — выходят новые версии. Плюс на рынке остается огромное количество старых фреймворков и библиотек, которые до сих пор используются.
Мне кажется, в ближайшее время три лидера будут между собой бороться за рынок. Однако это не означает, что завтра не возникнут обстоятельства, в результате которых появится новый фреймворк или придется отказаться от одного из старых. Frontend — достаточно нестабильное поле.
— А какой фреймворк ты сам предпочитаешь?
— Высказывать личные предпочтения по поводу использования того или иного фреймворка можно, попробовав как минимум и Vue, и React, и Angular. Я писал только на React, поэтому не могу говорить объективно.
— Как развивается сегмент с точки зрения кадров? В какую сторону, условно говоря, ветер дует?
— Активно развивается верстка в целом. Специалисты становятся лучше, они больше углубляются в UI/UX — в этом смысле мы движемся в сторону Запада, где зачастую нет выделенного верстальщика, а есть дизайнер, который разрабатывает интерфейсы с точки зрения UI/UX, и есть frontend-разработчик, создающий логику.
Бывает также, что эти функции совмещает один человек. Но пока в большинстве своем у нас наблюдается иное разделение — на рынке достаточно много верстальщиков и frontend-разработчиков, но мало тех, кто занимается UI/UX (еще меньше тех, кто компетентен во всех трех областях, поэтому они очень дорого стоят).
На мой взгляд, специалистам, которые занимаются версткой, надо больше углубляться в сторону UI/UX, ведь это тоже важная часть интерфейса, как и JavaScript. Лично у меня в какой-то момент произошел дисбаланс, которого теперь я советую избегать. Почти пять лет я занимался фактически только версткой — изучил JavaScript на уровне подключения и использования готовых плагинов JQuery, и мне этого хватало. Так я чуть не потерял связь с фронтендом, превращаясь в простого верстальщика.
Осознав это, я начал развиваться параллельно в нескольких направлениях. И теперь, когда у меня есть свободное время, я продолжаю заниматься UI/UX — хоть на рынке пока мало компаний, которым нужен frontend, совмещенный с UX. Откровенно говоря, развитием надо было заняться раньше.
— Считается, что квалифицированного frontend-разработчика искать чуть ли не сложнее, чем бэкендера. Это так?
— С квалификацией кадров у нас действительно все сложно. Как человек, непосредственно связанный с образованием, могу сказать, что самая главная наша проблема сегодня — нехватка хороших разработчиков уровня middle и выше. Уже сейчас чувствуется, что не хватает сеньоров, и с каждым годом это будет заметнее.
Но источник проблемы — на первых ступенях. Ребята, которые заканчивают обучение, не могут найти работу и получить опыт. Многие из них — потенциально хорошие разработчики, которые через два-четыре года могут дорасти до middle, а через 5-7 лет — до senior. Но джуниора без опыта брать никто не хочет. Всем нужны как минимум middle: из-за отсутствия доверия менее квалифицированным специалистам. А ни миддлов, ни сеньоров у нас не будет, пока мы не начнем выращивать джуниоров (самостоятельно они могут вырасти не совсем правильно). В какой-то момент мы просто упремся в потолок — джуниоры не развиваются, новым миддлам взяться неоткуда, а все хорошие middle уже к тому моменту уже дорастут до сеньоров.
Я считаю, что те, кто отрицает проблему, еще просто не прочувствовали ее на себе. Наш рекрутинг постоянно сталкивается с этим при поиске разработчиков уровня middle и senior. На позицию middle чаще приходят те, чьи навыки больше соответствуют junior. И чем дальше, тем хуже.
— И что делать?
— Мы пытаемся на уровне своей компании предпринимать какие-то шаги. Например, сделали аутсорс по верстке. Ребята, которые окончили наш интенсив, получают от нас задачи и набираются опыта. И впоследствии их охотнее берут на работу.
Но это решение — локальное, в рамках нашего же проекта, и не для всего потока джуниоров. Нам ведь тоже надо продать свои услуги, а когда мы говорим заказчику, что проект будут делать джуниоры, появляются вопросы. В одиночку мы отраслевые проблемы не решим.
— Может, как-то использовать отраслевые мероприятия?
— К сожалению, то, что происходит на конференциях, уместнее назвать монологом. Можно рассказать свою точку зрения, найти отдельных энтузиастов, пообщаться с ними. Но донести мысль до всего сообщества так, чтобы оно начало как-то меняться, — маловероятно.
Я как-то выступал с докладом о новичках — о том, что им надо давать шанс. И мы даже нашли несколько людей, которые взяли джуниоров, запустив проект, помогающий новичкам в поиске работы. Но за год мы решили проблему для 30 — 40 специалистов. То есть получилось очень локальное решение — не масштабов отрасли.
Но об этом можно и нужно говорить, постоянно напоминать, чтобы тебя услышали.
— В чем причина такого «ужаса» перед джуниорами?
— Выращивание специалиста — это затраты. Непонятно, насколько хорошо он будет развиваться. Многие боятся, что как только джуниор вырастет, он уйдет. Но, на мой взгляд, это немного странно, поскольку фронтендеры постоянно меняют место работы. Это уже стало нормой.
Кроме того, боятся потенциальных проблем с качеством. Но, давайте откровенно, половина ресурсов в интернете и так достаточно низкого качества. Это наша общая проблема: и бизнеса, и разработчиков. Мы все вместе тянем веб на дно, когда забываем о том, что надо думать о качестве — и иногда не в угоду бизнесу.
Я не раз вступал в диалог с сообществом на тему того, что джуниорам надо доверять, ведь с каждым годом специалистов становится все больше (объективно порог вхождения во frontend ниже, чем в тот же backend), и им всем надо развиваться.
— Что сегодня необходимо изучить frontend-разработчику, помимо JavaScript?
— JS-разработчикам надо понимать, что они должны уметь верстать. Почему-то многие не любят этого делать, некоторые считают, что это не входит в обязанности frontend-разработчика, но это неправда (в соответствии с названием профессии frontend занимается интерфейсом в целом, а туда входит и верстка, и UX).
На мой взгляд, для JS-разработчика важнее всего понять, что нельзя зацикливаться на одном фреймворке и или начинать изучать JS с фреймворка. Сейчас появились отдельно React-, Angular- и Vue-разработчики и все меньше JS или frontend-разработчиков. Но это тупиковый путь. Мы уже через это проходили — в свое время у нас множились JQuery-разработчики, способные написать 10 тыс. строк кода на JQuery, но не готовые сделать то же самое на JavaScript (хотя по сути JQuery — это просто библиотека, которая помогает быстрее писать на JS).
Надо учить сам JavaScript, тогда любой фреймворк или библиотека станут просто инструментом для написания кода, а разработчик сможет легко переходить из команды в команду с разными стеками.
— А как вы относитесь к развитию специалистов в направлении fullstack-разработки?
— Честно говоря, скептически. Ни в коем случае не хочу обидеть fullstack-разработчиков (я знаю реально крутых специалистов с очень большим опытом работы), но я считаю, что каждый должен быть профессионалом в своей области.
Я занимаюсь версткой почти 10 лет. На данный момент знаю в этой сфере почти все (конечно, есть некоторые вещи, которые я не пробовал, но я знаю о том, что они есть и как их можно применить). И мне немного странно видеть, когда человек с трехлетним опытом работы причисляет себя к fullstack — вряд ли за три года можно изучить все технологии. Квалификация тех, кто занимается этим 15 и более лет, вопросов не вызывает. Но я считаю, что лучше развиваться в чем-то одном, поскольку чем дальше ты движешься, тем ценнее ты как специалист в этой сфере. Хотя на рынке есть те, кому больше нравится именно fullstack; и на таких специалистов есть спрос.
— А что в последний год изменилось во фронтенде технологическом плане?
— Безусловно, появились новые технологии. На прошлой конференции я только рассказывал про CSS Grid Layout, а сейчас он уже полностью принят. Развивается CSS Houdini.
Очень большой рывок сделал Vue. Но пока непонятно, это рывок в популярности или в качестве. Еще год назад на рынке условно выделялись те, кто пишут на Angular или React, и те, кто изучают Vue, теперь же Vue захватывает свою долю рынка, и есть мнение, что через год он полностью его поглотит (знающие люди говорят, что это лучший фреймворк).
Как мне кажется, в этом году важной тенденцией был еще больший отказ от поддержки старых браузеров. В начале года Microsoft «похоронила» Windows Phone 8.1 — последнюю ОС, где единственным браузером был Internet Explorer. Теперь официально нет ОС, в которой не было бы, например, Edge. Это не означает, что все перестали пользоваться IE и перешли на современные браузеры. Однако это важный шаг к убийству старых браузеров, которые на самом деле тормозят отрасль.
Большинство возникающих проблем упираются именно в кросс-браузинг. Они решаемы, но использовать на 100% современные технологии мы не можем именно из-за поддержки старых систем.
— Как в условиях борьбы моды и технологий твой программный комитет отбирает доклады?
— Решению по каждому докладу предшествует достаточно долгое обсуждение темы — в первую очередь, с докладчиком. Мы пытаемся понять, что услышим в итоге: реальный опыт или абстрактные рассуждения. И причину, по которой проблема решалась именно так.
К примеру, доклады о смене фреймворков. У какого-то человека при решении конкретной проблемы возникла потребность в смене фреймворка. Он его сменил и рассказывает, почему, на что и как это решило его проблему. Со стороны программного комитета мы пытаемся добиться от докладчика истины, стараемся максимально раскрыть тему доклада через беседы со спикером и обсуждения внутри программного комитета. Так отбираются только те доклады, которые действительно могут быть интересны публике, а не просто рассуждения на салфетках.
— У каких докладов больше шансов?
— В этом году мы стараемся отказываться от «справочных» докладов. Любой frontend-разработчик должен быть способен самостоятельно зайти на сайт библиотеки в раздел документации, понять изложенное там и начать работать. Конференция концентрирует в себе конкретные проблемы и способы их решения. Она позволяет искать единомышленников и помогать именно на практике. По сути это обучение через опыт.
Вообще программа очень разнородная. Наша задача как раз и состоит в том, чтобы сделать ее максимально интересной для всех, кто имеет отношение к фронтенду. И с каждым годом программный комитет работает все слаженнее, а отбор докладов проходит все жестче.
— Многие доклады на конференцию уже поданы. Можно ли по ним выявить вопросы, которые волнуют отрасль больше всего?
— Сложно выделить какие-то тенденции. Все доклады рассказывают о чем-то новом. Мне не очень понравилось численное превосходство докладов про JavaScript. Да, среди них много действительно хардкорных историй, но я сам ближе все-таки к интерфейсной части, чем к программированию, да и отрасль рассматриваю как взаимодействие всех элементов. Поэтому мне не нравится, что очень мало докладов про CSS, UI/UX, инструменты и т.п.
Есть несколько докладов про рефакторинг, что в принципе необычно. Люди не так часто говорят на эту тему, поскольку этим никто не любит заниматься. Но раз такие темы есть, значит проекты развились настолько, что приходится их рефакторить. И это говорит об уровне развития сообщества.
На западе сейчас очень популярна тема доступности интерфейсов. Об этом будут говорить и у нас. Прошел отбор доклад про то, как делать свой open source-проект — хотя в целом в нашей стране культура open source-проектов развита не сильно.
— Как вы думаете, в какую сторону FrontendConf следует развиваться дальше?
— Мне кажется, надо двигаться в сторону англоязычности. Хотелось бы иметь поток англоязычных докладов и приглашать туда спикеров с европейских конференций, чтобы наше сообщество развивалось в соответствии с мировыми стандартами. Но РИТ++ всегда был больше ориентирован на внутренний рынок, поэтому сложно сказать, нужно ли такое развитие самой конференции.
Друзья, очередной фестиваль конференций РИТ++ состоится уже совсем скоро — 28-29 мая в Сколково. В этом году он объединит в себе FrontendConf, BackendConf, RootConf, WhaleRider, Aletheia Business и съезд русскоязычных IT-сообществ. В общей сложности запланировано более сотни докладов и 35 митапов!
итоги года / RUVDS.com corporate blog / Habr
В 2019 году мир фронтенд-разработки, как уже бывало, развивался с головокружительной скоростью. Материал, перевод которого мы сегодня публикуем, посвящён обзору важных событий, новостей и трендов 2019 года.А вот, кстати, аналогичный материал, опубликованный нами в 2018 году. Там, в конце, есть раздел прогнозов на 2019 год. На наш взгляд, многие из них оправдались. Не обойдётся без прогнозов и эта статья, но не будем забегать вперёд.
О загрузках популярных фронтенд-фреймворков и библиотек из npm
Библиотека React снова забирает пальму первенства и продолжает расти, а jQuery, как ни странно, попала на второе место. Недалеко от лидеров ушли Angular и Vue. Оба эти фреймворка отличаются мощной базой увлечённых своим делом разработчиков. Фреймворк Svelte в этом году пользовался немалым вниманием общественности, но его внедрение идёт пока не особенно активно.
Загрузки фронтенд-фреймворков и библиотек из npm (источник)
WebAssembly становится четвёртым языком веба, присоединяясь к HTML, CSS и JavaScript
После довольно-таки тихого года технология WebAssembly, в начале декабря, оказалась у всех на слуху. Дело в том, что она официально рекомендована для веб-разработки W3C. W3C (World Wide Web Consortium) — это центральная международная организация, занимающаяся стандартизацией веб-технологий.
Технология WebAssembly, с момента её появления в 2017 году, привлекает к себе всеобщее внимание. Многие ей уже пользуются. В предыдущие годы вышла спецификация WebAssembly 1.0, поддержка этой технологии была интегрирована во все основные браузеры.
Ещё одна новость 2019 года, касающаяся WebAssembly, связана с формированием Bytecode Alliance. Цель организаций, входящих в альянс, заключается в том, чтобы обеспечить будущее WebAssembly за пределами браузера, совместно работая над реализацией стандартов и предлагая новые стандарты.
Мы всё ещё ждём того момента, когда положение WebAssembly по-настоящему упрочится, когда эта технология будет внедряться массово. Каждое улучшение WebAssembly приближает нас к этому моменту. Заявление W3C — это, безусловно, огромный шаг в направлении легитимизации этой технологии в корпоративном мире. Нам нужно продолжать снижать входные барьеры в мир WebAssembly-программирования, что позволит упростить разработку новых WebAssembly-проектов.
Уровень использования TypeScript стремительно растёт, многие разработчики признаются в любви к этому языку
2019 можно назвать годом TypeScript. Этот язык не только стал стандартом де-факто в решении задачи типизации JS-кода. Многие разработчики ещё и отдают ему предпочтение перед обычным JavaScript как в личных проектах, так и на работе.
В исследовании StackOverflow, опубликованном в начале этого года, TypeScript, в рейтинге языков, которые больше всего любят разработчики, разделил второе место с Python, уступив лишь Rust. И не будет ничего удивительного, если TypeScript поднимется ещё выше в таком же исследовании, выход результатов которого ожидается в начале 2020.
Многие разработчики любят TypeScript
TypeScript буквально захватил мир веб-разработки. Это касается и фронтенда, и бэкенда. Некоторые программисты пытались отмахнуться от TypeScript как от очередного кратковременного веяния. Они думали, что он разделит печальную судьбу Coffeescript. Но TypeScript доказал свою пригодность в решении базовой проблемы JS-разработки. Возникает такое ощущение, что со временем его популярность лишь растёт.
TypeScript даёт веб-разработчикам серьёзные удобства благодаря интеграции со всеми основными редакторами кода. JavaScript-разработчики рассматривают TypeScript как инструмент, применение которого приводит к уменьшению количества ошибок. TypeScript в их глазах — это типизированный код, который читается легче JavaScript-кода. Это — объектные интерфейсы, которые способствуют созданию самодокументирующихся программ.
Если говорить о популярности TypeScript, то стоит отметить хотя бы то, что он в 2019 году обошёл React по количеству загрузок из NPM. У него, кроме того, гораздо больше загрузок, чем у его конкурентов — у таких проектов, как Flow и Reason.
Хотелось бы обратить ваше внимание на то, что TypeScript и React — это совершенно разные технологии, рассчитанные на решение разных задач. Поэтому подобное сравнение — это как сравнение тёплого с мягким. Это — лишь демонстрация популярности TypeScript.
TypeScript обходит React в NPM
TypeScript 3.0 вышел в конце 2018 года. В 2019 году он добрался до версии 3.7, куда вошли свежие возможности стандарта ECMAScript, такие, как опциональные цепочки и проверка значений только на null и undefined. В новой версии TypeScript улучшен и функционал, касающийся работы с типами.
React продолжает лидировать, разработчики увлечены хуками
У Vue и Angular есть увлечённые своим делом сообщества пользователей. Vue даже обошёл React по количеству звёзд на GitHub. Но в деле практического использования, будь то личные проекты программистов, или их работа, React уверенно держит первое место.
В конце 2018 года команда React выпустила так называемые хуки. В 2019 хуки буквально захватили мир React. Подавляющее большинство React-разработчиков использует их как основной механизм для управления состоянием компонентов и для работы с событиями их жизненного цикла. В течение года было написано бесчисленное множество статей о хуках, всё чётче вырисовывались паттерны их использования, важнейшие React-пакеты начали предоставлять пользовательские хуки, которые можно применять для работы с этими пакетами.
Хуки дают программисту способ управления состоянием и жизненным циклом функциональных компонентов с использованием простого и лаконичного синтаксиса. Кроме того, React позволяет создавать пользовательские хуки, которые помогают разработчикам писать код, подходящий для многократного использования, помогают создавать логику, которую можно использовать совместно. При этом отпадает необходимость в применении компонентов высшего порядка или свойств рендеринга.
Команда разработчиков React обращает особое внимание на удобство работы программистов и на инструменты, которые помогают трудиться продуктивнее. После громкого появления хуков в React 16.8, по мере того, как библиотека добралась в 2019 году до версии 16.4., остальные нововведения были не столь масштабными.
Можно сказать, что команда разработчиков React после выпуска хуков сосредоточилась на удобстве программистов за счёт создания вспомогательных инструментов. Удобство работы программиста, те ощущения, которые он испытывает, разрабатывая React-приложения, стали главной темой конференции React Conf 2019. Том Оччино, ведущий докладчик конференции и менеджер команды React, сказал, что ощущения разработчика от использования React основаны на трёх идеях: низкий входной барьер, высокая продуктивность, масштабируемость решений. Взглянем на то, что было выпущено (или планировалось выпустить) командой React для поддержки этих идей:
- Новая версия инструментов разработчика React.
- Новый профилировщик производительности.
- Create React App v3.
- Обновления утилиты для тестирования.
- Конкурентный режим (ожидается).
- Система CSS-in-JS, используемая в Facebook (ожидается).
- Прогрессивная/селективная подготовка заранее отрендеренного кода страницы к работе (ожидается).
- Улучшения в ядре React, касающиеся доступности (ожидается).
Есть мнение, что если программисту приятно работается, то у него получится то, что вызовет положительные впечатления у пользователей. В результате вышеописанная инициатива разработчиков React — это выигрыш для всех. Вот выступление с React Conf 2019, посвящённое ожидаемым возможностям React, а вот — ссылка на все выступления с этого мероприятия.
Фреймворк Vue готовится к релизу версии 3, объём его использования растёт
Вероятно, пока Vue нельзя назвать самым распространённым фреймворком, но сложно не заметить то, что вокруг него сложилось сообщество, члены которого увлечены своим делом как никто другой. Известно, что Vue взял лучшее от React и Angular, но при этом устроен проще, чем они. Ещё одно важное преимущество Vue заключается в его более сильной открытости, и в том, что его не контролирует какая-нибудь крупная компания вроде Facebook (React — это её детище) или Google (эта компания поддерживает Angular).
Главная новость в мире Vue — это грядущий релиз 3.0. Появление альфа-версии ожидается в конце года. В этом году Vue 2.x получил лишь несколько обновлений, было это ближе к началу года. Дело в том, что все силы разработчиков направлены на выпуск Vue 3.0.
То, что у Vue в этом году было не особенно много релизов, не значит, что с этим фреймворком не происходит ничего интересного. Когда Эван Ю выпустил RFC для третьей версии Vue, в сообществе разгорелись обширные обсуждения, касающиеся изменений. Например, почитать их можно здесь и здесь.
Главная проблема, которая беспокоила Vue-разработчиков, заключается в серьёзном изменении API фреймворка. Правда, после возникновения подобной негативной реакции, было сказано, что новые API будут добавляться к старым, и что они будут обратно совместимыми с Vue 2. Многие разработчики заявляют, что если новый релиз Vue будет выглядеть не так, как им хотелось бы, они рассмотрят возможность перехода на Svelte. Люди опасаются того, что изменения Vue сделают этот фреймворк слишком сильно похожим на React. Хотя многие члены сообщества всё ещё обеспокоены будущим фреймворка, возникает такое ощущение, что шум поутих и все просто ждут нового релиза.
В Vue 3, помимо спорного функционала, ожидается появление некоторых новых интересных возможностей и полезных изменений:
- API Composition.
- Изменения в API конфигурирования и монтирования.
- Фрагменты.
- Поддержка технологии Time Slicing (экспериментальная).
- Поддержка нескольких v-model.
- Порталы.
- Новый API пользовательских директив.
- Улучшенная реактивность.
- Переписанная виртуальная DOM.
- Поднятие статических свойств.
- Поддержка API хуков (экспериментальная).
- Оптимизация генерирования слотов (разделение рендеринга для родительских и дочерних компонентов).
- Улучшенная поддержка TypeScript.
Заметным событием в мире Vue стал выход в этом году 4-й версии Vue CLI, где основное внимание уделено обновлению базовых инструментов.
Вот выступление Эвана Ю о Vue.
Выходят 8 и 9 версии Angular, а также — новый движок компиляции/рендеринга Ivy
Философия Angular, когда фреймворк предписывает разработчику определённые схемы действий, помогла этому инструменту набрать большую пользовательскую базу. Angular говорит разработчикам о том, что правильно, а что — нет, но при этом предоставляет все необходимые разработчикам инструменты.
Это устраняет множество поводов для обсуждения того, какие библиотеки и зависимости нужно включать в состав проекта. Надо отметить, что подобные вопросы часто встают в командах, использующих React. Кроме того, Angular-приложения пишут на TypeScript. Так как тот, кто выбирает Angular, вынужден согласиться с тем, что множество решений уже принято за него, этот фреймворк очень нравится различным компаниям. Такое положение дел позволяет разработчикам сосредоточиться на разработке программных продуктов, а не тратить время на размышления о пакетах.
В 2019 вышла 8 версия Angular. В этом же году увидел свет новый движок компиляции/рендеринга Ivy. Самая главная сильная сторона Ivy заключается в том, что благодаря ему уменьшаются размеры бандлов. Но, на самом деле, он приносит в Angular и многие другие полезности. Сейчас, до выхода Angular 9, Ivy — это опциональная возможность. Здесь можно почитать подробности том, что нового появилось в Angular 8. Особо же хотелось бы отметить следующее:
- Дифференциальная загрузка современного JavaScript-кода.
- Возможность ознакомиться с технологией Ivy.
- Обеспечение обратной совместимости маршрутизатора Angular.
- Улучшенная сборка веб-воркеров.
- Возможность передавать разработчикам Angular сведения об использовании Angular CLI.
- Обновления зависимостей.
В течение декабря 2019 года команда Angular готовилась к выпуску Angular 9. Похоже, что данная версия фреймворка выйдет либо в конце этого года, либо в начале следующего. Главнейшее новшество Angular 9 заключается в том, что Ivy станет стандартным движком рендеринга. Вот видео, просмотрев которого можно узнать подробности об Angular 9.
Теперь на доступность (a11y) и на интернационализацию (i18n) обращают больше внимания, чем раньше
Веб должен быть пространством, открытым для всех людей и пригодным для использования всеми людьми. В результате во фронтенде доступность и интернационализация стали приоритетными задачами. После быстрого развития JavaScript и веб, начавшегося в 2015 году, паттерны и фреймворки наконец начинают стабилизироваться. В наши дни, когда технологии более устойчивы чем несколько лет назад, ситуация позволяет разработчикам уделять больше внимания инструментам для локализации приложений и для повышения уровня их доступности. Это делает веб более гостеприимным местом для всех категорий пользователей. Нам стоит гордиться тем путём в этих направлениях, который мы уже прошли, но многое ещё впереди.
Вот что говорится о доступности на MDN: «Доступность — это практика, позволяющая использовать ваши сайты как можно большему числу людей. Мы традиционно думаем об этом как о доступности для людей с ограниченными возможностями, но на самом деле, в это число входят и другие группы пользователей, которые используют мобильные устройства либо имеют медленное сетевое соединение».
А вот что сказано об интернационализации на w3.org: «Если вы интернационализируете проект — это значит, что вы так проектируете или создаёте свои материалы, приложения, спецификации и прочие подобные ресурсы, что это позволяет им нормально работать для пользователей, принадлежащих к любой культуре, проживающих в любом регионе, говорящих на любом языке, или позволяет легко адаптировать их для таких пользователей».
Возможности ES2019
ECMAScript (спецификация, на которой основан JavaScript), по-прежнему следует в этом году ежегодному циклу обновления. В стандарте ES2019 появилось немало новых возможностей. Вот некоторые из них:
- Метод
Object.fromEntries(). - Метод
String.trimStart()иString.trimEnd(). - Улучшенная поддержка unicode в методе
JSON.stringify(). - Метод
Array.flat(). - Метод
Array.flatMap(). - Улучшенная работа с
try/catch. - Свойство
descriptionобъектовSymbol.
Хотя в ES2019 появились очень интересные новые возможности, в ожидаемом стандарте ES2020 могут появиться такие вещи, которые, вероятно, станут самыми ожидаемыми со времён ES6/ES2015:
- Приватные поля классов.
- Опциональные цепочки —
obj.field?.maybe?.exists. - Проверка значений только на
nullиundefined—item ?? 'use this only if item is null/undefined'. - Тип данных
BigInt.
Взрывной рост популярности Flutter
Flutter вышел через 2 года после React Native, но быстро обрёл популярность. Этот проект очень близок к React Native по количеству звёзд на GitHub. А если популярность проекта будет продолжать расти теми же темпами, то он скоро обгонит React Native. Flutter конкурирует с React и представляет собой ещё один отличный инструмент разработки кросс-платформенных мобильных приложений.
Если учесть то, что Flutter не может похвастаться тем же сообществом дружественных разработчиков, которое есть у React Native и представлено веб-разработчиками, пользующимися React, то такие успехи выглядят особенно впечатляюще. Цель Flutter — быть лучшим фреймворком для кросс-платформенной мобильной разработки.
Вот таблица, в которой React Native и Flutter сопоставлены по некоторым показателям.
Node.js Foundation и JS Foundation объединились, сформировав OpenJS Foundation; Node.js 12 станет LTS-релизом
Для того чтобы поддержать экосистему JavaScript и ускорить рост языка, Node.js Foundation и JS Foundation объединились, сформировав OpenJS Foundation. Основная идея этого шага заключается в налаживании сотрудничества и в развитии технологий под эгидой нейтральной организации, которая сейчас объединяет 31 опенсорсный проект. В состав этих проектов входят Node, jQuery и Webpack. Эту инициативу можно рассматривать как позитивное движение для всего JS-сообщества. Его поддерживают ведущие технологические компании, такие, как Google, IBM и Microsoft.
12 версия Node.js, вышедшая в этом году, по сложившейся традиции получит долговременную поддержку (LTS, long term support) до апреля 2023 года. Node.js 12 предлагает множество новых возможностей, обновлений безопасности и улучшений производительности. Среди некоторых заметных новшеств можно отметить нативную поддержку конструкций import/export, поддержку приватных полей классов, совместимость с движком V8 версии 7.4, поддержку TLS 1.3 и появление дополнительных диагностических средств. Вот материал о новшествах Node.js 12.
Фреймворк Svelte привлекает к себе немало внимания, но используется пока недостаточно широко
Фреймворк Svelte смог найти своё место в и без того переполненном мире фронтенд-фреймворков. Однако, как уже говорилось, это пока не привело к широкому использования этого фреймворка. Если выразить суть Svelte в двух словах, то можно сказать, что это «простой, но мощный» инструмент. На сайте проекта отмечается три его ключевых сильных стороны:
- Svelte-разработчики пишут меньше кода.
- Фреймворк не использует виртуальную DOM.
- Он по-настоящему реактивен.
Svelte пытается перенести основную часть работы на этап компиляции, вместо того, чтобы делать что-то в браузере во время работы страницы. Svelte обладает архитектурой, основанной на компонентах, структуры которой компилируются в чистые HTML и JavaScript. Это обещает необходимость в меньших объёмах шаблонного кода. Фреймворк использует идеи реактивного программирования, что позволяет выполнять непосредственные изменения в DOM вместо того, чтобы менять виртуальную DOM, а потом согласовывать изменения с реальной.
Svelte предлагает фронтенд-разработчикам что-то новое и интересное, давая им не больше возможностей, а меньше. В 2020 году интересно будет наблюдать за ростом и развитием Svelte. Хочется надеяться на то, что нам удастся увидеть примеры его использования в крупномасштабных проектах. Это позволит узнать о том, как он выглядит в сравнении со своими более крупными конкурентами — React, Vue и Angular.
Статические сайты по-прежнему актуальны, разработчики внедряют JAMStack
Статические сайты доказали, что они являются составной частью веба и не собираются сдавать позиции. В пользу этого утверждения говорит расширение использования фреймворков наподобие Gatsby, быстрый рост хостингов статических сайтов вроде Netlify, бесчисленное множество новых компаний, создающих CMS без пользовательского интерфейса.
Статические сайты комбинируют то, что уже было в вебе, с новыми инструментами и библиотеками. Они позволяют создавать проекты, несравнимые ни с чем другим. Мы можем создавать сайты, используя современные библиотеки наподобие React, а потом можем компилировать их в статические HTML-страницы во время сборки проекта. Так как теперь все страницы хранятся в готовом виде, сервер не тратит ресурсы на заполнение их данными при обращении к нему клиента. Страницы могут быть доставлены клиенту мгновенно, проекты способны в полной мере пользоваться преимуществами CDN-кэширования. Это позволяет держать содержимое сайтов так близко к их пользователям, как это возможно.
При создании статических сайтов весьма популярен паттерн JAMStack (JavaScript, API, Markup). Это — гибридный подход, комбинирующий статические сайты и одностраничные приложения (SPA, single page application). При использовании такого подхода страницы отдаются клиенту в статическом виде, но, оказываясь на клиенте, они ведут себя как SPA, которые используют API и действия пользователя для изменения состояния интерфейса.
PWA растут, увеличиваются объёмы их внедрения
Использование статических сайтов — это один из способов создания чрезвычайно быстрых веб-проектов. Но они подходят не для всех случаев. Ещё один интереснейший вариант — это прогрессивные веб-приложения (PWA, progressive web application). PWA позволяют кэшировать ресурсы в браузере для того, чтобы ускорить время реакции страниц на воздействия пользователя и для обеспечения работоспособности проектов без подключения к интернету. Кроме того, они позволяют пользоваться фоновыми рабочими процессами, которые сближают эти приложения с нативными приложениями, реализуя, например, функционал push-уведомлений.
Кое-кто даже заявляет, что PWA способны заменить обычные мобильные приложения. Как бы там ни было, можно отметить, что нет сомнений в том, что PWA ещё долго будут важной частью наборов технологий, используемых компаниями при разработке своих проектов.
Фронтенд-инструменты становятся по-настоящему качественными
Фронтенд-разработчики уже несколько лет жалуются на «усталость» от JavaScript. Но можно видеть, как эта проблема постепенно уходит благодаря огромным усилиям тех, кто поддерживает опенсорсные проекты.
Раньше, если нужно было создать SPA, требовалось собирать собственный набор зависимостей, пользуясь Bower или NPM. Нужно было разбираться с тем, как транспилировать код с помощью Browserify или Webpack, нужно было с нуля писать Express-сервер и поддерживать свои приложения на плаву в штормах обновлений библиотек.
Сообщество разработчиков страдало от этого всего несколько лет, но теперь мы постепенно добрались до такого уровня развития технологий, когда в нашем распоряжении оказалась чрезвычайно мощная и проработанная экосистема поддержки пакетов. Существуют инструменты, которые помогают абстрагировать наиболее проблемные процессы разработки приложений. Это, например, Create React App, Vue CLI, Angular CLI. Это — проект Gatsby, который помогает создавать статические сайты, это платформа Expo, облегчающая разработку мобильных приложений на React Native. У нас есть Next и Nuxt для решения задач серверного рендеринга, генераторы для создания серверов. GraphQL-серверы можно создавать автоматически с помощью Hasura, можно автоматически генерировать TypeScript-типы с использованием GraphQL Code Generator. Продолжает развиваться Webpack. Короче говоря — в распоряжении современного разработчика есть инструменты, которые позволяют ему решить практически любую встающую перед ним задачу.
Кстати, может уже пора говорить об «усталости от инструментов веб-разработки»?
GraphQL продолжает пользоваться любовью разработчиков, расширяются масштабы внедрения этой технологии
Технологи GraphQL обещает решить множество проблем, сопутствующих традиционным приложениям, основанным на REST. Разработчики очень скоро буквально влюбились в эту технологию, а теперь это чувство разделяют и технологические компании, которые начали внедрять GraphQL. Например, новейший API GitHub был написан на GraphQL несколько лет назад, в сторону этой технологии двигаются и другие компании.
В основе GraphQL-приложений лежат данные а не конечные точки. Это позволяет клиентам запрашивать именно те данные, которые им нужны и получать от сервера соответствующие JSON-ответы. API GraphQL предоставляют разработчику схему, документирующую все данные и их типы, что делает такие API полностью прозрачными для программиста.
Так как API GraphQL дают в наше распоряжение полностью типизированную схему, эта технология, кроме того, хорошо интегрируется с TypeScript-приложениям. Инструмент наподобие GraphQL Code Generator может читать запросы в коде клиента, сопоставлять их со схемой и предоставлять нам TypeScript-типы, которые будут использоваться во всём приложении.
Количество загрузок GraphQL за прошедший год более чем удвоилось. Разработчики Apollo начинают позиционировать свой проект как наиболее широко применяемый фреймворк.
Число загрузок GraphQL за год более чем удвоилось
Технологии CSS-in-JS набирают популярность
Если понаблюдать за развитием веб-разработки, то может возникнуть такое ощущение, что технологии находятся на пути объединения абсолютно всего под знаком JavaScript. Это видно и в сфере внедрения технологий CSS-in-JS, которые используют технику создания стилей, основанную на JavaScript-строках.
Это позволяет работать со стилями и зависимостями, например, совместно использовать их, применяя обычные JavaScript-конструкции import/export. Это, кроме того, упрощает создание динамических стилей, так как компоненты, стилизованные средствами CSS-in-JS могут включать значения передаваемых им свойств в строки, описывающие стили. Как уже было сказано, вполне вероятно то, что в видении Facebook CSS-in-JS — это будущее стилизации, поэтому компания может выпустить соответствующую библиотеку собственной разработки.
Ниже показан пример, в котором классический CSS сравнивается с CSS-in-JS. Для обеспечения поддержки динамических стилей в обычном CSS нужно работать в компонентах с именами классов и обновлять их, основываясь на состоянии или на свойствах компонента. Кроме того, для каждой вариации стиля нужен собственный CSS-класс:
// JS-файл компонента
const MyComp = ({ isActive }) => {
const className = isActive ? 'active' : 'inactive';
return <div className={className}>HI</div>
}
// CSS-файл
.active { color: green; }
.inactive { color: red; }При использовании CSS-in-JS работать с CSS-классами больше не нужно. Достаточно просто передать стилизованному компоненту соответствующее свойство, а компонент обеспечит динамическую стилизацию средствами декларативного синтаксиса. Код получается гораздо более чистым, в нашем распоряжении оказывается более чёткое разделение функционала стилей и React, так как управление динамической стилизацией основано на свойствах, передаваемых компоненту. Теперь код стилизации читается как обычный JS-код, написанный для React:
const Header = styled.div`
color: ${({ isActive }) => isActive ? 'green' : 'red'};
`;
const MyComp = ({ isActive }} => (
<Header isActive={isActive}>HI</Header>
)Библиотеки styled-components и emotion — это два ведущих CSS-in-JS-решения. При этом emotion в 2019 году опередила styled-components по количеству загрузок. Эти две библиотеки значительно обходят, в плане популярности, другие инструменты, реализующие технологию CSS-in-JS. Возникает такое ощущение, что их быстрый рост продолжится.
Загрузки CSS-in-JS-библиотек
VS Code лидирует в сфере редакторов кода
Разработчики трепетно относятся к своим IDE и редакторам кода. Они, не стесняясь, готовы вступать в споры, доказывая безусловное преимущество их инструментов над всеми остальными. Но современные фронтенд-разработчики, похоже, забыли о спорах. Они, будто сговорившись, поголовно выбирают VS Code. Это — опенсорсный бесплатный редактор, который, благодаря возможности использования плагинов, даёт разработчикам возможность настраивать его именно так, как им того хочется.
Вот данные по использованию текстовых редакторов из State of JS Survey 2019.
VS Code — самый популярный редактор кода
Webpack 5 входит в стадию бета-версии и приближается к релизу
Webpack стал ключевым звеном практически всех современных цепочек инструментов, используемых в JavaScript-проектах. Это — самое популярное средство для сборки проектов. Webpack продолжает улучшаться, как в плане производительности, так и в плане удобства работы с ним с точки зрения разработчика. В 5 версии Webpack упор делается на следующее:
- Повышение производительности при сборке проектов с использованием постоянного кэширования.
- Улучшение долговременного кэширования с использованием усовершенствованных алгоритмов и хорошо подобранных стандартных параметров.
- Переработка внутренних механизмов без введения изменений, способных нарушить работоспособность проектов, использующих существующие версии Webpack.
Jest переходит с Flow на TypeScript
Facebook поддерживает популярную библиотеку для тестирования, которая называется Jest. Компания занимается и проектом Flow — конкурентом TypeScript. Сделав соответствующее громкое заявление в начале 2019 года, компания решила перевести Jest с Flow на TypeScript. Это даёт лишний повод говорить о том, что TypeScript стал стандартным решением для типизации JS-кода. Можно ожидать роста масштабов использования TypeScript как в 2020 году, так и в более отдалённом будущем.
Вышли стабильные версии Chrome 72-78
Разработка Chrome продолжает идти в быстром темпе. В браузер оперативно добавляются новые возможности, ориентированные как на веб-технологии, так и на поддержку разработчиков. В 2019 вышло 7 стабильных версий Chrome. Сейчас Chrome 79 находится на стадии бета-версии, Chrome 80 представляет собой dev-версию, а Chrome 81 — это canary-версия. Здесь можно найти сведения о том, что нового появилось в Chrome в 2019 году.
Браузер Microsoft Edge переходит на Chromium
Internet Explorer, в своём новейшем воплощении называемый Edge, всегда давал веб-разработчикам поводы для шуток. Правда, работать с этим браузером было очень неудобно, а это уже совсем не смешно. Этот браузер постоянно отставал от конкурентов в плане поддерживаемых возможностей, его существование серьёзно усложняло задачу написания кросс-браузерного кода. Большой удачей для разработчиков стало то, что Microsoft решила воспользоваться опенсорсным проектом Chromium от Google. Эта разработка достигла в середине 2019 года бета-версии.
Facebook выпускает Hermes — JavaScript-парсер для Android, направленный на совершенствование React Native
Компания Facebook решила, что JavaScript-движок Android недостаточно быстр. Поэтому компания создала собственный движок — Hermes. Facebook чрезвычайно заинтересована в успехе React Native. Этот ход показывает то, что компания хочет создать среду, которая позволит React Native максимально эффективно работать на всех платформах.
Прогноз на 2020 год
А теперь давайте подумаем о том, что ждёт фронтенд в 2020 году:
- Веб-разработчики продолжат уделять повышенное внимание производительности. Для достижения высокой скорости работы сайтов будут использоваться технологии разделения кода и PWA.
- Технология WebAssembly станет более привычной, появится больше примеров её реального использования.
- GraphQL обойдёт REST, находя использование во всё большем количестве новых проектов и новых компаний, в то время как существующие компании будут продолжать постепенный переход на GraphQL.
- TypeScript станет стандартным выбором для стартапов и новых проектов.
- Начнут появляться реальные приложение, созданные без сервера, основанные на блокчейн-технологиях. Это сделает веб более открытым.
- Технологии CSS-in-JS могут стать, вместо обычного CSS, стандартным средством стилизации.
- «Бескодовые» приложения станут более популярными. В наши дни развиваются технологии искусственного интеллекта, растёт число уровней абстракции. А это значит, что создавать приложения становится всё легче и легче. В 2020 году мы можем увидеть значительный сдвиг в области создания приложений без написания кода.
- Flutter может обойти React Native и стать основным инструментом для разработки кросс-платформенных мобильных приложений.
- Появится больше реальных проектов, основанных на Svelte.
- Мы увидим практическое применение Deno (среды выполнения TypeScript, разработанной создателем Node.js).
- Технологии AR/VR будут развиваться в сфере использования библиотек наподобие A-Frame, React VR и Google VR. Произойдут улучшения и в браузерной поддержке AR/VR.
- Во фронтенд-разработке больший вес приобретут технологии контейнеризации (Docker, Kubernetes).
Уважаемые читатели! Каким вы видите фронтенд-2020?
Термины «фронтенд», «клиентская сторона» и «интерфейс» — как употреблять и не облажаться
До работы редактором и контент-маркетологом в компании Лайв Тайпинг я два года занимался гуманитарными текстами: редактировал и писал статьи про моду, музыку, кино, изобразительное искусство, социологию и тому подобное. От меня требовалось не столько корректно донести смысл, сколько добиться яркого образа, создать настроение и подарить читателю эмоцию. Это развязывает руки в отношениях со словами: прежде имевшие точный смысл, они становятся сырьём для аллегорий, метафор и других литературных приёмов.Попав в техническую среду, я понял, что словесные украшательства мешают функции. Вместе с трендом инфостиля это заставило меня пересмотреть подход к работе с текстами. В том числе пришло время вспомнить, что у каждого термина есть своё значение.
При работе над кейсом проекта Designet я поймал себя на том, что считаю термины «фронтенд», «клиентская сторона» и «интерфейс» синонимами. Чтобы расставить все точки над i и больше их не путать, я написал эту памятку. Надеюсь, что она поможет не только мне, но и коллегам — редакторам, копирайтерам, техническим журналистам, маркетологам, менеджерам проектов и всем, кто не имеет прямого отношения к программированию.
Интерфейс
Всё, что помогает человеку управлять инструментом, будь то программа, компьютер, бытовой прибор или панель заводского станка — это интерфейс. Элементами интерфейса являются меню, кнопки, клавиатура, мышь, монитор, переключатели, тумблеры, тулбары, поля для набора текста, экраны с ошибками и прочие способы взаимодействия и ввода/вывода информации. Применительно к интерфейсу программ и приложений в английском языке встречается словосочетание user interface (UI).
Интерфейс — это всё, что вы видите и что можете потрогать.
Интерфейс может быть удобным и неудобным. Критерием удобного интерфейса по сегодняшним меркам считается короткая череда действий, которая не бесит, не смущает, не выматывает и в итоге даёт желаемое. Сумма ощущений от пользования интерфейсом называется опытом взаимодействия, пользовательским опытом или user experience (UX). Он тоже может быть плохим или хорошим.
Интерфейс поисковой страницы Google — пример интерфейса с UX уровня «дзен».
Файловый менеджер FileMatrix — пример ужасного интерфейса из обсуждения на Stack Overflow. Не лезь, он тебя сожрёт.
Чем больше в интерфейсе действий, тем дольше пользователю придётся продираться к функциональностям программы, сайта или приложения, и тем быстрее он плюнет на это и пойдёт искать интерфейс с единственной кнопкой, приносящей результат.
Фронтенд
Если интерфейс — это прослойка между пользователем и кодом, запускающая последний в работу, то фронтенд — это тот самый код и есть. Возьмём, например, какую-нибудь страницу «Википедии». Чтобы открыть её, мы даём команду браузеру: «А покажи». Браузер запрашивает у внешнего сервера строительный материал страницы — код. Этот код исполняется на странице и рисует то, что вы попросили у браузера.
Стоит заметить, что часто под фронтендом понимают веб-разработку. Из-за двойственности в определении существует спор, как писать этот термин по-английски: раздельно или через дефис. Свет на проблему проливает эта публикация.
Фронтенд складывается из взаимодействия трёх технологий:
- HTML (HyperTextMarkupLanguage). Язык разметки документа, понятный браузерам за счёт дескрипторов, или тегов. HTML указывает, какие элементы есть на странице, задаёт их порядок в документе и вложенность одного в другой;
- CSS (Cascading Style Sheets, или каскадные таблицы стилей). Придаёт HTML особый вид, облагораживает его: подчёркивает и меняет цвет ссылок, задаёт размеры заголовков или шрифты и т.п.;
- JavaScript. Язык программирования, имеющий доступ к элементам страницы и браузера, оперирующий данным в HTML и CSS и служащий для них подобием волшебного пенделя, потому что сами по себе HTML и CSS ничего не делают. С помощью JavaScript, например, в браузере работает анимация и всякие интерактивные штуки. Есть во всех браузерах за исключением Opera Mini, где он ограничен производителем для упрощения работы.
Одно нажатие F12, и страница показывает всё, что под ней спрятано.
Клиентская сторона
Средство, которое принимает данные и показывает их в понятном человеку виде, называется клиентской стороной, или клиентом. Этим средством является браузер, мобильное приложение, работающее с данными с сервера, компьютер, телефон, планшет, телевизор или радиоприёмник.
Этих клиентов уже никто не обслужит.
Понятие о клиентской стороне вышло из парадигмы клиент-серверной архитектуры. Она появилась вместе с первыми компьютерными сетями: разработчики решили, что часть общих ресурсов можно хранить за пределами устройства. Устройство в таком случае — это клиент: он получает данные от внешнего сервиса, отрисовывает их в себе и отправляет вносимые изменения обратно на сервис.
Закрепление
Клиент — это устройство для оперирования удалёнными данными.
Интерфейс — это набор элементов для управления программой или устройством
Фронтенд — это код, принятый клиентом, запущенный на нём и ставший интерфейсом, или веб-разработка на клиентской стороне как таковая.
Окончательно понять разницу поможет пример. Если от вас под страхом смерти потребуют ответ на вопрос, что такое браузер Chrome — клиентская сторона, фронтенд или интерфейс,— смело отвечайте: «Клиентская сторона». А чтобы враг молча отдал оружие, уточните, что отдельно взятая страница — уже интерфейс, а внутри неё работает фронтенд.
Не так страшно повторять в тексте один и тот же термин, как безрассудно заменять его на неправильные синонимы. Если вы хотите указать на неточности и спорные моменты или высказать что угодно по теме — добро пожаловать в комментарии.
Frontend-разработчики должны быть в теме всего / Habr
Мысли Криса Койера
Одна из мыслей, которая поселилась в моей голове: должен ли frontend-разработчик быть в курсе всего? В общем смысле, frontend-разработчик может использоваться и на других рабочих местах. Вся команда разработчиков заканчивает разговор на frontend-разработчике. В этом смысл моей идеи. Frontend-разработчики создают те вещи, с которыми будут взаимодействовать люди. Все этапы разработки проходят вместе с frontend-разработчиком. Возможно, именно поэтому это такая забавная работа! Поскольку frontend-разработчик занимает центральное место в цепочке разработки, и при этом мы имеем дело с большим количеством разных специалистов, мы должны понимать их работу и иногда подсказывать, что и как сделать лучше.
От переводчика
Всем привет, с вами Максим Иванов, и сегодня мы поговорим на довольно острую тему в сфере веб-разработки. Как утверждает Крис Койер, frontend-разработчик должен разбираться в очень многих вещах, о которых не все даже и задумываются. Конечно, мы должны понимать, что frontend-разработчик не главный в процессе разработки любого онлайн-сервиса или ПО в целом. На ту же позицию frontend-разработчика вы найдете больше откликов на вакансию, чем на позицию backend-разработчиком. Но почему же тогда Крис Койер считает, что работать frontend-разработчиком сложнее, ибо ты должен специализироваться во всем. Конечно, ситуаций в жизни очень много, разные компании по-разному используют своих специалистов, но в чем наверняка должен разбираться frontend-разработчик? Об этом мы сегодня и поговорим. Жду комментариев на эту тему, а сейчас приступим.
Содержание
- Frontend-разработчик должен разбираться в дизайне
- Frontend-разработчик должен разбираться в работе серверной части (backend)
- Frontend-разработчик должен разбираться в работе сетей
- Frontend-разработчик должен разбираться в производительности
- Frontend-разработчик должен разбираться в контент-стратегии
- Frontend-разработчик должен разбираться в базах данных
- Frontend-разработчик должен разбираться в тестировании
- Frontend-разработчик должен разбираться в системах сборки
- Frontend-разработчик должен разбираться в методологиях разработки
- Frontend-разработчик должен разбираться в настройке веб-серверов
- Frontend-разработчик должен разбираться в юзабилити
- Frontend-разработчик должен разбираться в мобильном дизайне
Frontend-разработчик должен разбираться в дизайне
Если frontend-разработчик не является сам по себе дизайнером, он должен знать, насколько важен дизайн. Он должен иметь хороший вкус. Он должен знать об инструментах, участвующих непосредственно в разработке.
К прочтению:
1. Памятка дизайнеру сайтов
2. Принцип цикады и почему он важен для веб-дизайнеров
3. Стив Круг «Веб-дизайн или Не заставляйте меня думать»
4. Якоб Нильсен «Веб-дизайн»
5. Дональд Норман «Дизайн привычных вещей»
6. Джеф Раскин «Интерфейс»
7. Как за 15 лет изменились главные страницы Apple, Microsoft, IBM, Sony
8. Ководство
9. О дизайне
10. Почему курсор мыши наклонён на 45°?
11. Наберитесь смелости сделать не как все. 12 устаревших интерфейсных и технологических решений
12. Имена людей и интерфейс
13. User experience design: как построить сайт для клиентов, а не для себя
14. Главные особенности китайского веб-дизайна и их истоки
Frontend-разработчик должен разбираться в работе серверной части (backend)
Даже если вы и не backend-разработчик, то вы явно осознаёте всю важность серверной части. Вы понимаете, с чем взаимодействует backend, что передается на сервер, а что нет. Вы знаете об обязанностях backend-разработчика. Вы понимаете, какой язык используется на сервере, и при этом должны уметь объяснить, что должен дать вам backend и что нужно от серверной части frontend-а.
К прочтению:
1. Чему мы научились, разрабатывая backend
2. Собеседование на должность PHP Backend Developer в Германии
3. Пишем backend для мобильного приложения за несколько минут
4. Что должно быть впереди фронтэнд или бекенд?
5. Что нужно знать, чтобы стать Backend разработчиком?
6. Что должен знать «PHP Junior Developer без опыта работы»?
7. Какими технологиями должен обладать backend разработчик (уровень начальных знаний — новичок+)?
Frontend-разработчик должен разбираться в работе сетей
Frontend-разработчик понимает, что сайты располагаются в интернете, данные передаются по сети, и что сеть — это дикое и непредсказуемое. Необходимо понимать, какие бывают сети, как они работают, и насколько они бывают быстрые и надежные.
К прочтению:
1. Принципы работы сети Интернет
2. Архитектура и принципы работы сети
3. Принцип работы торрент-сетей и как достигается высокая скорость
4. Руководство по TCP/IP для начинающих
5. Domain Name Service — cлужба Доменных Имен
Frontend-разработчик должен разбираться в производительности
Если вы не сосредоточены на производительности, то знаете, что производительность имеет важное место в успехе вашего проекта. Frontend-разработчики знают об этом нелегком мире. Нужные навыки помогут вам одержать быструю победу в долгой борьбе. Необходимо понимать насколько быстрым должен быть backend, а также, что оставшиеся 80% времени это загрузка сайта, т.е. это frontend.
К прочтению:
1. Производительность web: Why Performance Matters
2. Тонкости производительности
3. Выигрыш в производительности для rel=noopener
4. Измерение производительности веб-страниц
5. Улучшаем UX посредством оптимизации
6. Подходы к оптимизации (веб-)приложений
7. Пример веб-производительности
8. Производительность рендеринга картинок в Web
9. 10 Ways to Test Your Website Performance
Frontend-разработчик должен разбираться в контент-стратегии
Опять же, вы можете и не разрабатывать контент-стратегию, но должны понимать, что сайт живет и существует благодаря контенту на нем. Отсутствие определенного плана может вызвать определенные сложности, которые вы не сможете предотвратить во время разработки. Люди, которые будут пользоваться ресурсом, и те, кто что-то ищет, должны быть уверены в достоверности и корректности информации.
К прочтению:
1. Как создать контент-стратегию, которую будут обсуждать
2. Супер контент-стратегия. 5 успешных примеров
3. Нужна ли контент-стратегия при наполнении сайта?
4. Эрин Киссейн «Основы контентной стратегии»
5. Как построить SMM-стратегию: пошаговый план продвижения в социальных сетях
6. Как оптимизировать контент для SEO и SMM?
Frontend-разработчик должен разбираться в базах данных
Контент хранится в базе данных. База данных должна корректно работать с контентом. А frontend-разработчик должен уметь работать с тем, что приходит ему из этой самой базы данных. Frontend-разработчику при работе с ответом базы данных нужно уметь комбинировать контент с шаблонами на сайте.
К прочтению:
1. Введение в базы данных
2. Базы данных: SQL (DDL/DML)
3. Ускоряем базу данных веб-сайта
4. Веб-интерфейс для баз данных размером в один .php файл
5. Возможности PostgreSQL, которых нет в MySQL, и наоборот
6. HTML 5. Работа с Web SQL базой данных
7. Базы данных и NoSQL
8. Как отобразить 350 миллионов строк из базы данных на Web-форме
9. Встраиваемая JavaScript база данных с прицелом на API совместимость с MongoDB
Frontend-разработчик должен разбираться в тестировании
Существует большое количество видов тестирования. Интеграционное тестирование. Регрессионное тестирование. Пользовательское тестирование!
К прочтению:
1. Тестирование программного обеспечения
2. Зачем нужны тесты?
3. Модульные тесты и интеграционные: в чём разница?
4. Тестирование
5. JavaScript Testing курс (eng)
6. QUnit. Тестирование javascript кода
7. Как развиваться начинающему тестировщику?
8. Повышаем стабильность Front-end
9. Бек Кент. Экстремальное программирование. Разработка через тестирование
10. Пишем свой первый юнит-тест, на примере методологии BDD и библиотеки Jasmine
10. Процесс тестирования мобильных приложений
11. Макгрегор Джон, Сайкс Девид. Тестирование объектно-ориентированного программного обеспечения
12. Тестирование JS. Кармический Webpack
Frontend-разработчик должен разбираться в системах сборки
Frontend-разработчики пишут совместный код, и каждый должен брать на себя ответственность за внедрение чего-то нового в проекте. Если вы написали свою систему сборки, другие члены команды должны понимать, что это такое и для чего оно нужно. Даже если кто-то не использует систему сборки, он все равно должен понимать, как использовать такие вещи.
К прочтению:
1. Webpack – один из самых мощных и гибких инструментов для сборки frontend
2. Grunt — Обзор системы сборки
3. Автоматизация сборки
4. Приятная сборка frontend проекта
5. Сравнение популярных систем сборки для frontend-разработчиков
6. Grunt vs Gulp сравнение систем сборки для front-end разработчика
7. Gulp или Grunt, да всё равно
8. Методология сборки БЭМ-проекта
Frontend-разработчик должен разбираться в методологиях разработки
Fronend-разработчик пишет и стилизует код самостоятельно, так же, как и другие разработчики проекта, поэтому им необходимо придерживаться единых установок. Если не вы писали систему сборки, то в любом случае вы должны знать, как с ней работать, что она делает и на что способна. Если вы не умеете развертывать такие системы, то нужно научиться с этим работать.
К прочтению:
1. Необходимый минимум для фронтенд-разработчика
2. Методологии фронтенд-разработки
3. Советы front-end разработчику
4. Какими знаниями должен обладать Front-end разработчик в 2015 году
5. Что нужно знать и уметь front end разработчику в 2015/2016
6. Карта развития веб-разработчика
7. Основные навыки фронтенд-разработчика
8. Isobar Front-end Code Standards
9. Front-end Style Guides
10. JavaScript Style Guide
11. Coding style (Mozilla)
Frontend-разработчик должен разбираться в настройке веб-серверов
Без них не было бы веб-сайтов.
К прочтению:
1. Основные типы серверов
2. Что такое веб-сервер
3. Веб-сервер
4. Простым языком об HTTP
5. Веб-сервисы в теории и на практике для начинающих
6. Сравнение веб-серверов
7. Web-сервера и их использование для управления нагрузкой на приложение.
8. PHP. Встроенный web-сервер
9. Локальный веб-сервер
10. Использование преимуществ встроенного PHP сервера
11. Как поднять сервер для python скриптов за 1 минуту
Frontend-разработчик должен разбираться в юзабилити
Если frontend-разработчик не очень хорошо разбирается в юзабилити, в любом случае он должен понимать насколько это важно. Необходимо уметь тестировать и налаживать юзабилити. Frontend-разработчик должен знать, с кем поговорить на эту тему.
К прочтению:
1. Юзабилити
2. Юзабилити сайта
3. 10 советов по юзабилити сайта, основанных на результатах исследований
4. Основы юзабилити (usability) сайтов
5. Юзабилити-тестирование (ИТМО)
6. Usability vs. User Experience
7. What is the difference between UX and UI designer and web designer?
Frontend-разработчик должен разбираться в мобильном дизайне
Frontend-разработчик должен понимать, что его сайтом могут пользоваться везде, на его сайт могут зайти с любого устройства, поэтому необходимо позаботиться заранее на этот счет. Большие экраны, маленькие, сенсорные, устаревшие устройства. Frontend-разработчик должен быть готов к неизвестному!
К прочтению:
1. Лучшие практики по мобильному UX от Ника Бабича
2. Адаптивный веб-дизайн
3. Responsive Web Design: What It Is And How To Use It
4. Книга Итана Маркотта «Отзывчивый веб-дизайн»
4. 10 адаптивных фреймворков для веб-дизайна
5. Responsive Web Design Fundamentals курс (eng)
Заключение
Это всего лишь часть того, что должен знать frontend-разработчик. Чем больше, тем лучше. Все это, конечно, познается в работе. HTML, CSS, JavaScript, адаптивный дизайн, библиотеки и фреймворки — этот список может долго не заканчиваться.
Как стать фронтенд-разработчиком в 2018 году / RUVDS.com corporate blog / Habr
Камран Ахмед, автор материала, перевод которого мы сегодня публикуем, говорит, что занимается фуллстек-разработкой уже 5 лет и в настоящее время работает на должности ведущего инженера в компании tajawal. Там ему приходится заниматься многими вещами. Ему, по долгу службы, надо быть в курсе того, что происходит в мире веб-разработки, кроме того, одна из его задач заключается в том, чтобы поддерживать знания и навыки других разработчиков в хорошем состоянии. По его словам, наблюдение за развитием технологий — это не только его работа, но и хобби. Ему приходилось видеть сложности, с которыми сталкиваются начинающие программисты (и опытные — тоже), когда речь заходит об оперативном освоении новшеств. Камрану, в прошлом году, часто приходилось отвечать на вопросы о том, в чём нужно ориентироваться для того, чтобы оставаться современным и востребованным программистом. В результате он, для того, чтобы помочь себе и другим, решил подготовить схемы, ссылки на которые отвечали бы на большинство вопросов, которые ему обычно задают.
Изначально эти схемы представляли собой нечто вроде списка рекомендаций по инструментам, но недавно Камран решил привести их в порядок: структурировать, добавить подробностей, и оформить их в виде пошагового плана действий, который дал бы всем желающим возможность понять — чем и в каком порядке нужно заниматься для того, чтобы стать современным и востребованным веб-программистом. Работа над схемами по бэкенд-разработке и DevOps всё ещё продолжается, а вот пошаговый план действий для фронтенд-разработчиков уже готов. О нём Камран расскажет в этой статье.
Обзор
Прежде чем я расскажу о различных частях предлагаемого здесь плана действий, мне хотелось бы сделать оговорку. Цель этого плана заключается в том, чтобы дать вам общее представление о том, что происходит в современном мире фронтенд-разработки, и рассказать о порядке освоения технологий на тот случай, если вам это нужно. Цель моей схемы заключается не в том, чтобы призвать вас к изучению чего-то такого, что переживает сейчас пик популярности, возможно, недолгий. Вам нужно развить в себе понимание того, почему в некоторых случаях определённый инструмент предпочтительнее всех остальных, и помнить о том, что если о чём-то говорят буквально на каждом углу, это — не обязательно лучшее средство для решения некоей задачи.
Теперь приступим к делу. Собственно говоря, вот — план развития фронтенд-разработчика, о котором я говорил выше.
План развития фронтенд-разработчика
Сейчас мы поговорим об этой схеме, рассмотрим основные шаги, которые нужно предпринять программисту, который хочет заниматься разработкой фронтенда в современных условиях. Первое, что стоит освоить такому программисту — это основы HTML, CSS и JavaScript.
Изучение основ HTML
HTML — это то, что позволяет структурировать веб-страницы. Это — что-то вроде человеческого скелета, который формирует основу нашего тела. Первый шаг, который следует предпринять тому, кто хочет стать фронтенд-программистом — это изучение синтаксиса HTML и его возможностей. В ходе учёбы особое внимание надо обратить на следующее:
- Основы HTML и правила написания HTML-кода.
- Способы разделения страниц на части и правильное структурирование DOM.
▍Задание
После того, как вы освоите основы HTML, создайте как минимум 5 HTML-страниц. Я порекомендовал бы выбрать любой веб-сайт — например, страницу профиля на GitHub, или страницу входа в Twitter, и воссоздать её, обращая особое внимание на структурирование элементов страницы. То, что получится, будет не таким уж и красивым, но беспокоиться пока об этом не стоит. Самое главное сейчас — структура.
Изучение основ CSS
Теперь, после того, как вы узнали правила создания скелетов страниц, пришло время обтянуть эти скелеты кожей, украсить их. Технология CSS, или каскадные таблицы стилей, используется для придания страницам привлекательного вида. Вот на что стоит обратить внимание, знакомясь с CSS:
- Синтаксис и свойства CSS.
- Блоковая модель, разработка макетов с использованием технологий Grid и Flexbox.
- Разработка отзывчивых сайтов с использованием медиа-запросов.
▍Задание
После того, как вы освоите основы CSS, займитесь стилизацией созданных ранее страниц. Например, если вы написали HTML-код, воссоздающий структуру страницы профиля на GitHub — сделайте с помощью CSS так, чтобы ваша разработка выглядела в точности как настоящая страница профиля. Стилизуйте все пять страниц, созданных на предыдущем шаге.
Изучение основ JavaScript
JavaScript — это технология, которая позволяет сделать HTML-страницы интерактивными. Например, средствами JavaScript создают все те слайдеры, всплывающие окна, уведомления, которые вы видите на веб-сайтах. JS даёт возможность перезагрузки частей страниц без необходимости перезагрузки страниц целиком. На данном шаге вам нужно освоить основы JavaScript и приготовиться к самому интересному. Изучая JS, обратите внимание на следующее:
- Изучите синтаксис и базовые конструкции языка.
- Освойте методики работы с DOM средствами JS, то есть, например, разберитесь с тем, как добавлять элементы на страницу и удалять их с неё, как работать с классами элементов, как применять CSS-стили.
- После освоения основ разберитесь с более продвинутыми вещами, такими, как области видимости, замыкания, поднятие функций, всплытие событий, и так далее.
- Разберитесь с тем, как выполнять HTTP-запросы из JS-кода с использованием технологий XHR или Ajax. Именно Ajax позволяет выполнять какие-либо действия, обычно требующие перезагрузки страниц, не перезагружая их целиком.
- Далее — уделите время изучению новых возможностей языка, того, что появилось в ES6+. ES6 — это версия JavaScript, в которой имеется множество интересных обновлений, таких, как классы, различные способы объявления переменных. Тут появились новые методы массивов, средства для конкатенации строк, и так далее. Большинство материалов по ES6, которые вам попадутся, будут использовать Babel в процессе разъяснения особенностей новых возможностей языка. Babel — это транспилятор, он конвертирует, условно говоря, «новый» JavaScript-код в «старый». Нужно это для того, чтобы новый код работал в старых браузерах. Пока, однако, не обращайте внимания на Babel. Ваша задача — понять основы JS и научиться пользоваться этим языком в современных браузерах. Ниже мы ещё поговорим о ES6.
На данном этапе освоения веб-технологий вы уже должны почувствовать, что кое-что знаете и начинаете ощущать вкус современного фронтенда. Кроме того, тут вы можете себя поздравить, так как HTML, CSS и JavaScript — это очень важно, это — база, на которой строится всё остальное, и вы освоили эту базу и готовы двигаться дальше.
Стоит ли изучать jQuery?
В былые времена слово «jQuery» было у всех на устах, и у такого положения дел были веские причины. Это — мощная библиотека, которая основана на JavaScript и позволяет решать множество задач, не заботясь об особенностях различных браузеров. Все эти особенности учтены при разработке библиотеки. Но теперь дни бешеной популярности jQuery прошли, эту библиотеку уже не так активно используют для новых проектов, однако, кое-кто ей всё ещё пользуется. Изучать jQuery необязательно, но освоить эту библиотеку несложно, а сделав это, вы приобретёте навыки, которые вполне могут вам пригодиться.
Практика
Я часто это говорил и скажу это снова: нельзя что-либо изучить без практики. Не практикуясь, вы можете думать, что знаете что-то, что что-то поняли, но подобные ощущения длятся недолго, «понимание» и «знание» без практики быстро исчезают. Постарайтесь, в ходе освоения всего того, о чём мы тут говорим, как можно больше практиковаться.
Например, можете сделать отзывчивый веб-сайт и оснастить его интерактивными функциями с использованием JavaScript. Скажем, скопируйте любую понравившуюся вам страницу и постарайтесь при этом воспользоваться всем тем, что уже изучили.
После того, как вы достаточно попрактикуетесь, придёт время заняться настоящими делами. Загляните на github.com, найдите подходящий опенсорсный проект и постарайтесь внести в него посильный вклад, создав несколько пулл-реквестов. Вот несколько идей, касающихся вклада в опенсорс:
- Улучшите интерфейс, дизайн, добавьте какой-нибудь странице интерактивности.
- Взгляните на списки ошибок и проблем, и подумайте, можете ли вы помочь с их исправлением и решением.
- Найдите код, который можно улучшить, и выполните его рефакторинг.
Сделав что-то полезное и отправив запрос на включение изменений в проект, добавьте туда ссылку на этот репозиторий, сообщите, что вы учитесь, попросите дать отзыв о вашей работе и рекомендации о том, как сделать её лучше.
Хотя я и рекомендую начинающим разработчикам попробовать свои силы на GitHub, всё это требует, помимо знаний веб-технологий, ещё и умения работать с git. Кроме того, этот шаг необязателен, хотя, если вы решитесь его выполнить, вы поймёте, что он принесёт вам много полезного, а ещё — вы будете удивлены тому, как много людей готовы вам помочь, если вы их об этом попросите. Существует множество учебных материалов по git, например, можете взглянуть на этот.
После того, как вы освоите всё то, о чём шла речь выше, вы имеет полное право это отпраздновать. Если вы ответственно подошли к изучению HTML, CSS и JavaScript, вы уже можете найти себе какую-нибудь работу, возможно — это будет фриланс, а может быть — и настоящая работа. Однако если вы хотите профессионального роста, на этом останавливаться не стоит. Впереди — большой и интересный путь.
Менеджеры пакетов
До этого момента, если вы пользовались какими-нибудь внешними библиотеками, например, плагинами или виджетами, вам приходилось самостоятельно загружать JS и CSS-файлы и добавлять их в проект. Когда у того, чем вы пользовались, выходила новая версия, вам, опять же, самостоятельно, приходилось эту новую версию загружать. Это — довольно скучная и утомительная задача. Менеджеры пакетов способны вас от этого избавить. Они помогают включать в проекты внешние библиотеки и плагины, делая это таким образом, что разработчику не приходится беспокоиться о том, чтобы вручную копировать необходимые файлы в проект и следить за выходом их новых версий. В частности, речь идёт о менеджерах пакетов yarn и npm. И тот и другой, в общем-то, представляют собой практически одно и то же, различия между ними не так уж и велики, и вы можете изучить любой из них, после чего другой покажется вам очень знакомым.
Практика
Теперь, когда вы освоили основы работы с менеджерами пакетов, подключите какие-нибудь внешние библиотеки к страницам, которые вы разрабатывали, когда осваивали HTML, CSS и JavaScript. Например, это может быть какой-нибудь плагин для вывода всплывающих уведомлений при щелчке по кнопке. Можете воспользоваться библиотекой для проверки данных, вводимых в форме. Поэкспериментируйте с настройками, разберитесь с тем, как устанавливать различные версии библиотек. Занимаясь этим, почитайте о семантическом версионировании.
Препроцессоры CSS
Препроцессоры расширяют возможности CSS, давая стилям функционал, недоступный при их стандартном использовании. Существует множество препроцессоров: Sass, Less, Stylus, PostCSS, и другие. Если бы мне пришлось бы выбрать один из них, я остановился бы на Sass. Однако в последнее время весьма интересно выглядит препроцессор PostCSS, умение обращаться с ним вам точно не помешает, это что-то вроде Babel для CSS. Его можно использовать автономно или поверх Sass. На данном этапе вашего обучения я порекомендовал бы освоить Sass, а позже, когда у вас будет время, разобраться с PostCSS.
CSS-фреймворки
В принципе, изучать CSS-фреймворки вам необязательно, однако, если вы решите освоить какой-нибудь из них, знайте, что существует их очень много. Из того, что я пробовал, мне больше всего понравились Bootstrap, Materialize и Bulma. Если вы выбираете фреймворк с учётом его рыночной востребованности, обратите внимание на Bootstrap. Я бы точно выбрал его, если бы сейчас задумывался об освоении CSS-фреймворка.
Организация CSS
По мере роста вашего веб-приложения растёт и объём CSS, в описания стилей проникает беспорядок, ими становится тяжело управлять. Существует множество способов структурирования CSS с учётом нужд масштабирования. Тут можно отметить OOCSS, SMACSS, SUITCSS, Atomic, BEM. Вам следует получить представление о них, понять различия между ними. Я бы в подобной ситуации, для более глубокого изучения, выбрал BEM.
Средства для сборки проектов
Инструменты для сборки проектов помогают в ходе разработки JS-приложений, в частности, позволяя упаковывать ресурсы приложения в пакеты. В эту категорию входят линтеры, средства для выполнения задач и средства для создания пакетов.
В области средств для выполнения задач существует множество вариантов, включая npm-скрипты, gulp, grunt и другие. Но в наше время, когда большинство задач, которые обычно решали с помощью gulp, можно решить с помощью Webpack, в этой категории, пожалуй, стоит обратить внимание лишь на npm-скрипты, используя их для автоматизации задач, которые не может выполнить Webpack. Вам необязательно изучать gulp, однако, если вы найдёте время, взгляните на него — возможно, он окажется полезным в вашем проекте.
В области линтеров, опять же, существует масса вариантов: ESLint, JSLint, JSHint, JSCS. Однако сейчас наибольшей популярностью пользуется ESLint, поэтому вы вполне можете остановиться на нём.
В вопросе инструментов для создания пакетов можно наблюдать ту же ситуацию. Тут есть Parcel, Webpack, Rollup, Browserify, и так далее. Если вы хотите выбрать какой-то один, можете без лишних раздумий остановиться на Webpack. Rollup тоже весьма распространён, но его рекомендуется использовать, в основном, для библиотек. Если же речь идёт о веб-приложениях — тогда вам нужен Webpack. Поэтому освойте Webpack, а позже, если хотите, разберитесь с Rollup.
Практика
После того, как вы освоите всё то, о чём шла речь выше, у вас появится очередной повод для праздника. Фактически, вы теперь стали современным JS-разработчиком примерно на 75%. Помните о том, что практика — это очень важно, поэтому создайте какой-нибудь проект, используя всё то, что уже изучили. Может быть — это будет некая библиотека, в которой будут применены возможности Sass и JavaScript. Завершив работу, используйте Webpack для преобразования Sass в CSS, примените babel для транспиляции ES6-кода. А когда всё будет готово — опубликуйте свою разработку на GitHub и выложите в npm.
Выбор фреймворка
В старой версии схемы, которую мы рассматриваем, шаг выбора фреймворка следовал сразу за освоением основ, но теперь я поместил его после Sass, инструментов для сборки проектов и менеджеров пакетов, так как всем этим вы будете пользоваться при работе с фреймворками.
В том, что касается выбора фреймворка, можно отметить несколько вариантов, однако наиболее распространёнными являются React, Vue и Angular. Причём в наши дни потребность рынка в React.js всё растёт и растёт. Однако выбрать можно любой из перечисленных фреймворков. Я бы, например, выбрал React или Angular. Стоит отметить, что вам, как начинающему разработчику, Angular может показаться проще в сравнении с React, возможно, из-за того, что Angular поддерживает практически всё, что нужно для работы, что называется, «из коробки». Это — мощный маршрутизатор с поддержкой ленивой загрузки, HTTP-клиент, поддерживающий перехватчики, средства для внедрения зависимостей, инкапсуляция CSS компонентов, и так далее. Используя Angular, вы будете избавлены от забот о подборе внешних библиотек. Однако React пользуется большей популярностью, вокруг него сложилось замечательное сообщество, Facebook активно занимается его развитием. Тут мне хочется отметить, что выбирать фреймворк, основываясь только лишь на его «популярности» не стоит. Лучше всего — оценить альтернативные варианты, сравнить их, «примерить» их к нуждам своего проекта и сделать выбор.
Тут я не буду рассказывать о том, как я работал с Angular и React, не буду сравнивать их. Пожалуй, это — тема для отдельной статьи. Однако, раз уж мы говорим об освоении технологий, рассмотрим кривые обучаемости для Angular и React.
Кривые обучаемости, представленные ниже, построены с учётом того факта, что разработчик уже знаком с TypeScript и RxJS. Описание особенностей этих кривых достойно самостоятельного материала, тут я лишь отмечу, что они выглядят именно так благодаря стандартизации и возможностям, которые присутствуют в Angular по умолчанию. Это не означает, что React в чём-то плох. У каждого из этих фреймворков есть своя область применения. Итак, вот эти кривые.
Кривые обучаемости для React и Angular
После выбора фреймворка для освоения, вам придётся выбрать и ещё кое-что. Например, если ваш выбор пал на React, вам может понадобиться изучить Redux или Mobx для целей управления состоянием приложения. Что именно выбрать — зависит от размера приложения, над которым вы будете работать. Mobx подходит для малых и средних приложений. Redux лучше подходит для крупных проектов. Кроме того, возможно, что ни Redux, ни Mobx могут вам и не понадобиться, и ваше приложение вполне сможет обойтись стандартными средствами для управления состоянием, присутствующими в React.
Если вы выбрали Angular, вам понадобится изучить TypeScript. Разрабатывать Angular-проекты можно и без TypeScript, но, всё же, рекомендуется применять именно этот язык. Кроме того, вам надо будет освоить и RxJS — это очень вам пригодится при разработке Angular-приложений. Это — по-настоящему мощная библиотека, которая, кроме того, подходит для функционального программирования.
Если вы выберете Vue.js, то вам может понадобиться изучить Vuex. Эта библиотека очень похожа на Redux, но предназначена для Vue.
Тут следует понимать, что Redux, Mobx и Rx.js не привязаны к соответствующим фреймворкам. Эти библиотеки можно использовать и в приложениях, написанных на чистом JavaScript. И, если вы выбрали Angular — обратите внимание на то, что это должен быть Angular 2+, а не Angular 1+.
Практика
Теперь вы знаете практически всё, что может понадобиться для разработки современных веб-приложений. Не забывая о практике, создайте что-нибудь на основе выбранного фреймворка. Если вам нужны идеи — поищите в интересных вам GitHub-репозиториях папки
ideas, выберите то, что вам понравится, и приступайте.После того, как вы сделаете то, что решили сделать — почитайте материалы об измерении и улучшении производительности. Например, обратите внимание на такие вещи, как Interactivity Time, Page Speed Index, Lighthouse Score, и так далее.
Прогрессивные веб-приложения
Освоив всё то, о чём мы до сих пор говорили, разберитесь с сервис-воркерами и с тем, как создавать прогрессивные веб-приложения.
Тестирование приложений
В сфере тестирования существует масса инструментов, ориентированных на различные цели. Я, в основном, пользуюсь комбинацией из Jest, Mocha, Karma и Enzyme. Однако прежде чем вы выберете свою библиотеку для тестирования, полезно будет разобраться с различными типами тестов, проанализировать доступные инструменты и выбрать те, которые лучше всего вам подходят. Вот хороший материал о современных средствах JS-тестирования.
Статическая проверка типов
Средства для статической проверки типов помогают контролировать типы данных в JavaScript-приложениях. Нельзя сказать, что изучать их обязательно, но они, определённо, способны принести огромную пользу, да и освоить их, вывести на уровень практического использования, можно буквально за несколько часов. Я, в основном, имею в виду TypeScript и Flow. Лично я отдаю предпочтение TypeScript, но вам советую опробовать и то и другое, а потом уже решить — что вам больше понравится.
Серверный рендеринг
Если вы изучили всё то, о чём мы говорили, ваших знаний будет достаточно для того, чтобы получить должность фронтенд-разработчика. Однако, это — не повод останавливаться.
Изучите возможности серверного рендеринга в выбранном вами фреймворке. Как именно это будет выглядеть — зависит от фреймворка. Например, в сфере React особое внимание стоит обратить на Next.js и After.js. В случае с Angular — это Universal. Если речь идёт о Vue, то это — Nuxt.js.
Итоги
Не берусь говорить о том, что в представленной здесь схеме предусмотрено абсолютно всё. Однако она содержит всё то, что нужно любому, кто претендует на должность фронтенд-разработчика. Главное — не забывайте о том, что успех вашего обучения основан на практике. Больше практики — лучше результат. Поначалу объём информации, которую надо освоить, может и испугать, вам может казаться, что вы чего-то не понимаете, не ухватываете суть, но это нормально, и со временем вы будете замечать, что становитесь всё лучше и лучше в осваиваемом вами деле.
Уважаемые читатели! Если вы работаете в сфере фронтенд-разработки, просим вас рассказать о том, как вы научились тому, что умеете, и как поддерживаете свои знания и навыки в актуальном состоянии.
Топ-5 JS-фреймворков для фронтенд-разработки в 2020 году. Часть 1 / RUVDS.com corporate blog / Habr
Вероятно, фронтенд-разработчикам знакомо нечто подобное: вводишь в поисковике «лучшие JavaScript-фреймворки» и получаешь в ответ целую гору результатов, из которой очень непросто выбрать именно то, что нужно.Что лучше всего подходит для разработки клиентских частей веб-проектов? Автор материала, первую часть перевода которого мы сегодня публикуем, говорит, что она, как человек, полный рабочий день занимающийся программированием, знает, что фронтендеры ищут то, что позволит им ускорить работу и облегчить создание интерфейсов.
В основу составления этого рейтинга фреймворков и библиотек легли результаты опроса более чем 450 разработчиков из ValueCoders. Сюда попали пять наиболее интересных инструментов.
Разработчики из ValueCoders выбирают React
Я, когда узнала о том, что мои коллеги голосуют за React, не удивилась. Большинство участников опроса сочло React одной из лучших JavaScript-библиотек. Наши разработчики использовали React во множестве проектов. Это позволило ясно увидеть сильные стороны этого инструмента. Тот, кто пользуется React, получает комбинацию из следующих возможностей:
- Компоненты, пригодные для многократного использования.
- Синхронизация состояния приложения и интерфейса.
- Системы маршрутизации и шаблонизации.
Наши разработчики серьёзно полагаются на возможности React при создании логики фронтенд-проектов. Инструмент это очень мощный, но, в то же время, что меня удивило, пользоваться им на удивление легко.
Обзор нашего приложения
Наше приложение устроено довольно просто. Это — программа для учителей музыки, которая помогает им управлять занятиями в онлайн-школе. Этот проект помогает учителям заниматься своим основным делом, облегчая решение организационных задач.
Главной сложностью в создании этого проекта стала разработка панели управления, предназначенной для учителей. Она позволяет им управлять занятиями учеников и отслеживать их достижения. Мы решили эту задачу, положив в основу приложения экосистему библиотеки Redux. А именно, мы создали раздел приложения, предназначенный для преподавателей, пользуясь которым они могли получать сведения о достижениях учеников, демонстрировать им новые музыкальные уроки, общаться с ними, сравнивать с чем-либо их игру, оставлять им отзывы.
Сведения об ученике и о его занятиях
Собственно говоря, я получила опыт работы с React в ходе создания этого приложения. Означает ли это то, что React — это признанный всеми лидер фронтенд-инструментов? Нет, не означает. Многие, например, могут особо отметить Vue, назвав этот фреймворк одним из лучших и вспомнив о богатом наборе имеющихся в нём стандартных вспомогательных средств.
В общем-то, решение о том, какой фреймворк подойдёт для решения конкретной задачи, принимают именно фронтенд-разработчики. Принимая подобные решения, они встают перед необходимостью ответить на массу непростых вопросов. При этом, учитывая то, что на выбор инструмента у разработчиков обычно почти нет времени, они, как правило, останавливаются на том, что знают. При этом они упускают потенциальные плюсы конкурирующих технологий. Например — речь может идти о том, что фреймворк, знакомый разработчику, если сравнить его с чем-то ещё, может оказаться далеко не самым быстрым.
А для начинающих разработчиков сложно даже сделать выбор, ограничив варианты тройкой ведущих фреймворков — Angular, React и Vue. Мы, для того, чтобы облегчить подобный выбор, отобрали 5 самых интересных фронтенд-фреймворков и библиотек, на которые стоит обратить внимание тем, кто собирается заниматься веб-разработкой в 2020 году.
Большая пятёрка фронтенд-инструментов
Если отталкиваться от популярности и распространённости инструментов фронтенд-разработки, то вот — пять наиболее заметных JavaScript-фреймворков и библиотек:
- React
- Vue
- Angular
- Ember
- Backbone.js
Вокруг каждого из этих инструментов сложилось значительное сообщество разработчиков. И если вы ищете основу для своего очередного веб-проекта, то вы не прогадаете, сделав ставку на один из этих инструментов. Вот сведения по ним за последние шесть месяцев, собранные средствами npmtrends.com.
Объёмы загрузок пакетов angular, ember-source, react, vue и backbone
Сравнение пакетов angular, ember-source, react, vue и backbone
Теперь поговорим о каждом из этих проектов. Начнём с React.
1. React
В JavaScript-мире React — это, определённо, лидер. В этой библиотеке используются идеи реактивного программирования, она вводит во фронтенд-разработку и множество собственных концепций.
Для того чтобы гибко использовать React в разработке веб-проектов, нужно изучить множество дополнительных инструментов. Вот, например, далеко не исчерпывающий список подобных инструментов, представленный библиотеками, которые можно использовать совместно с React. Это — Redux, MobX, Fluxy, Fluxible, RefluxJS. В React-разработке, кроме того, можно использовать jQuery AJAX, Superagent, Axios и Fetch API.
▍Конкурентный режим
Вот твит от 24 октября сего года, в котором сообщается о введении в React экспериментальной возможности по поддержке конкурентного режима (Concurrent Mode). Разработчики React постоянно улучшают этот режим. Здесь можно найти ссылки на выступления с React Conf 2019, посвящённые конкурентному режиму и другим нововведениям React, таким, как рендеринг ленивых (создаваемых с помощью
React.lazy) компонентов внутри компонентов React.Suspense. Обе эти технологии позволяют сделать React-приложения более отзывчивыми за счёт выполнения рендеринга без блокировки главного потока. Это позволят React не задерживать обработку высокоприоритетных задач, таких, как формирование реакции приложения на воздействия пользователя.▍Suspense и другие технологии
Технология
React.Suspense позволяет улучшить обработку асинхронной загрузки данных в React-приложениях. Если описать эту технологию в двух словах, то можно сказать, она позволяет организовать ожидание компонентом выполнения неких условий и при этом не нарушать работу всего приложения.Ещё одно новшество, появившееся в React 16.8, это хуки (Hook). Хуки React позволяют разработчику пользоваться важнейшими возможностями React и при этом обойтись без применения компонентов, основанных на классах. Среди таких возможностей — управление состоянием компонента и работа с методами его жизненного цикла. React содержит несколько встроенных хуков, но при этом позволяет программисту создавать собственные хуки.
React-приложения состоят из компонентов, которые содержат логику работы приложения и HTML-разметку для формирования интерфейса. Для того чтобы улучшить взаимодействие между компонентами, разработчик может воспользоваться Flux или похожей JavaScript-библиотекой.
В React-программировании используются такие понятия как состояние (state) и свойства (props) компонента. Они представлены соответствующими объектами. Их использование позволяет организовать хранение данных в компоненте и обмен данными между компонентами. Например — передачу данных из программной логики, реализуемой компонентом, в интерфейс приложения, или передачу данных от родительских компонентов дочерним компонентам.
▍Элементы экосистемы React
Вокруг библиотеки React сложилась целая экосистема, представленная различными вспомогательными инструментами и библиотеками. Вот некоторые составные части этой экосистемы:
- Сама библиотека React и React Router — средство для управления маршрутами в приложении.
- Пакет react-dom, предназначенный для работы с DOM.
- Инструменты разработчика React для браузеров Firefox и Chrome.
- JSX — язык разметки, который позволяет описывать HTML-элементы в JavaScript-коде.
- Средство командной строки create-react-app, которое предназначено для создания шаблонных React-проектов.
- Различные вспомогательные библиотеки. Среди них, например, можно отметить библиотеку Redux, используемую для управления состоянием приложений, и библиотеку Axios, используемую для обмена данными с серверными API.
Завершая разговор о React можно сказать, что эта библиотека вполне может стать оптимальным выбором для тех, кто планирует создать продвинутый веб-проект.
2. Angular
На конференции AngularConnect 2019 команда разработчиков Angular сделала заявления, которые позволяют считать выход Angular 9 поворотной точкой в развитии этого фреймворка. В частности, планируется сделать компилятор Angular Ivy стандартным средством, доступным для всех приложений. Основные преимущества этой технологии заключаются в том, что её применение позволяет ускорить процесс разработки, уменьшить размер приложений, повысить их производительность и надёжность.
Современный Angular — это продвинутый модульный фреймворк для фронтенд-разработки. Раньше для подключения Angular к странице достаточно было просто добавить в её HTML-код соответствующий тег, теперь же разработчик может импортировать в свой проект необходимые ему модули Angular.
Angular известен своей гибкостью. Именно поэтому всё ещё актуальны версии Angular 1.x. Однако многие разработчики в наши дни пользуются Angular 2+ из-за MVC-архитектуры фреймворка, которая значительно изменилась в сторону архитектуры, основанной на компонентах.
Тому, кто хочет пользоваться Angular, придётся, при освоении этого фреймворка, столкнуться с некоторыми трудностями. Так, для создания Angular-приложений практически обязательно использовать TypeScript. Хотя это и усложняет работу с Angular, у такого положения дел есть свои плюсы. В частности, это повышает надёжность приложений за счёт продвинутого контроля типов, это даёт программисту дополнительные средства разработки.
▍Элементы экосистемы Angular
Вот некоторые составные части экосистемы Angular:
- Инструменты командной строки, упрощающие создание заготовок приложений.
- Набор модулей, которые можно использовать при разработке Angular-проектов:
@angular/common,@angular/compiler,@angular/core,@angular/forms,@angular/http,@angular/platform-browser,@angular/platform-browser-dynamic,@angular/routerи@angular/upgrade. - Библиотека Zone.js, которая позволяет управлять контекстами выполнения кода.
- Языки TypeScript и CoffeeScript.
- Обмен данными в Angular-приложениях можно организовать с использованием RxJS и наблюдаемых (Observable) объектов.
- Angular Augury — средство для отладки Angular-приложений.
- Технология Angular Universal, предназначенная для организации серверного рендеринга Angular-приложений.
Angular — это полноценный JS-фреймворк, дающий современному веб-программисту всё необходимое для продуктивной работы. На Angular стоит обратить внимание тем, кому хотелось бы получить в своё распоряжение обширный набор стандартных средств и свести к минимуму использование сторонних библиотек.
Продолжение, часть 2
Уважаемые читатели! Если бы вам предложили назвать лучший фреймворк для фронтенд-разработки — что бы вы выбрали?