Фреймворки JavaScript для создания одностраничных приложений [закрыто]

Моя цель - перенести существующее веб-приложение в одностраничное приложение RESTful (SPA). В настоящее время я оцениваю несколько фреймворков веб-приложений Javascript.

Мои требования следующие:

• Уровень данных RESTful (например, ember-data)
• MV * -структура
• Динамические маршруты
• Тестирование-поддержка
• Кодирование по соглашению
• SEO-поддержка
• Браузер-История-Поддержка
• Хорошая (API-) документация
• Готово к производству
• Живое сообщество

Магистраль

Текущее приложение использует backbone.js. В целом, backbone.jsэто хороший проект, но мне не хватает четко определенных структур, которые определяют, где что должно происходить и как все должно быть реализовано. Работа в более крупной команде с меняющимися разработчиками приводит к некоторому неструктурированному коду, который трудно поддерживать и трудно понять. Вот почему я сейчас ищу фреймворк, который уже определяет все это.

Ember

Я заглянул в ember.jsпоследние дни. Мне этот подход кажется очень многообещающим. Но, к сожалению, код меняется практически ежедневно. Так что я не буду называть его готовым к производству. И, к сожалению, мы не можем дождаться версии 1.0. Но мне очень нравится идея этого фреймворка.

Угловой

Angular.jsтакже широко распространенный фреймворк, поддерживаемый Google. Но с angular я так и не познакомился. Для меня структура кажется неясной, отсутствуют объяснения общих обязанностей каждой части фреймворка, а реализации кажутся окольными. Чтобы прямо сказать: это всего лишь мое личное впечатление и может быть основано на недостающих знаниях.

Бэтмен и Метеор

Как я понял, обеим фреймворкам тоже нужна серверная часть. А поскольку нам просто нужен бэкэнд RESTful - независимо от языка, техники или программного обеспечения, это не то, что мы хотим. Кроме того, серверный API уже существует (RoR).

Нокаут , CanJS и Spine

Я не стал углубляться в этих трех кандидатов. Может быть, это будет мой следующий шаг.

Итак, мои вопросы сейчас:

• Не хватает хороших SPA-фреймворков?
• Какую структуру вы бы предложили / порекомендовали?
• Вы бы избегали любой из упомянутых фреймворков?
• Каков ваш опыт работы с более крупными приложениями SP?

PS: Я хотел бы порекомендовать отличный пост в блоге от Стивена Андерсона (основного разработчика Knockout.js) о конференции «Трон JS» (с 2012 года) и фреймворках javascript в целом.

PS: Да, я знаю, что уже есть вопросы по SO. Но поскольку SPA-центры развиваются очень быстро и быстро, большинство из них уже устарели.

Недавно мне пришлось выбрать фреймворк JavaScript SPA для проекта.

• Ember

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

• Магистраль

  Backbone был первым фреймворком, на который мы серьезно посмотрели. Я не уверен, что понимаю, почему вы думаете, что у него нет «четко определенных структур»? Backbone довольно ясно понимает, как разделить код модели и код представления. Может вы имеете в виду, что нет какого-то шаблона приложения? В любом случае Backbone, кажется, действительно сосредоточен на части привязки модели / REST, но на самом деле ничего не предписывает для привязки представления. Если привязка модели важна для вас и вы используете Rails, сделать это будет несложно. К сожалению, веб - службы для моего приложения на самом деле не совпадают, и я должен был писать свои собственные .syncи .parseметоды для всего. Разделение кода модели и представления было приятным, но, поскольку нам пришлось бы писать все наши привязки с нуля, оно того не стоило.

• Выбить

  Нокаут подобен Инь и Ян позвоночника. Если Backbone ориентирован на модель, Knockout - это платформа MVVM, ориентированная на представление. Он имеет observableоболочки для свойств объекта JavaScript и использует data-bindатрибут для привязки свойств к вашему HTML. В конце концов, мы выбрали Knockout, поскольку привязка представлений была в основном тем, что нам нужно для нашего приложения. (... плюс другие, как обсуждается позже ...) Если вам нравится привязка представления Knockout и привязка модели Backbone, есть также KnockBack, который объединяет обе структуры.

• Угловой

  Посмотрел на это после Knockout - к сожалению, мы все казались очень довольными тем, как Knockout просматривал привязку. Это казалось намного более сложным и трудным для восприятия, чем Knockout. И он использует кучу настраиваемых атрибутов HTML для привязки, что я не уверен, что мне нравится ... Я могу еще раз взглянуть на Angular позже, потому что, поскольку я встречал нескольких людей, которым действительно нравится структура - возможно, мы просто посмотрел на это слишком поздно для этого проекта.

• Бэтмен , Метеор , CanJS , Позвоночник

  Я не особо внимательно смотрел ни на одну из них. Хотя я знаю, что Spine похож на Backbone с явными объектами Controller и написан на CoffeeScript.

• Послесловие

  Как я уже упоминал, мы закончили использовать Knockout, потому что для нашего проекта более важным было сосредоточение на привязке представления. Мы также закончили тем, что использовали RequireJS для модуляции, перекрестков и Hasher для обработки маршрутизации и истории, Jasmine для тестирования, а также JQuery , Twitter Bootstrap и Underscore.js (и, возможно, других библиотек, о которых я сейчас забываю).

  Разработка приложений Javascript больше похожа на экосистему Java, чем на экосистему Rails. Rails предоставляет прочное ядро ​​того, что вы собираетесь использовать для каждого приложения (фреймворк Rails), и сообщество предоставляет множество дополнительных настроек (драгоценные камни). Java предоставляет ... язык. А затем вы можете выбрать Java EE, Spring, Play, Struts или Tapestry. И выберите JDBC, Hibernate, TopLink или Ibatis, чтобы поговорить с базой данных. А затем вы можете использовать Ant, Maven или Gradle для его создания. И выберите Tomcat, или Jetty, или JBoss, или WebLogin, чтобы запустить его. Таким образом, больше внимания уделяется выбору того, что вам нужно и что работает вместе, чем выбору ИДЕАЛЬНОЙ структуры для использования.

Прошел год с тех пор, как мы начали разработку нашего проекта облачных сервисов с многочисленными SPA, поэтому было важным решением, какую инфраструктуру javascript использовать для нашего пользовательского интерфейса, чтобы удовлетворить потребности нашей архитектуры RESTful. и после многих исследований мы остановились на фреймворке Dojo .

основные функции, которые вам понравятся:

1. образованное сообщество и команда, которая придумала идеальный шаблон дизайна. отличные соглашения и модульная / объектно-ориентированная архитектура. с отношением к программированию CrossBrowser :)
2. Структура МВ *. создавать виджеты пользовательского интерфейса с помощью внешних шаблонов .htm, а для производства - объединить все ваши javascript и шаблоны в единый, миниатюрный и небольшой .js
3. строить классы с наследованием. установщики свойств, множество функциональных инструментов.
4. механизм pub / sub (названные темы в додзё)
5. множество элементов управления пользовательского интерфейса, от элемента управления формой проверки, диалогов / всплывающих подсказок до многофункциональных, настраиваемых (но легких) диаграмм и решения для сетки данных.
6. хорошая система модульного тестирования под названием DOH. у него также есть робот для воспроизведения действий мыши / клавиатуры.
7. инструмент запросов (например, JQuery) с именем NodeList со всеми функциями jquery и даже множеством его плагинов.
8. и хорошая, но не очень полная часть. у него есть модуль JsonRest для использования с вашими службами REST. это удобный инструмент, но в нем отсутствуют многие функции.

Чтобы решить эти проблемы, мы разработали AJAX-опросчик, обработку ошибок и универсальное решение для загрузки и уведомлений. мы сделали это очень легко, используя соглашения и структуры dojo framework. если вы не хотите этого делать, возможно, вам придется использовать другой фреймворк для этой части.

Посмотрев на отличные SPA в Интернете, вы обнаружите, что все они настроены и используют несколько фреймворков. но наш опыт работы с одним Додзё был фантастическим. и поэтому я предлагаю вам не думать о каких-либо других фреймворках, поскольку все они неполны для SPA. но в конечном итоге у вас есть еще один вариант (который я не рекомендую и не имею подробной информации). используйте среду JAVA, которая способна создавать SPA путем автоматической генерации пользовательского интерфейса и javascript.