Популярность Javascript-фреймворков

[weatherman]

Обеими руками голосую за Backbone!

[MrSLonoed]

Мне он всегда нравился. Прост как три копейки и исходники очень чистые. Однако начал смотреть обучалки по ангуляру и кажется меня тянет на тёмную сторону…

[Akuma]

Меня тоже ангуляр перетянул на свою сторону.
Исклютельно из-за удобной привязки моделей к шаблонам. В бекбоне такого нет, и с вьюшками всегда приходилось чтото придумывать

[Seldon]

Если вы про байндинг моделей на вьюшки, то мы решили этот вопрос использованием плагина model-binder (кстати существует несколько версий), который сейчас уже переписали под себя и в тоге получилось много плюшек. Так что если я правильно вас понял, то проблема решаем и вполне просто

[Akuma]

Все же ангуляр мне больше нравится. Сам подход к написанию приожений на нем.
А может быть мои задачи как раз под него подходят :)

[metamorph]

Knockout еще посмотрите.
Мне как-то больше понравился.

[inook]

За Ember.js, т.к мало пишешь шаблонного кода. Плюс ко всему есть ember-data и новые роутинги которые они анонсировали в январе

[KeepYourMind]

А я! А я за ангулар! :-)

[tamtakoe]

А я за Spine!… Нет, все-таки за Angular)) Если продолжить линии, то в октябре, он сравняется с Backbone

[sdevalex]

Один Backbone редко используют, есть Marionette, Chaplin, Thorax. Возможно стоит добавить к Backbone их статистику…

[tamtakoe]

Добавил голосование

[jMas]

Предлагаю добавить пункт Другой (отпишусь в комментариях).

[tamtakoe]

Да, можно было, но поздно. Можно воздержаться и написать в комментах про свой

[jMas]

Эм, у меня вопрос: почему не указали Ext.JS это ведь MVC, если не ошибаюсь? То есть не ошибаюсь. :)

[tamtakoe]

Изначально собирался сделать голосование лишь по тем фреймворкам, которые есть на графике (на самом деле, голосования, вообще, не собирался делать. Просто попросили и добавил потом). В последний момент вспомнил, что есть Нокаут. В следующий раз подготовлюсь лучше :-)

[toptalo]

Предлагаю добавить голосование)

[tamtakoe]

Добавил

[demark]

Backbone всё-таки не фреймворк, а библиотека-основа и как уже отметили выше, используется с разными модулями на выбор разработчика. Meteor слишком специфичная штука, завязанная на своей экосистеме, «вещь в себе».

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

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

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

Картинка в тему:

[Mithgol]

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

[demark]

На оф. сайте есть туториал, но, имхо, лучше бы они туда сразу вставили ссылку на egghead.io.

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

Третье — ngmodules.org.

[tamtakoe]

Да, на Angular UI есть хорошие примеры, как интерфейсных решений, так и интеграции jQuery плагинов и прочее. И код простой. Стоит посмотреть

[Akuma]

Ооо, не знал про этот роутер. Спасибо, почитаю )

[Akuma]

Да это же просто волшебный роутер, и как я мог не заметить его раньше. Спасибо :)

[tamtakoe]

Заинтриговали! В чем волшебство (кроме того, что можно инклудить в разные части страницы)? Пока не углублялся в тему роутинга, интересно :-)

[Akuma]

Мне как раз и не хватало множественного инклуда.

При этом есть наследование роутов (с переопределением, конечно). И довольно «умное» — можно переписать родительские компоненты.
В общем просто полезный модуль, прочтите их вики :)

[tamtakoe]

Читал жалобы в списке рассылки на то, что на странице может быть только один ng-view. Разработчики обещали подумать и, возможно, изменить это в будущих версиях. А пока рекомендовали использовать ng-replace. Так же отписывались люди, утверждавшие что уже долгое время пользуются ng-replace и не замечают особой разницы (хотя по началу тоже жаловались). Надо будет самому разобраться, а вики почитаю :-)

[demark]

В том-то и дело, в ui-router сделали возможность указывать столько ui-view, сколько душе угодно (в отличии от родного роутера и ng-view). Советую пройтись по вики (там чтения на 10 минут).

[tamtakoe]

Всё, повалили на лопатки, пошел в вики :-)

[Akuma]

Даже больше того. Несколько ng-view которые наследуются, переопределяются и работают независимо :)

[tamtakoe]

Посидел в вики. Прикольно. Только гложут сомнения, правильно ли это? Логика одного ng-view в Ангуляре ясна. Вид может быть только один, потому что у нас только одна адресная строка. Если же видов много, то их комбинации нужно как-то шифровать в адресе и получится не пойми что. Что думаете по этому поводу?

[Akuma]

А Вам правда хватает одного ng-view? Мне не хватает.
К тому же, никто не заставляет Вас менять шаблоны каждый раз.
Можно поделить приложение на сайдбар и основную часть, при этом сайдбар будет меняться очень редко. Ну и т.д.

И, по моему, не обязательно «шифровать в адресе» все представления.

[tamtakoe]

Разработчики обещали на этой недели сделать ui-show, для перехода в состояние без изменения URL (сейчас такое сложно сделать), вот тогда действительно шифровать будет не обязательно и концепция состояний станет законченной. Кстати, перевел вики, пока изучал angular.ru/ui/

[demark]

Его относительно недавно зарелизи, до этого было достаточно объёмное обсуждение каким должен быть идеальный роутер :)
По мне, концепт стейтов, который сделали — отличная идея.

[Akuma]

Да, мне тоже понравилось. Отличная реализация

[tamtakoe]

Можете поделиться ссылочкой на обсуждение? У меня так сомнения по поводу необходимости нескольких видов (описал их выше в соседней ветке)

[demark]

github.com/angular-ui/ui-router/issues/1
Wiki: Votes-on-Router-Specs-(old)

[tamtakoe]

Не сказал бы, что официальные доки слишком сложны. Скорее, в них не хватает примеров использования для специфических методов. Часто случаются затыки, когда пытаюсь какую-нибудь штуковину реализовать типа древовидного, сортируемого (с помощью jQuery sortable) меню с возможностью редактирования каждого пункта и синхронизацией всего этого, используя высокоуровневую реализацию CRUD (ngResource). Думаю, и в других фреймворках такое с первого подхода не сделать. До всего этого можно и так додуматься, но иногда проще спросить в списке рассылки, т.к. многое уже придумано.

Некоторые примеры публикую здесь: angular.ru/cookbook/, тут тоже кое-что есть: javascript.ru/forum/angular/38293-igra-v-demki-piar-angulyara-i-obuchenie-3.html#post253683

[tamtakoe]

Вот за этот подход его и любят :-) Смысл директив в том, чтобы кратко рассказать как элемент будет выглядеть и вести себя.

<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. Директивы как раз избавляют от таких заморочек.

[Romanych]

Для не сложный вещей — Knockout. Низкий порог вхождения, хорошая скорость написания кода, не плохая производительность.

[kidar2]

Ни на что не променяю любимую Vanilla js.

[Razaz]

Сейчас смотрю на Ember и Angular. Может кто подскажет как развивается Angular и на сколько сильно влияние Гугла? Все ли core разработчики от Гугла? Спрашиваю, так как в свете постоянных закрытий сервисов от Гугла немножко страшно вкручивать его в продукт.

[tamtakoe]

Это не совсем сервис, скорее отдельный проект. Могут просто от него отказаться и отправить в свободное плавание (откуда он, кстати, начинал). Не думаю, что пойдут на это, особенно, если завоюет популярность. А так проект развивается, постоянно правится репозиторий, неделю назад новый релиз вышел.

[Triang3l]

Может быть, стоит добавить в опрос «не пользуюсь фреймворками»?

[tamtakoe]

Уже поздно. Будем считать, что воздержавшиеся не пользуются :-)

[inook]

Просьба, всем проголосовавшим за Ember.js, отписаться мне в личку. Есть вакансия (штат|удаленка).

[inook]

Не понимаю минусов. Я написал в статье с нужной тематикой, т.к ember.js разработчики не могут найти себе работу на этом фреймворке, а мы не можем найти разработчиков на этом фреймворке. Т.к все идут за тенденцией рынка и пишут на Angular|Backbone и нанимают все Angular|Backbone, а мы выбрали функциональный решающий наши проблемы фреймворк.

[Triang3l]

Хабрахабр — для статей.
Для вакансий есть Хантим.

[AmdY]

Почему не чекбоксами? Мне очень нравится ангуляр, но я понимаю, что некоторые проекты лучше делать на метеоре.

[tamtakoe]

Больше шума вносят. Кто-то может всем галочек понаставить т.к. бесспорно в каждом фреймворке есть своя фишка, а кто-то лишь одному за совокупность параметров. Получается неравноценное распределение голосов по людям.

[Imbolc]

В случае одностраничных приложений использую angular. А когда роутинг и основная шаблонизация происходит на сервере (например в случае дописывания проектов) — knockout.

[Siarhei]

не кодирую, занимаюсь дизайном, на базе Ангуляра собираю команды кодеров и практикую Lean UX подход для прототипирования/проектирования/разработки — выступал с этой темой на Нью-Йорковском митапе ангулярщиков, если кому интересна тема — ссылка на видео доклада — siarheimardovich.com/core-approach-2 (снимается группой гуглеров, на этом же канале много других ангуляровских видео)

при выборе для проекта, я чаще обращаю внимание, кто пользуется фреймворком (численность и разнообразие представителей субкультуры), точно знаю, что помимо самого Гугла он прочно засел в Блумберге, Амазоне, HBO, McKinsey

[tamtakoe]

Можно пару слов про Lean UX подход. Там все на английском, да еще и видео :-)

[Siarhei]

Всё просто — производить как можно более существенные вещи с т.з. 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).

[tamtakoe]

Вау! Теперь знаю, как называется подход, которого всегда стараюсь придерживаться… Наверное, потому что сам пришел из дизайна :-) Правда, к обычным сайтам и заказчикам среднего уровня, со своими фирмами он с трудом подходит. Они мыслят в категории: заплатили деньги — получили готовый сайт под ключ через установленное время. Инвесторы — другое дело.

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

Жалко, все материалы на английском. Усваиваю его в 4 раза медленнее.

[Siarhei]

Важно, чтобы участники команды выкладывали на стол свои козыри/опасения вовремя. Можно ограничиться дизайнером и парой кодеров. Например — статическим JSON имитируем бэк-энд, потом, когда вершины UX (look and feel, interactions, etc.) будут взяты — можно подтянуть остальную команду, ей останется взять статический JSON и на его примере собрать RESTful решение. Lean UX довольно молодой топик, я думаю, что скоро потечёт инфа.

[iHun]

Несколько странно сравнивать Meteor, который является node.js фреймворком, с js фреймворками. Meteor можно использовать с любым из них, а внутри самого Meteor уже используется backbone

[tamtakoe]

Мопед не мой, все претензии к автору статьи :-) А, вообще, спасибо за комментарий, не знал, что там backbone. Тогда получается, что всю его клиентскую часть на Angular можно заменить. Надо будет копнуть глубже.

[iHun]

Да, без проблем (сам правда не проверял). Насчёт backbone я понял, что не так выразился. Имел ввиду, что он входит в стандартный комплект пакетов.

[dos]

У кого-нибудь есть опыт создания сложнейших корпоративных приложений (минимум 50 разных views, несколько графиков, миниум два десятка stores и всё в связях one-to-many, many-to-many, генерация отчётов, и т.п.) на Angular JS это возможно — как оно? Как по сравнению, например с ExtJS?

[tamtakoe]

Попробуйте посмотреть проекты, сделанные на Ангуляре: github.com/angular/angular.js/wiki/Projects-using-AngularJS, может быть там будет что-то близкое к тому, что вы хотите. А дальше уже у разработчиков спросить.

[dos]

Спасибо за ссылку, но к сожалению не нашёл подходящего крупного проекта. Все проекты решают одну какую-нибудь задачу, которую в принципе можно было бы и решить, используя тот же jQuery.

[tamtakoe]

Перевел статью на подобную тему: habrahabr.ru/post/182556/. Судя по всему, проблемы с производительностью решаются достаточно легко

[dos]

Большое спасибо за перевод.