CMS - почему web-интерфейс зло

Любая программа, работающая внутри браузера, обязана принести в жертву невероятную производительность и возможности.

Пользователи требуют программное обеспечение, работающее в браузерах, потому что не знают лучших альтернатив.

Алан Купер, «Психбольница в руках пациентов»

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

Более того. Веб-интерфейс имеет все преимущества, когда может потребоваться доступ к данным хоть из интернет-кафе. Тому прекрасный пример - почта Google. Я ей сам пользуюсь только через браузер и это почему-то меня не коробит :)

Но мы рассуждаем в контексте систем управления сложным сайтом. Основной аргумент веб-интерфейса - "доступ отовсюду". Вы хорошо представляете себе менеджера, который пришел в интернет-кафе и начал заниматься обновлением товарного ассортимента на сайте из корпоративной ERP-системы ? Видимо, предварительно поставив ее на флешку. По моему - не смешно.

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

Оставим за кадром врожденную тормознутость браузера, которую никогда не вылечат ни WebKit, ни TraceMonkey, просто в силу принципиально иных задач браузеров как явления. Если вылечат - это уже будет другое явление, и не совсем браузер. Мозилла и Chrome уже делают шаги в эту сторону, кстати.

Посмотрим на возможности интерфейса с точки зрения пользователя.
Смотрим на Битрикс (лидер рынка, как к нему не относись), на Юми и на прочих, легион им имя. Я бы молчал в тряпочку, если бы эти красивые веб-интерфейсы родили новую парадигму взаимодействий пользователя-администратора с сайтом, но ведь нет ! Все, абсолютно все эти интерфейсы делают вполне убогие попытки имитировать GUI внутри окошка браузера.

Все рюшечки интерфейса не должны по полминуты грузиться с сервера, потому что ламер-настройщик забыл выставить правильные заголовки кеширования. Я не должен ждать первой загрузки экрана модуля столько, что успею попить кофейку. И не надо кричать, что у меня дохлый канал от SkyLink, скажите спасибо, что вообще не GPRS. И, наконец, модальный диалог должен быть модальным диалогом, а не новой вкладкой в Файрфоксе !!! Бредить на эту тему можно много, но караул уже устал ...

Заканчивая критику - никогда внутри браузера не удасться достичь хотя бы качественной имитации GUI с приемлемой скоростью работы. И никакие монструозные ExtJS тут не помогут. Купер был прав, и с 1999 года ни фига не поменялось. Про новую парадигму работы с сайтами тоже что-то не слышно. Наверное, мы и тут будем в авангарде, есть идейки :)

Конечно, так плохо все быть не может, у подхода с веб-интерфейсами есть масса плюсов. И коллектив не может ошибаться :) Поехали по порядку.

Плюс 1. Низкий ценз вхождения в разработку.
На сайте xhtml+css+js - и в админке то же самое. Нового учить не надо. Движок сервера - един. Все прекрасно.

Аргумет отметаем с некоторым недоумением. Господа, смотрите на XULRunner, AIR и кто там еще, Silverlight ? Про AIR не знаю, но XULRunner на начальном уровне конечно требует некоторого интеллекта, но как минимум не более ExtJS. И изучения новых невиданных технологий тоже требует в объеме 1 дня. Там тот же XML, JS, CSS, XMLHttpRequest и проч. А то, что из XULRunner можно напрямую работать с любым софтом и протоколом на уровне ОС - для начала и знать не надо. XPCOM компонеты и XBL вам понадобятся, если вы ленивы и любите повторное использование :) Уверен, что в AIR картина примерно та же.

Плюс 2. Обновление приложения сразу и для всех.
Залили код на продакшен, у всех все сразу заработало.

Да. Это важно. Если не учитывать, что и XULRunner и AIR предоставляют нативный функционал апдейтов. У вас с обновлениями Firefox и его кучи расширений часто проблемы были ? Ну, то-то ... Да, разработчику для поддержки апдейтов нужно держать свой сервер. Можно подумать, что CMS с веб-интерфейсом не нужно ... Хотя, справедливости ради, надо заметить, что при кривизне реализации в standalone можно поймать изрядные грабли. А где нельзя, при кривизне ...

Плюс 3. Наличие фреймворков.
Админку с веб-интерфейсом можно (и нужно) забацать на том же фреймворке, на котором сайт написан, и все хелперы и маны ужо есть внутри фреймворка. А как у нас со standalone, поди не так ?

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


По минусам веб-интерфейса для разработчиков пройдемся галопом. Все их и так знают.

Это необходимость кроссбраузерности. Ибо если вы кроссбраузерность не обеспечиваете - теряется исходный смысл, специальное приложение поставить не сложнее специального браузера.

Это юзабилити. Практически не лечится. Точнее, еще пока никто не вылечил :)

Это скорость работы. См. предыдущий пункт.

Это пробемы, связанные с хранением и передачей с сервера на клиент всяких состояний, настроек конкретного юзера etc. Чего будет стоить реализовать запоминание состояния "открытые-закрытые ветки каталога из 150 элементов для 3 разных менеджеров" ? Я не знаю, у меня нет этих проблем, все состояния и настройки живут на клиенте. Может, знаете вы ?

Это проблемы, возникающие при необходимости интеграции. Попробуйте из браузера залезть в корпоративную ERP по ODBC или как-нибудь еще. Да, код на сервере по команде из админки может полезть curl-ом или через сокет ... Что подразумевает открытость ERP наружу из локальной сети. Это, конечно, бывает.

Ну и всякие мелочи. Например, загрузка картинок в визивиг-редактор. Открыли файл-менеджер в админке (он еще подгрузиться должен, пользуемся им редко и в кеше его нет :), клацнули на кнопочку, ищем файл на диске, путешествуя по папкам ... А я хочу скопировать картинку на открытой страничке браузера, в редакторе нажать Ctrl+V - вуаля, картинка вставилась. Не как ссылка, как файл с моего сервера. Что ? Нельзя принципиально ? Ню-ню.


Уффффф. Продолжение следует ...