Следующее переиздано из Tech Times # 159 .
После моего последнего выпуска журнала «Избегание зла» JavaScript я получил много противоречивых отзывов. Это неудивительно, учитывая твердое мнение людей о доступности и его важности в Интернете.
Тем не менее, прежде чем я покажу вам несколько простых и практичных способов написания лучшего JavaScript, я хотел бы прояснить одно распространенное недоразумение, которое я обнаружил в некоторых из этих отзывов.
Сам по себе JavaScript не является злом , равно как и веб-сайты и приложения, которые обеспечивают удобное и удобное использование JavaScript. То, что я называю «злом», — это использование JavaScript таким образом, что оно лишает некоторых пользователей возможности доступа к сайту или приложению.
Как правило, это не только возможно, но и довольно практично, чтобы создать свой удобный пользовательский интерфейс на основе JavaScript на основе стандартных HTML и CSS. Эта основа позволяет доставлять контент вашего сайта не только пользователям, которые отключают JavaScript, но и в автоматизированные системы, такие как поисковые системы.
Приложив немного дополнительных усилий, вы можете даже заставить свои функции JavaScript работать с вспомогательными технологиями и работать с пользователями, работающими только с клавиатуры.
Но вещи начинают разваливаться, когда Ajax входит в картину, и пользователи начинают требовать приложений, похожих на настольные, которые это делает возможным. Зачастую статический HTML / CSS не может обеспечить полезную основу для этих приложений, и создание альтернативы, отличной от Ajax, может быть совершенно отдельным проектом, который, вероятно, нельзя оправдать затратами на разработку и сопровождение. В крайних случаях возможно, что то, что делает ваше приложение, просто не переводится в основанную на страницах модель простого HTML.
Решение этой дилеммы, на мой взгляд, состоит в том, чтобы отделить эти типы приложений от текущей веб-страницы на основе страниц и переместить их в «сеть приложений», которая столь же универсально доступна, как и сеть сейчас, но которая разработан с нуля с учетом приложений и решает все проблемы, которые в настоящее время вызваны нашими попытками внедрить настольные приложения в систему, которая была разработана для обслуживания информационных страниц.
Эта «сеть приложений» может быть такой же простой, как новый протокол URL (hatp: // для протокола передачи HyperApplication?) Или тип MIME, который будет распознаваться браузерами, и на самом деле ряд поставщиков пытались (или планируют попытка) именно так:
- Java Web Start (протокол запуска сети Java)
- Язык интерфейса пользователя XML (XUL)
- Macromedia Central
- Скоро в продаже: Adobe Apollo
- Скоро: Microsoft WPF (XAML)
Тем временем W3C также работает над этой проблемой через рабочую группу по форматам веб-приложений .
До сих пор каждая из этих инициатив не получила широкого распространения, поскольку требовала установки некоторого конкретного программного обеспечения в дополнение к веб-браузеру (в случае XUL требовался специальный веб-браузер). Если они не смогут достичь такой же повсеместности, как HTML, CSS и JavaScript, настольные приложения, маскирующиеся под веб-страницы, будут оставаться более популярным и проблематичным выбором.
Итак, в отсутствие подходящей повсеместно распространенной платформы для приложений, подобных настольным компьютерам, веб-приложения на основе Ajax-приложений подпадают под действие «злого JavaScript»? Лично я думаю, что они это делают, но в зависимости от вашей конкретной ситуации они могут быть необходимым злом.
Эволюция веб-технологий идет своим чередом, но нам, как разработчикам, нужно делать все возможное, чтобы технологии и ресурсы были в нашем распоряжении сегодня. Самое главное в моих книгах — убедиться, что вы хорошо информированы, прежде чем принять решение, которое может помешать некоторым пользователям получить доступ к вашему сайту.