Пользователь
0,1
рейтинг
31 мая 2013 в 11:22

Разработка → Популярность Javascript-фреймворков перевод

Интерес к Javascript MV* фреймворкам вызвал их подъем. Meteor, Ember, Angular, and Backbone, все они действительно популярны на Github. Измерить популярность довольно сложно, но хорошим показателем может быть количество Github-фоловеров. Используя данные из Github-архива, можно продемострировать это визуально (с помощью запроса на BigQuery и некоторых других скриптов).

image

Если интересно, расскажу о нескольких точках перегиба:



Хотя эта диаграмма и является хорошим показателем для измерения популярности, но по ней нельзя точно судить об использовании фреймворков в реальных приложениях. В имеющихся данные из Github-архива недостает данных старше марта 2012 года. Данные по некоторым кратким промежуткам отсутствуют (либо из-за ошибок Github'а, либо из пропустил Github-архив).

Какой путь выбрать?

2013 будет волнующим годом для разработчиков веб-приложений!
Какой фреймворк больше всего вам нравится

Проголосовало 1113 человек. Воздержалось 866 человек.

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

Перевод: Trevor Orsztynowicz
Олег Истомин @tamtakoe
карма
60,0
рейтинг 0,1
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.