Всякий раз, когда в JavaScript происходит крупное обновление, по-видимому, мы повторяем один и тот же цикл. Поначалу разработчики восхищены новыми возможностями. Снова начинают писать код на чистом JavaScript, а популярность фреймворков спадает. Но периоды между релизами относительно долгие, за это время фреймворки успевают обрасти новыми возможностями и опять приманить разработчиков. Затем все сначала.

С появлением ES6— пожалуй, это пока крупнейшее изменение в языке JavaScript – тот же самый цикл вновь может повториться. Фреймворки и близко не пользуются той популярностью, что непосредственно перед выходом ES6, тогда как JavaScript только крепнет. Но я решусь и на более радикальный прогноз: по мере того, как разработчики все лучше и лучше узнают, каковы возможности ES6, мы можем, наконец-то вырваться из этого цикла. В будущем JavaScript-разработчики не будут пользоваться фреймворками. Вообще.

Сознаю, что этот вывод покажется непопулярным, но выслушайте меня до конца. Я не говорю, что область применения JavaScript сузится — на самом деле, и сейчас есть много компаний, разыскивающих JavaScript-разработчиков. Но я считаю, что две ключевые составляющие ES6 (конкретно – модули и классы) приведут к тому, что большинство популярных фреймворков выйдут из употребления. Иными словами, JavaScript-фреймворки вымрут по тому же сценарию и в силу тех же причин, по которым умер Flash — поскольку в данной технологии просто уже не было нужды, а из-за присущих ей уязвимостей пользоваться ею стало опасно.

Итак, прежде, чем вы броситесь отстаивать ваш любимый фреймворк, позвольте мне объяснить, почему (на мой взгляд) такой переход наступит.

Проблема с фреймворками JavaScript

Фреймворки JavaScript существуют в качестве инструментов, позволяющих разработчикам абстрагировать некоторые наиболее сложные аспекты создания клиентских приложений. Притом, что когда-то фреймворки были очень полезными инструментами – невозможно это отрицать – совершенствование спецификации веб-компонентов в JavaScript значительно упростило разработку новых клиентских приложений на JavaScript (это касается, например, одностраничных приложений) без обращения к имеющимся фреймворкам. Поэтому возникает вопрос, а в самом ли деле фреймворки до сих пор необходимы.  

Давайте рассмотрим наиболее популярные современные фреймворки JavaScript и разберем, в чем они не дотягивают. Много искать при этом не придется, поскольку большинство фреймворков, используемых сегодня, страдают от ряда фундаментальных недостатков.

Большинство из нас, тех, кому приходилось работать с фреймворками JavaScript  (да, и я в этих рядах) не замечают этих недостатков – конечно же, ведь мы так к ним привыкли. Это была своеобразная сделка с дьяволом: мы высоко ценили легкость разработки, которую обеспечивали нам эти абстракции, но сквозь пальцы смотрели на тот путаный JavaScript, который из них получался. Но есть простой факт: большинство используемых нами фреймворков – это просто разбухшие библиотеки, управляющие сложными процессами, такие, для которых JavaScript просто не приспособлен. Также эти библиотеки просто срезают углы, а такая практика усложняет отладку кода.

Вдобавок к этим есть и еще одна, более важная проблема: вообще не существует четкой дефиниции, что же понимается под «фреймворком JavaScript». Это привело к достаточно абсурдной ситуации: один из наиболее популярных «фреймворков» JavaScript — React — в сущности, фреймворком не является (неудивительно, что он до сих пор так популярен). В лучшем случае, это библиотека, которую разработчики используют для выстраивания собственных, высоко специализированных фреймворков JavaScript.

Все эти проблемы проявляются в наиболее популярных фреймворках, используемых сегодня. Но есть и ряд специфических проблем, затрагивающих конкретные фреймворки. Давайте быстро рассмотрим каждый из них по очереди.

AngularJS и Angular

Тот факт, что AngularJS приходится упомянуть в этом списке, показательно свидетельствует об одной из проблем всех фреймворков JavaScript — даже когда они устаревают, люди не перестают ими пользоваться. На самом деле, и сейчас найдется множество разработчиков, которые расскажут вам, что AngularJS – по-прежнему «лучший» способ писать код на JavaScript, пусть даже этот фреймоворк (a) устарел и (b) труднопонимаем для любого, не имеющего многолетней практики работы с ним.

Эта вторая проблема — код, понимать который почти невозможно – на самом деле, перетекла и в Angular 2. Притом, что кто-то видит в этом объяснение, почему бекенд-разработчики могут заработать больше, в реальности такая ситуация может испортить жизнь разработчикам. Вспомним, к примеру, что в Angular 2 содержатся включения HTML, чувствительного к регистру, что не только нарушает принципы самого HTML, но и вынуждает многих реализовывать промежуточный парсер просто для подчистки того HTML, который порождается Angular 2.

React

Еще один большой «фреймворк» JavaScript — React — страдает от иного набора проблем. Фактически, в ретроспективе заметно, что разработка React – это своеобразная реакция (каламбур намеренный) на ретроградство Angular. React привлекает пользователей тем, насколько он легок в использовании, а также что не станет сложнее, чем усложните его вы сами.

В какой-то степени это верно. Проблема в том, что на самом деле React – не интегрированный фреймворк, а, на самом деле, набор модулей и компонентов, которые зачастую не слишком хорошо взаимодействуют друг с другом. В React начинаются затруднения при попытке сделать что-нибудь хотя бы немного сложное, например, реализовать идентификацию браузера. Для этого требуется построить сложный стек компонентов, которые затем нуждаются в постоянной поддержке и управлении. 

Здесь со мной можно поспорить, указав, что есть системы вроде Redux и Flux, при помощи которых со сложными стеками React могут справиться даже начинающие. Я же возражу, что, если вам нужен фреймворк для обращения с вашим фреймворком, который обращается с JavaScript, то у вас реально проблемы. Но, поскольку React – не вполне фреймворк, делать такое сравнение не очень честно.

Ember, Vue и Aurelia

Наконец, упомяну и о некоторых менее известных и не столь привычных фреймворках. Большинство разработчиков не имеют серьезного опыта обращения с ними по той причине, что эти фреймворки не слишком распространены за пределами собственных нишевых вариантов применения.

У каждого из этих фреймворков есть свои причуды, но основная их проблема связана непосредственно с нишевостью их использования. Ни один из этих фреймворков не завоевал такой доли рынка, которая гарантировала бы по-настоящему прочные связи с широким сообществом JavaScript (правда, по статистике запросов в Stack Overflow, Vue сегодня котируется примерно на одном уровне с jQuery). В результате те разработчики, которым нравятся эти фреймворки, зачастую вести неравный бой, когда приходится приводить аргументы в пользу конкретного фреймворка.

Кроме того, здесь стоит коротко отметить, почему ни один из этих фреймворков так и не стал по-настоящему популярен, особенно притом, что во многих отношениях это наиболее «полнофункциональные» системы в списке. Например, Ember, вероятно, наиболее «фреймворкный» из всез фреймворков из этого списка, но он страдает от проблем с производительностью, у него самый большой размер скачиваемого файла, его API занимает больше всего места, а кривая обучения – круче, чем у какого-либо из фреймворков в этом списке.

Задумайтесь об этом ненадолго, и можете прийти к странному выводу: по мнению многих разработчиков, для программирования на JavaScript нам нужен фреймворк, но, когда нам действительно предлагается полноценный фреймворк, мы предпочитаем ему импровизированные решения, например, React. С учетом этого нужно, пожалуй, переосмыслить, а нужны ли нам фреймворки вообще .

Что обещает ES6

Именно в таком контексте и была выпущена ES6. ES6 — также называемая ECMAScript2015 — это самая свежая версия JavaScript. Она изменила работу с этим языком в некоторых фундаментальных отношениях. В нее вошел ряд новых возможностей, к внедрению которых в сообществе призывали долгие годы.

Заявление, ES6 приведет к моральному устареванию фреймворков JavaScript, на первый взгляд кажется весьма абсурдным, так как изменения, привнесенные с ES6 (как минимум, по мнению некоторых авторов) – не более, чем синтаксические корректировки. Но, рассматривая дополнения, которые действительно были внесены на уровне синтаксиса, мы упускаем суть.

Дело в том, что большую часть «дополнительного функционала», предоставляемого фреймворками, можно охарактеризовать точно так же – как метод предоставления быстрого доступа к возможностям JavaScript при помощи синтаксических изменений. Некоторые из этих синтаксических упрощений уже настолько знакомы нам, что мы уже воспринимаем их как полноценные возможности, но на самом деле они – не более, чем автоматизация уже имеющихся элементов JavaScript.

Не стремлюсь преуменьшить полезность синтаксических инноваций. На самом деле, большинство нововведений в ES6 – это, в сущности, синтаксические упрощения. В их числе:

• Параметры по умолчанию

• Шаблонные литералы

• Многострочные строки

• Деструктурирующее присваивание

• Улучшенные объектные литералы

• Стрелочные функции

Но причина, по которой эти возможности способствуют устареванию фреймворков – в том, что они привносят в язык функционал, ранее применявшийся только в пределах фреймворков, а теперь входит прямо в ядро JavaScript. В свою очередь, в большинстве ситуаций это снижает потребность прибегать к фреймворкам. Все больше функций – в том числе, промисы и конструкции с областью видимости в пределах блока — стандартизируют те вещи, для ситуативной реализации которых мы использовали фреймворки. Разработчики, ранее специализировавшиеся на разных фреймворках, теперь впервые за многие годы могут поговорить друг с другом на общепонятном языке. 

Правда, в ES6 есть еще две возможности, которые по-настоящему приговаривают фреймворки или, как минимум, приостанавливают жестокий жизненный цикл фреймворков JavaScript. Я говорю о новаторских способах реализации классов и функций в ES6.

Классы

Сегодня многие разработчики используют ООП как стандарт, поэтому годами реализуют на JavaScript объекты. До сих пор для этого использовались как фреймворки, так и наши собственные кустарные решения, поскольку в ES5 работа с классами была сплошной болью. Эта странность всегда поражала меня, поскольку с самого начала было ясно, что ES5 задумывалась именно для поддержки классов, ведь даже ключевое слово CLASS в ней зарезервировано. 

К этому привели споры. Все обращались к любимым фреймворкам и с их помощью создавали ООП-интерфейс. Обычно с такими интерфейсами было сложно работать всем, кроме их авторов, кроме того, такие конструкции плохо сочетались друг с другом.

Наконец, в ES6 появился стандартизированный способ работы с классами. Классы ES6 используют прототипы, а не подход с фабричными функциями, где, если у нас есть класс baseModel, мы можем определить конструктор и метод getName(). 

Модули

Примерно такая же ситуация сложилась и с модулями. Фактически, многие разработчики до сих пор с удивлением узнают, что по умолчанию в ES5 не было нативной поддержки модулей. Просто мы настолько привыкли к обходным путям, реализуемым через AMD, RequireJS, CommonJS и пр., что забыли: все, чем мы при этом занимаемся, на самом деле не входит в состав JavaScript.

Теперь, в ES6, все могут пользоваться простыми командами — import и export — для работы с модулями. Если не все, то хотя бы некоторые из нас, время от времени. Поскольку, чтобы немного подкосить собственные тезисы под конец статьи, именно для этой цели нам  впервые может понадобиться вновь обратиться к фреймворкам. 

Потому что модули были введены в ES6 по-настоящему путаным образом. Они не отражают того, как модули используются в Node.js, а многие люди привыкли использовать модули именно как в Node.

Итоги

Итак, ES6 привнесла в JavaScript кучу синтаксических изменений, которые сильно снижают потребность в большинстве фреймворков. Вместе с тем фактом, что большинство применяемых сегодня фреймворков затемняют код JavaScript и привносят дополнительные зависимости, мы можем увидеть заметное и перманентное снижение популярности фреймворков в ближайшие несколько лет.

Либо, может быть, цикл просто повториться, и у нас будет всего несколько лет, чтобы научиться писать более качественный JavaScript, прежде, чем мы отступим обратно к фреймворкам.