Dojo Framework

[recoder]

Вялотекущие архитектурные изыскания вышли в стадию активного прототипирования клиентской части. Очень хотелось найти JS-фреймворк, одновременно предоставляющий достаточный уровень абстракции над DOM, единообразную поддержку разных событий, средства моделирования данных (чтобы не возиться с прикручиванием Backbone, Knockout и прочих), инструменты для разработки UI-компонент и обладающую уже готовым набором этих компонент. Искать пришлось довольно долго.

Довольно быстро с дистанции сошли SproutCore (который теперь Ember), Qooxdoo, dHTMLx, SmartClient, Rico. Туда же пошли монстры вроде AppCraft.

В финал вышли: jQuery UI, ExtJS, Dojo и YUI3. Отбросил YUI3, потому что где будет Yahoo даже через полгода - совсем непонятно, плюс даже третья версия показывает признаки старости. jQuery UI выглядел неплохо, но разработка его как целого тулкита у меня вызывает лёгкое недоумение (они там похоже простое дерево третий год пишут). ExtJS, особенно четвёртая его инкарнация, очень хорош, однако его лицензионные заморочки настораживают даже меня (а что скажут юристы?!). И остался Dojo Toolkit.

Пристальное изучение самого свежего Dojo 1.7 показало, что это офигенный фреймворк, незаслуженно обделённый вниманием в интернетах. Поначалу конечно подсознательно сравниваешь его с jQuery и огорчаешься от необходимости писать столько много буковок. Но когда понимаешь, что приобретаешь за такую небольшую цену - приходит настоящее счастье. Итак, что мы имеем в бонусах?

1. Продуманную модульность с асинхронной загрузкой (AMD-compliant). Есть компактное микро-ядро, которое умеет грамотно подгружать всё остальное, разрешая зависимости на лету.
2. Неплохой инструментарий для работы с DOM. Конечно всё не так изящно, как в jQuery, но привыкнуть можно. Можно делать запросы селекторами и скармливать результаты итераторам и прочим map'ам и reduce'ам. (Для фанатов - есть всякая продвинутая функциональщина.)
3. Полная модель событий. На элементах поддерживаются как DOM-события, так и свои собственные. Плюс есть глобальный механизм pub/sub по именованным топикам.
4. Есть средства моделирования данных (data stores) с набором готовых хранилищ поддерживающих JSON, CSV, OPML, YQL, RDF и др. Хранилища умеют интегрироваться с другими компонентами, вроде таблиц или графиков, обеспечивая живое обновление на лету.
5. В Dojo имеется удобный механизм для создания независимых виджетов ("dijits") и в комплекте поставляются десятки уже готовых виджетов разной степени завершённости: средства layout'a, диалоговые окна, продвинутые формы, многофункциональные таблицы и деревья, всяческие менюшки, графики, карты и многое-многое другое.
6. Графическая подсистема с поддержкой анимации. Помимо кросс-браузерной поддержки векторной графики, в Dojo есть и весьма обширная библиотека диаграммных компонент вполне на уровне лучших платных JS-библиотек. Те, кому вдруг не хватит встроенных средств визуализации, смогут легко дополнить библиотеку своими собственными модулями - это довольно несложно.
7. Есть методология поддержки тем оформления - как для виджетов, так и для диаграмм, с возможностью подменять темы на лету.
8. Заявлена поддержка мобильных интерфейсов - для клиентов на iOS, Android и Blackberry. Пока не тестировал, но хочется верить что поддержка достойная.

Есть в Dojo и ещё одна крайне любопытная фича - декларативный стиль создания страниц. Работает это так: в заголовке страницы указывается флаг для подключения dojo-парсера, а затем в теле страницы создаются теги которые на лету будут заменяться на виджеты согласно свойствам описанным в атрибутах тегов (как раз в HTML5 не так давно узаконили data attributes).

Надо заметить что во всей этой бочке мёда имеется и ложка говна дёгтя. Мне кажется, что проблемы проистекают из того что это проект, создаваемый программистами для программистов. Соответственно первая проблема - это непостоянство API. Вероятность того, что найденный в интернетах пример на Dojo заработает на классах 1.7 с первого раза - мягко говоря невысокая. Где-то просто поменялись аргументы, где-то классы переехали между namespaces, а где-то и просто нет обратной совместимости. Показательно: берём примеры с официального сайта из раздела tutorials, запускаем их и видим в JS-консольке предупреждения о deprecations. То есть как только выйдет обещаемая версия Dojo 2.0 - нас опять будут ждать весёлые времена. И сюда же примыкает вторая громадная проблема - отсутствие внятной документации. Вероятность обнаружить полную документацию по, скажем, аргументам конструктора класса из dojox.*, стремится к нулю. На официальном сайте иногда можно найти примеры использования классов, иногда - подробный tutorial, но как правило страница документации содержит стандартное "class Foo наследуется от FooBase, создаётся foo = new Foo и делает Foo". То есть пользоваться Dojo без тщательного изучение всех исходников - скорее всего не получится. Насколько это плохо - придётся решать каждому девелоперу самому. Лично я пока ещё в глубоких раздумьях.

Вообще, похоже что Dojo - проект с трудной судьбой, ведущий свою историю с лохматого 2004 года. Так что пишется он давно, в разработчиках в разное время засветились IBM, AOL, Sun и другие конторки помельче. Однако, похоже что пару раз в процессе развития им приходилось отказываться от совместимости назад, что не добавляло популярности. А в районе 2008 года их чуть было не запинал jQuery, но ребята нашли силы и средства дать отпор. И, хочется верить, продолжат движение вперёд. Дополнительную надежду даёт наличие в разработчиках нашего бородатого дядьки по имени Eugene Lazutkin. :)

Резюмируя, в общем Dojo мне понравился и, если не наткнусь на что-то совершенно фатальное, буду строить UI именно на нём. Если у кого будут вопросы по Dojo - приходите обсуждать на ХэшКод или на StackOverflow.

Comments

[bamsic.livejournal.com]

jQuery UI выглядел неплохо, но разработка его как целого тулкита у меня вызывает лёгкое недоумение

- там же, вроде, тоже есть ядро и отдельные блоки, только набирать нужно самому.

[vanxant.livejournal.com]

Спасибо за наводку, ознакомился. Ну точнее, посмотрел примеры кода из туториалов - этого обычно достаточно, чтобы оценить предлагаемый coding style.
Увы, моя душа уже развращена нокаутом, так что - нет. Dojo это прошлый век.

Возьмем типичный пример. Допустим, нужно нарисовать некую табличку (грид) с фильтрами и сортировками. Данные для этой таблички динамически запрашиваются ajax-ом с сервера в виде json. Юзер может что-то в этой табличке поправить, соответственно нужно сохранять изменения всё тем же ajax-ом c json-ом через новомодный REST.

На первый взгляд, в Dojo всё здорово. Есть навороченный Grid со всеми свистелками и перделками, есть хранилище (store), в котором лежат данные таблицы в виде почти обычных js-объектов. Грид умеет самостоятельно обновляться при изменению объектов в хранилище и наоборот. Кроме того, в Dojo есть хранилище JsonREST, которое умеет само синхронизироваться с сервером при помощи json и REST. Казалось бы, красота - берем два готовых компонента, настраиваем, ???, PROFIT! И ни одной строчки HTML кода.

Но это только на первый взгляд.
Берём туториал, смотрим настройку грида.
Вот кусочек, отвечающий за описание одного столбца таблицы:

{ name: "Bats", field: "bats", width: "70px", cellStyles: "text-align: right;" }

Ну это нормальный стиль для программистов десктопных приложений. Но не для веба. Ну даже закроем глаза на явное указание width и стиля, будем считать что это не быдлокод, а сделано для простоты восприятия.
Но! Dojo здесь работает как прослойка с ООП-синтаксисом, которая генерирует html-код. Нафига? Зачем описывать то, что должно быть в html коде? Почему не использовать собственно html-код, как в нокауте? Сферический веб-программист в вакууме отлично знает html, css, чистый javascript. А вот библиотеку dojo - не знает, и по словам recorder-a доки есть не на всё. Вообще, каков смысл существования этой прослойки?

Дальше, про заявленные рюшки типа пейджинга, сортировки и фильтров. Грид сам этого не делает, предоставляя работать хранилищу. Это в-общем разумно. Но! Далее хранилище JsonREST этого тоже не делает, оно сбрасывает всё на сервер. А вот это уже опаньки. Дергать сервер каждый раз, когда юзер прокручивает таблицу - это за гранью. И второе - придется допиливать сервер, чтобы научить его делать пейджинг с сортировкой. Тоже не айс.

Не, ну они приводят пример таблицы со 100500 строками, и типа у них все работает. Извините ребята, но это бред. Таких таблиц не должно быть ни в вебе, ни в десктопных приложениях. Человек не способен воспринять таблицу не то что на сто тысяч строк, даже на сто уже с трудом. Ну максимум - тысяча. Дорабатывайте UI своего приложения так, чтобы таблиц длиннее 1000 строк у вас не было в принципе. Разбивайте данные по группам, по годам, давайте сводные итоги, как хотите. Оставшиеся тысячу строк должны передаваться на клиенте целиком, и их сортировкой должен заниматься клиент, а не сервер.

Это всё конечно решаемо. Можно написать своё хранилище с сортировками и собственным Json... Или перелопатить исходный код и найти, как настроить имеющийся компонент. Только желания как-то не возникает.