Давайте разбираться. Прошу под кат.
Несколько команд разработчиков провели достаточное количество времени с Angular 2.0, примерно столько же, сколько и наша (Прим. пер.: Ionic team). Мы вернулись к проектированию Ionic 2, когда Angular 2 был еще в статусе «пре-альфа», в надежде получить еще более быстрый, более совместимый со стандартами, и перспективный мобильный веб-фреймворк, — еще лучше, чем Angular 1.
Самое главное, что мы поняли, работая над Ionic 2 — это то, как похожи Angular 2 и Angular 1 на высоком уровне, и как понимание этого поможет разработчикам гораздо легче перейти с Angular 1 на Angular 2. Во многих отношениях, Angular 2, на самом деле, не является новым фреймворком как таковым. Это лишь новый стандарт Angular, с которым мы знакомы и который так полюбили.
Один фреймворк, множество стандартов
Вместе с Angular 1, Angular 2, и Angular Dart, Angular прошел путь от фрейворка, основанного на одном стандарте ES5, до концептуального фреймворка, или паттерна проектирования с множеством стандартов.
Можно спроектировать пользовательский интерфейс и frontend-приложение в стиле Angular, базируясь, по крайней мере, на трех основных языках: ES5, ES6/TypeScript и Dart, хотя ES6/TypeScript становится де-факто стандартом Angular.
Если мы ближе познакомимся с тем, как приложения на Angular работают на каждом из указанных выше языков, мы начнем замечать массу сходтв. Давайте взглянем на примере.
Пример
Чтобы вывести свойство из нашего скоупа (scope) или контекста, мы можем сделать вот так:
Angular 1:
<span>Сегодня {{todaysDate | date}}</span>
Angular Dart:
<span>Сегодня {{todaysDate | date}}</span>
Angular 2:
<span>Сегодня {{todaysDate | date}}</span>
Заметили что-нибудь? Они абсолютно одинаковые! Давайте попробуем более сложный пример. Представим, что у нас есть список песен:
В Angular 1 и Angular Dart это будет выглядеть так:
<ion-list>
<ion-item ng-repeat="song in songs" ng-click="openSong(song)">
{{song.artist}} - {{song.title}}
<span ng-if="song.isFavorite"><i class="icon ion-heart"></i></span>
</ion-item>
</ion-list>
А вот так в Angular 2 (вместе с Ionic 2):
<ion-list>
<ion-item *ngFor="#song of songs" (click)="openSong(song)">
{{song.artist}} - {{song.title}}
<span *ngIf="song.isFavorite"><ion-icon name="heart"></ion-icon></span>
</ion-item>
</ion-list>
Ну, что ж, здесь мы уже видим больше различий. Но различия эти четко определены: ng-repeat теперь превратился в ngFor, со звездочкой *, которая используется для обозначения данного элемента в качестве шаблона (которй будет повторен N-раз).
В циклах теперь используется "of" вместо "in", чтобы получить значения списка. Еще ближе к стандарту ES6 и TypeScript. Начиная с Angular 2, мы больше не используем kebab-casing (Прим. пер.: это когда синткасис написания у нас «вот-такой-вот») для написания атрибутов (то есть: ng-repeat, ng-if, ng-show и т.д.). Разработчики решили перейти к более четкому наименованию. (более подробно об этом (eng))
Если мы применяем стандарт Angular 1 к синтаксическому преобразованию Angular 2, то мы имеем код, который, концептуально, идентичен Angular 1 и Angular 2. Если предположить, что мы уже знакомы с Angulat, то мы можем взглянуть на этот код и сразу понять, что он делает.
Пример компонента
Большинство пользователей Angular найдут шаблоны прямо в самом Angular 2. Гораздо большие изменения приходят с новой моделью компонента, которая заменяет установку директивы/контроллера из Angular 1.
В Angular 1:
.controller('HomeCtrl', function($scope) {
// контроллер конкретной страницы
})
.directive('profileImage', [function() {
// ... а здесь директива
}])
В Angular 2, учитывая, что все — это компонент, мы можем применить простое преобразование: включить контроллеры в компоненты, а также включить в них и директивы.
Так как Angular 2 живет и дышит стандартами TypeScript и ES6, мы определяем «компоненты» как классы, которые могут содержать внутри себя шаблоны. Аналогом примера выше (Angular 1), код в Angular 2 может выглядеть следующим образом:
import {Component} from 'angular2/core';
@Component({
selector: 'home',
template: '<div>главная страница</div>'
})
export class HomeComponent { }
И директива из Angular 1 как компонент Angular 2:
@Component({
selector: 'profile-image',
template: '<div>profile image</div>'
})
export class ProfileImageComponent { }
А как же скоуп(scope)?
В Angular 1 скоуп был на самом деле только «контекстом», доступным в конкретной области пользовательского интерфейса. К примеру, наша директива profileImage ссылается на текущего пользователя как часть своего скоупа, или контекста, и рендерит картинку профиля пользователя.
Данная концепция в точности такая же, как в Angular 2, за исключением того, что мы используем естественную концепцию данных экземпляра класса из ES6! Angular прошел путь от обычной контекстной системы до основанного на стандартах подхода. Это благодаря тому, что JavaScript эволюционировал, сделав подобное возможным (с небольшой декоративной магией TypeScript, что делает код еще чище):
export class ProfileImageComponent {
@Input() user;
clickFace() {
// теперь мы можем использовать запись this.user, так же, как и $scope.user мы использовали в Angular 1
}
}
В Angular 2 нам больше нет необходимости пользоваться привычной $scope системой, чтобы обрабатывать данные для компонента. Теперь мы получаем их свободно*, благодаря ES6 и TypeScript!
*сильно упрощенное понятие, конечно, но для конечного пользователя это действительно свобода действий!
Снижение порога вхождения
Наши ветераны Angular 1 имеют тенденцию забывать, как сложно было разобраться с Angular 1. Мне пришлось взять месячный перерыв от большого количества своей остальной работы, чтобы только понять, что это за непонятные термины, как: транклюзии, директивы, связывания, скоупы, и что они на самом деле означают.
Разработчику, который является новичком в Angular и который начинает уже с Angular 2, не понадобится много специальных знаний для его изучения. Он может пропустить все эти эзотерические термины из Angular 1, и сразу с места в карьер прыгнуть в код спецификации ES6/TypeScript.
Плюс, с отсутствием привычной модульной системы, код Angular 2 легко уживается с остальной частью экосистемы ES6, делая его смертельно простым в установке и импорте третьей стороной (Прим. пер: тут, я полагаю, имеется в виду поддержка кода кем-либо на стороне, сторонними разработчиками).
Есть ли жизнь после Angular 1?
После того, как разработчики совершат психологический переход от синтаксиса Angular 1 к синтаксису Angular 2, мы думаем, они обнаружат, что, оказывается, они уже знают Angular 2. Обе концепции практически идентичны, и сходства не ограничиваются лишь шаблонами и компонентами; как только пользователи копнут глубже в пайпы, депенденси инджекшен, сервисы, они обнаружат тонну подобных сходств.
Поскольку существует так много совпадений, мы попытались сделать Ionic 2 похожим на Ionic 1, так как в его основе лежит Angular. Но теперь только новая, еще лучшая реализация! До сих пор переход протекает очень хорошо, и я оптимистичен в плане того, что Angular 2 становится хитом, именно сейчас, в тот момент, когда пыль оседает и API Angular 2 становится действительно стабильным.
Angular 2 — это определенно лучший Angular!
Комментарии (23)
Fesor
20.03.2016 11:04+3Заметили что-нибудь? Они абсолютно одинаковые!
Это декларативное представление, в чем может быть разница в принципе? Это как если взять шаблоны twig, twig.js, jninja и сказать что "абсолютно одинаковые!".
В Angular 1:
В Angular1 на самом деле так:
class ProfileComponent { // ... } // ... .component('myProfile', { template: `<div>profile image</div>` controller: ProfileComponent }
Так как Angular 2 живет и дышит стандартами TypeScript и ES6
Не ES6 а ES2015, да и TypeScript это ES2015+ES2016+модификаторы доступа (зачем — не понятно) + информация о типах (в том числе интерфейсы). Если так ставить вопрос то разницы уже не столь много.
В Angular 2 нам больше нет необходимости пользоваться привычной $scope системой
Собственно с версии Angular 1.3 мы можем так же не использовать $scope вообще, собственно я и не пользуюсь например. Об этом я писал в своей статье-обзоре Angular 1.5.
Он может пропустить все эти эзотерические термины из Angular 1
Это заявление основано практически ни на чем. К слову документацию к angular 1 уже переписывают в соответствии с компонентным подходом и в соответствии с angular styleguide. Уже год процесс потихоньку идет. А "месяц" брать надо было не потому что ангуляр сложный, а потому что документация не отвечала на основной вопрос — как его готовить. Да и если кто помнит angular 1.0 там что бы делать хорошо надо было много кода лишнего писать. Сегодня же писать поддерживаемые апы на ангуляре — проще простого.
Поскольку существует так много совпадений, мы попытались сделать Ionic 2 похожим на Ionic 1
Ionic1 был ущербен… особенно все что связано с навигацией.
spmbt
20.03.2016 11:46+3Похоже, что у автора была цель — проанонсировать Ionic 2, а основное средство восхвалеений — Angular 2 (если в чём-то ошибутся, то все шишки в A2), поэтому так много неточностей. Но по общей идее — это примерно так. Взяты идеи А1, обновлены инструменты в соответствии с духом времени, получается А2.
koceg
20.03.2016 11:55+3Было бы странно, если бы человек, писавший в официальный блог Ионика, преследовал какую-то иную цель.
beduin01
20.03.2016 12:30Очень рекомендую всем посмотреть на http://vuejs.org/!
Fesor
20.03.2016 12:48Очень рекомендую думать что рекомендовать. vue интересная штука и для небольших проектов оно круто, но для быстрой разработки больших приложений лучше ангуляра ничего нет (ну разве что Ember может поспорить, но я с ним плотно не работал)
Davert
20.03.2016 15:30+5реквестируем сататью — плюсыи минусы vue и его сравнение с ангуляром )
Fesor
20.03.2016 17:13+2Получится обзор в духе react vs angular, я не вижу смысла сравнивать эти инструменты. Лично я использовал vue.js там, где ангуляр выглядил уж сильно оверхэдом. Но если приложение придется поддерживать больше года — я бы брал ангуляр. Достаточно просто разобраться что есть в vue.js и что есть в angular2. И если вам все что есть в angular2 не нужно, например возможности разделить ui и логику по разным потокам через воркеры, или серверсайд пререндеринг, или вам нужна эффективная схема дерти чекинга между состоянием приложения и декларативным представленем, то vue хорошо подойдет. И большинству все это не нужно. Но есть еще категория проектов где сразу не скажешь, нужно или нет, так что эффективнее брать с запасом что бы экономить время разработки.
Например если мы возьмем vuejs в качестве основы для приложения, и нам внезапно понадобился server-side пререндеринг (например для ботов соц сетей) — нам придется прикручивать jsdom и т.д. Работа с сервисным слоем уже затрудняется. Одно дело когда разработчик знает что делает и хотя бы модули нормально использует, или там dependency injecton практикует, тогда подменять реализации труда не составляет. Но справедливости ради высоки шансы что кто-то все это уже сделал за нас и нам будет не так сложно все это прикручивать.
Но вот если мы захотим тот же сервер-сайд пререндеринг использовать для улучшения UX приложения при первой загрузке — тут мы однозначно проигрываем перед angular2 в плане времени разработки. Ну и опять же, ангуляр супортит больше людей, в него вбухивают усилия много компаний, а значит рисков в плане поддержки минимум.
Словом — здравый смысл. Тянуть библиотек на 500-800 килобайт для приложеньки в три скрина мне кажется не рациональным.
MikeLP
20.03.2016 17:14+2У них есть свое сравнение с топ библиотеками и фреймворками, правда на английском. Насколько предвзятое — не знаю, каждый обычно хвалит свое болото.
Ag47
20.03.2016 17:02-1Согласен с другими хабраюзерами, что ваше утверждение требует некой аргументации. Вы же пишите, что он не просто лучше vuejs, а вообще самый лучший для быстрой разработки больших приложений. Поэтому, было бы, конечно, очень интересно узнать подробнее. Я просто не встречал столь категоричных утверждений в обзорах и сравнениях, кроме того "быстро" и "большие приложения" вообще редко рассматриваются, все чаще искуственные мелкие примеры.
Fesor
20.03.2016 17:23Я подразумевал быстрый рост, стратапчики всякие, когда кровь из носу нужно фичи выкатывать быстрее конкурентов, а лишние 200 килобайт трафика — можно кэширование + сервер-сайд пререндеринг сделать и все будет хорошо.
MikeLP
20.03.2016 17:11+1А я несогласен с Fesor. Не следует путать мягкое с теплым. Vue подходит для больших проектов так же как и React, Angular, Ember и другие. Разница лишь в том что это библиотека, как и react, а не фреймворк. А все остальное дело вкуса. Минус (если не брать мелочи в документации и некоторые мелкие баги) — это то, что он не так распиарен как другие продукты. Соответственно риск в том, что поддержка автором или сообществом может в любой момент уменьшиться или совсем пропасть. К тому же прибавьте тупую тененцию на рынке разработки. Многие ищут reactjs, angularjs разработчика, а не собственно js разработчика, и поэтому можно услышать такую фразу — "ой, а где мы потом найдем vue.js разработчика". А по сути у них очень много общих принципов.
Fesor
20.03.2016 17:22+3Я не говорил что vue не подходит для больших проектов, я говорил о том, что с экономической точки зрения ангуляр дает больше профита в случае больших и быстро развивающихся проектов, которым может потребоваться внезапно, например, выкинуть все что не относится к UI приложения (трекинг изменений, ваша логика) в отдельный webworker например. С vue.js это так же можно сделать, но уже надо закладывать недельку другую на реализацию и стабилизацию. А с ангуляром можно за день это сделать, так как это из коробки практически идет.
Или там… время идет и сервер-сайд пререндеринг вдруг понадобился не только для ботов (для них кое как можно наклепать быстро и с vue и даже с первым ангуляром используя jsdom например), но и для обычных юзеров, поскольку для них критически важно быстро увидеть актуальную информацию, а взаимодействие с приложением — тут могут и подождать пару десятков секунд. В angular/universe это из коробки.
Ну то есть, мое мнение — вообще все можно сделать на ванильном JS, но никто в здравом уме так делать не будет поскольку нужна гибкость и эффективность в разработке. И в зависимости от проекта и условий, выбирая ангуляр мы получаем огромнейший оверхэд с одной стороны, и максимальную гибкость с другой. Если нам такая гибкость не нужна — можно уже отдельный разговор вести. Подходы то у всех фреймворков которые мы обсуждаем приблизительно одинаковые.MikeLP
20.03.2016 17:36+1Когда вы уточнили свою точку зрения, тут я согласен с вами. Действительно возможностей фреймворка намного больше чем у просто библиотеки (на то он и фреймворк) и если точно известно, что ты будешь использовать или по крайней мере есть высокая вероятность, что скорее всего это понадобиться, то конечно разумнее выбрать фреймворк. Но даже в такой ситуации нужно просмотреть, что лучше - библиотека + библиотека + библиотека или фреймворк + допиливание напильником.
Fesor
20.03.2016 17:56Вот честно, я пока так и не придумал ситуации, при которой "библиотека + библиотека + библиотека" выгоднее фреймворка. Вроде как основной мыслью подобного является гибкость разработки, мол берем DI из ангуляра, роутер отдельный, реакт какой или там тот же vue и вперед. Но я знаю не так много ситуаций когда это будет эффективнее в краткосрочной и долгосрочной перспективе. Маленькие библиотеки обычно грешат отсутствием должной поддержки со стороны их разработчиков и комьюнити, с другой стороны их своими силами поддерживать проще. Словом… вопрос очень скользский на самом деле. Я же просто ленивый и потому в 99% случаев предпочитаю фреймворк библиотекам. Тем более, если глянуть на тот же реакт, вроде бы и библиотека, но тянет за собой целую инфраструктуру. И тогда уже грань размывается.
jMas
20.03.2016 19:57После работы с vue, react + flux, angular могу сделать небольшое личное наблюдение — когда при работе например с angular, react + flux — тебе не приходится выдумывать ничего нового — основные концепции уже изобретены и проработаны, тогда как при работе с vue можно наткнуться на множество пробелов или недосказанности, где то приходится включать воображение и придумывать обходные пути для решения достаточно обыденных вопросов. Из понравившегося в vue — это computed функции. Но из-за обилия концепций — очень сложно написать хорошее решение, особенно когда в официальной документации мало сказано: как делать так чтобы добиться максимальной эффективности и простоты поддержки кода на vue.
lega
20.03.2016 20:14Из понравившегося в vue — это computed функции
Странно, что «костыль» может понравится, когда в Ангуляре и Реакте это делается обычными функциями или пропертями. Вот в Vue этот костыль нужен т.к. там kvo.jMas
20.03.2016 21:50Можете дать более развернутое объяснение, что это "костыль" и желательно на примерах кода? Спасибо.
lega
20.03.2016 22:34+2Основная идея у computed — это взять данные из третьего источника, преобразовать и вернуть результат. В Ангуляре и Реакте вы можете просто сделать/вызвать функцию. В vue вы тоже можете сделать функцию, но vue не будет отслеживать её результат, в итоге вам нужно разместить эту функцию в computed раздел, т.е. сделать computed объект, для того что-бы vue смог построить зависимости.
Такие махинации требуются от vue, вместо использования обычных функций в штатном режиме.
Другими словами — в vue создали проблему и героический её решили, когда у других такой проблемы вовсе нет. Вот и не понятно почему оно вам нравится.jMas
21.03.2016 00:06Понял о чем вы. Дело в том, что именно эти функции решили проблему агрегации данных из нескольких переменных из объекта data. Видимо я неправильно воспринял это и воспринял как фичу. Спасибо за разъяснения.
vaniaPooh
Опыт других фреймворков (например, Play, где Java заменили на Scala), в которых был сделан переход с одного языка на другой (в Angular 2 Javascript заменен на TypeScript), показывает, что для эффективного использования технологии все равно нужно изучать новый язык. Так что, на мой взгляд, время все-таки придется потратить.
Tomio
Согласен с вами. Тут, как автор пишет, нужно совершить "психологический переход от синтаксиса Angular 1 к синтаксису Angular 2". И тогда освоение второго Ангуляра пойдет легче. Я с ним в этом согласен. Сам очень люблю первый Ангуляр, и пока не могу себя сломать на переход ко второму =) Но, думаю, это лишь вопрос времени.