Любые существенные причины не использовать AJAX?

Я планирую сделать мой веб-приложение довольно AJAX тяжелым.

Прежде чем я это сделаю, мне интересно, что люди думают о таких сайтах. Есть ли существенные причины не делать этого?

Кстати, не нужно упоминать причины SEO. Кроме того, я думаю, что преимущества компенсируют тот факт, что люди без javascript будут иметь ограниченный опыт (хотя я открыт для того, чтобы быть уверенным в противном случае).

Ответы

Ответ 1

Это зависит от того, как вы планируете использовать его, IMO.

1) Если сайт будет работать без него, вы исключаете пользователей с отключенными сценариями. Я считаю, что во многих сценариях справедливо ограничить , но не удалять функциональность для пользователей no- script (например, Google не выполняет автозаполнение поисковых запросов, если у вас отключен сценарий, он не может.. но основной поиск по-прежнему работает).

2) Правильные методы необходимо использовать в нужном месте. Например, ASP.Net UpdatePanel будет работать ужасно, если вы сбросите в нее тысячи элементов.

3) Я становлюсь все большим и большим поклонником контента, загружаемого небольшими блоками на странице, которая не требует полного обновления NOR, для этого требуется, чтобы вся страница была выполнена снова. Это хорошо поддается SOA, но еще более подвержено ограничениям # 1.

4) РЕДАКТИРОВАТЬ: Не создавать элементы интерфейса, которые (из-за AJAX) ведут себя неожиданно. Например, я когда-то создал раскрывающийся список, который был заполнен только тогда, когда он был переключен. Из-за латентности и времени создания DOM она не реагировала. Кроме того, размер часто менялся в зависимости от того, какие элементы были динамически добавлены. Вы могли бы предложить способы решения этих проблем, но это все еще было неправильным использованием технологии.

Ответ 2

AJAX - это инструмент для работы. Если ваше приложение лучше всего обслуживается инструментом, используйте его.

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

Ответ 3

Очевидно, что существует много популярных сайтов, которые полагаются на AJAX, поэтому, конечно, его не следует избегать, если его использовать хорошо. Однако есть вещи, которые следует учитывать:

  • Должны ли пользователи иметь возможность глубокой ссылки (т.е. сохранять закладки на "страницы", которые были созданы динамически)? Нужно ли им использовать кнопку "Назад" для навигации? (Обе эти вещи могут быть выполнены с использованием AJAX, но они должны быть явно рассмотрены, поскольку наивные реализации AJAX могут заставить их работать плохо или вообще не работать.)
  • Будет ли использование AJAX негативно сказываться на отключенных пользователях (например, тех, кто использует программу чтения с экрана)?

Ответ 4

Это зависит от того, как вы используете AJAX. Страницы, на которых вам приходится ждать, пока страница отображается, И THEN ждут еще 10 секунд, пока скрипты выполняют и загружают фактический контент, заставляя людей сердиться. Страницы, которые быстро загружаются и хорошо работают с AJAX, конечно же, конечно.

Поисковая оптимизация - это одно, но способность находить вещи на вашем сайте - это другое. Вам нужно будет подумать о том, как Google может индексировать ваш контент. Следовательно, вам все равно придется иметь версию "простого текста", где ссылки ведут себя как ссылки.

Ответ 5

Глубокая связь может быть проблемой с тяжелыми сайтами Ajax. Есть способы обойти это (т.е. Использовать метод url-hash), но это не всегда безопасно.

Ответ 6

Вы можете сделать свой сайт AJAX основанным и до сих пор не пропустите SEO, если вы планируете заранее. Вот ссылка Google о том, как сделать ваш контент AJAX доступным.

http://code.google.com/web/ajaxcrawling/docs/getting-started.html

Ответ 7

Пользователи, которые находятся на другой стороне планеты, с ограничением скорости 3/times; 10 8 установленным физикой, найдут ваш сайт вялым и невосприимчивым, если у вас много пользовательского интерфейса взаимодействие происходит с AJAX.

Типичное время обработки пакета (в оба конца) от Новой Зеландии до Калифорнии составляет примерно 200 мс, а пользовательский интерфейс должен отвечать в течение 100 мс, чтобы не чувствовать себя вялым.