Всё, что связано с JavaScript, очень быстро развивается. Это касается и того, что можно отнести к сфере веб-разработки. В наши дни те, в основе чьих проектов не лежат самые современные технологии, начинают особенно сильно ощущать разрыв между тем, чем они пользуются, и тем новым, что появляется едва ли не ежедневно. К таким технологиям можно отнести Webpack, React, Jest, Vue, Angular в их современном состоянии. В то время как «население» мира фронтенд-разработки, включающее в себя технических специалистов и программистов, постоянно растёт, этот мир стремится к стандартизации. Появление новых технологий и инструментов уже меняет ситуацию.
Можно с изрядной долей уверенности говорить о том, что общим трендом развития фронтенд-технологий будет стандартизация разработки пользовательских интерфейсов. В частности, речь идёт о композиции, основанной на компонентах, о стремлении к модульности систем. Эта тенденция воздействует практически на всё — от стилизации до тестирования и даже до управления состоянием приложений. В этот тренд можно включить технологии, построенные вокруг веб-компонентов, ES-модулей, сюда же попадают соответствующие инструменты и многое другое.
1. Системы для работы с веб-компонентами, независимые от фреймворков и библиотек
В целом, можно сказать, что это и есть будущее. Почему? Всё дело в том, что те системы, о которых идёт речь, независимы от фреймворков. Это означает, что они могут работать как совершенно самостоятельно, так и совместно с любым фреймворком, учитывая его особенности, касающиеся представления кода. Этим системам не свойственно то, что называют «JavaScript fatigue», «усталость от JavaScript». Их поддерживают современные браузеры. В проекты, созданные с их использованием, включается оптимальное количество вспомогательного кода. Они эффективно используют возможности VDOM.
Компоненты, о которых идёт речь, построены с использованием стандарта Custom Elements. Он позволяет создавать новые HTML-теги, тонко настраивать их свойства — от внешнего вида, до внутренних механизмов и особенностей работы с Shadow DOM.
Заметные проекты в рассматриваемой области — это Lit-html (и Lit-element), StencilJS, SvelteJS, Bit.
Как принципы модульности, многократного использования, инкапсуляции и стандартизации должны выглядеть в эру компонентов? Если об этом поразмышлять, подумать о будущем UI-разработки, то оказывается, что это будущее представляют именно веб-компоненты. Мы ещё вернёмся к этой идее. А пока — вот несколько полезных материалов о веб-компонентах. Тут можно почитать об инструментах для разработки веб-компонентов. Вот материал о библиотеках веб-компонентов. Здесь можно найти пример прототипирования RSS-ридера с использованием веб-компонентов.
2. О будущем войн фреймворков и библиотек
В плане количества загрузок из NPM React всё ещё уверенно обходит Angular и Vue. По крайней мере — на данный момент.
Тут мы не собираемся рассуждать о том, какие фреймворки и библиотеки лучше других и почему этот так. Если вам интересно об этом почитать — вот и вот — материалы, в которых, на реальных данных, сравнивают Angular, React и Vue. Мы же собираемся изучить общую картину. А она выглядит следующим образом: во фронтенд-разработке доля технологий, основанных на компонентах, растёт. Постоянно растёт. Число разработчиков, которые пользуются подобными технологиями, также растёт, причём — быстро. Кроме того, в этой сфере достаточно свободного пространства для внедрения новых инструментов.
Итак, какой фреймворк будет на первом месте через 5 лет? Никто этого не знает. Но можно с уверенностью говорить о том, что тому, кто хочет быть готовым к будущему, стоит изучать базовые технологии экосистемы JavaScript, и привыкать к среде, в которой DOM находится под контролем веб-компонентов. Может быть через 5 лет ведущим инструментом для разработки интерфейсов будет React? Об этом можно подумать, взглянув на приведённый выше график, построенный по данным NPM. Но не всё так просто. Взгляните, например, на эти показатели. Они позволяют говорить о том, что, в плане реального использования, разрыв между React и Vue очень мал.
Vue и React, в плане их реального использования, очень близки
В будущем нас ожидает совершенствование стандартизации веб-компонентов, независимых от фреймворков. В этой связи можно поразмышлять о том, какой эффект это окажет на войну фреймворков. И кстати, как все мы знаем, React — это даже не фреймворк, а всего лишь библиотека.
3. Изоляция, многократное использование и композиция компонентов
Bit — пример платформы, ориентированной на разработку компонентов, на совместную работу с ними и на их многократное использование
Говоря о фронтенд-разработке и о компонентах, из которых строятся пользовательские интерфейсы, нельзя не вспомнить о Bit.
Эта опенсорсная платформа позволяет изолировать компоненты (или любые фрагменты JS-кода, подходящие для многократного использования) и превращать их в строительные блоки, которые можно использовать во множестве проектов. При этом разработчик может контролировать исходный код компонентов, управлять его изменениями и полным деревом его зависимостей.
Проще говоря, благодаря Bit у разработчика появляется возможность заниматься совершенствованием своих компонентов в рамках разных проектов и синхронизировать изменения. Благодаря хабу компонентов bit.dev эта идея расширяется и на командную разработку, позволяя членам команд упорядочивать код и совместно его использовать.
Хаб Bit даёт в распоряжение разработчика всё что нужно для совместного создания и использования компонентов. Например — удобные инструменты поиска, интерактивную среду, в которой можно экспериментировать с компонентами, полную поддержку CI/CD.
Благодаря Bit пользоваться можно не только компонентами, созданными усилиями своей команды, но и опенсорсными проектами. Сюда входит и возможность рекомендовать изменения существующих компонентов, и возможность выкладывать в общий доступ свои разработки.
4. ES-модули и CDN
ES-модули — это часть стандарта ES6, описывающая работу с модулями в браузере. Использование этой технологии позволяет выносить некий функционал в модули, которые можно загружать, например, через CDN. После выхода Firefox 60 можно говорить о том, что ES-модули поддерживаю все основные браузеры. Работа над поддержкой ES-модулей идёт и в среде Node.js. Кроме того, ожидается добавление поддержки ES-модулей в WebAssembly.
5. Управление состоянием на уровне компонента
Что нового можно сказать об управлении состоянием приложений? В наши дни управление состоянием сводится к помещению всего чего угодно в глобальное хранилище Redux.
Но такой подход может усложнить работу с компонентами, может стать препятствием к полному раскрытию их возможностей в плане многократного использования и модульности. Если рассматривать ситуацию с этой точки зрения, то можно сказать, что проекты наподобие MobX дают нам интересный, более реактивный подход к работе с состоянием приложений (тут ещё можно вспомнить и проект unstated).
Если говорить о новых стандартных механизмах React для управления состоянием, то можно вспомнить API Context и хуки. Их появление означает, что программисту, для управления состоянием, больше не нужны сторонние библиотеки, и то, что состоянием можно управлять на уровне функциональных компонентов. Это улучшает модульность проектов и возможности по повторному использованию компонентов.
В результате, если попытаться заглянуть в будущее, вполне может случиться так, что термин «состояние» будут употреблять преимущественно в применении к инкапсулированным компонентам, а не в применении к неким глобальным хранилищам данных уровня приложения.
6. Стилизация компонентов — это композиции
Разделение компонентов, реализующих логику и стили — путь к стилизации компонентов через композицию
О том, как стилизовать компоненты, за последние пару лет сказано очень много. В этой сфере существует масса возможностей. Это и встроенный CSS, и CSS-модули, и описание CSS в JS-коде, и стилизованные компоненты, и промежуточные решения наподобие Stylable.
Размышляя о будущем стилизации компонентов, я склоняюсь к тому, чтобы представлять себе стилизацию в виде композиции. Это означает, что системы проектирования компонентов должны включать в себя и компоненты, реализующие некую логику, и компоненты, описывающие стили. При таком подходе можно создать систему дизайна компонентов, которая развивается по мере развития проекта. Это позволяет избавить разработчиков от необходимости освоения громоздких библиотек для стилизации. Инструменты, используемые для проектирования компонентов, наподобие Sketch или Figma, тоже могут пользоваться этой идеей.
7. GraphQL-API и клиентские приложения, управляемые данными
Технология GraphQL и компонентный подход к разработке открывают восхитительные возможности для клиентских веб-приложений. Например, с помощью Apollo можно, без особого труда, создавать UI-компоненты, работающие с данными посредством GraphQL. Существуют и многие другие средства, облегчающие работу с GraphQL.
Разумное обращение с различными API позволяет упростить разработку приложений, управляемых данными. Это позволяет и увеличить скорость разработки. В результате GraphQL — это технология, на которую стоит обратить внимание тем, кто задумывается о будущем.
8. Инструменты для дизайнеров, основанные на компонентах
Компоненты постепенно становятся неотъемлемой частью систем дизайна веб-проектов. Благодаря этому сокращается разрыв между дизайнерами и программистами. И те и другие приближаются друг к другу.
Например, в Sketch уже предусмотрены средства модульной разработки дизайна компонентов, предусматривающие наличие зависимостей между компонентами. Уже появляются и средства для работы в Sketch с компонентами, формирующими своё визуальное представление программно. Широкое распространение подобных средств — это лишь вопрос времени. Инструменты наподобие Figma изначально ориентированы на компоненты пользовательского интерфейса, подходящие для многократного использования. В рамках проекта Framer идёт разработка инструмента для программирующих дизайнеров. Этот инструмент позволяет дизайнерам контролировать то, как элементы пользовательского интерфейса превращаются в React-компоненты.
Итоги
Здесь мы представили вам несколько трендов клиентской веб-разработки, на которые, по мнению автора материала, стоит обратить внимание тому, кто хочет быть готовым к будущему. Надеемся, эта публикация дала вам пищу для размышлений.
Уважаемые читатели! Каким вы видите будущее веб-разработки?
Комментарии (24)
AxisPod
07.06.2019 18:14+2Но как обычно, ни одна из тенденций так и не способствует TDD. И не надо пытаться убеждать в том, что есть и другие решения. Меня очень сильно не устраивают инструменты, которые говорят «У тебя ошибка», а уж где, будь добра найти сам.
RubaXa
07.06.2019 18:51+7Как же надоели такие статьи, сил нет.
Если бы автор реально пытался анализировать тренды, то хотя бы воспользовался существующими исследованиями:
И вот на основе их понял, какую поверхностную лажу он написал.
Сорян, за такие слова, но сколько можно-то?!
africaunite
08.06.2019 01:59-1Никак не хочу комментировать текст самой статьи. Но вот такие безапелляционные сообщения мне всегда "нравилилсь". Благо недостатка в них нет и даже наоборот.
Посмотрел по первой ссылке. Не вижу, где предположения автора противоречат результатам даже таких, косвенно относящихся к "прогнозированию будущего", исследований.RubaXa
08.06.2019 09:32+1Безапелляционные? Ну вроде я вроде приложил ссылки, но и без ссылок видно, что расклад сил уже давно устаканился и изменения нужно искать не в веб компонентах, ui либах и тем более инструментах для дизайнера, но если вам это не очевидно, могу развернуть:
Custom Elements. Уже давно не будущее, но за все года они показали крайне мало пригодным. Обычно их выбирают огромные копрорации (ибо стандарт, да и гугл за спиной), но из реальных, крупных решений вышел, наверно только Youtube и текущая ситуация с ним очень показательна.
Кроме этого, использовать их себе дороже, а профит сомнительный, проблема шаринга высосана из пальца, мы уже лет 5+ живем в эру компонентов (до которой были jquery plugins/widgets на любой вкус), поэтому проблема найти для того же React, Angular, Vue готовый, качественный компонент, просто нет, любые серьезные либы имеют биндинг под каждую из них.
Проблема как раз в таких решениях как Lit-html, StencilJS или SvelteJS (который не понятно как попал в этот список, ведь совсем не про CE). Можно было рассчитывать, что эти решения займут нишу для построения виджетов, но практика показывает, что проще сделать на чистом JS с литеральными шаблонами, или собрать из готовых React компонентов, заменить
React.createElementнаh, чтобы сжималось лучше, в финале выкинуть React, добавив Preact и готово.
Фреймворки. И тут как обычно видим React, хотя FW на фронте, которые ещё живы, это Ember, Angular и Vue (Aurelia может). React только либо, а дальше во круг неё люди стоят бог знает что, сам Реакт никакой официальной архитектуры не предлагает, только тонкие намёки… хотя вру, с появлением
useReducer, намёки становиться более прямыми, думаю весь 2019 год мы будем наблюдать, как люди обмазываются хуками изобретаю чудных монстров типа Flux, а дальше очередной «Дэн» нам покажет, как можно «проще», вот так и наступит 2020.
GraphQL. Опять же, какое это будущее? Он есть, он работает и уже давно, кто хотел, то уже использует, но если мы говорим про реальные highload проекты, то там как был RPC/REST, то так и останется, т.к. особой проблемы при их использовании нет.
Ну и так далее, такое ощущение, что автора нам пишет из 2016-2017, всё что он написал подходит к любому этому году.
Тредны на 2020 будут достаточно простыми, ситуация мало чем изменятся, проблем с компонентами и их стилизацией нет уже сейчас, максимум можно чего ожидать, это новые версии популярных компонент, типа Ant.Design, Material Design и т.п.
Главным будет конечно WASM, но скорей главным он будет к концу 2019, пока на фоне люди будут выяснять, как же лучше использовать хуки в React ;]
Ещё ещё один важный тренд и ниспадающий, это безопасность и тут конечно WebAuthn.
Да, и если говорить про дизайн и разработку, то тут нас ждет больше Grid'ов и конечно типографики.
Ну и так далее и тому подобное.
raamid
08.06.2019 02:48-1Спасибо за ссылки, познавательно. Однако это немного не то, о чем пишет автор. Статья у автора в основном аналитическая, в ней приводятся рассуждения. А по ссылкам собрана статистика с последующим анализом. У каждого подхода есть сильные и слабые стороны. У «статистики» слабая сторона — невозможность «заглянуть» в будущее, потому что у него нет никакой статистики. Например, специально искал информацию про веб-компоненты, но там об этом ни слова.
t_kanstantsin
09.06.2019 14:54основном аналитическая, в ней приводятся рассуждения
А на основе чего автор проводится анализ? Просто на основе своих фантазий или он всё же опирается на статистику и тренды? Если просто фантазии, то какой это "анализ"?
lega
10.06.2019 11:06Интересный анализ, в глаза бросилось ES6 vs TypeScript.
Кол-во тех кто то попробовал TypeScript и больше бы его не использовали, более чем в 9 раз выше относительно, чем у ES6.
Т.е. большой антирейтинг у TS, что вы об этом думуаете?RubaXa
10.06.2019 11:16Мне кажется проблема в сообществе, низкий порог входа, поэтому у людей нет нормального бекграунда и для них все эти «типа» сложны, непонятно и просто излишни. Кроме этого, огромная проблема с самими инструментами, они не TS-friendly, что Vue, что React (особенно с Redux) в них TS смориться инородно и монструозно.
Увы, люди не видят полной картины, что TS, кроме проверки типов, даёт супер крутой autocomplete, изумительно удобный рефакторинг, а ещё если вникнуть в Transformer API, то инструмент раскроет себя во всей красе.
dimoff66
08.06.2019 07:51+1В следующем сезоне в тренде будут башмаки на высокой подошве, начните изучать их уже прямо сейчас, чтобы как следует подготовиться к новому сезону...
zim32
08.06.2019 20:06+2Sketch, Apollo, Bit.dev… я надеюсь в будущем фронт разработки не будет миллион инструментов, делающих какую-то магию под капотом
epishman
Еще бы TypeScript в браузеры имплементировали, в чем сложность, два движка осталось всего.
wrqqq
Зачем?
epishman
Cчастье, когда строгий компилятор находит ошибки за тебя, особенно если ты поправил декларацию в одном месте, а при сборке он проверил 10 тысяч строк кода, и нашел несоответствие где-то далеко, о чем уже и не вспомнишь.
RyDmi
Так вы же сами и написали. Typescript нужен при сборке. В браузере-то он зачем?
epishman
Отладка например, скорость загрузки, интеграция с другими языками. По сути движок все-равно компилирует в момент открытия страницы, зачем нам лишняя прослойка, пусть сразу из тайпскрипта в байткод компилирует. Тут Rust ругают, что он компилирует в LLVM, хотя это глазу никак незаметно, а в JS-это уже весьма заметно. Тому же wasm-у проще линковаться с типизированным интерфейсом, чем с нетипизированным, и так далее.
RyDmi
Почти всё вышеперечисленное как раз таки лучше делать в AOT режиме, а не в браузере у клиента. Для отладки есть source-map, которые также просто позволяют дебажить исходники на ts. Соглашусь только с аргументом про
при условии, что речь о компиляции в обычный js. Если со временем это всё переползет на компиляцию в wasm, то опять таки это надо делать в AOT, а не у клиента.
Тут не понял о чём речь.
Cerberuser
А перегнать TypeScript в WASM — это хотя бы в теории вообще реально? Пусть даже и с ограничениями типа "никаких any и никаких X as unknown as Y"...
Vadem
Уже есть похожий проект — AssemblyScript.
Cerberuser
Спасибо! Как я и предполагал, компилируется довольно жёстко ограниченное подмножество, но то, что его удаётся чётко очертить, — уже приятный сюрприз. Буду изучать.
epishman
Возможно Вы и правы насчет AOT, а про другие языки — модули wasm можно писать и на других языках, и в идеале желателен мэппинг параметров, а когда на стороне JS один тип «объект» — привет тестирование в рантайме.
Zoolander
V8 при оптимизации тратит довольно много ресурсов на попытку понять, с каким объектом он имеет дело. Если бы информация о типах объекта передавалась сразу в движок — движок мог бы потратить эти ресурсы на что-то другое. Ну или стал бы работать быстрее, потому что часть работы бы отпала
RyDmi
Дык тут wasm надо тащить, Имхо. А то о чем вы пишете это просто колоссальная переработка движка, как мне видится. Смысла нет, тем более, что wasm уже есть, хоть и тулы для него (TS — >wasm) в зачатке только.
Zoolander
wasm спроектирован так, что он может только дополнить JavaScript — обращаться к API и DOM все равно приходится через Javascript-вызовы.
Посему непонятно, как вы видите решение «тащить wasm». Далеко его не протащищь, это хороший инструмент для оптимизации абстрактных (не привязанных к конкретному API) вычислений. Для работы ему нужен JavaScript
RyDmi
V8 во многом занимается тем, что дженериковые словарики типизирует в рантайме и оптимизирует вызовы функций. И да, wasm фактически работает через js (что вроде как не обязательно, но на текущий момент только так), но если для исполнения wasm кода ему в чем-то не хватает типизации, то лучше её вносить в сам wasm (через аннотации и т. п., примерно как в IL .Net например), а не тащить в браузер ещё один высокоуровневый язык, вместо унификации единого формата исполняемого кода. Всё имхо, конечно. Под wasm не кодил, не могу сказать является ли подобное для него принципиальным ограничением, но, думаю, что нет.