Основы пользовательского интерфейса на HTML5 [закрыт]


Я нашел там много фреймворков HTML5 UI, таких как:

Я вроде как перегружен снова столько ресурсов. Выглядели некоторые из них, но почти все казались слишком медленными и тяжеловесными.

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

как новичок в разработке веб-приложений и клиентских фреймворков JS UI; вы, ребята, основываясь на своем опыте, какой из них вы рекомендуете для быстрой разработки настольных веб-приложений с учетом скорость, коллекции виджетов, сложность, внешний вид, поддержка и т. д.?

какой из них вы рекомендуете мне начать учиться?

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

2 54

2 ответа:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

большой недостаток пакета-это документация. Компания является восточноевропейским разработчиком, и поэтому часто трудно понять, что именно означает их документация. Также их документация, как правило, не документирует все полностью, и поэтому много времени тратится на обучение методом проб и ошибок.

надеюсь, что это помогает