JavaScript SPA-Framework (одностраничное приложение)

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

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

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

BACKBONE

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

EMBER

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

ANGULAR

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

BATMAN, METEOR p >

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

KNOCKOUT, CANJS, SPINE

Я не пошел глубже в этих трех кандидатах. Возможно, это будет мой следующий шаг.

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

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

С уважением,

Кристофер

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

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

Ответ 1

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

  • Ember

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

  • Backbone

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

  • Knockout

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

  • Angular

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

  • Batman, Meteor, CanJS, Spine

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

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

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

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

Ответ 2

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

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

  • образованное сообщество и команда, которая придумала идеальный дизайн. большие соглашения и модульная/объектно-ориентированная архитектура. с настройками программирования CrossBrowser:)
  • MV * структура. создайте виджеты пользовательского интерфейса с внешними шаблонами .htm и создайте все свои javascript и шаблоны в единый, миниатюрный и маленький .js
  • строить классы с наследованием. средства настройки свойств, множество функциональных инструментов.
  • pub/sub механизм (названные темы в dojo)
  • множество элементов управления пользовательского интерфейса, от контроля формы проверки, диалогов/всплывающих подсказок до тяжелой, хорошо настраиваемой (но легкой) диаграммы и решения сетки данных.
  • хорошая unit test система с именем DOH. у него также есть робот для воспроизведения действий мыши/клавиатуры.
  • инструмент запросов (например, JQuery) с именем NodeList со всеми функциями jquery и даже с множеством плагинов.
  • и хорошая, но не полная. он имеет модуль JsonRest для использования с вашими службами REST. его удобный инструмент, но ему не хватает много возможностей.

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

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