Ember.js? Я вас умоляю. У них на форуме есть целая большая дискуссия о том, как сделать эмбер попроще так, чтобы он по learning curve смог хоть как-то приблизиться к ангуляру. Сейчас там все очень плохо в этом плане. Автор этой статьи, судя по всему, в случае эмбера ни до каких CarProviderProvider бы вообще докопаться не смог, так как просто не осилил бы написать ни одной строчки работающего кода.
CarProviderProvider — это замечательный пример в статье, показывающий, что ее автор вообще не понимает, что такое сервисы в ангуляре и как их готовить (и даже в принципе не очень знаком с базовым синтаксисом из документации). Но смешно писать умеет, этого не отнять. Хотя после этого примера дальше можно и не читать.
Кстати, в моем типичном ангулярном приложении большинство сервисов — это самые что ни на есть POJO (и при этом да, там есть провайдеры и фабрики).
В качестве аргумента я привел то, что мои сложные приложения от использования ангуляра стали проще, и не только мои. Я считаю это важным фактором эффективности. И как тимлид с некоторым опытом, я лучше возьму в команду дорогого специалиста, умеющего с помощью ангуляра решить сложную задачу за 1500 строк, чем трех дешевых новичков, которые напишут 17 000 строк «простого» кода с тем же результатом.
Кстати, по поводу 100 000 строк кода. История ангуляра началась с того, что Мишко Хевери практически на спор смог переписать фронтэнд Google Feedback, насчитывающий на тот момент 17 000 строк, так, что он уместился в 1500 строк, не потеряв в функциональности. Это к вопросу о сложных и простых вещах из комментария товарища SowingSadness ниже.
Порог вхождения — это не блажь или злые козни разработчика фреймворка, желающего потешить свое самолюбие, а объективные требования к квалификации программиста. Ангуляр сложный ровно настолько, насколько это требуется. Я и до ангуляра писал приложения, используя примерно те же самые подходы, просто не настолько элегантно выполненные. Для меня ангуляр сделал работу проще, а не сложнее.
Согласен, и для решения этой проблемы уже существует три различных решения от противоборствующих лагерей — typescript от майкрософт, dart и closure compiler от гугла. И независимо от предпочтений, все три замечательно сочетаются с ангуляром.
Совсем не кажется, потому что это практически уже MVC-фреймворк #1 на данный момент. Сужу по вакансиям на odesk.com и бывшем hantim.ru — куда ни плюнь, везде требуется либо ангуляр, либо, реже, ember.js.
Много хейта, мало вдумчивости. Если бы автор поработал над приложением, где много сложной клиентской логики, и которое пытается следовать лучшим практикам современного программирования в плане тестируемости, использования IoC, и тому подобного, то он бы сам все понял. Хотя, возможно, и не понял бы, но от этого ангуляр не становится менее прекрасным.
Кстати, именно по той причине, что есть некие сложности в работе с ключевым словом new, я всем всегда рекомендую не использовать Module.service() вообще, а ограничиться во всех случаях одним Module.factory() для простых сервисов и Module.provider() для конфигурируемых. Так жизнь будет сильно роще.
В ангуляре 2.0 сервисы вообще станут обычными классами ES6 с аннотациями, и проблема исчезнет вовсе.
Ну а в целом да, у ангуляра довольно крутая learning curve, и это скорее достоинство, чем недостаток, потому что позволяет быстро и точно отсеять тот табун js monkey coders, про которых сам же автор и упомянул в начале.
Если я правильно вас понял, то да, можно — посмотрите на пример в статье, там есть контролы на каждом уровне. Можно изменять состояние контрола и смотреть, что будет происходить при навигации в нижних уровнях.
В 1934 г. американец Норман Р. Френч получил патент на оптическую телефонную систему, речевые сигналы в которой передавались при помощи света по стержням чистого стекла.
Это не своеобразный функционал, это data binding, который в современных приложениях используется не в пример чаще, чем дубовая логика «переключить инпут в противоположное состояние при клике». У вас, вероятно, просто еще мало опыта в разработке сложных js-приложений — рекомендую прислушаться к советам в статье, а не спорить с ними.
Ваш код не будет работать аналогично примеру из статьи. См. ответ на комментарий выше.
Все тоже самое делает под капотом Ангулар.
Разумеется. Так же, как например браузер под капотом выполняет императивные инструкции по рендерингу страницы, что не лишает нас удобной возможности определять ее внешний вид в декларативном HTML, оставляя его парсинг заботам браузера.
Кстати, в моем типичном ангулярном приложении большинство сервисов — это самые что ни на есть POJO (и при этом да, там есть провайдеры и фабрики).
Кстати, именно по той причине, что есть некие сложности в работе с ключевым словом new, я всем всегда рекомендую не использовать Module.service() вообще, а ограничиться во всех случаях одним Module.factory() для простых сервисов и Module.provider() для конфигурируемых. Так жизнь будет сильно роще.
В ангуляре 2.0 сервисы вообще станут обычными классами ES6 с аннотациями, и проблема исчезнет вовсе.
Ну а в целом да, у ангуляра довольно крутая learning curve, и это скорее достоинство, чем недостаток, потому что позволяет быстро и точно отсеять тот табун js monkey coders, про которых сам же автор и упомянул в начале.
Разумеется. Так же, как например браузер под капотом выполняет императивные инструкции по рендерингу страницы, что не лишает нас удобной возможности определять ее внешний вид в декларативном HTML, оставляя его парсинг заботам браузера.