×Закрыть

Javascript MVC

Доброго времени суток!
На текущем проекте растет количество джаваскрипта и логики на клиентской стороне. Поэтому стал вопрос: Как это все организовывать?
На данный момент активно используется jQuery/jQueryUI, но задачу организации кода он не решает, к сожалению. Второй момет: для простого CRUD, он так же не имеет никах средств.

Какой фреймфорк (библиотеку) вы бы посоветовали для построения интерфейсов с тяжелой логикой на клиенте?
Требования:

  • скорость работы
  • удобство разработки
  • не большой размер
  • желательно интеграция с jQuery, или хотя бы не конфликтовал с ним

Посмотрел на:

  • backbone.js
  • knockout.js
  • javascriptmvc
  • еще несколько тяжеловесов
Выбрать не смог.

P.S. Юзабилити у создания тем, просто писец!

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Мы используем Knockout JS. Вам может быть интересна моя статья на Хабре о впечатлениях от него: habrahabr.ru/...ascript/124731

Кое-что изменилось в лучшую сторону, поэтому большая часть моих нареканий к Knockout уже не актуальна. Появились плагины, существенно дополняющие фреймворк именно в узких местах:
— аналог Backbone Models (RESTful Sync)
— поддержка Underscore для коллекций Нокаута

— интеграция с jQuery UI

Мы их пока еще не используем, но присматриваемся — Knockout Models у нас на очереди. Выбором своим более чем довольны.

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

Backbone дает вашему проекту больше структуры, но привязка к UI руками меня оттолкннула. Есть плагин github.com/...ne.modelbinding который позволяет делать байндинги в Нокаут-стиле, но список возможностей там очень скромный.

Вот эти самые декларативные связи и пугают, уж очень похоже не «черную магию» (сюда же поддержка в разных ИДЕ, в моем случае ИДЕА).

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

А если подобные связи не писать декларативно, то получится супчик из if-ов, в котором без бутылки не разберешься. Сам использую WebStorm — осложнений в связи с использованием Нокаута не заметил.

Отлаживаю я только средствами браузеров — как настроить дебаггер в ИДЕ для Джаваскрипта для меня так и остается загадкой. Пользуюсь в основном Chrome Dev Tools — там можно автоформатировать код, нагенерированный Нокаутом для байндингов, и ставить брейкпоинты на события. Затем IE f12 и Firebug с Dragonfly по необходимости.

Вообще, ошибки в байндингах приводят к нормальному сообщению от фреймворка, мол, такого-то метода в объекте нет, например. Они возникают первое время, но потом сходят на нет. При этом из-за того, что есть нормальное сообщение и нормальный стектрейс, исправлять их — минутное дело. По сложности исправления сравнимы с обычными TypeError или ReferenceError в JavaScript.

Большие условия вы все равно внутри data-bind-атрибутов писать не будете — некрасиво и мейнтейнить неудобно. Оборачивайте сложные условия в dependentObservable — и будет вам счастье: и привязка поведения к элементам простая, и условия все сгруппированы в коде, который вам ИДЕ подсветит и дебаггер из коробки найдет.

Если все еще есть опасения, то лучше Backbone — спокойствие разработчика дороже всяких удобств. Он никуда не денется — им, как мне кажется, сейчас больше людей пользуется, чем Нокаутом или jMVC.

Я в ближайшую неделю-две напишу еще одну статью по Ko на Хабр: набралось еще материала и еще опыта. Если время проекта терпит, можете подождать. Жаль, что мы с вами в разных городах, а то просто встретились бы — я вам все по быстренькому рассказал да показал.

Можно обойтись без МВЦ, не усложняя себе жизнь допущениями фреймворков.
Подход можно назвать «Менеджер — Блок — Виджет»
Менеджер — страница задач TaskManager.js — конфигурирует и создает блоки
Блок — например, форма добавления задачи TaskForm.js

Виджет — используется в блоках и где угодно (это джквери уи)

Связи между блоками и менеджеров посредством агрегации и колбеков. Если интерфейс сложный и иерархия связей сильно увеличивается, тогда используем pub/sub (глобальные события).

Я такую методику успешно использую не один год, на этом сайте (ДОУ) именно так реализованы джсы.

в моем случае это скорее Java-приложение с навороченными страницами.

Попробуйте посмотреть в сторону GWT.

задачу организации кода

решит MVP

с тяжелой логикой на клиенте

логику с клиента теоретически можно с легкостью перенести на сервер с помощью RPC например

логику с клиента теоретически можно с легкостью перенести на сервер с помощью RPC например

Приложение работает Интернет, а не за фаерволом. Поэтому ганять данные с/на сервер «по каждому чиху» не хотелось бы.

Попробуйте посмотреть в сторону GWT.

Смотрели (не пробовали, а смотрели, слушали, читали). Не понравилось. Основные проблемы:
— сложность в дизайне. Сложно подогнать вид компонента под текущий дизайн.
— сложности вызова уже написанных джавсриптов и вызова из джавасрипта ГВТ-сгенерированного кода. Это важно так как приложение уже давно как не новое.
— сложности при обновлении версии ГВТ.

Было бы интересно услышать ваш опыт использования.

решит MVP

Могли бы вы раскрыть свою мысль?

Насколько я понял из интернетов и по рассказам знакомых:
backbone.js сейчас мейнстрим, но есть несколько но:
1) по слухам сильно усложняет сотрудничество с дизайнерами, если я правильно понял, там даже нет интеграции с клиентсайд шаблонизатором (но могу ошибаться)

2) он больше для SPA, а в моем случае это скорее Java-приложение с навороченными страницами. Как вы считаете, его можно использовать в таких условиях?

ExtJS. В версиях 4.х можно делать mvc и по файловой структуре, но он сильно сырой, я например сейчас предпочитаю пока строить на 3.4 версии, получается всё, что необходимо.

Единственное, может не подойти по лицензии, у них их 2.

С лицензией и правду может быть муть, ибо контора продает инсталяции.

Второй момент: Екст уж очень тяжелый. По факту будет 2 фреймворка — Екст и джКвери.

В версиях 4.х можно делать mvc и по файловой структуре, но он сильно сырой

Как на ваш взгляд, когда он станет «готовым к промышленному использованию»?

Как на ваш взгляд, когда он станет «готовым к промышленному использованию»?
Год-два, если всё будет идти нормально
Екст уж очень тяжелый. По факту будет 2 фреймворка — Екст и джКвери.
Тяжесть стоит его, сам с jquery использовал, потом стал без jquery.

Тяжелый.
Он уже готов к промышленному использованию. Мы им пользуемся и всё работает прекрасно ;)

На счет сырости 4й версии — 100%. Именно с ней сейчас работают коллеги по проекту — веселостей хватает. С 3м никаких больших проблем не наблюдалось.

На счет лицензий. Никаких проблем или вопросов с лицензией у нашего заказчика никогда небыло. Купил — спи спокойно.

Вот еще презентация кажется по теме:

addyosmani.com/...pparchitecture

Спасибо, интересная презентация, хоть и досмотрел только до половины :)

Сам не пишу на Javascript, но друзья лестно отзывались об AngularJS angularjs.org

Единственное что пугает: Оно, вроде, рассчитано на то что их XML компилируется в HTML. Или я что-то не так понял?

Как я понимаю, xml расширяет возможности.Вот тут создатель отписывался: www.quora.com/...bone-js-compare

Подписаться на комментарии