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

101

Моя цель - перенести существующее веб-приложение в одностраничное приложение 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-центры развиваются очень быстро и быстро, большинство из них уже устарели.

Кристофер Уилл
источник
Ознакомьтесь с основанной на нокауте фреймворком SPA,
исходный код которого

Ответы:

81

Недавно мне пришлось выбрать фреймворк 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, чтобы запустить его. Таким образом, больше внимания уделяется выбору того, что вам нужно и что работает вместе, чем выбору ИДЕАЛЬНОЙ структуры для использования.

Нейт
источник
Большое спасибо за подробный ответ. Некоторые вопросы относительно knockout.js: 1) Предоставляет ли он какой-то уровень данных для синхронизации модели во внешнем / внутреннем интерфейсе? 2) Как поддерживается включение одного шаблона в другой (возможно, вместе с requireJS)? 3) Легко ли разместить все файлы (модели, представления, контроллеры, помощники и т. Д.) Отдельно и в разных папках? Помимо этих вопросов я установил ваш ответ как принятый, поскольку вы предоставили много информации.
Кристофер Уилл
@ChristopherWill Спасибо! 1.) Подобно тому, как Backbone оставляет это на ваше усмотрение для привязки представления, Knockout оставляет его на ваше усмотрение для привязки REST-> Model. В документации есть несколько примеров - knockoutjs.com/documentation/json-data.html, или вы можете использовать KnockBack для объединения REST-> Model популяции Backbone.
Nate
2.) Это зависит от того, что вы имеете в виду - Knockout имеет встроенную привязку данных, которая позволяет вам взять коллекцию из модели, привязать к тегу списка или тегу таблицы и для каждого из них отобразить указанный шаблон. Для крупномасштабных вещей, например, как вы создаете свои общие представления и меняете их местами - это все еще несколько ручное (по крайней мере, как я это делаю, все еще учусь) - RequireJS с текстовым плагином делает это немного проще, но вам все равно нужно указать логику и поменять местами div - я просто делаю это в методах, которые отвечают на мои маршруты. Тем не менее, вы можете подключить для этого события Knockout.
Nate
3.) RequireJS позволяет вам это делать.
Nate
Спасибо, Нейт. Думаю, я попробую KnockBack ... звучит многообещающе. И, конечно же, с вашими упомянутыми библиотеками (requireJS, crossroads и т. Д.)
Кристофер Уилл
8

Прошел год с тех пор, как мы начали разработку нашего проекта облачных сервисов с многочисленными 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.

Единорог
источник
Здравствуйте! Ты сейчас пользуешься Додзё? Вы ведете блог о Додзё?
Дунаевский Максим
Здравствуй! Да, мы по-прежнему используем его для того же продукта и поддерживаем его. наш внутренний фреймворк написан поверх додзё, и мы добавляем к нему каждый день .. нет, у меня нет блога для этого. если вы собираетесь начать с него, в настоящее время он считается старым инструментом. Они все еще работают над Dojo 2.0, но сейчас, возможно, лучше использовать другие варианты. у нас есть React / Angular вверху списка.
Unicornist