Ошибки при работе с Ajax

Мой перевод заметок Alex Bosworth.

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

Этот список скопирован из моего блога: Alex Bosworth’s Weblog: Ajax Mistakes

Не согласны? Имеете вашу собственную ошибку? Этот документ имеет общую страницу @ SWiK.net

Так же посетите wiki страницу places to use Ajax

Комментарии в моем блоге.

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

Кнопка «Назад» – огромная функциональная возможность стандартного пользовательского интерфейса веб-сайта. К сожалению, она плохо работает с JavaScript. Сохранение функциональности кнопки «Назад» – главная причина не делать веб-приложение только на JavaScript.

Если я кликаю по кнопке с Ajax функциями, вы должны дать мне визуальный сигнал, что что-то происходит. Пример этого – кнопка загрузки GMail сверху справа. Всякий раз, когда я делаю что-нибудь в GMail, маленький красный прямоугольник в верхнем правом углу показывает, что страница загружается. Он замещает стандартную функцию пользовательского интерфейса браузера – отображение процесса загрузки новой страницы, т.к. Ajax этого не поддерживает.

Так как границы веб-приложений раздвигаются все шире и шире, вскоре все приложения переместятся в веб. Инициализация, подготовка к работе – лучше, всемирная модель доступа – это здорово, эксплуатация и конфигурация – классная, изучение пользовательского интерфейса – проще и короче.
Тем не менее, с новым поколением Ajax приложений, люди, имеющие нестабильное соединение с Интернетом, или люди, которые не хотят переходить на веб-приложения, должны быть оснащены также хорошо. То, что технология передовая, не означает, что люди готовы и желают работать с ней. При проектировании веб-приложений, в крайнем случае, надо предполагать оффлайн доступ. У GMail это POP, Backpackit имеет интеграцию с SMS. В Enterprise, это веб-сервисы.

Со вкладками FireFoxа я могу управлять различным задержками на веб-сайтах и обычно я вынужден ждать только загрузки страницы. В случае приложения AJAX и плохого сетевой соединения / узкой полосы пропускания / большой задержки я могу получить действительно ужасное время взаимодействия с интерфейсом, потому что каждый раз, когда я что-либо делаю, я должен ждать ответа сервера. Помоги мне Боже, если я должен обратиться к диску сервера, прежде чем продолжить. Такие приложения могут даже заставить меня думать, что Ajax это не круто.

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

Создание Ajax приложений – это кросс-платформенная разработка. Код Ajax выполняется JavaScript-движком IE, Rhino JavaScript-движок мозиллы), или другим, менее популярным двигателем, который может стать популярным. То есть, соответствия только со стандартным JavaScript недостаточно, необходимо тестирование для большинства приложений. Большая трудность создания хорошего Javascript кода – глючность реализации JavaScript в IE, хотя есть утилиты для облегчения разработки JavaScript IE кода.

Ajax представляет возможность сделать JavaScript приложения более интересными, к сожалению, «интересными» часто означает больше выполняющегося кода. Больше кода – больше работы для браузера, а это значит, особенно для некоторых плохо написанных скриптов, что вам нужен более производительный центральный процессор, чтобы функциональность оставалось «живой». Производительность CPU раньше действительно была ограничением функциональности JavaScript, и то, что компьютеры стали быстрее, не означает, что проблема исчезла.

Согласно статистике использования браузеров W3C, которая в любом случае имеет наклон в сторону популярных браузеров, у 11 % всех посетителей нет JavaScript. Так что если ваше приложение полностью зависит от JavaScript, вы сразу же теряете десятую часть вашей аудитории.

Главная ошибка, которую легко сделать, используя Ajax: ‘щелкни по этой непонятной штуке и получи неочевидный результат’. Конечно, пользователи, которые используют приложение некоторое время могут выучить, что если по этой области кликнуть и удерживать кнопку нажатой, то эту область можно перетащить и оставить на новом месте. Но пока эта возможность не станет общей для большинства пользователей, вы увеличите сложность и время на изучение
вашего приложения, а это большой минус для любого приложения.

Как я заметил в предыдущей записи, приложения Ajax создают множество проблем для пользователей, который полагают, что GET операции не меняют состояние приложения. Зависимость состояния приложения от ссылки проблема не только для роботов, но и для пользователей, которые привыкли к навигации по ссылкам – они будут озадачены тем, что ссылки используются для смены состояния.

Первая буква А в Ajax означает асинхронный. Проблема асинхронных сообщений в том, что можно вполне сбиться с толку, когда они вдруг неожиданно выскакивают. Изменения на асинхронной странице должны происходить в строго определенном месте, и они должны быть ожидаемы. Вспыхивающие и мигающие сообщения, на которых я не хочу концентрироваться, напоминают о html тэге «blink».

Другая великолепная возможность веб-сайтов – я могу передать ссылки другим людям, и они увидят то же, что смотрю я. Ещё я могу сохранить адрес в закладках и позже вернуться к нему. JavaScript, и приложения Ajax, могут создать множество проблем при такой схеме использования. Как только JavaScript начинает динамически генерировать страницу вместо сервера, адрес не может больше использоваться для навигации. Очень нежелательно терять такую возможность, и многие Ajax приложения имеют специально сконструированные ссылки, чтобы избежать этого.

Так как Ajax/JavaScriptдает вам особенный контроль над содержанием страницы, то можно легко сфокусироваться на одной области страницы и совсем забыть об общей картине. Например заголовок на Backpackit. Если вы меняете заголовок страницы Backpackit, он немедленно заменяется в правой части страницы, но не меняется главный заголовок (тег title). При работе с Ajax вы должны думать о целой картине, даже когда делаете локальные изменения.

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

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

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