Автор Брайан Ринальди
В мире JavaScript много фреймворков. Это было верно даже несколько лет назад, до того как стало понятно, что у вас есть собственная структура, чтобы присоединиться к элите, толпе участников конференции.
Всего пару лет назад казалось, что Backbone находится на пути к тому, чтобы стать де-факто фреймворком для разработчиков JavaScript. Он побеждал более устоявшиеся фреймворки, такие как Dojo, и держал в стороне таких выскочек, как Knockout и Ember.
Затем, казалось бы, в одночасье все изменилось, и AngularJS, похоже, внезапно стал доминировать в любом обсуждении фреймворка, связанном с JavaScript. У меня был популярный сайт для разработчиков (под названием Flippin ‘Awesome, который сейчас называется Modern Web ), и казалось, что все, о чем хотел написать любой автор, — это Angular. В то время я думал, что Angular — это просто флейвор, и сообщество так же быстро пойдет дальше. Этого не случилось.
Угловой процент с течением времени в соответствии с Google Trends
Инструменты и интеграция
Я думаю, что несколько факторов привели к тому, что «доминирование» Angular было относительно стабильным. Первой была рамочная усталость. Никто не мог реально поспевать за скоростью новых фреймворков, поэтому казалось, что пришло время объединиться вокруг конкретной фреймворк, и тот факт, что он возглавлялся Google, вероятно, сделал его более безопасным выбором.
Однако это привело к тому, что, вероятно, является более важным фактором, а именно интеграцией Angular в другие инструменты и платформы. Это сделало решение выбрать Angular проще, особенно для крупных компаний. Например, интеграция Angular поставляется предварительно встроенной в такие фреймворки, как Keriko UI от Telerik, Ionic, Famo.us, Wijmo и другие. Среды IDE, включая WebStorm / IntelliJ, Visual Studio и NetBeans, предварительно подготовлены с функциями, специально предназначенными для проектов Angular.
Дело в том, что все эти интеграции не только облегчают выбор Angular, но и усложняют уход. Это больше не просто код, который я пишу, но Angular связан со всем моим опытом разработки.
Противоречие
Угловое доминирование не остановило рост конкурентных систем. Эмбер продолжает вводить новшества. Реакт получил небольшое, но растущее (и, казалось бы, преданное) следующее. Похоже, что проекты, подобные Meteor, находят аудиторию, особенно среди тех, кто ищет фронтенд и бэкэнд JavaScript.
Я хотел бы наметить относительный интерес к этим фреймворкам с помощью Google Trends, но трудно найти конкретные поисковые термины (т. Е. React, Ember и Meteor, все дают нерелевантные результаты, а поиск Reactjs, Emberjs и Metorjs, например, едва зарегистрироваться на графике).
Однако недавно команда Angular, похоже, вступила в противоречие с некоторыми планами, выходящими в Angular 2.0.
Во-первых, это полное переписывание, что само по себе неплохо. Тем не менее, одной из ключевых проблем является потенциальная нехватка обратной совместимости или простой путь миграции. Вот цитата на эту тему от Игоря Минара (выделено мое):
Наша цель в Angular 2 — создать наилучший набор инструментов для создания веб-приложений, не ограничивая их, поддерживая обратную совместимость с существующими API. Как только у нас будет начальная версия Angular 2, мы начнем работать над путем миграции для приложений Angular 1.
В обзоре изменений в Angular 2.0, объявленных на конференции ng-europe, Дэвид Иффланд сказал :
Разработчики, знакомые с Angular 1.X, столкнутся с кардинально отличающимся фреймворком и должны будут изучить новую архитектуру.
На основе видеозаписи презентации из ng-europe Джаксентер привел базовый пример, иллюстрирующий, насколько разным может оказаться код. Ниже приведен пример в Angular 1.3 (взято примерно с 3:20 в видео ):
<div ng-controller="SantaTodoController">
<input type="text" ng-model="newTodoTitle">
<button ng-click="addTodo()">+</button>
<tab-container>
<tab-pane title="Tobias">
<div ng-repeat="todo in todosOf('tobias')">
<input type="checkbox"
ng-model="todo.done">
{{todo.title}}
<button ng-click="deleteTodo(todo)">
X
</button>
</div>
</tab-pane>
...
… И тот же пример, написанный для Angular 2.0 (примерно с 3:26):
<div>
<input type="text" [value]="newTodoTitle">
<button (click)="addTodo()">+</button>
<tab-container>
<tab-pane title="Good kids">
<div [ng-repeat|todo]="todosOf('good')">
<input type="checkbox"
[checked]="todo.done">
{{todo.title}}
<button (click)="deleteTodo(todo)">
X
</button>
</div>
<tab-pane>
...
Внимательное изучение кода показывает ряд существенных различий, ни одно из которых не вызывает каких-либо быстрых и простых путей обновления (например, синтаксис для директив полностью изменился).
Обновление 11/3/14: В настоящее время обсуждается влияние предлагаемого синтаксиса и способы его устранения.
Что это значит?
Как и недавние противоречия с Рене Зеллвегер , разработчики Angular, казалось, смотрели на нечто, что выглядело слегка знакомым и в то же время неузнаваемым. В то время как другие популярные фреймворки претерпели серьезные изменения или сложные пути миграции, Angular 2.0 казался настолько отличным, что вызвал некоторые резкие реакции.
Например, Джон В. Петерсен говорит, что Google сломал OSS compact с Angular 2.0:
Ясно, что 2.0 — это революционный шаг над 1.x. Команда Angular стремится извлечь выгоду и развить успех Angular 1.x. Таким образом, сообщество, получившее высокую оценку в ng-Europe, имеет разумное ожидание, чтобы его держали в курсе событий. Именно так вы должны относиться к сообществу, которое составляет вашу базу партнеров по развитию. Мне это кажется довольно здравым. С какой стати команда хочет лишить права голоса того самого сообщества, на которое она опирается и которого хвалит?
Реакция Reddit на пост в Jaxenter была почти единодушно резкой (да, резкие комментарии на Reddit — обычное явление, но единодушное недовольство изменениями все еще несколько удивляло). Этот комментарий jbarkett был символом общего чувства комментаторов:
Честно говоря, я не думал, что команда Angular сможет сделать что-то в версии 2.0, что бы меня выключило. Все разговоры о реальном слое постоянства с офлайновыми первыми возможностями и отказом от поддержки старых браузеров, чтобы освободить место для новых вещей, звучали замечательно.
Это беспорядок … огромный разрыв между этим и 1,3 означает, что те из нас, кто имеет реальную работу, где проекты живут годами, должны отступать. Я не могу сказать своему боссу, что мы собираемся создать что-то невероятное, но нам нужно спланировать только код, никаких новых функций в течение 18 месяцев не переписывают.
Между тем другие структуры продолжают вводить новшества. Например, только на этой неделе была представлена новая версия Ember с обновленным слоем рендеринга и новая версия React (и не забудьте о новой бета-версии Kendo UI ).
Возникает вопрос: сможет ли Angular сохранить свое господство? Например, в ответ на мой твит о выпуске Ember Джейсон Маршалл написал:
При достаточном изменении синтаксиса и функциональности переход с 1.3 на 2.0 приведет к крутой кривой обучения. Несмотря на то, что Angular обладает некоторыми из присущих инструментам и преимуществам интеграции, о которых я говорил ранее, радикальные изменения могут также затруднить поддержку инструментам и средам интеграции с 1.3, удовлетворяющей большую часть их аудитории, и 2.0, удовлетворяющей ранних пользователей. Кроме того, в какой-то момент, если миграция является сложной, вы практически стимулируете пользователей хотя бы исследовать альтернативы, сводя на нет многие из присущих Angular преимуществ.
И давайте не будем забывать предприятия. Многие были только в процессе стандартизации на Angular 1.3 только для того, чтобы увидеть, что он, похоже, резко развернулся, что может повлиять на их проекты в долгосрочной перспективе (а предприятия не часто известны своим быстрым внедрением). Возможно, они не решатся в дальнейшем участвовать в проекте, если потеряют доверие к способности Google возглавить его.
В игре все еще относительно рано, и команда Angular может воспринимать обратную реакцию как знак, чтобы изменить свое направление или, по крайней мере, предложить более простую историю миграции. Кроме того, по общему признанию, фактические длительные эффекты обратной реакции такого рода часто могут быть завышены во время пика момента. Тем не менее, похоже, что Google, по крайней мере, открыл дверь достаточно широко, чтобы конкурент фреймворка мог пройти через нее.
Я хотел бы услышать ваши мысли.