При выборе программной платформы обычно разбегаются глаза — тут такое, тут сякое и все неизменно превосходно. Не больше помогают и разного рода сравнительные матрицы — можно увидеть, что во фреймворке Х нет подключения к промышленной системе автоматического смыва воды в унитазах, но эта информация не всегда полезна.
А хочется понять, на что годится та или иная библиотека в практических применениях, хочется прочитать о чьем-нибудь опыте. А с этим не очень. Например, по ExtJS я ничего такого не нашел. Пришлось пробовать самому.
Далее следуют мои впечатления от работы на ExtJS 4.1.1. Они по определению субъективны и не претендуют на вселенские обобщения.
Итак, условия. Мне нужно написать красивый веб-интерфейс достаточно большой сложности. Очень хочется, чтобы все это выглядело приложением, а не сайтом. Приложение интранетноое, поэтому красота особенно не нужна. Пользователи гораздо больше ценят удобство и скорость своей работы, чем рюшечки, к которым за три дня привыкаешь. Еще они любят предлагать всякие изменения и очень одобряют, когда эти изменения делаются быстро. Вопрос совместимости с браузерами не стоит — будут сидеть на том, что я скажу.
Дополнительное условие — я не очень люблю возиться с веб-интерфейсом и стараюсь отделаться от этой части побыстрее.
Итак, положительные стороны ExtJS 4.1.1.
Глобально поставленной цели с ее помощью добиться можно — на ней действительно можно написать веб-приложение. Оно будет выглядеть профессионально и красиво, я бы даже сказал, роскошно. Богатый выбор элементов управления, тщательно подобранные цвета, заранее написанные стили. Достаточно сказать, что можно вообще не иметь дела ни с HTML, ни с CSS, и забыть их оба как страшный сон. Доступ к DOM в библиотеке на всякий случай есть, но я ни разу им не пользовался — все решается и так.
Приложение легко стыкуется с REST, главное, чтобы REST отдавал данные в правильном (и не особо сложном) формате. Достаточно описать только, куда ходить за данными — и вуаля. Из коробки работает весь джентльменский набор CRUD.
Практически все действия пользователя можно вынести в интерфейс и не грузить ими сервер. На долю последнего остается только дополнительная проверка правильности данных и работа с базой. Это очень его упрощает — буквально до 5-10 кб кода (nodejs, mojo — я пробовал несколько вариантов, везде получается хорошо).
Теперь о недостатках.
Он один, но глобальный — всё это, как те самые елочные игрушки, не радует. Программирование на ExtJS не только не приносит никакого удовольствия, но совсем наоборот. Это изобильный источник фрустраций, комплексов и зажимов.
Общий стиль библиотеки лучше всего передается словом «монстроподобность». Это эдакий мастодонт, в котором счет файлов с исходниками идет на десятки. При подключении страницы в браузер грузится около 6 мегабайтов всякого добра и это время весьма и весьма заметно.
Из-за жутко медленной загрузки невозможно программировать моим любимым способом, которому я научился еще от Форта — мелкими правками. Вносишь одно изменение, смотришь результат, правишь. Повторить. Так не получается — пока этот слон загрузится после каждого изменения, забываешь, что хотел сделать. Мысли уже унеслись куда-то далеко, на сочные поля зелени и белые горы с водопадами.
Учить ExtJS жутко трудно. Она огромная, непонятно с чего начинать. Учебники и книжки в основном относятся к третьей версии, а она, в свою очередь, мало похожа на версию 4, в которой почти все сделано по-другому. По этой же причине почти бесполезны форумы, ибо все, что там написано, давно устарело.
Стыдно сказать, но я банальное приложение писал с нуля почти неделю, страдая при этом резкими перепадами настроения. Мне все время хотелось биться головой об стену — непонятно было абсолютно все. Ни одну технологию я с такими страданиями не учил.
Второе приложение, впрочем, было не лучше. Чуть быстрей, но не намного.
В 4 версии ваше приложение должно быть сделано по принципу MVC. На практике это означает, что даже hello world будет состоять из десятка файлов, разложенных по нескольким разным каталогам. И прежде чем приступить к программированию любой задачи, эти файлы надо будет создать и разложить. Это не HTML, который открывается даже с пустой страницей. Ситуация напоминает профессиональных штангистов, которым, прежде чем подойти к снаряду, надо по несколько часов разминаться и разогревать мышцы.
Набор стандартный. В модели описываются ваши данные, в хранилище (Storage) — как до этих данных добраться, в видах — как все это будет выглядеть. Здесь все более-менее логично.
Контроллер типа соединяет вид с обработчиками, но на деле в четвертой версии он до ума не доведен и обычно бесполезен. Предполагается, что у вас будет глобальный контроллер для каждой сущности и совершенно невозможно с его помощью написать какой-то самодостаточный виджет, который можно было бы потом вставлять куда хочешь.
С данными тоже не все благополучно. Хранилище предполагает, что все данные всегда совершенно однородны. Можно, правда, описывать какие-то вложенные сущности на манер «один ко многим», но эти дополнительные данные только читаются — записать их нельзя, что делает всю затею бесполезной.
Описание интерфейса — это нечто. Он описывается чисто декларативно — и это плюс. Но как он описывается, господи. С помощью декларации данных Яваскрипта — а видов данных там немного, массивы да хеши. Поэтому любой экран, всего с парой контролов, — это длиннющая портянка декларативного кода, со структурами, многократно вложенными друг в друга. Искать при таких условиях, в каком месте стоит лишняя скобка — это ад. Упростить декларации невозможно — надо описывать каждый чих, полезных значений по умолчанию практически не существует.
Поэтому любое изменение интерфейса или кода, даже исправление грамматической ошибки, обязательно предполагает долгий розыск того места, где, собственно надо править. Сначала надо постараться припомнить, где же это, потом пошариться по куче вложенных каталогов, там выбрать нужный файл опять же из десятка, а в нем долго-долго рыться в коде, который из-за многократных отступов обычно уезжает черт знает куда, и при этом молиться, что вложенность не сломается.
В библиотеке есть ошибки. Не очень много, но есть. Однако из-за общей сложности они превращаются в кошмар — их невозможно никак исправить. Непонятно, от чего они происходят, непонятно, что надо изменить, непонятно, вообще в чем дело. Особенно тяжко, если это ошибки в алгоритмах верстки — тогда ты оказываешься просто с пустой страницей и непонятным сообщением в консоли.
Или пишут тебе пользователи — у нас не грузится таблица. Открываешь — и правда, не грузится. Вчера грузилась, а сегодня нет, притом, что в этом месте ты ничего не менял.
Не лучше обстоит дело и с твоими собственными ошибками. Диагностика очень часто крайне загадочна и только после пары месяцев ты начинаешь догадываться, что «undefined» где-то глубоко в недрах ExtJS означает пропущенный атрибут Store при описании выпадающего списка.
Соответственно, становится бесполезной и отладка. Твой собственный код чисто декларативный, отлаживать там нечего, а разбираться с мегабайтами кода самой библиотеке — занятие, требующее огромного мужества.
Писать собственные контролы или модифицировать старые — занятие еще то. Впрочем, если модификации не очень большие, то это делается относительно легко — наследуется старый объект и в него вносятся изменения. Обычно это самый легкий способ заставить библиотеку делать то, что тебе нужно. Но если изменений чуть больше — следует резкий скачок сложности. Из декларативных описаний мы оказывается где-то глубоко в яме со львами, ДОМом, неочевидными событиями, родительскими объектами и черт знает чем еще.
В целом, общий стиль фреймворка напоминает майкрософтовский. Легко, очень легко делать то, что заранее было предусмотрено авторами, но шаг влево, шаг вправо — сразу расстрел.
Исходя из всего вышесказанного, в своем следующем проекте (а у меня их много разных) я все-таки для интерфейса попробую что-нибудь другое.
Автор: gatoazul
