Как стать автором
Обновить

Комментарии 64

Обеими руками голосую за Backbone!
Мне он всегда нравился. Прост как три копейки и исходники очень чистые. Однако начал смотреть обучалки по ангуляру и кажется меня тянет на тёмную сторону…
Меня тоже ангуляр перетянул на свою сторону.
Исклютельно из-за удобной привязки моделей к шаблонам. В бекбоне такого нет, и с вьюшками всегда приходилось чтото придумывать
Если вы про байндинг моделей на вьюшки, то мы решили этот вопрос использованием плагина model-binder (кстати существует несколько версий), который сейчас уже переписали под себя и в тоге получилось много плюшек. Так что если я правильно вас понял, то проблема решаем и вполне просто
Все же ангуляр мне больше нравится. Сам подход к написанию приожений на нем.
А может быть мои задачи как раз под него подходят :)
Knockout еще посмотрите.
Мне как-то больше понравился.
За Ember.js, т.к мало пишешь шаблонного кода. Плюс ко всему есть ember-data и новые роутинги которые они анонсировали в январе
Один Backbone редко используют, есть Marionette, Chaplin, Thorax. Возможно стоит добавить к Backbone их статистику…
Добавил голосование
Предлагаю добавить пункт Другой (отпишусь в комментариях).
Да, можно было, но поздно. Можно воздержаться и написать в комментах про свой
Эм, у меня вопрос: почему не указали Ext.JS это ведь MVC, если не ошибаюсь? То есть не ошибаюсь. :)
Изначально собирался сделать голосование лишь по тем фреймворкам, которые есть на графике (на самом деле, голосования, вообще, не собирался делать. Просто попросили и добавил потом). В последний момент вспомнил, что есть Нокаут. В следующий раз подготовлюсь лучше :-)
Предлагаю добавить голосование)
Добавил
Backbone всё-таки не фреймворк, а библиотека-основа и как уже отметили выше, используется с разными модулями на выбор разработчика. Meteor слишком специфичная штука, завязанная на своей экосистеме, «вещь в себе».

Angular корректнее сравнивать с Knockout (ключевое отличие).

В последнее время всё чаще и чаще вижу как коллеги-фронтендеры переходят с backbone на angular (я в том числе).

Лично моё мнение, angular среди фреймворков, на данный момент, самый продвинутый (как в смысле фич, гугловской команды, так и продвижения в коммьюнити).

Картинка в тему:
Ну хорошо. Правду ли говорят, что по официальным докам AngularJS невозможно выучить далее определённого момента, потому что они неприемлемо сложны — так что поневоле приходится пользоваться альтернативными источниками свéдений?
На оф. сайте есть туториал, но, имхо, лучше бы они туда сразу вставили ссылку на egghead.io.

Второе, что лучше изучить, это Angular UI и их отличный роутер.

Третье — ngmodules.org.
Да, на Angular UI есть хорошие примеры, как интерфейсных решений, так и интеграции jQuery плагинов и прочее. И код простой. Стоит посмотреть
Ооо, не знал про этот роутер. Спасибо, почитаю )
Да это же просто волшебный роутер, и как я мог не заметить его раньше. Спасибо :)
Заинтриговали! В чем волшебство (кроме того, что можно инклудить в разные части страницы)? Пока не углублялся в тему роутинга, интересно :-)
Мне как раз и не хватало множественного инклуда.

При этом есть наследование роутов (с переопределением, конечно). И довольно «умное» — можно переписать родительские компоненты.
В общем просто полезный модуль, прочтите их вики :)
Читал жалобы в списке рассылки на то, что на странице может быть только один ng-view. Разработчики обещали подумать и, возможно, изменить это в будущих версиях. А пока рекомендовали использовать ng-replace. Так же отписывались люди, утверждавшие что уже долгое время пользуются ng-replace и не замечают особой разницы (хотя по началу тоже жаловались). Надо будет самому разобраться, а вики почитаю :-)
В том-то и дело, в ui-router сделали возможность указывать столько ui-view, сколько душе угодно (в отличии от родного роутера и ng-view). Советую пройтись по вики (там чтения на 10 минут).
Всё, повалили на лопатки, пошел в вики :-)
Даже больше того. Несколько ng-view которые наследуются, переопределяются и работают независимо :)
Посидел в вики. Прикольно. Только гложут сомнения, правильно ли это? Логика одного ng-view в Ангуляре ясна. Вид может быть только один, потому что у нас только одна адресная строка. Если же видов много, то их комбинации нужно как-то шифровать в адресе и получится не пойми что. Что думаете по этому поводу?
А Вам правда хватает одного ng-view? Мне не хватает.
К тому же, никто не заставляет Вас менять шаблоны каждый раз.
Можно поделить приложение на сайдбар и основную часть, при этом сайдбар будет меняться очень редко. Ну и т.д.

И, по моему, не обязательно «шифровать в адресе» все представления.
Разработчики обещали на этой недели сделать ui-show, для перехода в состояние без изменения URL (сейчас такое сложно сделать), вот тогда действительно шифровать будет не обязательно и концепция состояний станет законченной. Кстати, перевел вики, пока изучал angular.ru/ui/
Его относительно недавно зарелизи, до этого было достаточно объёмное обсуждение каким должен быть идеальный роутер :)
По мне, концепт стейтов, который сделали — отличная идея.
Да, мне тоже понравилось. Отличная реализация
Можете поделиться ссылочкой на обсуждение? У меня так сомнения по поводу необходимости нескольких видов (описал их выше в соседней ветке)
Не сказал бы, что официальные доки слишком сложны. Скорее, в них не хватает примеров использования для специфических методов. Часто случаются затыки, когда пытаюсь какую-нибудь штуковину реализовать типа древовидного, сортируемого (с помощью jQuery sortable) меню с возможностью редактирования каждого пункта и синхронизацией всего этого, используя высокоуровневую реализацию CRUD (ngResource). Думаю, и в других фреймворках такое с первого подхода не сделать. До всего этого можно и так додуматься, но иногда проще спросить в списке рассылки, т.к. многое уже придумано.

Некоторые примеры публикую здесь: angular.ru/cookbook/, тут тоже кое-что есть: javascript.ru/forum/angular/38293-igra-v-demki-piar-angulyara-i-obuchenie-3.html#post253683
НЛО прилетело и опубликовало эту надпись здесь
Вот за этот подход его и любят :-) Смысл директив в том, чтобы кратко рассказать как элемент будет выглядеть и вести себя.

<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. Директивы как раз избавляют от таких заморочек.
Для не сложный вещей — Knockout. Низкий порог вхождения, хорошая скорость написания кода, не плохая производительность.
Ни на что не променяю любимую Vanilla js.
Сейчас смотрю на Ember и Angular. Может кто подскажет как развивается Angular и на сколько сильно влияние Гугла? Все ли core разработчики от Гугла? Спрашиваю, так как в свете постоянных закрытий сервисов от Гугла немножко страшно вкручивать его в продукт.
Это не совсем сервис, скорее отдельный проект. Могут просто от него отказаться и отправить в свободное плавание (откуда он, кстати, начинал). Не думаю, что пойдут на это, особенно, если завоюет популярность. А так проект развивается, постоянно правится репозиторий, неделю назад новый релиз вышел.
Может быть, стоит добавить в опрос «не пользуюсь фреймворками»?
Уже поздно. Будем считать, что воздержавшиеся не пользуются :-)
Просьба, всем проголосовавшим за Ember.js, отписаться мне в личку. Есть вакансия (штат|удаленка).
Не понимаю минусов. Я написал в статье с нужной тематикой, т.к ember.js разработчики не могут найти себе работу на этом фреймворке, а мы не можем найти разработчиков на этом фреймворке. Т.к все идут за тенденцией рынка и пишут на Angular|Backbone и нанимают все Angular|Backbone, а мы выбрали функциональный решающий наши проблемы фреймворк.
Почему не чекбоксами? Мне очень нравится ангуляр, но я понимаю, что некоторые проекты лучше делать на метеоре.
Больше шума вносят. Кто-то может всем галочек понаставить т.к. бесспорно в каждом фреймворке есть своя фишка, а кто-то лишь одному за совокупность параметров. Получается неравноценное распределение голосов по людям.
В случае одностраничных приложений использую angular. А когда роутинг и основная шаблонизация происходит на сервере (например в случае дописывания проектов) — knockout.
не кодирую, занимаюсь дизайном, на базе Ангуляра собираю команды кодеров и практикую Lean UX подход для прототипирования/проектирования/разработки — выступал с этой темой на Нью-Йорковском митапе ангулярщиков, если кому интересна тема — ссылка на видео доклада — siarheimardovich.com/core-approach-2 (снимается группой гуглеров, на этом же канале много других ангуляровских видео)

при выборе для проекта, я чаще обращаю внимание, кто пользуется фреймворком (численность и разнообразие представителей субкультуры), точно знаю, что помимо самого Гугла он прочно засел в Блумберге, Амазоне, HBO, McKinsey
Можно пару слов про Lean UX подход. Там все на английском, да еще и видео :-)
Всё просто — производить как можно более существенные вещи с т.з. 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).
Вау! Теперь знаю, как называется подход, которого всегда стараюсь придерживаться… Наверное, потому что сам пришел из дизайна :-) Правда, к обычным сайтам и заказчикам среднего уровня, со своими фирмами он с трудом подходит. Они мыслят в категории: заплатили деньги — получили готовый сайт под ключ через установленное время. Инвесторы — другое дело.

2-3 Front-End кодера, 1 QA, 1 Back-End специалист, 1 спец по нагрузочному тестирования, 1 по БД не многовато для стартапа? Считается, оптимальный состав команды на начальном этапе 2 человека. Максимум 3. Т.е. вы дизайнер, универсальный программист + узкий специалист, если реализуется какая-то сложная фича.

Жалко, все материалы на английском. Усваиваю его в 4 раза медленнее.
Важно, чтобы участники команды выкладывали на стол свои козыри/опасения вовремя. Можно ограничиться дизайнером и парой кодеров. Например — статическим JSON имитируем бэк-энд, потом, когда вершины UX (look and feel, interactions, etc.) будут взяты — можно подтянуть остальную команду, ей останется взять статический JSON и на его примере собрать RESTful решение. Lean UX довольно молодой топик, я думаю, что скоро потечёт инфа.
Несколько странно сравнивать Meteor, который является node.js фреймворком, с js фреймворками. Meteor можно использовать с любым из них, а внутри самого Meteor уже используется backbone
Мопед не мой, все претензии к автору статьи :-) А, вообще, спасибо за комментарий, не знал, что там backbone. Тогда получается, что всю его клиентскую часть на Angular можно заменить. Надо будет копнуть глубже.
Да, без проблем (сам правда не проверял). Насчёт backbone я понял, что не так выразился. Имел ввиду, что он входит в стандартный комплект пакетов.
У кого-нибудь есть опыт создания сложнейших корпоративных приложений (минимум 50 разных views, несколько графиков, миниум два десятка stores и всё в связях one-to-many, many-to-many, генерация отчётов, и т.п.) на Angular JS это возможно — как оно? Как по сравнению, например с ExtJS?
Попробуйте посмотреть проекты, сделанные на Ангуляре: github.com/angular/angular.js/wiki/Projects-using-AngularJS, может быть там будет что-то близкое к тому, что вы хотите. А дальше уже у разработчиков спросить.
Спасибо за ссылку, но к сожалению не нашёл подходящего крупного проекта. Все проекты решают одну какую-нибудь задачу, которую в принципе можно было бы и решить, используя тот же jQuery.
Перевел статью на подобную тему: habrahabr.ru/post/182556/. Судя по всему, проблемы с производительностью решаются достаточно легко
Большое спасибо за перевод.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории