От автора: часто веб-разработка связана с ошеломляющим опытом. Я постоянно стараюсь оставаться в тренде, изучая новые фреймворки, новые функции языков, иногда изучая совершенно новые языки. Неудивительно, что front-end разработчики часто испытывают стресс.
Но надежда есть: в последние несколько лет, несмотря на то, что все еще происходят чрезвычайно быстрые изменения, и возникают новые среды и пакеты, также произошла некоторая консолидация концепций в несколько мега-трендов. Это то, что нужно знать для front-end разработки.
Если у нас есть понимание этих мега-трендов, это может помочь нам сосредоточиться на том, что стоит изучать. В этом контексте решение о том, какой конкретный фреймворк или инструмент вам учить, воспринимается менее сложным — до тех пор, пока тот, который мы выбрали, вписывается в эти мега-тренды.
Чем больше мы понимаем общую картину, тем проще нам удерживаться на гребне этой сумасшедшей волны, а не чувствовать себя отставшим.
Итак, вот они: Top 5 мега-трендов front-end разработки.
1. Компонентно-ориентированная разработка
В наши дни каждый JavaScript-фреймворк применяет компонентно-ориентированный подход. Неважно, какой из них вы используете — React, Angular, Vue — это большая тройка, но мы также рассмотрим такие инструменты, как Ember, Dojo, Mithril … все они используют компоненты в качестве основной абстракции для представления интерфейса пользователя.
Эта ориентация также присутствует в CSS как на методологическом, так и на базовом уровне. Такие методологии, как BEM, разработаны именно для поддержки компонентно-ориентированного подхода к CSS. UI фреймворки, такие как Bootstrap, Material или Foundation, по сути являются просто наборами готовых компонентов. Это лежит в основе почти всех современных инструментов front-end разработки.
Почему компонентно-ориентированная разработка стала такой популярной? Потому что это позволяет разделить задачи и модульную разработку таким образом, который имеет смысл для пользовательских интерфейсов.
Мы всегда знали о важности модульности кода — это позволяет нам разрабатывать гораздо более сложные системы, сохраняя управляемость кода. Но правильный способ реализовать эту модульность для внешнего интерфейса не всегда был ясен. Подход React, направленный на то, чтобы развивать методы разделения компонентов, а не язык программирования, произвел революцию в мире front-end.
JSX — не всеми любимое решение. Я предпочитаю подход Vue Single File Component, и у обеих сторон есть веские аргументы, как в пользу шаблонных языков, так и включений JavaScript. Несмотря на это, ключевым изменением является ментальный сдвиг в контексте представления компонентов в виде небольших блоков тесно связанных HTML, CSS и JavaScript, которые сами по себе могут быть слабо связаны с другими компонентами.
2. Декларативное кодирование
На заре Интернета, и до сих пор во многих простых не-фреймворк приложениях JavaScript, мы используем императивную парадигму.
Но все чаще JavaScript-фреймворки переходят на использование декларативной парадигмы, когда вместо того, чтобы указывать, как делать что-то, мы описываем результат, а сам фреймворк отвечает за выяснение того, как этого добиться. Теперь мы просто заявляем что нужно, а фреймворк обрабатывает как и когда.
Если мы хотим, чтобы элемент пользовательского интерфейса изменился, мы просто сообщаем платформе, каким должно быть новое конечное состояние, и позволяем ей вносить все обновления, необходимые для этого. Он может использовать такие инструменты, как Virtual DOM, чтобы эффективно вносить эти изменения, и другие вещи, такие как разбивка времени, чтобы это происходило так, чтобы не мешать взаимодействию с пользователем, но нам, разработчикам, не нужно об этом беспокоиться. Это открывает две возможности.
Первое — это феноменальное улучшение читаемости и понятности кода. Вместо того, чтобы копаться во многих строках jQuery для выяснения, что меняется, и пытаться определить, как будет выглядеть конечное состояние, мы можем просто взглянуть на шаблон и увидеть это.
Второе — это возможность воспользоваться опытом авторов фреймворка, чтобы проще и быстрее внедрить лучшие практики. React уже занимается этим с помощью выделения временных отрезков и приостановки компонентов, пока они извлекают асинхронные данные, но я также подозреваю, что этому будет уделено большое внимание в WebAssembly. Чем больше контроля у фреймворка, тем больше он может незаметно сделать для нас под капотом.
3. Консолидация управления состоянием
По мере того, как все больше и больше сложных операций переходило во front-end, нам также приходилось придумывать все более и более эффективные решения для управления состоянием front-end. Чисто компонентно-ориентированная разработка хороша для локального состояния, но иногда нам нужно разделить состояние между разными компонентами. Одна из уникальных задач внешнего интерфейса заключается в реализации того, как все происходит асинхронно, но иногда нам необходимо обеспечить предсказуемость в управлении состоянием. Это касается двух, на первый взгляд, разных, но, по моему мнению, связанных событий.
Первое — это развитие архитектуры Flux. Этот шаблон был реализован в таких инструментах, как Elm, Redux, Vuex. Сила этой архитектуры в том, что она вызывает однонаправленный поток данных, что значительно упрощает управление и отладку состояния. Все заканчивается прохождением через центральный диспетчер, что означает, что вы можете обеспечить предсказуемость, воспроизводимость и простую поддержку в управлении состоянием.
Вторая вещь, которая, я считаю, решает ту же проблему — это GraphQL. Это еще один способ решения проблемы — создание слоя консолидации, который вместо front-end в диспетчере функционирует на сервере GraphQL. Front-end больше не нужно управлять множеством разных мест, из которых он должен получать состояние, и их взаимосвязями… он просто запрашивают именно то, что ему нужно, а сервер GraphQL позаботится о том, чтобы это подготовить.
4. Одностраничные приложения и маршрутизация на стороне клиента
Когда сложные внешние интерфейсы впервые вступили в игру, сразу не было понятно, как мы собираемся их организовывать. Будем ли мы просто встраивать все более и более мощные компоненты в независимые серверные страницы?
Со временем стало ясно, что URL-адрес является одним из величайших нововведений в сети, но мы можем получить огромные преимущества при перемещении между страницами полностью в пределах клиентских приложений.
Ember.js, вероятно, был первым фреймворком, который воплотил это как философию, но с тех пор это было реализовано во всех основных фреймворках на стороне клиента. Хотя не для каждого проекта требуется одностраничное приложение, все чаще встречаются решения, когда, по крайней мере, частично, а возможно, и полностью front-end, выполняет собственную маршрутизацию.
И независимо от того, используете ли вы маршрутизаторы React Router, Vue-router, Mithril или что-то еще, основные концепции довольно схожи. URL-адрес сопоставляется с набором компонентов и состоянием, часто с приложением компонентов на основе вложенных маршрутов.
5. Типы для управления сложностью
JavaScript долгое время был быстро развивающейся средой разработки. Типы были свободными, аргументы не проверялись, и даже автоматическое тестирование долгое время оставалось без внимания. Но по мере роста сложности того, что мы передаем во front-end, увеличиваются и потребности в управлении кодом и предотвращении ошибок.
И самый мощный мега-тренд в этом плане — это типы. Еще в таких инструментах, как Flow, и тем более сегодня с повсеместным использованием компилируемых в JavaScript языков, таких как TypeScript, front-end охватывает проверку типов.
Потрясающая статистика по принятию на уровне 46% респондентов на npm, использующих TypeScript, показывает, что это происходит, и в 2019 году все признаки говорят за то, что эта тенденция сохранилась.
Бонус: рендеринг на стороне сервера и универсальный JavaScript
Хотя это скорее касается «развертывания» или эксплуатационных инноваций, чем инноваций в области front-end разработки, еще один мега-тренд, который очень четко проявился — это тенденция к упрощению рендеринга одностраничных приложений на стороне сервера.
Это позволяет вам использовать лучшие качества как серверных приложений, так и SPA — быстрое первоначальное отображение страницы, а также эффективность использования сети и все преимущества малой задержки и интерактивности SPA.
Заключение
Преимущество осведомленности об этих мега-трендах состоит в том, что вам не нужно паниковать по поводу необходимости «идти в ногу со временем» или выяснять, чему учиться. Вы можете сосредоточиться на одном стеке, но, изучая его, обратите внимание на общие принципы, которые вы по мере необходимости сможете быстро применить к другим стекам. Например, вы можете глубже изучить Next.js, используя TypeScript. Это заставит вас уделить внимание каждому из этих мегатрендов.
Вы будете работать с React, компонентно-ориентированным фреймворком с отличным декларативным стилем. Вы можете использовать Redux или GraphQL, и вы получите из коробки маршрутизацию и рендеринг на стороне сервера.
Если позже, например, вы решите перейти на Vue.js, все эти знания будут востребованы — частности Vue немного отличаются, но общая картина очень похожа, существует даже эквивалентная структура более высокого уровня: Nuxt .js.
Источник: https://zendev.com
Редакция: Команда webformyself.
