Comments 64
Обеими руками голосую за Backbone!
+4
Мне он всегда нравился. Прост как три копейки и исходники очень чистые. Однако начал смотреть обучалки по ангуляру и кажется меня тянет на тёмную сторону…
+3
Меня тоже ангуляр перетянул на свою сторону.
Исклютельно из-за удобной привязки моделей к шаблонам. В бекбоне такого нет, и с вьюшками всегда приходилось чтото придумывать
Исклютельно из-за удобной привязки моделей к шаблонам. В бекбоне такого нет, и с вьюшками всегда приходилось чтото придумывать
+2
Если вы про байндинг моделей на вьюшки, то мы решили этот вопрос использованием плагина model-binder (кстати существует несколько версий), который сейчас уже переписали под себя и в тоге получилось много плюшек. Так что если я правильно вас понял, то проблема решаем и вполне просто
0
Knockout еще посмотрите.
Мне как-то больше понравился.
Мне как-то больше понравился.
0
За Ember.js, т.к мало пишешь шаблонного кода. Плюс ко всему есть ember-data и новые роутинги которые они анонсировали в январе
0
А я! А я за ангулар! :-)
+16
А я за Spine!… Нет, все-таки за Angular)) Если продолжить линии, то в октябре, он сравняется с Backbone
+1
Один Backbone редко используют, есть Marionette, Chaplin, Thorax. Возможно стоит добавить к Backbone их статистику…
+1
Добавил голосование
0
Предлагаю добавить пункт Другой (отпишусь в комментариях).
0
Да, можно было, но поздно. Можно воздержаться и написать в комментах про свой
0
Эм, у меня вопрос: почему не указали Ext.JS это ведь MVC, если не ошибаюсь? То есть не ошибаюсь. :)
0
Предлагаю добавить голосование)
+1
Backbone всё-таки не фреймворк, а библиотека-основа и как уже отметили выше, используется с разными модулями на выбор разработчика. Meteor слишком специфичная штука, завязанная на своей экосистеме, «вещь в себе».
Angular корректнее сравнивать с Knockout (ключевое отличие).
В последнее время всё чаще и чаще вижу как коллеги-фронтендеры переходят с backbone на angular (я в том числе).
Лично моё мнение, angular среди фреймворков, на данный момент, самый продвинутый (как в смысле фич, гугловской команды, так и продвижения в коммьюнити).
Картинка в тему:
Angular корректнее сравнивать с Knockout (ключевое отличие).
В последнее время всё чаще и чаще вижу как коллеги-фронтендеры переходят с backbone на angular (я в том числе).
Лично моё мнение, angular среди фреймворков, на данный момент, самый продвинутый (как в смысле фич, гугловской команды, так и продвижения в коммьюнити).
Картинка в тему:
+9
Ну хорошо. Правду ли говорят, что по официальным докам AngularJS невозможно выучить далее определённого момента, потому что они неприемлемо сложны — так что поневоле приходится пользоваться альтернативными источниками свéдений?
0
На оф. сайте есть туториал, но, имхо, лучше бы они туда сразу вставили ссылку на egghead.io.
Второе, что лучше изучить, это Angular UI и их отличный роутер.
Третье — ngmodules.org.
Второе, что лучше изучить, это Angular UI и их отличный роутер.
Третье — ngmodules.org.
+8
Да, на Angular UI есть хорошие примеры, как интерфейсных решений, так и интеграции jQuery плагинов и прочее. И код простой. Стоит посмотреть
+1
Ооо, не знал про этот роутер. Спасибо, почитаю )
0
Да это же просто волшебный роутер, и как я мог не заметить его раньше. Спасибо :)
0
Заинтриговали! В чем волшебство (кроме того, что можно инклудить в разные части страницы)? Пока не углублялся в тему роутинга, интересно :-)
0
Мне как раз и не хватало множественного инклуда.
При этом есть наследование роутов (с переопределением, конечно). И довольно «умное» — можно переписать родительские компоненты.
В общем просто полезный модуль, прочтите их вики :)
При этом есть наследование роутов (с переопределением, конечно). И довольно «умное» — можно переписать родительские компоненты.
В общем просто полезный модуль, прочтите их вики :)
+1
Читал жалобы в списке рассылки на то, что на странице может быть только один ng-view. Разработчики обещали подумать и, возможно, изменить это в будущих версиях. А пока рекомендовали использовать ng-replace. Так же отписывались люди, утверждавшие что уже долгое время пользуются ng-replace и не замечают особой разницы (хотя по началу тоже жаловались). Надо будет самому разобраться, а вики почитаю :-)
0
Всё, повалили на лопатки, пошел в вики :-)
0
Даже больше того. Несколько ng-view которые наследуются, переопределяются и работают независимо :)
0
Посидел в вики. Прикольно. Только гложут сомнения, правильно ли это? Логика одного ng-view в Ангуляре ясна. Вид может быть только один, потому что у нас только одна адресная строка. Если же видов много, то их комбинации нужно как-то шифровать в адресе и получится не пойми что. Что думаете по этому поводу?
0
А Вам правда хватает одного ng-view? Мне не хватает.
К тому же, никто не заставляет Вас менять шаблоны каждый раз.
Можно поделить приложение на сайдбар и основную часть, при этом сайдбар будет меняться очень редко. Ну и т.д.
И, по моему, не обязательно «шифровать в адресе» все представления.
К тому же, никто не заставляет Вас менять шаблоны каждый раз.
Можно поделить приложение на сайдбар и основную часть, при этом сайдбар будет меняться очень редко. Ну и т.д.
И, по моему, не обязательно «шифровать в адресе» все представления.
+1
Разработчики обещали на этой недели сделать ui-show, для перехода в состояние без изменения URL (сейчас такое сложно сделать), вот тогда действительно шифровать будет не обязательно и концепция состояний станет законченной. Кстати, перевел вики, пока изучал angular.ru/ui/
0
Его относительно недавно зарелизи, до этого было достаточно объёмное обсуждение каким должен быть идеальный роутер :)
По мне, концепт стейтов, который сделали — отличная идея.
По мне, концепт стейтов, который сделали — отличная идея.
0
Не сказал бы, что официальные доки слишком сложны. Скорее, в них не хватает примеров использования для специфических методов. Часто случаются затыки, когда пытаюсь какую-нибудь штуковину реализовать типа древовидного, сортируемого (с помощью jQuery sortable) меню с возможностью редактирования каждого пункта и синхронизацией всего этого, используя высокоуровневую реализацию CRUD (ngResource). Думаю, и в других фреймворках такое с первого подхода не сделать. До всего этого можно и так додуматься, но иногда проще спросить в списке рассылки, т.к. многое уже придумано.
Некоторые примеры публикую здесь: angular.ru/cookbook/, тут тоже кое-что есть: javascript.ru/forum/angular/38293-igra-v-demki-piar-angulyara-i-obuchenie-3.html#post253683
Некоторые примеры публикую здесь: angular.ru/cookbook/, тут тоже кое-что есть: javascript.ru/forum/angular/38293-igra-v-demki-piar-angulyara-i-obuchenie-3.html#post253683
0
UFO just landed and posted this here
Вот за этот подход его и любят :-) Смысл директив в том, чтобы кратко рассказать как элемент будет выглядеть и вести себя.
Можно просто по именам называть. В Метеоре каждый элемент еще и в шаблон вынесен — ужас для дизайнера
Раньше тоже так делал. Проблема заключалась в том, что приходилось придумывать специальные нотации для написания имен, чтобы было ясно, что это меню и ведет себя так, а это переключатель, а это календарь и называть как-то так: super_toogle или my_menu_tree. Директивы как раз избавляют от таких заморочек.
<ul>
<li ng-repeat="item in menu">{{item.name}}</li>
</ul>
Можно просто по именам называть. В Метеоре каждый элемент еще и в шаблон вынесен — ужас для дизайнера
<ul name="my_menu">
{{#each menu}}
<li name="my_menu_item">{{name}}</li>
{{/each}}
</ul>
Раньше тоже так делал. Проблема заключалась в том, что приходилось придумывать специальные нотации для написания имен, чтобы было ясно, что это меню и ведет себя так, а это переключатель, а это календарь и называть как-то так: super_toogle или my_menu_tree. Директивы как раз избавляют от таких заморочек.
+2
Для не сложный вещей — Knockout. Низкий порог вхождения, хорошая скорость написания кода, не плохая производительность.
+1
Ни на что не променяю любимую Vanilla js.
+7
Сейчас смотрю на Ember и Angular. Может кто подскажет как развивается Angular и на сколько сильно влияние Гугла? Все ли core разработчики от Гугла? Спрашиваю, так как в свете постоянных закрытий сервисов от Гугла немножко страшно вкручивать его в продукт.
-1
Может быть, стоит добавить в опрос «не пользуюсь фреймворками»?
+2
Просьба, всем проголосовавшим за Ember.js, отписаться мне в личку. Есть вакансия (штат|удаленка).
-4
Не понимаю минусов. Я написал в статье с нужной тематикой, т.к ember.js разработчики не могут найти себе работу на этом фреймворке, а мы не можем найти разработчиков на этом фреймворке. Т.к все идут за тенденцией рынка и пишут на Angular|Backbone и нанимают все Angular|Backbone, а мы выбрали функциональный решающий наши проблемы фреймворк.
0
Почему не чекбоксами? Мне очень нравится ангуляр, но я понимаю, что некоторые проекты лучше делать на метеоре.
+2
В случае одностраничных приложений использую angular. А когда роутинг и основная шаблонизация происходит на сервере (например в случае дописывания проектов) — knockout.
0
не кодирую, занимаюсь дизайном, на базе Ангуляра собираю команды кодеров и практикую Lean UX подход для прототипирования/проектирования/разработки — выступал с этой темой на Нью-Йорковском митапе ангулярщиков, если кому интересна тема — ссылка на видео доклада — siarheimardovich.com/core-approach-2 (снимается группой гуглеров, на этом же канале много других ангуляровских видео)
при выборе для проекта, я чаще обращаю внимание, кто пользуется фреймворком (численность и разнообразие представителей субкультуры), точно знаю, что помимо самого Гугла он прочно засел в Блумберге, Амазоне, HBO, McKinsey
при выборе для проекта, я чаще обращаю внимание, кто пользуется фреймворком (численность и разнообразие представителей субкультуры), точно знаю, что помимо самого Гугла он прочно засел в Блумберге, Амазоне, HBO, McKinsey
0
Всё просто — производить как можно более существенные вещи с т.з. UX (чаще всего прототип) — как можно скорее/дешевле, а также раскопаться из кучи производимых дизайнерами артефактов (get out of deliverables business).
Каждый проект — стартАп. Вам надо понять, что то, что вы делаете — кому-то (заказчику, начальнику, конечному пользователю, рынку) нужно. И если вы ошибаетесь, то надо начать ошибаться рано, ошибаться часто (a-la Fail often, fail faster by S. Jobs) и удешевить цену ошибки, начать быстро учиться на них; такими итерациями и выходим на путь к чему-то стоящему.
Я встречаюсь с заказчиками, провожу свою работу с конечными пользователями, создаю low fidelity инпут для команды. Собираю команду вместе и обеспечиваю её итеративную деятельность. Для этого я (дизайнер) вместе с манагером и аналитиком подбираем рабочую группу с разнообразными скилами — 2-3 Front-End кодера, 1 QA, 1 Back-End специалист, 1 спец по нагрузочному тестирования, 1 по БД и т.д. Все без исключения участвуют в создании скетчей (быстрых и дешёвых) будущего продукта, я со своей стороны гарантирую, что в итоге получится инпут (как минимум) для кодеров, и они (с учётом разницы во времени между офисами) за кратчайшее время выдадут прототип, пригодный для демонстрации и тесторования. На этот minimum viable product получаю быстрый фидбек, замыкаю систему обратной связи и двигаюсь к цели.
Т.е. кастомер/пользователи сталкиваются с прототипом с первых дней, и в этом большая помощь Ангуляра.
Есть готовая книга по этой теме — Lean UX (Jeff Gothelf, Josh Seiden), это переложение идей Райса для многострадального UX.
Также на конференции Lean UX NYC познакомился с очень интересным товарищем www.eewei.com/, рекомендую его книгу и презентации на SlideShare (погуглите Eewei).
Каждый проект — стартАп. Вам надо понять, что то, что вы делаете — кому-то (заказчику, начальнику, конечному пользователю, рынку) нужно. И если вы ошибаетесь, то надо начать ошибаться рано, ошибаться часто (a-la Fail often, fail faster by S. Jobs) и удешевить цену ошибки, начать быстро учиться на них; такими итерациями и выходим на путь к чему-то стоящему.
Я встречаюсь с заказчиками, провожу свою работу с конечными пользователями, создаю low fidelity инпут для команды. Собираю команду вместе и обеспечиваю её итеративную деятельность. Для этого я (дизайнер) вместе с манагером и аналитиком подбираем рабочую группу с разнообразными скилами — 2-3 Front-End кодера, 1 QA, 1 Back-End специалист, 1 спец по нагрузочному тестирования, 1 по БД и т.д. Все без исключения участвуют в создании скетчей (быстрых и дешёвых) будущего продукта, я со своей стороны гарантирую, что в итоге получится инпут (как минимум) для кодеров, и они (с учётом разницы во времени между офисами) за кратчайшее время выдадут прототип, пригодный для демонстрации и тесторования. На этот minimum viable product получаю быстрый фидбек, замыкаю систему обратной связи и двигаюсь к цели.
Т.е. кастомер/пользователи сталкиваются с прототипом с первых дней, и в этом большая помощь Ангуляра.
Есть готовая книга по этой теме — Lean UX (Jeff Gothelf, Josh Seiden), это переложение идей Райса для многострадального UX.
Также на конференции Lean UX NYC познакомился с очень интересным товарищем www.eewei.com/, рекомендую его книгу и презентации на SlideShare (погуглите Eewei).
+1
Вау! Теперь знаю, как называется подход, которого всегда стараюсь придерживаться… Наверное, потому что сам пришел из дизайна :-) Правда, к обычным сайтам и заказчикам среднего уровня, со своими фирмами он с трудом подходит. Они мыслят в категории: заплатили деньги — получили готовый сайт под ключ через установленное время. Инвесторы — другое дело.
2-3 Front-End кодера, 1 QA, 1 Back-End специалист, 1 спец по нагрузочному тестирования, 1 по БД не многовато для стартапа? Считается, оптимальный состав команды на начальном этапе 2 человека. Максимум 3. Т.е. вы дизайнер, универсальный программист + узкий специалист, если реализуется какая-то сложная фича.
Жалко, все материалы на английском. Усваиваю его в 4 раза медленнее.
2-3 Front-End кодера, 1 QA, 1 Back-End специалист, 1 спец по нагрузочному тестирования, 1 по БД не многовато для стартапа? Считается, оптимальный состав команды на начальном этапе 2 человека. Максимум 3. Т.е. вы дизайнер, универсальный программист + узкий специалист, если реализуется какая-то сложная фича.
Жалко, все материалы на английском. Усваиваю его в 4 раза медленнее.
0
Важно, чтобы участники команды выкладывали на стол свои козыри/опасения вовремя. Можно ограничиться дизайнером и парой кодеров. Например — статическим JSON имитируем бэк-энд, потом, когда вершины UX (look and feel, interactions, etc.) будут взяты — можно подтянуть остальную команду, ей останется взять статический JSON и на его примере собрать RESTful решение. Lean UX довольно молодой топик, я думаю, что скоро потечёт инфа.
+1
Несколько странно сравнивать Meteor, который является node.js фреймворком, с js фреймворками. Meteor можно использовать с любым из них, а внутри самого Meteor уже используется backbone
+1
Мопед не мой, все претензии к автору статьи :-) А, вообще, спасибо за комментарий, не знал, что там backbone. Тогда получается, что всю его клиентскую часть на Angular можно заменить. Надо будет копнуть глубже.
-1
Да, без проблем (сам правда не проверял). Насчёт backbone я понял, что не так выразился. Имел ввиду, что он входит в стандартный комплект пакетов.
+1
У кого-нибудь есть опыт создания сложнейших корпоративных приложений (минимум 50 разных views, несколько графиков, миниум два десятка stores и всё в связях one-to-many, many-to-many, генерация отчётов, и т.п.) на Angular JS это возможно — как оно? Как по сравнению, например с ExtJS?
+2
Попробуйте посмотреть проекты, сделанные на Ангуляре: github.com/angular/angular.js/wiki/Projects-using-AngularJS, может быть там будет что-то близкое к тому, что вы хотите. А дальше уже у разработчиков спросить.
0
Спасибо за ссылку, но к сожалению не нашёл подходящего крупного проекта. Все проекты решают одну какую-нибудь задачу, которую в принципе можно было бы и решить, используя тот же jQuery.
0
Перевел статью на подобную тему: habrahabr.ru/post/182556/. Судя по всему, проблемы с производительностью решаются достаточно легко
0
Sign up to leave a comment.
Популярность Javascript-фреймворков