Comments 24
Опыт других фреймворков (например, Play, где Java заменили на Scala), в которых был сделан переход с одного языка на другой (в Angular 2 Javascript заменен на TypeScript), показывает, что для эффективного использования технологии все равно нужно изучать новый язык. Так что, на мой взгляд, время все-таки придется потратить.
Согласен с вами. Тут, как автор пишет, нужно совершить "психологический переход от синтаксиса Angular 1 к синтаксису Angular 2". И тогда освоение второго Ангуляра пойдет легче. Я с ним в этом согласен. Сам очень люблю первый Ангуляр, и пока не могу себя сломать на переход ко второму =) Но, думаю, это лишь вопрос времени.
Заметили что-нибудь? Они абсолютно одинаковые!
Это декларативное представление, в чем может быть разница в принципе? Это как если взять шаблоны 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 был ущербен… особенно все что связано с навигацией.
Очень рекомендую всем посмотреть на http://vuejs.org/!
Очень рекомендую думать что рекомендовать. vue интересная штука и для небольших проектов оно круто, но для быстрой разработки больших приложений лучше ангуляра ничего нет (ну разве что Ember может поспорить, но я с ним плотно не работал)
На счёт vuejs можете поподробнее?
реквестируем сататью — плюсыи минусы vue и его сравнение с ангуляром )
Получится обзор в духе react vs angular, я не вижу смысла сравнивать эти инструменты. Лично я использовал vue.js там, где ангуляр выглядил уж сильно оверхэдом. Но если приложение придется поддерживать больше года — я бы брал ангуляр. Достаточно просто разобраться что есть в vue.js и что есть в angular2. И если вам все что есть в angular2 не нужно, например возможности разделить ui и логику по разным потокам через воркеры, или серверсайд пререндеринг, или вам нужна эффективная схема дерти чекинга между состоянием приложения и декларативным представленем, то vue хорошо подойдет. И большинству все это не нужно. Но есть еще категория проектов где сразу не скажешь, нужно или нет, так что эффективнее брать с запасом что бы экономить время разработки.
Например если мы возьмем vuejs в качестве основы для приложения, и нам внезапно понадобился server-side пререндеринг (например для ботов соц сетей) — нам придется прикручивать jsdom и т.д. Работа с сервисным слоем уже затрудняется. Одно дело когда разработчик знает что делает и хотя бы модули нормально использует, или там dependency injecton практикует, тогда подменять реализации труда не составляет. Но справедливости ради высоки шансы что кто-то все это уже сделал за нас и нам будет не так сложно все это прикручивать.
Но вот если мы захотим тот же сервер-сайд пререндеринг использовать для улучшения UX приложения при первой загрузке — тут мы однозначно проигрываем перед angular2 в плане времени разработки. Ну и опять же, ангуляр супортит больше людей, в него вбухивают усилия много компаний, а значит рисков в плане поддержки минимум.
Словом — здравый смысл. Тянуть библиотек на 500-800 килобайт для приложеньки в три скрина мне кажется не рациональным.
Например если мы возьмем vuejs в качестве основы для приложения, и нам внезапно понадобился server-side пререндеринг (например для ботов соц сетей) — нам придется прикручивать jsdom и т.д. Работа с сервисным слоем уже затрудняется. Одно дело когда разработчик знает что делает и хотя бы модули нормально использует, или там dependency injecton практикует, тогда подменять реализации труда не составляет. Но справедливости ради высоки шансы что кто-то все это уже сделал за нас и нам будет не так сложно все это прикручивать.
Но вот если мы захотим тот же сервер-сайд пререндеринг использовать для улучшения UX приложения при первой загрузке — тут мы однозначно проигрываем перед angular2 в плане времени разработки. Ну и опять же, ангуляр супортит больше людей, в него вбухивают усилия много компаний, а значит рисков в плане поддержки минимум.
Словом — здравый смысл. Тянуть библиотек на 500-800 килобайт для приложеньки в три скрина мне кажется не рациональным.
У них есть свое сравнение с топ библиотеками и фреймворками, правда на английском. Насколько предвзятое — не знаю, каждый обычно хвалит свое болото.
Согласен с другими хабраюзерами, что ваше утверждение требует некой аргументации. Вы же пишите, что он не просто лучше vuejs, а вообще самый лучший для быстрой разработки больших приложений. Поэтому, было бы, конечно, очень интересно узнать подробнее. Я просто не встречал столь категоричных утверждений в обзорах и сравнениях, кроме того "быстро" и "большие приложения" вообще редко рассматриваются, все чаще искуственные мелкие примеры.
А я несогласен с Fesor. Не следует путать мягкое с теплым. Vue подходит для больших проектов так же как и React, Angular, Ember и другие. Разница лишь в том что это библиотека, как и react, а не фреймворк. А все остальное дело вкуса. Минус (если не брать мелочи в документации и некоторые мелкие баги) — это то, что он не так распиарен как другие продукты. Соответственно риск в том, что поддержка автором или сообществом может в любой момент уменьшиться или совсем пропасть. К тому же прибавьте тупую тененцию на рынке разработки. Многие ищут reactjs, angularjs разработчика, а не собственно js разработчика, и поэтому можно услышать такую фразу — "ой, а где мы потом найдем vue.js разработчика". А по сути у них очень много общих принципов.
Я не говорил что vue не подходит для больших проектов, я говорил о том, что с экономической точки зрения ангуляр дает больше профита в случае больших и быстро развивающихся проектов, которым может потребоваться внезапно, например, выкинуть все что не относится к UI приложения (трекинг изменений, ваша логика) в отдельный webworker например. С vue.js это так же можно сделать, но уже надо закладывать недельку другую на реализацию и стабилизацию. А с ангуляром можно за день это сделать, так как это из коробки практически идет.
Или там… время идет и сервер-сайд пререндеринг вдруг понадобился не только для ботов (для них кое как можно наклепать быстро и с vue и даже с первым ангуляром используя jsdom например), но и для обычных юзеров, поскольку для них критически важно быстро увидеть актуальную информацию, а взаимодействие с приложением — тут могут и подождать пару десятков секунд. В angular/universe это из коробки.
Ну то есть, мое мнение — вообще все можно сделать на ванильном JS, но никто в здравом уме так делать не будет поскольку нужна гибкость и эффективность в разработке. И в зависимости от проекта и условий, выбирая ангуляр мы получаем огромнейший оверхэд с одной стороны, и максимальную гибкость с другой. Если нам такая гибкость не нужна — можно уже отдельный разговор вести. Подходы то у всех фреймворков которые мы обсуждаем приблизительно одинаковые.
Или там… время идет и сервер-сайд пререндеринг вдруг понадобился не только для ботов (для них кое как можно наклепать быстро и с vue и даже с первым ангуляром используя jsdom например), но и для обычных юзеров, поскольку для них критически важно быстро увидеть актуальную информацию, а взаимодействие с приложением — тут могут и подождать пару десятков секунд. В angular/universe это из коробки.
Ну то есть, мое мнение — вообще все можно сделать на ванильном JS, но никто в здравом уме так делать не будет поскольку нужна гибкость и эффективность в разработке. И в зависимости от проекта и условий, выбирая ангуляр мы получаем огромнейший оверхэд с одной стороны, и максимальную гибкость с другой. Если нам такая гибкость не нужна — можно уже отдельный разговор вести. Подходы то у всех фреймворков которые мы обсуждаем приблизительно одинаковые.
Когда вы уточнили свою точку зрения, тут я согласен с вами. Действительно возможностей фреймворка намного больше чем у просто библиотеки (на то он и фреймворк) и если точно известно, что ты будешь использовать или по крайней мере есть высокая вероятность, что скорее всего это понадобиться, то конечно разумнее выбрать фреймворк. Но даже в такой ситуации нужно просмотреть, что лучше - библиотека + библиотека + библиотека или фреймворк + допиливание напильником.
Вот честно, я пока так и не придумал ситуации, при которой "библиотека + библиотека + библиотека" выгоднее фреймворка. Вроде как основной мыслью подобного является гибкость разработки, мол берем DI из ангуляра, роутер отдельный, реакт какой или там тот же vue и вперед. Но я знаю не так много ситуаций когда это будет эффективнее в краткосрочной и долгосрочной перспективе. Маленькие библиотеки обычно грешат отсутствием должной поддержки со стороны их разработчиков и комьюнити, с другой стороны их своими силами поддерживать проще. Словом… вопрос очень скользский на самом деле. Я же просто ленивый и потому в 99% случаев предпочитаю фреймворк библиотекам. Тем более, если глянуть на тот же реакт, вроде бы и библиотека, но тянет за собой целую инфраструктуру. И тогда уже грань размывается.
После работы с vue, react + flux, angular могу сделать небольшое личное наблюдение — когда при работе например с angular, react + flux — тебе не приходится выдумывать ничего нового — основные концепции уже изобретены и проработаны, тогда как при работе с vue можно наткнуться на множество пробелов или недосказанности, где то приходится включать воображение и придумывать обходные пути для решения достаточно обыденных вопросов. Из понравившегося в vue — это computed функции. Но из-за обилия концепций — очень сложно написать хорошее решение, особенно когда в официальной документации мало сказано: как делать так чтобы добиться максимальной эффективности и простоты поддержки кода на vue.
Из понравившегося в vue — это computed функцииСтранно, что «костыль» может понравится, когда в Ангуляре и Реакте это делается обычными функциями или пропертями. Вот в Vue этот костыль нужен т.к. там kvo.
Можете дать более развернутое объяснение, что это "костыль" и желательно на примерах кода? Спасибо.
Основная идея у computed — это взять данные из третьего источника, преобразовать и вернуть результат. В Ангуляре и Реакте вы можете просто сделать/вызвать функцию. В vue вы тоже можете сделать функцию, но vue не будет отслеживать её результат, в итоге вам нужно разместить эту функцию в computed раздел, т.е. сделать computed объект, для того что-бы vue смог построить зависимости.
Такие махинации требуются от vue, вместо использования обычных функций в штатном режиме.
Другими словами — в vue создали проблему и героический её решили, когда у других такой проблемы вовсе нет. Вот и не понятно почему оно вам нравится.
Такие махинации требуются от vue, вместо использования обычных функций в штатном режиме.
Другими словами — в vue создали проблему и героический её решили, когда у других такой проблемы вовсе нет. Вот и не понятно почему оно вам нравится.
В эмбере это было задолго до Vue ...
Is Vue relevant anymore?
Sign up to leave a comment.
Angular — это паттерн проектирования