HTML5 UI Frameworks

Ответ 1

В вашем вопросе так много, что ответ будет нелегким и не будет определенным вообще. Это также будет очень упрямым. Глядя на список рамок, которые вы принесли, я вижу очень разные вещи, которые вряд ли сопоставимы друг с другом. Я попытаюсь как-нибудь их сгруппировать и добавить в список дополнительные фреймворки.

Основной вопрос здесь заключается не в плюсах и минусах конкретной структуры. Главный вопрос: сколько вы хотите? Вы действительно имели в виду приложение, такое как Gmail или Grooveshark? Или вы имели в виду что-то вроде Stackoverflow - динамичный и совсем не простой, но все же веб-сайт. Рассмотрим все эти варианты.

Возможно, вы просто хотите улучшить свой веб-сайт с помощью некоторых виджетов, таких как вкладки, диалоги, некоторые элементы перетаскивания/удаления, редактирования текста и т.д., и вы не хотите менять свою модель разработки. Я имею в виду, вы используете свой любимый Java/PHP/Ruby и не хотите писать много логики и поведения приложений в JavaScript. В этом случае для вас будут использованы плагиноподобные решения на основе jQuery, в частности jQuery UI и jQuery Mobile.

Виджеты jQuery следуют за его плагиновой системой. Обычно это означает, что они чрезвычайно просты в использовании. Чтобы создать кнопку, вы пишете:

$('#myButton').button();

Теперь, если вы хотите отключить его, вы вызываете метод, используя следующий шаблон:

$('#myButton').button('disable');

И получение или установка значений, например. на слайдере или datepicker, выглядит так:

$('#mySlider').slider('value');
$('#mySlider').slider('value', 42);

Как вы видите, решения на основе jQuery не имеют модели. Все ваши данные хранятся в DOM и получаются с помощью причудливых вызовов методов. Если вам необходимо динамически обрабатывать ваши данные, например. выполнять некоторые сложные проверки, загружать что-то в фоновом режиме, фильтровать или сортировать, то вы видите, что это скоро станет беспорядочным. Кстати, это проблема, почему команда jQuery UI еще не обеспечила управление сеткой - они не могут сделать это без модели. В jQuery Mobile вы получаете хороший мобильный пользовательский интерфейс с помощью простой разметки, но нет официального способа передачи данных между страницами.

Подводя итог: если у вас многостраничный сайт, если вы отправляете свои формы, используйте интерфейс jQuery или более легкое решение, например Twitter Bootstrap.

Возможно, вы хотите создать что-то более сложное, более прикладное (одностраничное приложение?). Вы знаете, что вам нужно будет работать с данными на стороне клиента. Каковы ваши варианты?

Вы можете использовать одну из многих фреймворков JavaScript, которые предоставляют вам модели, привязку данных и, возможно, другие средства создания веб-приложений и их интеграцию с почему-то не jQuery UI. Или вы можете использовать более полную структуру, например Kendo или Wijmo или jqWidgets. Эти рамки полагаются на jQuery (Wijmo полагается на пользовательский интерфейс jQuery) и предоставляют дополнительные средства манипуляции данными. У них модели данных. Kendo реализует свое собственное решение (я думаю), в то время как Wijmo и jqWidgets интегрируются с популярным нокаутом JS.

Итак, Kendo и Wijmo относятся к группе фреймворков, которые предоставляют как виджеты/элементы управления, так и некоторую модель поддержки. Существуют и другие структуры, подобные этим, которые не основаны на jQuery, например. Dojo Инструментарий. Добавьте динамическую загрузку данных, и вы получите несколько сложное веб-приложение. Что еще вы можете пожелать?

Собственно, самое главное забывается - как вы структурируете свое приложение? Если вы попытаетесь создать одностраничное приложение, которое взаимодействует с сервером с помощью RESTful, то вы скоро столкнетесь с беспорядком, если ваше приложение не имеет архитектуры. Обычно для этого требуются функции разделения (MVC, MVVM), шаблоны, маршрутизация и управление модулем. Здесь SproutCore и Sencha. Они предоставляют комплексное решение для создания веб-приложений, где виджеты - всего лишь небольшая часть.

Может показаться, что SproutCore и Sencha являются победителями здесь, потому что они являются самыми полными решениями, которые включают в себя как пользовательский интерфейс, так и бизнес-логику, а также структурируют ваше приложение. Несмотря на все плюсы, есть некоторые минусы. Некоторые говорят, что они слишком тяжелы или потребуют придерживаться своей модели развития, что вам может не понравиться. Например, в Sencha вы описываете свой графический интерфейс в JavaScript и используете систему типа Sencha. Это добавляет какое-то тяжелое чувство, что есть абстракции и обертки, в то время как вам действительно нравится легкость HTML, CSS и ванильный JavaScript.

Но это не единственный способ. Власть Интернета заключается в том, что существует множество фреймворков, библиотек, инструментов, меньше и более крупных, что поможет вам создать свое приложение как вам это нравится. Например, рассмотрите AngularJS. Он не предоставляет набор элементов управления самостоятельно, но в сочетании с Twitter Bootstrap становится полным решением для RIA. Или, например, посмотрите EmberJS, более легкую основу от парня, который создал супертяжелый SproutCore. Он также не предоставляет вам набор виджетов, но, на мой взгляд, очень хорошая база для приложения.

Итак, вот моя последняя мысль, а не заключение. Все эти рамки обычно показывают вам свой набор виджета, красивые темы и другие визуальные материалы. Но действительно важно, как вы на самом деле будете разрабатывать свое приложение, как вы его структурируете, где вы будете реализовывать свою логику. Узнайте, что обеспечивает инфраструктура, и подумайте, можете ли вы заменить то, что отсутствует.

Ответ 2

Ответ Infeligo на высшем уровне. Мой опыт может представлять интерес для некоторых. Я использую Ruby on Rails в качестве моей серверной платформы, где находится основная часть моей бизнес-логики.

На переднем конце я использую dHTMLX, который является JS-библиотекой "объектов", наиболее мощным из которых является их объект сетки. Большинство моих приложений имеют требования к обработке/отображению деловой/бухгалтерской информации, а объект сетки - мой основной компонент. Однако их набор объектов является всеобъемлющим, включая возможность создания дополнительных "окон" в одном приложении для предоставления интерфейсу типа MDI для конечного пользователя. Обычно у меня есть форма входа в систему, которая при успешном применении открывает одну страницу HTML с меню вверху. На основе выбора из меню открываются и закрываются новые окна для отображения/управления информацией. Эти окна находятся в пределах одной HTML-страницы.

Все объекты имеют очень хорошие события, связанные с ними, и я делаю довольно много проверки на лицевой стороне, используя эти события. Однако я обычно дублирую всю проверку данных в модели Rails. Это дополнительная работа, но я просто осторожна. Существует также ряд абстрактных объектов, которые помогают подключать данные между визуальными объектами переднего конца, например. сетью и сервером back end. Большинство соединений с данными можно выполнить с помощью XML или JSON. Я использую XML над JSON просто из-за моего опыта работы с этой структурой и того факта, что Rails предоставляет достойный XML-конструктор. Поэтому в моем случае я редко использую любые представления на основе Rails, поскольку все мои визуальные объекты поступают из dHTMLX.

Другим, что мне нравится в dHTMLX, является скорость их объектов. Например, объект сетки будет легко обрабатывать более 10 000 строк на очень приемлемых скоростях.

БОЛЬШОЙ СКАЧИВАНИЕ пакета - это документация. Компания является разработчиком в Восточной Европе, и поэтому часто трудно понять, что означает их документация. Кроме того, их документация имеет тенденцию не документировать все полностью, и поэтому много времени тратится в процессе обучения проб и ошибок.

Надеюсь, что это поможет