зачем нужны фреймворки javascript
Javascript-фреймворки: тенденции 2019 года
Представляем вам перевод статьи Nwose Lotannaс, которая была опубликована на blog.bitsrc.io. В ней подборки лучших фреймворков и информация, полезная как новичкам, так и опытным специалистам.
Очередной отчет от State of JS и наш прогноз на новый год уже здесь!
Давайте охватим взглядом удивительный путь развития, совершенный JavaScript в уходящем году и отраженный во мнениях более чем 20 тысяч веб-разработчиков со всего мира. Мы посмотрим, какие javascript-фреймворки для фронтенд-разработки, работы с данными и бэкенд-разработки были самыми востребованными, а также постараемся увидеть возможные будущие фавориты.
State of JS
В этой статье мы будем опираться на данные и выводы State of JS, а также на инсайты, которыми поделилась компания JetBrains в своем ежегодном отчете «Экосистема разработки» (The State of Developer Ecosystem).
Что такое State of JS?
Ежегодный опрос обо всем, что касается JavaScript. Прекрасно визуализированные ответы участвовавших в нем разработчиков отражают актуальное состояние JavaScript. Опрос охватывает следующие темы: фронтенд-фреймворки, базы данных, инструменты работы с состоянием (state), отношения между фреймворками, выбор фреймворка разработчиками и легкость использования, языки, компилируемые в JavaScript, мобильные фреймворки, системы сборки, инструменты тестирования кода для JavaScript и многое другое.
Почему State of JS?
Это первый опрос, респондентами которого выступают исключительно разработчики, имеющие дело с JavaScript. Он был организован Сашей Грейфом и его помощниками в 2016 году. Сейчас пользуется у целевой аудитории огромным уважением. Есть и другие не менее популярные опросы — от Stack Overflow (более 100 тысяч респондентов) или от JetBrains (свыше 6 тысяч респондентов). Тем не менее, сегодня мы сосредоточимся на опросе от State of JS — еще и потому, что по красоте визуализации ему нет равных.
Часть 1. Фреймворки для фронтенд-разработки
Мы живем в эпоху компонентов, и это касается не только фронтенда. Растет популярность таких инструментов, как Bit, позволяющих без труда делиться компонентами, использовать их повторно и создавать новые приложения быстрее, собирая их вместе и синхронизируя с другими проектами. Будущее определенно за компонентно-ориентированными платформами.
Здесь будут рассмотрены фреймворки для фронтенд-разработки в порядке от наиболее востребованного — благодаря своей доступности, а также получаемому удовольствию и легкости при работе.
React (больше 110 тысяч звезд на GitHub) — это эффективная и гибкая декларативная библиотека JavaScript для сборки UI от команды Facebook. Она позволяет без усилий создавать интерактивный пользовательский интерфейс. React не просто поддерживает сборку объектно-центричных приложений — он ее поощряет. Кроме того, создатели фреймворка со всей серьезностью отнеслись к обратной совместимости, так что в долговечности своего приложения можете быть уверены. По графику выше хорошо видно, что за последние несколько лет уровень осведомленности о React значительно повысился. Вот почему библиотека станет отличной отправной точкой вашего путешествия во фронтенд-разработку.
React-разработчики — одни из самых высокооплачиваемых javascript-разработчиков в 2018 году.
Вы можете создать новое приложение на React, используя предназначенный для этого тулчейн create-react-app, на данный момент самый популярный из существующих. Чтобы начать работать с ним, запустите следующие строки в командной строке папки проекта:
Vue.js, прогрессивный фреймворк для сборки пользовательских интерфейсов, созданный Эваном Ю и еще 234 энтузиастами, набрал больше 121 тысячи звезд на GitHub. Он включает доступную корневую библиотеку, которая в первую очередь решает задачи уровня представления, и экосистему дополнительных библиотек, позволяющую создавать сложные и объемные одностраничные приложения (Single-Page Applications).
Vue.js произносится в точности как слово view («представление») и имеет на 4 тысячи звезд GitHub больше, чем React.
Как видно на графике, Vue удалось перепрыгнуть маркетинговую пропасть: о нем слышал почти каждый разработчик. Можно предположить, что это произошло благодаря огромным усилиям, которые прикладывали Эван и его команда с 2017 года, посещая различные собрания и конференции, а также организуя собственные. Тем не менее, пробел в знаниях разработчиков все еще существует, и чтобы его закрыть, в 2019 году необходимо создать больше учебных материалов по работе с Vue.js. Установите этот фреймворк с помощью npm:
Angular — фреймворк от компании Google, получивший почти 44 тысячи звезд на GitHub. Представляет собой платформу, упрощающую сборку приложений в веб. В Angular сочетаются декларативные шаблоны, внедрение зависимости, двустороннее связывание данных и лучшие практики решения проблем разработки. Эта платформа позволяет собирать приложения для веб, мобильных устройств и настольных ПК. В ней предлагается самый удобный и понятный для начинающих интерфейс командной строки (CLI) и даже консоль (Console) — клиент с графическим интерфейсом.
Глядя на график, можно заметить огромную разницу по сравнению с графиками описанных выше фреймворков. Дело в необъективности данных, возникшей из-за формулировки вопросов, которая исключает AngularJS — независимый от Angular фреймворк. Вот почему эту визуализацию лучше не принимать во внимание. Для установки CLI с помощью npm откройте окно командной строки или консоли и введите следующую команду:
Часть 2. Фреймворки для работы с данными
В этой части мы рассмотрим технологии передачи данных и управления ими.
Redux, набравший 45 тысяч звезд на GitHub, — это предсказуемый контейнер состояния (state) для javascript-приложений. Он помогает писать приложения со стабильным поведением, которые запускаются на клиенте, сервере и в native-среде и легко тестируются. Redux можно использовать вместе с React или любой другой библиотекой для представления.
На графике можно наблюдать те же тенденции повышения осведомленности о бренде, что и в случае с Vue: о Redux слышал почти каждый javascript-разработчик. При этом некоторые из них жалуются на сложность работы с этим фреймворком, поэтому, чтобы сделать его для разработчиков привлекательнее, а концепты — доступнее, требуется больше учебных материалов. Для установки воспользуйтесь следующей командой:
GraphQL от компании Facebook с рейтингом на GitHub более 10 тысяч звезд — это язык для формулировки запросов в API (программном интерфейсе приложения) и среда выполнения этих запросов посредством существующих данных. С его помощью можно предоставить полное и понятное описание данных в API, позволяя клиентам запрашивать только то, что им необходимо, и ничего больше. Благодаря этому со временем становится проще развивать программные интерфейсы приложения и использовать мощные инструменты разработки.
Разумеется, в 2019 году появится рыночная ниша под материалы по работе с GraphQL, ведь множество людей заинтересовано в его изучении. Кроме того, на графике видно, что отсутствие осведомленности о бренде в 2018 удалось почти полностью устранить. Чтобы установить GraphQL, используйте npm:
Платформа Apollo — это реализация GraphQL, которая позволяет направлять данные из облака в UI. Она пригодна для постепенного внедрения и может выступать дополнительным слоем для уже существующих сервисов, включая API и базы данных, построенные с учетом REST. В дополнение к инструментарию разработчика, который предоставляет все, чтобы уверенно запустить графовый API, в Apollo входят две библиотеки с открытым исходным кодом для клиента и для сервера.
На графике выше видно, насколько повысился уровень осведомленности о бренде и как много еще нужно сделать в этой области. Видно также, что почти каждый, кто попробовал Apollo, готов использовать его снова. Однако не мешало бы добавить новых обучающих материалов, чтобы в 2019 году сделать платформу успешнее. Для установки используйте npm:
Часть 3. Фреймворки для бэкенд-разработки
В этой области без особых изменений: Express все еще впереди — больше ни один бэкенд-фреймворк не смог в той же степени порадовать разработчиков.
Обладатель более 41 тысячи звезд на GitHub, Express — скоростной, гибкий и минималистичный веб-фреймворк для приложений Node.js.
В 2018 году Express справился со своими задачами блестяще: он не только сохранил статус лидера, но и оставил конкурентов далеко позади. Работая с JavaScript в бекэнде приложения, выбирайте именно его, и не прогадаете. Для установки используйте npm:
Хотя для визуализации роста за время существования Next оказалось недостаточно данных, все же мы можем сказать, что у этого бэкенд-фреймворка был неплохой год, сделавший его самым востребованным после Express.
Next, получивший более 32 тысяч звезд на GitHub, дает разработчикам возможность легкого старта, ведь он использует React для шаблонов. Разработчики с опытом работы в React с помощью Next могут добиться быстрого результата. Для установки используйте npm:
За прошедший год популярность Koa выросла, хотя кажется, что уровень удовлетворения разработчиков этим фреймворком не изменился, ведь Express по-прежнему лидирует. Однако посмотрев на графики других бэкенд-фреймворков (например, Meteor), можно сказать, что дела Koa неплохи — и могут быть еще лучше.
Этот новый веб-фреймворк, набравший более 24 тысяч звезд на GitHub, был создан той же командой, что и Express, как менее громоздкая, более выразительная и надежная платформа для веб-приложений и API. Используя средства асинхронного программирования, Koa позволяет отказаться от callback-функций и в разы эффективнее обрабатывать ошибки. В ядре Koa не производится сборка промежуточного ПО. Этот фреймворк имеет набор первоклассных методик, которые делают написание серверов быстрым и приятным занятием. Для установки используйте npm:
Фреймворки JavaScript. Как изучить их по-быстрому
Сегодня мы хотели затронуть такую многогранную и противоречивую тему, как фреймворки JavaScript. За последние несколько месяцев в издательстве неоднократно обсуждались перспективы издания книг и по Angular.js, и по Knockout.js, а книга по Backbone.js у нас выходила в прошлом году. Следующий материал призван помочь разобраться в сильных и слабых сторонах различных фреймворков JavaScript. Возможно, после изучения статьи читателю будет проще ответить на вопросы о том, так ли схожи эти фреймворки, и желает ли он дополнительно изучить какую-то из технологий, упомянутых в этом обзоре. Мы же попросим вас поделиться вашими соображениями о том, нужны ли новые книги по этим фреймворкам, если да — то по каким (высказываемся в комментариях, не стесняемся давать ссылки на книги).
Чтобы быстро изучать фреймворки JavaScript из разряда MV*, важно уметь представить любой фреймворк как ряд возможностей. Основные функциональные возможности MV*-приложения — это маршрутизация, привязка данных, шаблоны/представления, модели и хранилище данных. В данной публикации я собираюсь описать эти возможности и показать код реализации каждой из таких возможностей в двух или трех фреймворках. Для начала мы конкретно разберем, решение каких именно задач оптимизирует каждый из фреймворков, после чего, надеюсь, вы заметите во всех этих фреймворках больше сходств, чем различий. Оказывается, что в большинстве фреймворков активно заимствуются возможности, оправдавшие себя в других фреймворках.
Я предпочитаю видеть в людях сходства, а не различия — Исабель Альенде
Не утруждайте себя разбором каждой строки кода. Пока просто постарайтесь оценить, в чем схожи эти фреймворки, и какие проблемы они позволяют решать на проекте.
Как минимум, маршрутизация отображает ваши URL на действия, но иногда дело доходит до реализации полного паттерна «машины состояний» для управления переходами между состояниями в пределах представления.
Если вам когда-нибудь доводилось использовать маршрутизатор в серверном MVC-фреймворке, например, в Rails, CodeIgniter, CakePHP, ASP.NET MVC, Spring MVC, JSF, STRUTS, Grails и т.д., можете считать MV*-маршрутизаторы JavaScript аналогичными сущностями, но работающими на клиенте с JavaScript и прокладывающими маршруты к серверному коду, который может быть написан на PHP, Ruby, Java, C# и т.д.
Может возникнуть вопрос: а как все это будет работать в старых браузерах? Механизм работает по умолчанию, используя при этом в качестве маршрута всю информацию, которая расположена в URL после хэштега. Правда, если в HTML сконфигурирована поддержка пуш-состояний (в большинстве фреймворков это делается одной строкой кода), то URL без хэшей, совпадающие с маршрутами, будут перехватываться на клиенте и также выполнять код JavaScript.
Пуш-состояние НЕ ПОДДЕРЖИВАЕТСЯ по умолчанию, так как, несмотря на то, что URL, запрошенный непосредственно через закладку или пересланный в электронном сообщении, будет работать на компьютере конечного пользователя, поисковые роботы не слишком хорошо приспособлены к работе с JavaScript. То есть, робот может не выполнить код JavaScript, поэтому, не сможет просмотреть истинное содержимое страницы.
Решение, обычно предлагаемое в таких случаях – запустить на сервере PhantomJS или другой легковесный браузер, заставить его загружать страницы и JavaScript, а затем возвращать сгенерированную разметку вместе с JavaScript. Чтобы настроить этот механизм, нужно потрудиться, поэтому он задается по умолчанию для URL с хэштегами, поддерживаемых во всех браузерах.
Довольно объяснений, переходим к коду.
Вот простой пример маршрутизации в Backbone.js
В частности, обратите внимание на объект AppRouter. Маршруты отображаются на функции. Функции просто создают объект представления, управляющий фрагментом модели DOM, и добавляют его на страницу, как только URL изменится. Функция Backbone.history.start() приказывает Backbone начать слушать изменения URL.
Пример с AngularJS
Вот простой пример маршрутизации в AngularJS.
Пример с AngularJS очень напоминает Backbone, за тем исключением, что маршруты отображаются на классы templateUrl и контроллеров (в таком контексте контроллеры подобны представлениям Backbone).
Пример с Ember
Ниже приведен простой пример маршрутизации в Ember.
Опять же, пример очень похож на предыдущие, за тем исключением, что в Ember.js первым параметром «ресурсного» объекта маршрутизатора является имя routeName, а вторым — URL. На первых порах такой порядок следования меня запутал, пока кто-то не подсказал, что параметр пути необязателен и зачастую может устанавливаться по соглашению, как в случае со страницей about из этого примера. Кроме того, для запуска этого простого примера маршрутизации нужны шаблоны, но я остановлюсь на них только в конце статьи. Пока достаточно знать, что шаблоны помещаются в элементе <
В большинстве фреймворков содержится решение для маршрутизации, но в Knockout.js основной акцент делается на привязке данных и предлагается лучшее в своем роде решение, предполагающее использование одной из библиотек JavaScript, единственное назначение которой — маршрутизация. Наиболее распространенные специализированные библиотеки такого рода — SummyJS и HistoryJS. SummyJS работает с браузерами, поддерживающими API History для HTML5, а также URL-хэши для устаревших браузеров (IE 8 и ниже). Библиотека HistoryJS меньше, но поддерживает только API History для HTML5.
Привязка позволяет вносить изменения в модель данных, которую требуется обновить в представлении или и/или позволяет автоматически обновить модель с учетом изменений, внесенных в представление, причем для этого не требуется никакого дополнительного кода. Однонаправленная привязка данных обычно означает, что изменения, вносимые в модель, распространяются в представление. При двунаправленной привязке данных появляется дополнительная возможность оперативно отражать в модели все изменения, вносимые в представление. Привязка данных избавит вас от массы стереотипного кода, который обычно приходится писать разработчикам. Соответственно, программист может сосредоточиться на решении уникальных задач, свойственных данному приложению.
Пример с AngularJS
Ниже приведен простой пример двунаправленной привязки данных в AngularJS. При наборе текста в поле ввода он будет выводиться на экран сразу же после приветственного сообщения.
Пример с KnockoutJS
Фреймворк KnockoutJS действительно сосредотачивается исключительно на привязке данных и используется в рамках наилучшего подобного решения вместе с другими фреймворками и библиотеками, в частности, с DurandalJS для управления дисплеем и History.js или Sammy.js для обработки маршрутизации. Вот пример привязки данных в KnockoutJS.
В Backbone нет автоматической привязки данных, однако ее можно выполнить вручную. По моему опыту, однонаправленная привязка данных, при которой представление обновляется в ответ на изменения, вносимые в модель, является исключительно полезной. Реальные случаи однонаправленной привязки данных от вида к модели встречаются реже (например, вы хотите реализовать живой предпросмотр текста, вводимого пользователем в текстовый редактор). Действительно, привязка от представления к модели может быть полезна, но зачастую причиной изменений представления является информация, вводимая пользователем, а вы хотите успеть реализовать и другую логику прежде, чем эти изменения будут внесены в модель. Например, речь может идти о валидации ввода или фильтрации списка, при которой также требуется запомнить текущий фильтр. Ниже показан простой пример кода, в котором реализованы оба варианта привязки.
Итак, вы слушаете события изменений, происходящие в модели, и вызываете свойство представления render, чтобы модель обновила представление. Аналогично, вы слушаете события «keyup» при вводе и изменяете модель, получая из вводимой информации нужное значение при помощи jQuery и устанавливая его в модели — так, чтобы представление обновило модель. Данный пример помогает составить впечатление о том, сколько кода потребуется, чтобы заработала привязка данных. Также необходимо упомянуть о существовании многочисленных плагинов, поддерживающих привязку данных в Backbone.
Привязка данных в Ember выглядит так:
Фреймворк Ember использует для шаблонизации знакомые нам объекты handlebar, но также включает «помощники ввода», обеспечивающие привязку тех полей ввода, которые встречаются в большинстве форм. В данном примере фигурные скобки << заменяют угловые
Обзор JS-фреймворков. Путешествие через джунгли JavaScript MVC. Ч. 1
(от 27 июля 2012)
При написании нативного веб-приложения легко начать чувствовать себя богом, способным работать просто с библиотекой работы с DOM (такой как jQuery) и горсткой сервисных плагинов. Вскоре возникает проблема в виде груды вложенных возвратных функций jQuery и разбросанных DOM-элементов без всякой структуры вместо приложения.
■ Что такое MVC или, лучше сказать, MV*?
Эти современные библиотеки дают разработчикам простой путь к организации кода, используя вариации паттерна проектирования, известного как MVC (Model-View-Controller). MVC разделяет задачи в приложении на 3 части:
Модель (логика) представляют проблемно-ориентированные знания и данные в приложении. Думайте о них как о типе данных, которые сможете смоделировать, о таких, как Пользователь, Фото, или Замечание. Модели должны информировать о чём-либо при наблюдении за их текущим состоянием.
Представление (вид) обычно проектируется в виде пользовательского интерфейса, такого как разметка и шаблоны, но не интерактивного. Они должны знать о существовании Моделей, но непосредственно не общаться с ними.
Контроллеры (диспетчеры) обрабатывают входные данные (клики, пользовательские действия) в приложении, а Представления можно рассматривать как выходной продукт обработки. Когда Контроллер меняет состояние Модели (например, редактирование заголовка на фото), он прямо не меняет Представление. Это — случай, где работают отношения Модели и Представления.
MVC-фреймворки на Javascript, помогающие в структурировании кода, не всегда строго следуют описанному образцу. У некоторых Контроллер будет отвечать за Представление (backbone.js), самоуверенно смешивая компоненты, считая, что так пока будет лучше.
■ Когда нам нужен MV*-фреймворк JS?
При построении одностраничного приложения или при создании сложного пользовательского интерфейса, или просто при сокращении количества HTTP-запросов вы, вероятно изобретёте много частей структуры MV*-фреймворка типа Backbone или Ember.
В начале работы не очень трудно написать каркас (фреймворк) приложения, предлагающий некоторый велосипед механизм для избегания спагетти-кода. Но говорить, что это не сложнее, чем написать «какой-нибудь» Backbone, было бы слишком неправильно.
Есть нечто намного большее в структурированных приложениях, чем связывание манипуляций DOM, шаблонизации и выявление связей. Зрелые фреймворки MV* обычно не только содержат много кусочков, которые вы бы написали, но и содержат решения будущих задач. Это экономит время, что нельзя недооценивать.
■ Где же мы будем нуждаться в MV*, а где нет?
Если вы пишете приложение для общения с API или для обработки данных бекенда, где основная тяжесть просмотра или управления данными будет в браузере, в нём JavaScript MV*-фреймворк будет полезным.
Хорошие примеры приложений этого рода — Google Docs и GMail. Обычно такие приложения загружают один раз полезный груз со всеми скриптами, стилями и разметкой для общих задач и затем выполняют много мелких действий в фоне страницы. Это — просто переходы с чтения почты или документа на составление писем, и вам вообще не нужно загружать новые страницы.
Но если вы строите приложение, которому требуется сервер для большого объёма Представлений (страниц) и используете небольшой JavaScript или jQuery для обмена, паттерн MV может стать убийственным. Конечно, есть сложные приложения в вебе, где частичный показ представлений МОЖЕТ хорошо жить вместе с одностраничным приложением, но для всего остального лучше выбрать механизм загрузки попроще.
■ Проблема выбора: слишком много вариантов?
В моем топике “Классификация JavaScript MVC: Злоупотребление или Развитие?” (англ.), я поднял вопрос о том, что сейчас есть слишком большой выбор инструментов для структурирования вашего JS-приложения. Часть проблемы истекает из того, как различные разработчики JavaScript выбирают организацию масштабируемого приложения: MVC, MVP, MVVM? Или что-то другое? Каждую неделю с большим избытком рождаются новые MV*-фреймворки, потому что мы всё ищем “правильный путь”, если он существует вообще. Много разработчиков полагают, что его нет.
Мы идём выбирать новые фреймворки, которые часто возникают как ‘Yet Another Framework Syndrome’ (или YAFS). На правах инноваций кое-что, конечно, приветствуется, но YAFS может привести к большой растерянности и фрустрации, когда разработчики хотят начать писать приложение, а им надо вручную оценить 30 инструментов, чтобы выбрать что-нибудь не сильно неподходящее. Различия между некоторыми фреймворками будут очень тонкими, если не трудноразличимыми.
■ TodoMVC: общее приложение для обучения и сравнения
Мы видим огромный бум в количестве таких MV*-фреймворков за последние несколько лет.
Backbone.js, Ember.js, AngularJS, Spine, CanJS… Список новых и работоспособных решений растёт каждую неделю; разработчики могут быстро потеряться в море вариантов. Им есть из чего выбирать. Имеется много сильных конкурирующих решений от умов, работавших над сложными приложениями, которые вдохновили на создание библиотек (такие как Yehuda Katz и Джереми Ashkenas). Вопрос: что использовать и как выбирать?
Мы осознали это положение и захотели помочь разработчикам максимально упростить процесс выбора. Мы создали TodoMVC — проект, который реализует одно и то же приложение Todo на различных популярных на сегодня MV*-фреймворках. Считайте его измерителем скорости работы с данными для фреймворков. Реализации живут и работают одинаково и помогают нам сравнивать синтаксис и структуру различных фреймворков; таким образом, мы можем выбрать тот, который чувствуется самым удобным или, по крайней мере, сравнение поможет сузить круг выбора. 
На этой неделе (14 июл.2012) мы выпускаем совершенно новую версию TodoMVC, подробности которой приводятся ниже в разделе приложений.
В ближайшем будущем мы хотим развить работу далее, предоставляя заметки о различиях и рекомендации о том, для каких типов приложений следует рассматривать вариант использования того или другого фреймворка.
■ Предложенные нами критерии выбора фреймворка
Выбор фреймворка — конечно, больше, чем простое сравнение работы приложения ToDo. Поэтому, когда ваш выбор оставит нескольких кандидатов, рекомендуем немного отойти от работы и осмотреться. Возможно, фреймворку придётся поддерживать нетривиальные функции, и может оказаться, что его придётся поддерживать долгие годы. Попробуйте ответить на вопросы.
На что действительно способен фреймворк?
Потратьте время на чтение исходного кода фреймворка и официального списка возможностей, чтобы узнать, насколько они соответствуют вашим требованиям. Будут проекты, которые могут потребовать изменения или дополнения исходного кода, и если вы посчитали это для себя выполнимым, код прошёл проверку.
Был ли проверен фреймворк в работе?
Есть ли разработчики, построившие и внедрившие большие, публично доступные приложения с этой библиотекой? Backbone имеет серьёзный список таких (SoundCloud, LinkedIn), но не все имеют подобное. Ember работает в ряде больших приложений, включая инструменты пользователя в Square. JavaScriptMVC используется в крупных приложениях в IBM, не считая других мест. Важно не только знать, что фреймворк работает, но и иметь возможность смотреть на реальный код и понимать, как это может быть построено.
Фреймворк отработан?
Мы рекомендуем разработчикам не просто “выбрать это и пойти работать”. Новые проекты часто сопровождаются множеством обсуждений релизов, не забудьте о них, выбирая релиз для приложения продакшн-уровня. Вы же не хотите иметь в проекте риск быть остановленным из-за срочного рефакторинга или других поломок, которые более предсказуемы, если фреймворк отработан, отлажен. Зрелые проекты обычно лучше документированы, официально или через сообщество.
Фреймворк гибкий или жёсткий в управлении?
Знайте, что есть библиотеки разного «характера». Фреймворки с жёстким управлением хотят от вас программирования в определённых рамках. Они ограничивают дизайн приложения и меньше уделяют внимание разработчикам, самостоятельно выясняющим, как это должно работать.
Вы действительно «поигрались» с фреймворком?
Напишите маленькое приложение, без фреймворка и затем попробуйте переделать код на работу с фреймворком, чтобы оценить, легко ли с ним работать. Поскольку работа с кодом повлияет на ваше решение, важно написать работающий код, чтобы убедиться, что вам удобно работать с его конструкциями.
Есть ли полная документация?
Хотя демо-приложения полезны для ссылки и просмотра, вы почти всегда будете общаться с официальными разработчиками фреймворка, узнавать, о поддержке API, о том, как решать общие задачи, как создавать компоненты и какие есть замеченные баги. Любой стОящий фреймворк должен иметь подробную документацию, помогающую разработчикам разобраться в нём. Без неё вы можете найти IRC-каналы с группами разработчиков или проводить самостоятельные исследования, которые сами по себе прекрасны, но часто отнимают много времени по сравнению с заранее предоставленным набором документов.
Каков объём фреймворка, способность к минификации, сжатию, модульности?
Какие зависимости имеет фреймворк?
Для фреймворков есть тенденция указывать размер их файла, но не упоминать размеры библиотек зависимостей. Маленькая библиотека окажется неожиданно большой, если, скажем, зависит от jQuery или других библиотек.
Вы ознакомились с сообществом пользователей-разработчиков фреймворка?
Есть ли активное сообщество участников проекта и пользователей, которые были бы в состоянии помочь, если будут проблемы? Достаточно ли много разработчиков использовали фреймворк, есть ли ссылки на работающие приложения, обучающие программы и, возможно, даже скринкасты, чтобы узнать о нём больше?
■ Dojo и усложнение фреймворков на JavaScript
Как многие знают, Dojo Toolkit была одной из первых попыток дать разработчикам средство разработки сложных приложений. Некоторые могут сказать, что это вдохновило их больше думать о задачах для необычных приложений. Я спрашивал [в письме] разработчиков Dojo — Dylan Schiemann, Kitson Келли, и Джеймса Томаса, что они думают о появлении MV*-фреймворков.
В.: Библиотека Dojo не могла всё это решить? Почему она не стала предпочтительным решением для желающих построить более структурированные и нетривиальные приложения?
О.: Несколько лет назад, когда окружение JavaScript развилось от добавления простого Ajax и эффектов на странице, Dojo проповедовал «инструментальный» подход к построению сложных приложений в Вебе.
Многие из тех функций были далеко впереди большинства потребностей разработчиков. С появлением браузера как доминирующей платформы приложения, многие новшества ввели в Dojo Toolkit, а теперь они появляются в новых инструментах. MVC был просто ещё одним пакетом, который предоставляла Dojo достаточно долгое время вместе с другими модулями кода: OOП в JS, виджетов UI, кроссбраузерной графики, шаблонов, интернационализации, доступа к данным, хранилищ данных, тестовых фреймворков, сборки системы и очень многого другого.
Джаваскрипт-библиотеки не должны иметь «претензии», почему Dojo с ранней стадии сконцентрировала усилия на полном цикле разработки приложений уровня предприятия. Тот же фокус имеется сейчас и у MVC, просто это один «инструмент из набора».
Почему Dojo — не доминирующий набор инструментов? Её цель никогда не состояла в том, чтобы стать единственным выбором. Цель была в том, чтобы обеспечить открытый набор инструментов, могущих работать с чем-нибудь другим в пределах проектов и с переносимостью в другие проекты. Dojo критиковалась за то, что была медленной и даже после того, как за это взялись, она критиковалась за то, что была медленной. Попытка избавиться от ярлыка — сложная задача. Трудно документировать особенности богатого набора инструментов. В Dojo 1.8 — 175 суб-пакетов и более 1 400 модулей.
Это не только вопрос о достижении цели документирования, он значит, что Dojo решает не одну задачу. Хорошо, когда вы пишете программу, но очень трудно сначала выяснить, с чего начать. Улучшенная документация и обучающие программы пытаются помочь в работе с Dojo 1.8.
В.: Почему разработчики должны выбрать Dojo и какой список идей вы имеете для будущего проекта? Говорят, что после 1.8 будет другая цель.
О.: В Dojo 1.8 пакет dojox/mvc делает ещё один шаг к зрелости. Много было затрачено времени, усилий, тестирования и внимания сообщества к пакету. Он специализируется на предоставлении модели MVC, усиливающей остальную часть Dojo. Вместе с прикладным пакетом dojox/app для построения rich-приложений для десктопов и мобильных устройств, это делает целостную систему для клиентской стороны.
И это — только один из жизнеспособных путей построения приложений в типичном подходе Dojo.
В 1.8, мало того, что подмодуль MVC становится более зрелым, он основан на устойчивом фреймворке. Это не только дает язык разметки, чтобы создать Ваши View-компоненты, выразить Ваши модели или разработать контроллер. Это намного больше, чем просто подключить ещё один модуль к источнику данных. Поскольку это подключено к остальной части Dojo, вы можете подключить всё, что потребуется.
В Dojo 2.0 мы будем пробовать поднять модульность на новый уровень, чтобы стало еще проще взять то, другое и собрать всё это вместе. Мы также исследуем концепцию изоморфизма, чтобы для пользователя не имело значения, где выполняется код, на клиенте или сервере, и, в конечном счете, это должно быть прозрачно разработчику.
■ Коллекция TodoMVC
В нашем совершенно новом выпуске теперь имеются реализации Todo для самых популярных фреймворков с большим количеством других умеренно используемых фреймворков, запущенных в Labs. Эти реализации прошли много пересмотров, часто принимая «на борт» подсказки из лучших практик и предложения от авторов фреймворка, участников его разработки и пользователей сообщества. 
Вслед за комментариями, сделанными автором Backbone.js Jeremey Ashkenas и Yehuda Katz, TodoMVC теперь тоже предлагает соответствующие реализации, сделанные на официальной спецификации приложения, такие как навигация (или управление состояниями). (?)
Мы не делаем вид, что более сложные приложения для сравнения невозможны (конечно, возможны), но простота приложения Todo позволяет разработчикам воспринимать структуру кода, синтаксис компонентов и «чувство потока» в достаточной степени, чтобы начать сравнивать фреймворки и смотреть детали их решений или нескольких решений.
Похожий обзор: Rich JavaScript Applications – the Seven Frameworks (Throne of JS, 2012), Steven Sanderson, 1th Aug 2012. Различия и совпадения подходов Backbone, Meteor, Ember, AngularJS, Knockout, Spine, Batman, CanJS — по результатам конференции «Throne of JS, 2012».