Comments 114
… а караван идет.
Непонятные символы везде. В Angular есть несколько крохотных языков, которые придется вставлять в строки в своем приложении. Готовьтесь изучать разницу между «=», «&», «=*», и «@»; «E», «A», и «EA»; оператором «|»; и другими иероглифами.Ну это несерьезно… понимание приходит после прочтения документации и ничего в этом сложного нет…
К сожалению со многим вынужден согласиться. Особенно с пунктом 3 — бороться с фреймворком приходится много, даже слишком. Когда только осваивал его, думал, что это просто с непривычки (парадигма-то другая), но опыт (и многочисленные публикации в интернете) показал, что нет — борются с ним все и недовольства много.
С чем конкретно вы боретесь, что вызывает недовольство? Хотя бы пункта три.
God-object в виде angular.
Совершенно уродский синтаксис директив, с чем связан высокий порог входа для написания директив.
Фабрики, сервисы — нет единого стиля описания зависимостей в контейнер, опять таки неоправданная сложность. А еще и не все понимают сам DI, так тут еще и запутанная реализация.
Совершенно уродский синтаксис директив, с чем связан высокий порог входа для написания директив.
Фабрики, сервисы — нет единого стиля описания зависимостей в контейнер, опять таки неоправданная сложность. А еще и не все понимают сам DI, так тут еще и запутанная реализация.
God-object в виде angular
God-object в виде Yii, Rails «впишите тут свой фреймвора» вас также не устраивает?
Совершенно уродский синтаксис директив, с чем связан высокий порог входа для написания директив
В чем он уродский? Или вы не разобравшись с compile, pre-link, post-link, scope transclusion, directive controller, controller require решили забить и обозвать его уродским?
А еще и не все понимают сам DI
Что там можно «не понять»?! Это дело одной недели.
Вам надо было просто написать «Ой, все», всего два слова, а смысла столько же.
Yii? Отвратительный фреймворк. Когда я писал на PHP — использовал Symfony, вот там все в этом смысле сделано прекрасно.
В чем уродский? Ну вот вы сами перечислили все эти магические вещи, в которых я достаточно долго и упорно разбирался и уже разобравшись говорю — да, это уродско.
Я-то понимаю DI, благодяря использованию Symfony, но я говорю про порог входа. Когда тебе показывают знаменитую вау-и-ах демку, где инпут и h1 связывают прямо в html — думаешь, как же все просто, это то, что я искал. А на деле при попытке написать что-то более серьезное — встречаешь стену из того что я описал и из того, что описано ниже.
И да, сбавьте высокомерие, я работаю с ангуляр прямо сейчас и прекрасно вижу его минусы и плюсы.
В чем уродский? Ну вот вы сами перечислили все эти магические вещи, в которых я достаточно долго и упорно разбирался и уже разобравшись говорю — да, это уродско.
Я-то понимаю DI, благодяря использованию Symfony, но я говорю про порог входа. Когда тебе показывают знаменитую вау-и-ах демку, где инпут и h1 связывают прямо в html — думаешь, как же все просто, это то, что я искал. А на деле при попытке написать что-то более серьезное — встречаешь стену из того что я описал и из того, что описано ниже.
И да, сбавьте высокомерие, я работаю с ангуляр прямо сейчас и прекрасно вижу его минусы и плюсы.
Совершенно уродский синтаксис директив
В чем он уродский?Я считаю, что создание директив должно быть ближе к vanilla JS который уже «все» знают, например в Angular Light, чтобы добавить директиву al-test, достаточно написать:
alight.directives.al.test = function(element) {};
И для этого не нужно создавать никаких модулей и т.п. А директиву можно установить/удалить в любой момент из любого места.
Все так, разработчики это осознают. В angular 2 все иначе делается (но это по сути уже совсем другой фреймворк).
Но, тем не менее, серьезных альтернатив пока что нет.
Но, тем не менее, серьезных альтернатив пока что нет.
Все перечисленное надуманное.
Ваша аргументация бесподобна.
А что аргументировать, возможно вам просто практики не хватает раз говорите о сложности и не понимании, ну и теории может быть, вам виднее как вы продуктивнее обучаетесь. То есть вы описали не проблемы инструмента, а свои.
Многие из перечисленных hell0w0rd проблем активно обсуждались в гугл-группе разработчиков angular при разработке архитектуры angular2. Так что не надуманные. Не настолько критичные, чтобы кричать «angular — дерьмо», как некоторые <irony>фанаты вывернутого наизнанку php</irony> — с ними прекрасно можно жить. Но не надуманные вовсе.
1. Фильтры. Совершенно убогий набор фильтров в стандартной поставке, на каждый чих надо писать свой новый фильтр.
2. Интероперабельность. Нельзя взять и заиспользовать готовое js-решение (почти на любую задачу оно есть). Надо или искать ангуляр-порт (не всегда хороший) или вдумчиво его оборачивать в ангулярные директивы и страдать.
3. Отладка. Где-то что-то поломалось — рухнуло всё приложение и в консоли чистота (если ошибка где-то в шаблоне).
В целом мы уже привыкли, набили шишек и вполне неплохо справляемся, но… Разработка идёт жутко медленно.
2. Интероперабельность. Нельзя взять и заиспользовать готовое js-решение (почти на любую задачу оно есть). Надо или искать ангуляр-порт (не всегда хороший) или вдумчиво его оборачивать в ангулярные директивы и страдать.
3. Отладка. Где-то что-то поломалось — рухнуло всё приложение и в консоли чистота (если ошибка где-то в шаблоне).
В целом мы уже привыкли, набили шишек и вполне неплохо справляемся, но… Разработка идёт жутко медленно.
Жутко медленно — по сравнению с чем?
Перефразируя вопрос: а на чём разработка шла бы заметно быстрее?
Перефразируя вопрос: а на чём разработка шла бы заметно быстрее?
По сравнению с «по старинке» — без js фреймворков (и практически без js вообще). Рендеринг на сервере, перезагрузка страницы на каждый чих, вот это всё.
Хех, я думал сейчас подискутируем о js фреймворках (vs js-библиотеки может)… а так, да, «по старинке» спору нет. Но эта страница истории уже перевёрнута.
Я думаю, что нет, не перевёрнута. Для информационных сайтов фреймворк типа Ангуляра не нужен. Потому что индексация поисковиками и вообще оверкилл. В веб-приложениях для всяких CRUDов это тоже оверкилл (хотя там-то проблем с ангуляром не возникает). И только на некоторых страницах с очень сложной логикой (типа GUI-редактора чего-нибудь, где надо двигать плашки по пространству) он себя оправдывает.
Мне кажется, что таких монстров надо держать в «клетках», т.е. внутри веб-компонент каких нибудь изолированных и не давать им властвовать над всем документом. Как-то так.
Мне кажется, что таких монстров надо держать в «клетках», т.е. внутри веб-компонент каких нибудь изолированных и не давать им властвовать над всем документом. Как-то так.
Angular сложноват. Я уже почти год использую его в небольшом проекте, но понимания все равно нет. Взять фабрики и сервисы. Читаешь доки, вроде делают одно и то же, отличаются самую малость. Зачем плодить сущности? Так и живу — пишу код на Angular, вроде все работает, но ни хрена не понимаю.
React не использую, но когда-то прочитал небольшой обзор и все было понятно.
React не использую, но когда-то прочитал небольшой обзор и все было понятно.
согласен. Непонятно, слишком много сущностей, избыточно много. И непонятно, что брать
Как можно за год его не понять??? Пусть я буду заминусован, но что-то с вами не так…
Вижу юношеский максимализм.
Я нигде не сказал, что я его изучал год. Периодически использовать и постоянно с чем-то работать — разные вещи.
В силу возраста какие-то вещи схватываются хуже, поэтому хочется простого и понятного инструмента, а Angular, по моей шкале, к таким инструментам не относится. Я изучил его ровно настолько, чтобы использовать его в нужных мне объемах, а ковыряться в нем дальше у меня желания нет.
Я нигде не сказал, что я его изучал год. Периодически использовать и постоянно с чем-то работать — разные вещи.
В силу возраста какие-то вещи схватываются хуже, поэтому хочется простого и понятного инструмента, а Angular, по моей шкале, к таким инструментам не относится. Я изучил его ровно настолько, чтобы использовать его в нужных мне объемах, а ковыряться в нем дальше у меня желания нет.
А что Вы считаете простым и понятным инструментом? парочку примеров
MeteorJS например. Периодически что-то делаю на AngularJS, но каждый раз получаются какие-то костыли, как по мне. Ковыряться тоже желания нет
У меня такая же ситуация с Angular. Полгод разрабатываю на Angular и до сих пор есть проблемы с service — factory — provider, со скопом директив, с банальным реюзом методов моделей. Да и с производительностью у него не ахти, я не нашел ни одного хорошего примера бесконечного списка, уже на 1000-1500 позиций большинство начинает безбожно тормозить. Тот же ng-repeat для больших таблиц с часто меняющимися данными не вариант. А когда приходится разбирать чужой код, там вообще финиш потому, что одни и те же вещи можно сделать очень разными способами и если не следить за псевдо глобальными переменным в rootscope получается страшная лапша.
оффтоп
Посмотрите как это реализовано в Ionicframework ionicframework.com/blog/collection-repeat/
не нашел ни одного хорошего примера бесконечного списка, уже на 1000-1500 позиций большинство начинает безбожно тормозить
Посмотрите как это реализовано в Ionicframework ionicframework.com/blog/collection-repeat/
jQuery например.
Я с новыми технологиями не работаю, но интересуюсь. Аналогичная ситуация складывается во многих сферах. Возьмем языки программирования. Где-то я понимаю практически всё не зная языка (например, Go), а если смотрю на современный С++, то мне становится страшно, хотя в 90-х активно писал на нем. Мне кажется развитие должно идти в сторону упрощения и понижения порога входа, а получается как-то наоборот.
Я с новыми технологиями не работаю, но интересуюсь. Аналогичная ситуация складывается во многих сферах. Возьмем языки программирования. Где-то я понимаю практически всё не зная языка (например, Go), а если смотрю на современный С++, то мне становится страшно, хотя в 90-х активно писал на нем. Мне кажется развитие должно идти в сторону упрощения и понижения порога входа, а получается как-то наоборот.
Как можно сравнивать «либу-расширение» (jQuery) и полноценный фреймворк?
Я в ангуляре разобрался за неделю. Может вы не там ищете? Я не спорю что сидя над одной документацией с офф сайта вы станете гуру быстро, но взять даже codeschool или Egghead с youtube
Я в ангуляре разобрался за неделю. Может вы не там ищете? Я не спорю что сидя над одной документацией с офф сайта вы станете гуру быстро, но взять даже codeschool или Egghead с youtube
Просто мне хочется от фреймворка такой же простоты, как в jQuery. Ну ладно, накладывается связь данных с DOM, асинхронность, но почему это настолько всё усложняет?
У нас спор с вами ни о чем, так как разговариваем немного о разных вещах.
У нас спор с вами ни о чем, так как разговариваем немного о разных вещах.
Так jQuery это простой набор методов и эвентов и ВСЕ. Я и спрашиваю как можно сравнивать 2 разных вещи? Это тоже самое что сказать Paint такой легкий — взял тыкнул карандаш и рисуешь, а Photoshop — там еще слои какие-то создавать надо и перемещать их можно — очень сложно.
Я не понимаю что такого сложного в Ангуляре? Минимум понимания для нормальной работы с ним это:
— в контроллерах храним чистые данные и обработчики
— в директивы выносим работу с DOM элементами и навешивание тех же jQuery плагинов
— сервисы как хранилища или конструкторы
Самый простой вид SPA:
— в конфиге полотно роутов
— для каждой страницы свой контроллер
— в контроллерах запрос данных через рест
— в хтмл вывод данных через директивы встроенные
Возможно сложно понять ангуляр тем кто не фронтендер? потому что кто его понимает — это рай для быстрой разработки.
Я не понимаю что такого сложного в Ангуляре? Минимум понимания для нормальной работы с ним это:
— в контроллерах храним чистые данные и обработчики
— в директивы выносим работу с DOM элементами и навешивание тех же jQuery плагинов
— сервисы как хранилища или конструкторы
Самый простой вид SPA:
— в конфиге полотно роутов
— для каждой страницы свой контроллер
— в контроллерах запрос данных через рест
— в хтмл вывод данных через директивы встроенные
Возможно сложно понять ангуляр тем кто не фронтендер? потому что кто его понимает — это рай для быстрой разработки.
— в контроллерах храним чистые данные и обработчики
Что подразумевается под обработчиками? Если речь о бизнес логике, то это не очень хорошее решение.
— в директивы выносим работу с DOM элементами и навешивание тех же jQuery плагинов
Иногда jQuery плагин удобнее навешивать после загрузчки данных, когда уже произошла линковка директив и отработал контроллер. Тут надо исхитряться.
— сервисы как хранилища или конструкторы
Использовать сервисы как конструкторы, довольно неудобно. Приходится изворачиваться, так как сервисы синглетоны.
Самый простой вид SPA:
Статья как раз о том, чтобы делать и поддерживать сложные SPA. С простыми проблем нет, и автор специально подчеркивает этот момент.
Иногда jQuery плагин удобнее навешивать после загрузчки данных, когда уже произошла линковка директив и отработал контроллер. Тут надо исхитряться.Приведите пример. Очень интересно что за случай такой где плагин не может навеситься раньше чем отработает контроллер (если я правильно понял что в это проблема)
Статья как раз о том, чтобы делать и поддерживать сложные SPA. С простыми проблем нет, и автор специально подчеркивает этот момент.В данной ветке сообщений обсуждается непонимания ангуляра вцелом, я привел пример самого просто СПА как вопрос «что тут понимать?»
Пример плагина: github.com/fengyuanchen/cropper
Если изображения нет, то он неправильно инициализируется, поэтому удобно навешивать его после того, как ангулар загрузит данные об изображении.
В простом случае все понятно, но это не опровергает того, что ангуляр сложный, непонятный, запутанный фреймворк.
Если изображения нет, то он неправильно инициализируется, поэтому удобно навешивать его после того, как ангулар загрузит данные об изображении.
В данной ветке сообщений обсуждается непонимания ангуляра вцелом, я привел пример самого просто СПА как вопрос «что тут понимать?»
В простом случае все понятно, но это не опровергает того, что ангуляр сложный, непонятный, запутанный фреймворк.
Что мешает сделать так с плагином: jsfiddle.net/U3pVM/12840/
Это хороший пример.
Но ломается, когда сначала задать дефолтовое изображение для которого не нужен кроппер, а потом поменять. В итоге я должен учитывать, когда выполняется директива и на что реагирует. Все это решаемо, но создает сложности.
Но ломается, когда сначала задать дефолтовое изображение для которого не нужен кроппер, а потом поменять. В итоге я должен учитывать, когда выполняется директива и на что реагирует. Все это решаемо, но создает сложности.
ЗЫ сам невнимательный забыл $('img') заменить — вот верный вариант jsfiddle.net/U3pVM/12842/
UFO just landed and posted this here
Скорее всего не бросят, пока альтернативу не родят.
Сделали и активно продвигают как «фреймворк будущего» www.polymer-project.org/
UFO just landed and posted this here
AngularJs 1.3 vs 2.0 — действительно боль, но не всё так страшно
* Ушел Роб Эйзинберг, вернувшись к своему старому начинанию — ещё ничего не значит. Может он просто устал, есть свои идеи, хочется чего-то свежего. Команда Ангуляра от этого не исчезает и там много сильных профессионалов.
* 2.0 полностью переписан и не понятно как мигрировать с 1.3 — действительно так. Но представим себе, что это просто новый фреймворк! Мы же не жалуемся, что мигрировать между Angular и React тяжело — разные фреймворки, каждый со своими фишками. Вопрос в том, на сколько эти фишки заманчивы, чтобы начать новый проект на Angular 2.0 или даже взять и переписать старый с нуля? Посмотрим. Верим, надеямся, ждём…
* Будут распылять свои силы между поддержкой AngularDart, 1.3 и 2.0…
AngularDart существовал и во времена 1.x и это «распыление» не мешала двигаться от 1.1 к 1.2 и к 1.3. Напротив, как писали разработчики в своём блоге, опыт с AngularDart их многому научил и какие-то идеи они портировали обратно в AngularJs.
Что действительно пугает: поддержка 1.3 может станет минимальной (например, гугловцы захотят форсировать этим повсеместное использование 2.0) и тогда миллионы проектов написанных на Angular 1.2 и 1.3 окажутся в неприятной ситуации. В а в заголовках описаниях вакансий мы увидим «Требуется разработчик Angular 1.3» или "… Angular 2.0". В итоге всё может получиться как с Python 3 или Perl 6.
Ещё не понятно как гуглить вопросы/ответы/обсуждения касающиеся какой-то определённой версии Angular, если будут два активных коммунити с разными фреймворками, но одинаковым ключевым словом «Angular».
* Ушел Роб Эйзинберг, вернувшись к своему старому начинанию — ещё ничего не значит. Может он просто устал, есть свои идеи, хочется чего-то свежего. Команда Ангуляра от этого не исчезает и там много сильных профессионалов.
* 2.0 полностью переписан и не понятно как мигрировать с 1.3 — действительно так. Но представим себе, что это просто новый фреймворк! Мы же не жалуемся, что мигрировать между Angular и React тяжело — разные фреймворки, каждый со своими фишками. Вопрос в том, на сколько эти фишки заманчивы, чтобы начать новый проект на Angular 2.0 или даже взять и переписать старый с нуля? Посмотрим. Верим, надеямся, ждём…
* Будут распылять свои силы между поддержкой AngularDart, 1.3 и 2.0…
AngularDart существовал и во времена 1.x и это «распыление» не мешала двигаться от 1.1 к 1.2 и к 1.3. Напротив, как писали разработчики в своём блоге, опыт с AngularDart их многому научил и какие-то идеи они портировали обратно в AngularJs.
Что действительно пугает: поддержка 1.3 может станет минимальной (например, гугловцы захотят форсировать этим повсеместное использование 2.0) и тогда миллионы проектов написанных на Angular 1.2 и 1.3 окажутся в неприятной ситуации. В а в заголовках описаниях вакансий мы увидим «Требуется разработчик Angular 1.3» или "… Angular 2.0". В итоге всё может получиться как с Python 3 или Perl 6.
Ещё не понятно как гуглить вопросы/ответы/обсуждения касающиеся какой-то определённой версии Angular, если будут два активных коммунити с разными фреймворками, но одинаковым ключевым словом «Angular».
Эйзенберг не устал, просто решил своё делать, так, как он хочет, только недавно выпустил новый фреймворк Aurelia — eisenbergeffect.bluespire.com/introducing-aurelia/
* 2.0 полностью переписан и не понятно как мигрировать с 1.3 — действительно так. Но представим себе, что это просто новый фреймворк! Мы же не жалуемся, что мигрировать между Angular и React тяжело — разные фреймворки, каждый со своими фишками. Вопрос в том, на сколько эти фишки заманчивы, чтобы начать новый проект на Angular 2.0 или даже взять и переписать старый с нуля? Посмотрим. Верим, надеямся, ждём…
Так и получается, если мыслить категориями 5-10 летней разработки(поддержки) сложного проекта, то риски переписывания всего приложения с нуля (например, с выходом
Но представим себе, что это просто новый фреймворк! Мы же не жалуемся, что мигрировать между Angular и React тяжело — разные фреймворки, каждый со своими фишками.
Что автоматически означает, что вы работаете с продуктом, который развиваться уже не будет и так или иначе нужно переписывать все заново — бизнес, зачастую, такого не понимает. Это никак нельзя сравнивать с миграцией на новую версию фреймворка XYZ. А актуализация инструментов, как мне кажется, жизненно необходима для поддержания приложения, эксплуатация которого планируется более-менее долгое время.
> Будут распылять свои силы между поддержкой AngularDart и 2.0
Angular2 поддерживает и ES6 и Dart. Уже можно посмотреть: github.com/angular/angular/
Angular2 поддерживает и ES6 и Dart. Уже можно посмотреть: github.com/angular/angular/
1.3 может станет минимальной
Вряд ли. Судя по трекеру на гитхабе — будет как минимум 1.4 и 1.5.
40 часов на изучение Angular-а — это очень мало, имхо. И не согласен с тем, что жесткая архитектура — это зло. Мне вот кажется, что Angular недостаточно жесткий. Сколько было статей на тему «самая правильная структура проекта Angular». Вообще текст в стиле «не читал, но осуждаю».
40 часов на изучение Angular-а — это очень мало, имхо.
Кажется, это само по себе минус ангуляра.
На мой взгляд, в javascript-мире царил хаос до появления Angular. Любой мало-мальски крупный проект вырождался в тонны лапши. И ни один фреймворк до Angular-а этой проблемы не решал. Вы скажете, а как же Backbone? Backbone — это просто поделка по сравнению с Angular-ом. Если вы когда-нибудь писали что-нибудь крупное на Backbone, то, конечно, знаете о том, что не очень-то он подходит для этого. 40 часов — это много? Ну тогда продолжайте варить лапшу.
Вы скажете, а как же Backbone? Backbone — это просто поделка по сравнению с Angular-ом.
Извините, кажется, я не готов поддерживать заданный уровень дискуссии ;-)
UFO just landed and posted this here
Яндекс использует Backbone во многих своих проектах со сложным фронтендом. Не сказал бы что эти проекты не крупные и насколько я понял когда был на их последнем митапе, они им очень довольны.
Очевидно, что эта статья — часть пиара ReactJS.
40 часов для человека, который хорошо владеет js и современными паттернами фронтенд-разработки мало? Тогда наверное ангуляр действительно сделан неоправдано сложно.
В статье много здравых мыслей. Но некоторые суждения явно следуют лишь из того, что автор работал с ним всего 40 часов.
Например:
Тупо разница в объёме кода: на Реакте кучу всего придётся написать ручками (опять и опять и опять, если только не начнёте использовать какую-то высокоуровневую абстракцию поверх Реакта), а в Ангуляре достаточно будет воспользоваться магическими иероглифами «=», «&», «=*», и «@»; «E», «A», и «EA», так критикуемые автором, которые к десятому проекту вы уже выучили.
Например:
Когда я писал такое же приложение в первые раз на Реакте, мне понадобилось 28¾ часов. То же самое приложение на Angular я писал 39½ часа, не смотря на то, что я мог использовать часть кода из первой попытки на Реакте. Десять часов сверху. Причина — излишняя сложность Angular.Ангуляр действительно сложнее, чем Реакт. Но попробуйте написать не первое приложение, а десятое, и окажется, что на Реакте вам всё ещё требуются условно 20 часов, а на Ангуляре справитесь за 5!
Тупо разница в объёме кода: на Реакте кучу всего придётся написать ручками (опять и опять и опять, если только не начнёте использовать какую-то высокоуровневую абстракцию поверх Реакта), а в Ангуляре достаточно будет воспользоваться магическими иероглифами «=», «&», «=*», и «@»; «E», «A», и «EA», так критикуемые автором, которые к десятому проекту вы уже выучили.
Отлично, всё в точку!
А такого же про Ember.js нету случайно?
А такого же про Ember.js нету случайно?
В блоге Джеймса Шора аналогичной статьи про Ember пока нет, но в комментариях его просили он обещал!
Статья слабенькая. Все фреймворки по определению обладают этими недостатками.
Backbone?.. ах да, он же не фреймворк, он либа…
какая же backbone либа? есть роутер, вью. либа это underscore, jquery. backbone — скелет, в вольном переводе. и он обязывает к определённому дизайну кода.
Не «скелет» а «хребет». И не обязывает а предлагает. В нём можно как быстренько наговнокодить html-ом и попапами в моделе, так и задать аттрибуты для вью. Кроме того — другой код спокойно интегрируется в проект на backbone, например тот же $.ajaxPrefilter для глобальной обработки ошибок. Я уж не говорю о том что можно спокойно переписать любой метод под нужды конкретного проекта.
А роутер — что роутер? Всё что он делает это вызывает инициализацию конкретных кусков кода или делает конкретные вещи. RequireJS и тот больше работы делает.
От «дизайна» кода останется только специфичный вариант работы с данными через сеттеры/геттеры да надстройка над ajax-запросами. Но эти вещи всёравно будут в любой современной фронтовой либе или фреймворке.
А роутер — что роутер? Всё что он делает это вызывает инициализацию конкретных кусков кода или делает конкретные вещи. RequireJS и тот больше работы делает.
От «дизайна» кода останется только специфичный вариант работы с данными через сеттеры/геттеры да надстройка над ajax-запросами. Но эти вещи всёравно будут в любой современной фронтовой либе или фреймворке.
Согласен. И на освоение Backbone нужно часа 2 — за это время он уже становится понятным.
Ну, а возможность переопределить поведение любого метода да и вообще чего угодно — это несомненно здорово. Например меня не устраивала логика работы модели и того, что она возвращала через
Так же и с добавлением WebSocket в качестве транспорта — не сказать, что совсем без проблем, но ничего сложного.
Ну, а возможность переопределить поведение любого метода да и вообще чего угодно — это несомненно здорово. Например меня не устраивала логика работы модели и того, что она возвращала через
previousAttributes(), переписал нужное, и переопределил прототип модели глобально.Так же и с добавлением WebSocket в качестве транспорта — не сказать, что совсем без проблем, но ничего сложного.
UFO just landed and posted this here
«На фундаментальном уровне, Angular считает, что вы используете stateless „сервис“-объекты для логики и простые объекты для структур данных (объекты без методов) для сохранения состояния. Сервисы по сути — глобальные переменные; большинство функций могут использовать любой сервис, обращаясь к ним по особому имени. Структуры данных хранятся в $scope, они связаны с шаблонами и директивами. Объекты структур данных управляются „контроллерами“ („клей“, связанный с шаблонами и директивами) и сервисами.»
Вы зачем это в дополнительные кавычки взяли? Я уж испугался, что автор обзора это откуда-то цитирует и что это из документации AngularJS.
UFO just landed and posted this here
Использовал ангуял в 6 проектах разной степени сложности. В последних перешал на angularjs + coffeescript. Все модели, вся бизнес логика, сервисы и т.д. описывается обычными классами на кофе, которые, при использовании nodejs, могут также использоваться на сервере.
После чего, при необходиости врапим, или используем на прямую.
В итоге никакой зависимости от ангуляра нет плавно и легко можно свалить на любой фреймворк
Если нет страха перед перездом можно использовать ng-classify с ним код еще чище.
class Resizer
constructor: (@$q)->
createImg: (urlData)->
resize: (doc, img, width, height)->
makeBlob: (doc, canvas, width, height)->
putImageToCanvas: (doc, img, width, height)->
resample_hermite: (canvas, W, H, W2, H2) ->
После чего, при необходиости врапим, или используем на прямую.
services.service 'Resizer', ['$q', Resizer]
В итоге никакой зависимости от ангуляра нет плавно и легко можно свалить на любой фреймворк
Если нет страха перед перездом можно использовать ng-classify с ним код еще чище.
Точно так же, обычными классами, можно писать и без кофескрипта (если кто, как и я, недолюбливает его синтаксис). Любая «классическая» реализация «классов на прототипах» подойдет.
Зависимости для внедрения можно определять прямо в классе сервера:
class sys.Service
@$inject: ['$log', '$http', '$q']
constructor: (@log, @http, @q) ->
@log.debug("sys.Service - ok")
Перешел на ангулар чуть больше, чем пол года назад с ванилла жс на классах + requirejs + jquery. За неделю чтения официальных доков и просмотра видео от egghead стало всё ясно-понятно. Проблемы или вопросы безусловно возникали, но быстро решались на стэковерфлоу.
Занимательный факт, что я заметил. Ангулар обычно хают люди, которые:
* не имеют большого опыта программирования на чистом js и ждут какой-то магии или супер-простоты от инструмента, что он, видимо, должен решать проблемы и архитектуры и языкаи вообще, я просто сейчас нафигачу по-быстрому, а как оно дальше будет жить потом разберемся
* не дочитав до конца доки и не поняв ключевые аспекты начинают городить костыли/лапшу/говнокод
* те, кто привык к лапше на джиквери, пишут лапшу на ангуляре, ни какой фреймворк или библиотека не решит проблему личного отношения к коду, не закладывая сразу пути для его более легкого масштабирования и поддержке
Занимательный факт, что я заметил. Ангулар обычно хают люди, которые:
* не имеют большого опыта программирования на чистом js и ждут какой-то магии или супер-простоты от инструмента, что он, видимо, должен решать проблемы и архитектуры и языка
* не дочитав до конца доки и не поняв ключевые аспекты начинают городить костыли/лапшу/говнокод
* те, кто привык к лапше на джиквери, пишут лапшу на ангуляре, ни какой фреймворк или библиотека не решит проблему личного отношения к коду, не закладывая сразу пути для его более легкого масштабирования и поддержке
если честно, то учитывая высокоуровневость сегодняшних технологий, то да, я ожидаю, что фреймворк будет за меня решать какие-то проблемы и архитектуры языка. тот же React сам следит за DOM, как пример. он же умеет рендериться на сервере, что решает одну из проблем клиентсайда — доступность инфы поисковикам. так что да, на сегодняшний момент сообщество имеет возможность из всех инструментов выбирать лучшие.
позиция «вы ещё на чистом js не писали» никуда не годится. давайте серверные приложения писать на ассемблере? а потом такие придём в современный .net, например и будем не понимать, чего это кто-то вообще возмущается, тут же вона одну функцию пишешь и не надо работать с регистрами. и опять же: да, я ожидаю от инструмента супер простоты и магии. для примера возьмите тот же React. virtual dom — чем не магия?
позиция «вы ещё на чистом js не писали» никуда не годится. давайте серверные приложения писать на ассемблере? а потом такие придём в современный .net, например и будем не понимать, чего это кто-то вообще возмущается, тут же вона одну функцию пишешь и не надо работать с регистрами. и опять же: да, я ожидаю от инструмента супер простоты и магии. для примера возьмите тот же React. virtual dom — чем не магия?
Ух ты, дожил! js назвали ассемблером!
Разные фреймворки для разных целей. Вы не думали что рендеринг на клиенте в некоторых случаях это преимущество? Что мешает от сервера получать «голые» данные, а статику рендерить из $templateCache? Это можно также сказать «ложкой можно суп есть, а вот вилка почему-то не отвечает моим требованиям»…
Занимательный факт, что я заметил. Ангулар обычно хают люди, которые
Безапелляционненько как-то. Есть люди которые просто нашли более _эффективный_ (результат\время) фреймворк для своих задач. И с высоты своего опыта, прошу прощения за высокий штиль, недоумевают почему ангулар присвоил себе звание «серебряной пули».
Я, например, считаю что в фундаменте ангулара(1.х) лежит серьёзный компромисс. Давайте у нас всё будет работать не так быстро как могло бы ( а иногда и откровенно умирать, признаемся честно), но это ничего — зато мы всё круто зарегулируем и стандартизуем. Это пахнет «программизмом для программистов», а не для конечных пользователей. Процессом ради процесса. Да, для каких-то задач ангулар — отличный инструмент. Но не для всех. И даже не для 90%. Это один инструмент из многих — есть молоток, а есть шуруповёрт.
Теперь можете рассказать мне что я не имею большого опыта программирования на vanillajs и далее по тексту. Только перед этим расскажите с какими фреймворками(кроме ангулара) вы реально работали, щупали руками и применяли на практике.
Я не восхваляю ангулар до небес :) Он хорош для большинства SPA/REST приложений, не так сложен, запутан и непоследователен, как тут плачутся многие. Да, конечно это инструмент и каждый вправе выбирать себе свой молоток и это хорошо.
По поводу производительности, тоже проблем не замечал, если не пихать кучу бесполезного хлама в скоуп и юзать милиард вотчеров. Даже на самом быстром фреймворке всегда можно написать тормознутое говно.
По поводу производительности, тоже проблем не замечал, если не пихать кучу бесполезного хлама в скоуп и юзать милиард вотчеров. Даже на самом быстром фреймворке всегда можно написать тормознутое говно.
Я считаю что angular абсолютно последователен и совершенно логичен в рамках выбранной дата-драйвин концепции.
Но это не отменяет проблем его реализации — вербозность и «тоталитарность», если вы понимаете о чём я.
Фиг с ней с вербозностью — хотя это вполне себе бессмысленные временные затраты, но вот «тоталитарность» гораздо злее. Высшим злом любого фреймворка я считаю ситуацию, когда его внутренние проблемы с формулировкой «вам это не надо», всплывают наверх через весь продукт, к конечному пользователю. И «вам это не надо» приходится говорить уже пользователю («все равно его не брошу потому что он хороший»). Или отказываться от такого фреймворка :)
Но это не отменяет проблем его реализации — вербозность и «тоталитарность», если вы понимаете о чём я.
Фиг с ней с вербозностью — хотя это вполне себе бессмысленные временные затраты, но вот «тоталитарность» гораздо злее. Высшим злом любого фреймворка я считаю ситуацию, когда его внутренние проблемы с формулировкой «вам это не надо», всплывают наверх через весь продукт, к конечному пользователю. И «вам это не надо» приходится говорить уже пользователю («все равно его не брошу потому что он хороший»). Или отказываться от такого фреймворка :)
Вставлю несколько слов о «жестких рамках» в которые нас вставляет Ангуляр. Когда-то одна команда встала перед выбором — что взять для нового проекта? Потенциально большого. Решили — в интернете полно решений для всего:
И всё шло хорошо. Пока в команде было 2 разработчика. Было много code review, всё писалось в едином стиле. Но вот появляется новый разработчик. Он пишет немного по другому. Потом четвертый. Теперь все пишут по-своему.
Это первая проблема — когда рамки в проекте держатся только на code review и уровне программиста.
А вот вторая проблема — появляется новый программист. Совершенно новый. Теперь ему надо въезжать во все эти велосипеды. В случае, если б это был Ангуляр, HR отдел бы искал js-angular программиста и он бы въехал в проект гораздо быстрее.
- нужны модули? require.js
- нужны роуты? Crossroads.js
- нужны темплейты? underscore.templates
- нужны тесты? mocha+chai
И всё шло хорошо. Пока в команде было 2 разработчика. Было много code review, всё писалось в едином стиле. Но вот появляется новый разработчик. Он пишет немного по другому. Потом четвертый. Теперь все пишут по-своему.
Это первая проблема — когда рамки в проекте держатся только на code review и уровне программиста.
А вот вторая проблема — появляется новый программист. Совершенно новый. Теперь ему надо въезжать во все эти велосипеды. В случае, если б это был Ангуляр, HR отдел бы искал js-angular программиста и он бы въехал в проект гораздо быстрее.
Не согласен с 3м пунктом статьи полностью. Во все времена какой бы фреймворк не юзал, если ты не имеешь представления как оно устроено и работает внутри, кашу не сваришь. Однотипные задачи научишься писать и всё. А вещи оптимизация приложения, и прочие просто отправляются на свалку с таким подходом. Раньше народ который писал на первобытных сях и прочем имея казалось бы хороший высокоуровневый язык, всё равно задумывался о выравнивании структур компилятором, и том сколько байт считывает за раз контроллер диска и тд и тп. Так что «побочаня сложность» в данном случае равна «мне лень это понять». Наверно в наши дни это одна из причин почему железяки становятся всё мощнее, а приложения под них как медленно работали, так и продолжают.
По сути минус только один, могут забросить поддержку 1.х после входа 2.х, а мигрировать будет не реально тк 2.х по сути будет новый фреймворк. Остальное надуманное.
Почитал… подумал… Авто пишет — избегать по возможности. Но встаёт вопрос — а что тогда использовать?
Я сейчас использую js + Knockout js в проектах. Но knockout'a стало не хватать. Кто подскажет, куда теперь посмотреть? Выбирал между AngularJS и BackBoneJS… Теперь и не знаю…
Я сейчас использую js + Knockout js в проектах. Но knockout'a стало не хватать. Кто подскажет, куда теперь посмотреть? Выбирал между AngularJS и BackBoneJS… Теперь и не знаю…
Так react же (в начале поста ссылка на такой же обзор про реакт). Его многие недооценивают и самое главное не понимают. Он работает принципиально не так как остальные фреймворки. Вместо 2-way data binding (без которого многие не представляют как вообще можно работать), reaсt предлагает 1-way data flow. Этот подход надо прочувствовать. Вот тут все рассказано github.com/facebook/flux.
Я уже выше писал в комментариях, у нас в hexlet.io на react/flux написана облачная IDE и простым это приложение не назовешь. Можно посмотреть: github.com/Hexlet/hexlet-ide.
Я уже выше писал в комментариях, у нас в hexlet.io на react/flux написана облачная IDE и простым это приложение не назовешь. Можно посмотреть: github.com/Hexlet/hexlet-ide.
Пытался я к нему присматриваться… " раза пытался на него серьёзно посмотреть, но не могу, не нравится мне он. Как увижу возвращение кусков вёрстки в нём… Он нарушает моё чувство прекрасного ) Не нравится мне этот подход.
Как я уже говорил, реакт это совершенно другая идеология. JSX это не верстка, это всего лишь обертка для более простого визуального восприятия. На самом деле оно компилируется в js код, если уж так хочется то можно сразу в js коде писать. Все дело в том что реакт работает с виртуальным домом, и вот это не просто прекрасно это революция в вебе. Посмотрите вот эту статью habrahabr.ru/post/217295/
Если по простому, то в реакте приложение генерируется полностью заного на каждое изменение. Основной смысл каждого компонента вернуть новый virtual dom. Дальше реакт делает diff с предыдущим состоянием и очень хитро производит изменения в реальном доме, таким образом чтобы сократить количество обращений до минимума. Эта техника приводит к очень серьезному ускорению, потому что virtual dom это всего лишь структуры данных на js которые работают чертовски быстро, а обращения к реальному дому это самое медленнное в работе js фреймворков. Так вот реакт не просто быстр, он фантастически быстр и еще он совсем другой. Его нельзя оценивать через призму обычных подходов, потому что его подходы революционны, а не эволюционны.
Спасибо за ссылку. Посмотрел.
Как я понял React — это всё равно не фулстэк фреймворк, как я понял, он только для UI. Поправьте, если я ошибаюсь. А проблем со скоростью я пока и на knockout не встречал.
Как я понял React — это всё равно не фулстэк фреймворк, как я понял, он только для UI. Поправьте, если я ошибаюсь. А проблем со скоростью я пока и на knockout не встречал.
Я не очень понимаю когда говорят «не фулстек», вот мы на нем делаем сложные приложения и фактически ничего дополнительного не используем. Только бекенд дописываем, но в таком случае ни ангуляр ни кнокаут тоже не фулстек, потому что у них тоже нет бекенда ;), в отличие от, скажем meteor.
Единственное это роутер, в реакте он идет не из коробки пока, но есть очень клевое популярное решение. И насколько я понял разработчики фейсбука уже общаются с теми кто делает этот роутер и возможно его включат.
Единственное это роутер, в реакте он идет не из коробки пока, но есть очень клевое популярное решение. И насколько я понял разработчики фейсбука уже общаются с теми кто делает этот роутер и возможно его включат.
Чего вам стало не хватать в нокауте?
По большому счёту всё устраивает… Не совсем корректно выразился. На Angular позарился из-за модульности из коробки, директив…
Я в свое время перешел с Knockout.js на Angular.js, тут описал некоторые преимущества второго.
UFO just landed and posted this here
Sign up to leave a comment.
Нетрадиционный обзор AngularJS