компоненты фронтенд части разрабатываемого приложения
34 лучших инструмента для frontend-разработчика
Мы собрали 34 популярных технологий и инструментов frontend-разработчика для начинающих.
Frontend-разработка — создание удобной, красивой и эффективной клиентской части приложения. Многие новички начинают именно с этого направления программирования, изучая языки разметки — HTML и CSS, постепенно подключая JavaScript и технологии на его основе.
От выбора инструментов зависят качество и скорость работы, а определяется он задачами, которые проект решает. Допустим, большинство сайтов сегодня создается при помощи фреймворков. Но порой проект можно написать на чистых CSS, HTML и JavaScript, а не накладывать новый слой абстракции, замедляя производительность. Но хватит лирики: расскажем о самых важных инструментах, которыми должен владеть начинающий frontend-разработчик.
CSS-препроцессоры
Это надстройки над самим CSS, открывающие новые возможности языка и делающие процесс работы проще и доступнее для разработчика с помощью особых конструкций. Программисты называют их «синтаксическим сахаром».
«Синтаксический сахар» — конструкции, которые не вносят ничего принципиально нового в технологию, но делают работу с ней удобнее, проще и человечнее.
Такой код будет на 100% валидным, но выглядит ужасно. Зато с помощью препроцессора он станет таким:
Термины «фронтенд», «клиентская сторона» и «интерфейс» — как употреблять и не облажаться
До работы редактором и контент-маркетологом в компании Лайв Тайпинг я два года занимался гуманитарными текстами: редактировал и писал статьи про моду, музыку, кино, изобразительное искусство, социологию и тому подобное. От меня требовалось не столько корректно донести смысл, сколько добиться яркого образа, создать настроение и подарить читателю эмоцию. Это развязывает руки в отношениях со словами: прежде имевшие точный смысл, они становятся сырьём для аллегорий, метафор и других литературных приёмов.
Попав в техническую среду, я понял, что словесные украшательства мешают функции. Вместе с трендом инфостиля это заставило меня пересмотреть подход к работе с текстами. В том числе пришло время вспомнить, что у каждого термина есть своё значение.
При работе над кейсом проекта Designet я поймал себя на том, что считаю термины «фронтенд», «клиентская сторона» и «интерфейс» синонимами. Чтобы расставить все точки над i и больше их не путать, я написал эту памятку. Надеюсь, что она поможет не только мне, но и коллегам — редакторам, копирайтерам, техническим журналистам, маркетологам, менеджерам проектов и всем, кто не имеет прямого отношения к программированию.
Интерфейс
Всё, что помогает человеку управлять инструментом, будь то программа, компьютер, бытовой прибор или панель заводского станка — это интерфейс. Элементами интерфейса являются меню, кнопки, клавиатура, мышь, монитор, переключатели, тумблеры, тулбары, поля для набора текста, экраны с ошибками и прочие способы взаимодействия и ввода/вывода информации. Применительно к интерфейсу программ и приложений в английском языке встречается словосочетание user interface (UI).
Интерфейс — это всё, что вы видите и что можете потрогать.
Интерфейс может быть удобным и неудобным. Критерием удобного интерфейса по сегодняшним меркам считается короткая череда действий, которая не бесит, не смущает, не выматывает и в итоге даёт желаемое. Сумма ощущений от пользования интерфейсом называется опытом взаимодействия, пользовательским опытом или user experience (UX). Он тоже может быть плохим или хорошим.
Интерфейс поисковой страницы Google — пример интерфейса с UX уровня «дзен».
Файловый менеджер FileMatrix — пример ужасного интерфейса из обсуждения на Stack Overflow. Не лезь, он тебя сожрёт.
Чем больше в интерфейсе действий, тем дольше пользователю придётся продираться к функциональностям программы, сайта или приложения, и тем быстрее он плюнет на это и пойдёт искать интерфейс с единственной кнопкой, приносящей результат.
Фронтенд
Если интерфейс — это прослойка между пользователем и кодом, запускающая последний в работу, то фронтенд — это тот самый код и есть. Возьмём, например, какую-нибудь страницу «Википедии». Чтобы открыть её, мы даём команду браузеру: «А покажи». Браузер запрашивает у внешнего сервера строительный материал страницы — код. Этот код исполняется на странице и рисует то, что вы попросили у браузера.
Стоит заметить, что часто под фронтендом понимают веб-разработку. Из-за двойственности в определении существует спор, как писать этот термин по-английски: раздельно или через дефис. Свет на проблему проливает эта публикация.
Фронтенд складывается из взаимодействия трёх технологий:
Одно нажатие F12, и страница показывает всё, что под ней спрятано.
Клиентская сторона
Средство, которое принимает данные и показывает их в понятном человеку виде, называется клиентской стороной, или клиентом. Этим средством является браузер, мобильное приложение, работающее с данными с сервера, компьютер, телефон, планшет, телевизор или радиоприёмник.
Этих клиентов уже никто не обслужит.
Понятие о клиентской стороне вышло из парадигмы клиент-серверной архитектуры. Она появилась вместе с первыми компьютерными сетями: разработчики решили, что часть общих ресурсов можно хранить за пределами устройства. Устройство в таком случае — это клиент: он получает данные от внешнего сервиса, отрисовывает их в себе и отправляет вносимые изменения обратно на сервис.
Закрепление
Клиент — это устройство для оперирования удалёнными данными.
Интерфейс — это набор элементов для управления программой или устройством
Фронтенд — это код, принятый клиентом, запущенный на нём и ставший интерфейсом, или веб-разработка на клиентской стороне как таковая.
Не так страшно повторять в тексте один и тот же термин, как безрассудно заменять его на неправильные синонимы. Если вы хотите указать на неточности и спорные моменты или высказать что угодно по теме — добро пожаловать в комментарии.
Фронтенд-разработка в компании: что это и как сделать её эффективной
Мы в компании КОРУС Консалтинг СНГ уже больше десяти лет занимаемся организацией разработки веб-сервисов для наших заказчиков. У нас за плечами уже несколько десятков серьёзных проектов в банковской сфере, некоторые из них получили международное признание.
За последние два года количество команд и проектов в нашей компании увеличилось в несколько раз, при этом многократно выросла и эффективность frontend-разработки. Мы научились создавать приложения за несколько недель вместо нескольких месяцев.
Мы постоянно работаем над развитием инфраструктуры нашей фронтенд-разработки, и сегодня я поделюсь некоторыми наработками на тему организации фронтенд-подразделения, которые могут пригодиться тем, кто занимается организацией фронтенда у себя в компании.
Из этой статьи вы узнаете о нашем пути к ответам на следующие вопросы:
Что такое современный фронтенд
Фронтенд-часть сайта или приложения — это то, что вы видите у себя в браузере, эта часть активно взаимодействует с серверной (backend) частью, которая находится на каком-либо сервере, постоянно обмениваясь с ней данными.
С технической точки зрения фронтенд-часть приложения — это набор файлов, среди которых есть файлы HTML, CSS и JavaScript, картинки и т.п. Работу с CSS и HTML относят к вёрстке, JavaScript — к программированию. Оба этих направления предлагают большое количество инструментов и технологий для работы, активно развиваются и требуют большого количества знаний. Особенно это относится к JavaScript, на котором написано гигантское количество фреймворков и библиотек для «всё более эффективного» создания веб-приложений.
Как-то у меня спросили, на чём сейчас нужно делать приложения, чтобы они не устарели ещё несколько лет?
Как программист, могу дать совершенно точный и совершенно бесполезный ответ: на HTML, CSS и JavaScript. Что конкретно выбрать, jQuery, Angular или React — это уже детали.
Если углубиться в эти детали, можно дать ещё один такой же правильный и бесполезный ответ: на чём угодно. Да, это действительно так. Приложение может быть написано на чём угодно, оно будет работать, его можно будет менять и развивать.
В чём же всё-таки разница?
Чтобы найти ответ, давайте разберём, что хочет бизнес от фронтенда. Я думаю, что никого не удивлю, если скажу, что бизнес хочет быстро и недорого получить качественный результат.
Итак, на чём сейчас нужно делать приложения, чтобы разработка шла быстро, качественно и не разорила заказчика?
Скорость разработки
Программист с большим опытом работы с React сможет быстро написать приложение на React, наличие опыта работы с Angular даёт скорость работы с Angular и так далее. Всё достаточно очевидно. Сами по себе фреймворки экономят время разработки тем, что дают решения типичных проблем и задач. Эти решения по сути могут быть очень близки друг другу, и разница между ними может заключаться в синтаксисе или парадигме программирования.
Скорость разработки с использованием определённого фреймворка зависит от опыта и квалификации программистов, которые на нём пишут, сам фреймворк здесь имеет второстепенное значение.
Качество продукта
Здесь то же самое: и хорошо, и плохо можно писать на любом фреймворке. Можно заложить правильную и неправильную архитектуру куда угодно.
Всё зависит от опыта и знаний разработчика.
Стоимость
Все основные современные фреймворки бесплатны, поэтому, если опустить детали, то стоимость разработки — это стоимость времени, которое разработчики потратили на изучение требований, технологий, проработку архитектуры и написание кода. Плюс стоимость поиска/обучения этих разработчиков.
Отсюда вывод: нужно делать ставку не столько на технологии, сколько на разработчиков и организацию их работы.
Практически любой современный популярный фреймворк достаточно хорош, чтобы на нём создать практически любое приложение, которое может потребоваться современному бизнесу.
Поэтому дальше будет про эффективность фронтенда с точки зрения организации разработки.
Как это было у нас
К 2017 году у нас были приложения практически на всём, что заслуживало внимания в мире JavaScript: от jQuery до разных версий Angular и React на Typescript и Flow. Над клиентской частью наших приложений работали верстальщики и backend/fullstack-разработчики. Каждый разработчик выбирал инструменты под свои задачи, в зависимости от своих знаний фронтенд-технологий.
Сейчас я могу только предполагать, но мне кажется, что выбор фреймворков и библиотек fullstack/backend-разработчиками происходил примерно так:
«Посмотрим, что у нас пишут в интернетах. »
При выборе фреймворка/библиотеки разработчик ограничен во времени, чаще всего ему некогда самостоятельно разворачивать новые для него фреймворки и делать тестовые приложения. Поэтому он как-то делает более-менее аргументированный выбор и дальше следует в выбранном направлении.
В разные моменты времени этот выбор может быть разным даже у одного и того же разработчика (см. иллюстрации выше). При этом менее аргументированным он не становится. Чего же тогда ожидать от разных разработчиков с разным опытом?
Незаметно к 2017 году мы превратились в настоящий зоопарк фронтенд-технологий.
Фронтенд как отдельное подразделение
Большое количество разных технологий в компании — это источник рисков. Разработчик с нужными знаниями может быть занят на другом проекте, может совсем уйти из компании. Найм специалистов с большим опытом в разных направлениях — тоже занятие непростое.
Качественная документация может смягчить негативные последствия такого разнообразия, но на её изучение и погружение в незнакомые технологии обычно требуется значительное время.
В 2017 году в нашей компании появилось фронтенд-подразделение, которое стало ответом на растущие требования к качеству фронтенд-части наших проектов и к их количеству, а также попыткой стабилизировать разнообразие технологий и повысить эффективность разработки.
Это было важным этапом для развития нашей компании: то, что мы делаем сейчас, невозможно было бы сделать силами разработчиков без специализации на фронтенде.
Как вылечить зоопарк?
Неконтролируемое разнообразие технологий сильно мешает прогнозировать скорость и качество разработки в целом, тогда как коммерческая разработка требует именно этого.
Поэтому нашим следующим шагом стала унификация стека компании силами экспертов нового подразделения.
Унифицированный стек — это строго ограниченный набор библиотек и инструментов, который разработчики могут использовать при решении задач бизнеса. Также туда входит политика в отношении разных подходов в программировании, например, использование преимущественно функционального подхода, или наоборот, отказ от него.
Единый стек даёт разработчику возможность быстро переходить с одного проекта на другой, проводить кросскомандное ревью, эффективно делиться опытом и наработками с коллегами.
Главная задача здесь — не решить, что мы теперь пишем на React или Angular, а сделать так, чтобы разработчики пользовались одинаковыми инструментами для создания приложений и одинаковыми подходами к решению типовых задач.
Для справки: наш основной инструмент — React, но мы также развиваем экспертизу и в Angular.
Вот тут и начинается самое интересное. Принудиловка в мире программирования работает очень плохо.
Поэтому вместо принуждения нужно сделать так, чтобы разработчики сами хотели следовать определённым правилам разработки.
Вопрос с мотивацией мы решили следующим образом: лучше всякой документации — дать разработчику полуготовое приложение (шаблон).
Это позволяет разработчикам быстрее решать задачи и впечатлять коллег своей производительностью и одновременно побуждает их придерживаться основных правил, которые уже зашиты в коде.
С одной стороны, похожие друг на друга приложения в итоге дают значительный прирост в скорости разработки за счёт накопления опыта, готовых решений, более глубокого ревью и возможности переходить с проекта на проект. С другой стороны, у каждого проекта есть свои особенности, поэтому здесь тоже важно не перемудрить с шаблонизацией.
Что нужно заложить в шаблон приложения
При старте новых проектов разработчики обычно решают следующие типовые задачи:
Шаблон приложения, который мы разработали, закрывает первые три пункта из этого списка. Мы выразили в этом шаблоне не только наши пожелания к единому стеку для разработки, но и основные правила архитектуры приложения.
По сравнению с популярными решениями, которые находятся в открытом доступе (например, create-react-app), наш шаблон уже содержит:
Но дальше разработчика ждёт большое количество других интересных (и не очень) задач.
Выбор библиотеки компонентов
Всё, что касается вёрстки, компонентов интерфейса (выпадающих списков, календарей и т.д.), форм и валидации мы решили с помощью собственной библиотеки. Это была самая сложная часть.
В 2017 основной библиотекой компании была платная библиотека компонентов Kendo, которая предоставляла UI-решения для разных технологий, начиная с jQuery. По разным причинам она нас не устраивала, и мы решили рассмотреть альтернативные библиотеки, в том числе и вариант с созданием собственной.
Это очень важный момент, в который нужно сделать правильный выбор: найти другую библиотеку, которая нам лучше подойдёт, или создать собственную. От этого выбора зависит дальнейшее распределение ресурсов разработки и время, которое тратят команды на создание и доработку элементов интерфейса. В своём выборе мы исходили из следующих соображений.
Готовые библиотеки
Плюсы готовых библиотек:
Собственные разработки
Плюсы собственных разработок:
Получается, что приходится выбирать между установкой сразу готового функционала с кучей ограничений и разработкой собственных решений с необходимостью ждать и тратить дополнительные ресурсы на разработку.
Ни один из вариантов нас полностью не устраивал, и мы нашли другое решение.
Мы решили сделать свою надстройку над готовой библиотекой.
Напомню, что на тот момент мы уже пользовались в чистом виде библиотекой Kendo, альтернативу которой мы хотели найти. Именно её мы и решили взять за основу нашей основной библиотеки компонентов для приложений на React. А сама наша новая библиотека представляла из себя фасад над Kendo. Я опущу технические детали, скажу только, что такое решение позволило сразу получить весь функционал Kendo, а то, чего нам не хватало, в том числе и оперативное исправление багов, мы делали сами в прослойке между клиентским API библиотеки и Kendo.
Такая архитектура позволила быстро расширять количество компонентов за счёт других библиотек и модулей, просто встраивая их в нашу прослойку. Для клиентов библиотеки (для разработчиков приложений) это выглядело как быстрый прирост функционала одной библиотеки (об этом я расскажу подробно в отдельной статье).
Со временем мы заменили все компоненты на собственные реализации и выпустили вторую версию библиотеки, где учли весь предыдущий опыт, переработали API и сделали собственную документацию.
Мы решили выложить наши наработки в открытый доступ, скоро их можно будет скачать и использовать в своих проектах, следите за анонсами.
Что в итоге у нас получилось
Сейчас у нас на одном стеке и с одним набором технологий работает больше 10-ти фронтенд-разработчиков в нескольких командах. На одном стеке мы создали уже около двадцати проектов.
Статистика показывает, что эффективность работы за два года выросла более, чем в три раза. Проекты, на которые мы раньше тратили 4-6 месяцев, теперь мы делаем за 1-2 месяца (речь идёт о фронтенд-части).
Мы начали сокращать время разработки за счёт изменения структуры задач программистов. Давайте посмотрим на то, как они изменились.
Я уже приводил список задач, которые решали разработчики два года назад:
Это сказалось не только на скорости работы, но и в целом на настроении разработчиков. Как ни крути, реализация бизнес-логики куда интереснее, чем настройка выпадающих списков. Проджект-менеджеру также гораздо проще объяснить заказчику, что неделя рабочего времени была потрачена на разработку важных бизнес-фич, а не на то, что потребовалась доработка небольшого элемента интерфейса, хотя по трудозатратам они могут быть вполне равнозначными.
Мы продолжаем работу в выбранном направлении и одна из основных задач на ближайшее будущее — повышение мотивации разработчиков к углублению компетенций в выбранном стеке и к поиску новых эффективных решений. Масштабирование таких решений на всю компанию теперь не составляет особого труда благодаря общей библиотеке и шаблону приложения.
С пожеланиями эффективности и до новых встреч!
Технологии фронтенд-разработки, на которые вы, возможно, не обратили внимания
«Хочешь жить — умей вертеться». Это — про работу фронтенд-программиста. Для того чтобы успешно справляться со своими обязанностями, такому специалисту приходится решать массу задач и необходимо обладать множеством способностей. Очень важно, кроме того, не забывать о главной цели, ради которой разрабатывают сайты. А именно, о том, что сайты должны помогать людям упрощать решение их повседневных задач.
В этом материале я собираюсь рассказать о различных аспектах веб-разработки, о которых стоит знать любому программисту соответствующего профиля. Я, если это возможно, буду приводить ссылки на материалы, демонстрирующие примеры применения соответствующих возможностей и рекомендации по их правильному использованию. Здесь я буду ориентироваться на реализацию тех или иных механизмов в Angular, React и Vue.
Пользовательский интерфейс
▍Макет страницы
Создание веб-приложения начинается с проектирования привлекательного и аккуратного макета, который понравится пользователям и будет способствовать тому, что они проведут на соответствующем сайте достаточно много времени.
Существует множество CSS-фреймворков. Возможно, среди них вы обнаружите именно тот, который вам идеально подойдёт. Самый знаменитый из них — это Bootstrap и, благодаря новым возможностям CSS-препроцессоров, вы можете подвергнуть стили этого фреймворка глубокой настройке. В нём вы можете найти различные компоненты и элементы управления, последовательное использование которых позволит создавать единообразно оформленные сайты.
В настоящий момент вышел альфа-релиз 5 версии Bootstrap.
Если вы предпочитаете создавать наборы стилей для своих проектов самостоятельно (компоненты, отступы, контейнеры и так далее), можете обратить внимание на CSS Flexbox, сделав этот способ гибкого размещения элементов веб-страниц основой вашего собственного CSS-фреймворка.
CSS Grid использует другой подход к организации материалов веб-страниц, размещая их в сетке.
▍Отзывчивый дизайн
Отзывчивостью называют возможность сайта адаптировать своё содержимое к устройству, на котором его просматривают. Например, на смартфоне и на ноутбуке эта статья будет выглядеть по-разному.
Отзывчивость веб-приложения помогает ему правильно отображаться на разных экранах, улучшает читабельность контента и пользовательский опыт.
На MDN можно узнать о том, что медиазапросы используются в тех случаях, когда нужно применить разные CSS-стили для разных устройств (например, для принтера или монитора), а также с учётом конкретных характеристик и параметров устройства (например, для разного разрешения экрана или для разной ширины области просмотра браузера).
CSS-медиазапросы — это мощное средство поддержки отзывчивого дизайна.
Их можно использовать вместе с уже упомянутыми CSS Flexbox или CSS Grid. Если вы предпочитаете пользоваться CSS-фреймворками, то эти фреймворки обычно уже реализуют соответствующие возможности. При таком подходе для создания отзывчивых страниц достаточно добавить к элементам соответствующие классы.
▍Однородные компоненты и элементы управления
Пользователю приятно будет работать с сайтом, компоненты и элементы управления которого оформлены однородно, в едином стиле. Такой подход к оформлению упрощает для пользователя освоение новых возможностей сайта и служит чем-то вроде визитной карточки компании.
Если вы хотите использовать для разработки своих проектов существующие фреймворки и библиотеки, Angular, React или Vue, то вот несколько примеров библиотек стилей, реализующих принципы Material Design, рассчитанных на эти инструменты:
▍Проверка форм и обработка ошибок
Проверка данных — это важнейшая задача тех проектов, которые принимают что-то от пользователя. Кроме того, ничто не должно помешать приложению получить от пользователя корректные данные: ни сетевые проблемы, ни ошибки на сервере, ни ошибки, допущенные самим пользователем. Вот какие решения для проверки пользовательского ввода созданы для различных фреймворков:
Пользовательский опыт
▍Использование асинхронных механизмов
Загрузка данных в приложение или сохранение данных могут занимать миллисекунды, секунды или даже минуты. Именно поэтому важно сообщать пользователю о подобных операциях с помощью соответствующих индикаторов и не блокировать при этом работу пользователя с проектом.
В решении этих задач нам помогут JavaScript-механизмы, вроде промисов, и браузерные API наподобие Fetch.
▍Поддержка устаревших браузеров (полифиллы)
Мир фронтенд-разработки развивается очень быстро. То же самое можно сказать и о браузерах. Но разные люди пользуются различными браузерами и разными их версиями. Поэтому, чтобы обеспечить правильную работу своего кода на всех применяемых платформах, разработчику нужно заботиться о совместимости. Например, старая версия IE не поддерживает те же возможности JS и CSS, которые поддерживает последняя версия Google Chrome.
Для обеспечения правильной работы проекта в старых браузерах применяются полифиллы. Они достаточно хорошо описаны в этом материале: «Полифилл (polyfill, polyfiller) — это фрагмент кода (или подключаемый модуль), который предоставляет реализацию технологии, которую вы, разработчик, ожидаете найти в числе стандартных возможностей браузера».
Для того чтобы узнать, поддерживается ли некое CSS-правило, или некая JS-функция в конкретной версии браузера, загляните на сайт Can I Use.
Если говорить о решении вопросов браузерной поддержки в Angular, React и Vue, то дело обстоит так:
▍Локализация и интернационализация
У вашего сайта могут быть пользователи со всего мира. Учёт этого факта при создании проекта повысит удобство работы с сайтом для всех, кто решит на него заглянуть.
Локализация (l10n, localization) — это, по определению W3C, адаптация содержания продукта, программы или документа к языковым соответствиям, культурным и другим требованиям определённого целевого рынка.
Интернационализация (i18n, internationalization) — это, если опираться на материалы W3C, создание и развитие содержания продукта, программы или документации, позволяющее производить лёгкую локализацию для целевых рынков, различающихся по культуре, региону или языку.
Обе эти концепции взаимосвязаны, они могут быть реализованы разными способами. Сюда относятся, например, следующие технические приёмы:
▍Доступность контента
Доступность (a11y, accessibility), это возможность сайта адаптироваться к нуждам пользователей с ограниченными возможностями.
О доступности веб-сайтов часто забывают. Для того чтобы сделать проект доступным для пользователей с ограниченными возможностями, может понадобиться пересмотреть используемый на нём подход к формированию пользовательского опыта, что иногда может потребовать глубокой переработки проекта. В любом случае, важно учитывать нужды всех пользователей, особенно принимая во внимание то, что даже небольшие изменения кода проекта способны значительно повысить удобство работы с сайтом для тех, кому тяжело пользоваться обычными сайтами.
В деле обеспечения доступности веб-проектов применимы различные технические приёмы. В их число входит следующее:
▍Уведомления
Для того чтобы держать связь с посетителями вашего сайта, можно использовать браузерное API Notifications. С его помощью можно сообщать пользователям о том, что на сайте появилось что-то новое.
Загрузка и обработка данных
▍Единый источник достоверных данных
Средства для управления состоянием приложения, которые обрели популярность в 2015 году, в наши дни являются обязательным компонентом практически любого веб-проекта. Хотя в сфере управления состоянием приложений не всё однозначно, использование специализированных решений обычно является простым и эффективным методом централизованной обработки данных приложения. Все средства для управления состоянием основаны на паттерне Flux.
В этих средствах используются разные названия для одних и тех же сущностей. Например, то, что в NgRx называется selectors, в Vuex называется getters. То, что в Angular получило имя reducers, в Vue называется mutations.
Вот средства для управления состоянием приложений, используемые в Angular, React и Vue:
▍Загрузка данных
Существуют разные способы загрузки данных в приложения. Самый распространённый из них заключается в использовании HTTP-запросов, направленных к веб-API. В браузере имеется API Fetch, предназначенный для организации загрузки данных, но для основных фреймворков и библиотек разработаны собственные решения:
Вот реализации GraphQL для интересующих нас фронтенд-инструментов:
▍Локальное хранение данных
▍Веб-воркеры
Веб-воркеры — это технология, представленная новым браузерным API. Она даёт возможность фонового выполнения JavaScript-кода, снимая нагрузку с главного потока и не влияя на производительность кода веб-страницы.
Веб-воркеры применимы в Angular, React и Vue:
Сеть и производительность
▍Размер бандла приложения
Рост рынка смартфонов стал причиной революции в мире веб-разработки. Теперь при создании веб-сайтов нам нужно, в первую очередь, учитывать нужды мобильных пользователей. Чем меньший объём данных придётся загружать мобильным устройствам при работе с веб-проектами — тем лучше. В соответствии с графиком, показанным ниже, мобильное использование интернета обогнало настольное ещё в 2016 году.
Это недвусмысленно говорит нам о том, как важны в наше время размеры бандлов веб-проектов. Размер загружаемых файлов должен быть, ради экономии ресурсов мобильных пользователей, как можно меньше. К нашему счастью, разработчики основных фронтенд-инструментов и дополнений к ним учитывают это, занимаясь развитием своих проектов. Уменьшение размеров бандлов приложений, кроме того, означает их более высокую производительность.
▍Сервис-воркеры и прогрессивные веб-приложения
Сервис-воркер — это скрипт, который работает в веб-браузере и управляет кэшированием данных приложения. Это — один из механизмов, используемых при превращении обычного веб-сайта в прогрессивное веб-приложение (PWA, Progressive Web Application). С PWA можно работать как с обычным сайтом, пользуясь HTTPS, но прогрессивные веб-приложения обладают некоторыми особыми возможностями. Среди таких возможностей, например, установка таких приложений на мобильные устройства без необходимости публикации их в специализированных магазинах приложений и поддержка работы приложений без доступа к интернету.
Пользоваться сервис-воркерами можно в Angular, React и Vue:
▍Серверный рендеринг
Серверный рендеринг (SSR, Server-Side Rendering) — это набор технологий, который кардинальным образом меняет ситуацию в сфере разработки приложений, основанных на Angular, React и Vue. При использовании SSR HTML-код формируется на сервере и отправляется в браузер. После этого осуществляется приведение статической HTML-разметки в рабочее состояние и на клиенте оказывается полностью готовое к использованию веб-приложение. При применении серверного рендеринга преследуют несколько целей:
▍Генераторы статических сайтов
С ростом масштабов использования Jamstack генераторы статических сайтов (SSG, Static Site Generator) стали крайне востребованной технологией. Jamstack-приложение — это разновидность веб-приложения, материалы которого готовы к визуализации средствами браузера и, по сути, не нуждаются в веб-сервере (эти материалы можно отдавать клиентам прямо с CDN). Подробности о таких сайтах можно найти, пройдя по вышеприведённой ссылке. Перечислим здесь лишь основные сильные стороны SSG:
Аналитика
▍Наблюдение за поведением пользователей и A/B-тестирование
Организация наблюдения за поведением пользователей на сайте — это необязательно, но владение подобными данными вносит значительный вклад в совершенствование веб-проектов. Существует особый класс инструментов, направленных на сбор сведений о работе пользователей с сайтом. Эти инструменты позволяют разработчикам сайтов лучше учитывать нужды пользователей и, благодаря A/B-тестированию, помогают выбирать самые адекватные альтернативы. Речь идёт о возможностях сайтов, о поддерживаемых ими шаблонах поведения пользователей, о дизайне.
Вот некоторые решения, позволяющие организовать наблюдение за поведением пользователей и A/B-тестирование:
▍Анализ производительности веб-проектов
Сложно за один заход разработать высокопроизводительное веб-приложение. Но, например, приложение, которое оптимизировали с целью ускорения его загрузки, вызовет у пользователя больше положительных эмоций, чем его более медленная версия. Существуют различные проекты, анализирующие сайты и выдающие рекомендации по их совершенствованию. Например — PageSpeed Insights от Google.
Среди инструментов разработчика Google Chrome можно найти весьма ценное средство для анализа производительности сайтов — Lighthouse. Оно оценивает сайты по пяти критериям (производительность, доступность, использование «лучших практик», SEO, PWA) используя 100-балльную шкалу. После анализа формируется отчёт с рекомендациями по улучшениям сайта.
Анализ сайта с помощью Lighthouse
Ещё одно средство анализа производительности, которое можно найти среди инструментов разработчика Chrome, это панель Coverage, позволяющая искать неиспользуемый JS и CSS-код. Исключив такой код из проекта, можно уменьшить размер его бандла. А это ускорит загрузку сайта, что будет особенно заметным на мобильных устройствах.
SEO, поисковая оптимизация, это то, чем надо заниматься ради повышения рейтинга сайта в поисковых системах, в таких, как Google, Bing, DuckDuckGo, да и во многих других. Хорошо оптимизированный сайт становится более «заметным». На самом деле, это так важно, что в мире веб-разработки есть даже особая должность: «SEO-специалист».
Если говорить о SEO в Angular, React и Vue, то получится следующее:
Итоги
Я согласен с тем, что фронтенд-разработка — это обширная и постоянно меняющаяся сфера знаний. На самом деле, если кто-то попытается стать универсальным разработчиком, всё знающим и умеющим, ему будет крайне сложно этого достичь, и на это ему потребуется очень много времени. При этом у каждого веб-проекта имеются собственные нужды и приоритеты. Именно поэтому необходимо определиться с самым важным в начале работы над проектом. Это позволит не распыляться, отобрав и изучив лишь самое нужное, и спланировать архитектуру проекта так, чтобы она соответствовала бы его целям.
Какие свежие технологии фронтенд-разработки кажутся вам самыми перспективными?