Чем может быть полезен Sproutcore/Qooxdoo?

Вот ответ с точки зрения qooxdoo:

Могу ли я легко повторно использовать код из одного приложения в другом?

Да, ты можешь. Вы можете организовать свой код в «библиотеках», которые могут быть включены в несколько приложений. Но каждое приложение будет отдельным целым (думайте об этом как о двоичном файле с кодом библиотеки, который подключается статически), нет ручного копирования файлов .js.

Можете ли вы также легко иметь одностраничные статические страницы?

Я не уверен, что вы имеете в виду здесь.

Они только на одну страницу, вроде как gmail?

Да, вы создаете одностраничные приложения с помощью qooxdoo.

Это имеет значение? Действительно ли это проще, чем не использовать его? Я имею в виду, что кривая обучения для фреймворка равна изучению html/css/javascript?

Это во многом зависит от вашего фона. Если вы хорошо разбираетесь в объектно-ориентированном программировании, возможно, даже имеете опыт работы с библиотекой интерфейсов объектно-ориентированного программирования, такой как Qt или Swing, изучение qooxdoo должно быть очень простым. В таком случае я бы сказал, что усилия по обучению меньше, чем по сравнению с html/css/javascript, поскольку вы в основном работаете с библиотекой классов OO, которая защищает от вас базовую технологию. (Что хорошо. Получить, например, правильный кросс-браузерный CSS сложно).

Приложения такого типа загружаются медленнее из-за больших накладных расходов?

Я бы сказал так. Вы платите штраф за инфраструктуру. Но если вам нужен настоящий веб-интерфейс, оно того стоит.

Каковы плюсы/минусы использования/не использования одного из них?

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

Но это инвестиции, я бы сказал, слишком большие для одноразового проекта. И если вам просто нужно несколько представлений списка, придерживайтесь шаблонов Django, возможно, приправленных небольшим количеством Javascript.

Вы должны иметь в виду, что T в HTML означает текст. HTML предназначен для отображения документов. JavaScript добавил интерактивности этим документам. Это было «извращено» (в некотором роде) до того момента, когда JavaScript использовался для создания опыта, подобного настольному приложению, манипулирующего объектами DOM.

В настоящее время, если вы посмотрите на веб-приложения, можно выделить три основные категории:

1. веб-сайты
   Такие приложения в основном представляют собой службы доставки контента/документов. Вы можете просматривать, искать, редактировать и публиковать некоторые документы. это в основном все. stackoverflow — хороший пример для этой категории.
2. веб-интерфейсы
   Такие приложения представляют собой веб-интерфейс для приложения, которое фактически работает на сервере. Они действуют как интерфейс к бизнес-логике, работающей на сервере. Хорошим примером являются приложения для онлайн-банкинга или веб-интерфейсы для различных видов услуг. В каком-то смысле это классическая страница Google.
3. RIA
   Эти приложения полностью выполняются на клиенте. Они получают данные с сервера и предоставляют пользовательский интерфейс, который позволяет манипулировать этими данными прямо на стороне клиента и, возможно, отправлять прогресс/результат.

Конечно, есть приложения, которые нельзя отнести только к одной из этих категорий.
Теперь для веб-сайтов очень важно создавать семантический, чистый и корректный HTML по ряду причин. Наиболее важными из них являются SEO и доступность.
Для веб-интерфейсов и RIA это не так. Здесь, на стороне клиента, важнее всего удобство использования. Для веб-интерфейсов желательно избегать обновления всей страницы и максимально облегчить ввод данных пользователем. Для RIA это обязательно. Обе категории используют HTML не для представления документов, а для создания пользовательского интерфейса. Для веб-интерфейсов могут помочь классические формы, в зависимости от сложности пользовательского ввода, поэтому вы можете рассматривать их либо как веб-сайты, либо как RIA для этого рассмотрения.

В то время как веб-сайты используют HTML для представления фактических данных, CSS для определения их внешнего вида и JavaScript для добавления интерактивности, веб-интерфейсы и RIA используют объекты DOM для создания пользовательского интерфейса, CSS для оформления этого пользовательского интерфейса и JavaScript для реализации бизнес-логики на стороне клиента.

Таким образом, несмотря на то, что вы используете ту же платформу, на самом деле вы делаете что-то совершенно другое. Думайте об этом как о текстовом режиме. Символы на экране могут представлять собой текст или элементы графического интерфейса пользователя. (Я полагаю, что веб-интерфейсы будут командными строками в этой аналогии: D).

Такие платформы, как qooxdoo и sproutcore, предназначены для облегчения создания RIA. Поскольку в этом подходе DOM используется неправильно, они обеспечивают необходимую абстракцию для связи между UI-логикой и базовой манипуляцией DOM. Они сводят на нет необходимость в HTML и CSS, потому что это не инструменты, предназначенные для создания интерактивных пользовательских интерфейсов.

В зависимости от того, что вы собираетесь делать, вам придется выбрать соответствующий инструмент.