Почему Javascript в качестве зависимости — это нормально

Пару дней назад моя лента в Твиттере загорелась дебатами о Progressive Enhancement и, в частности, о том, должны ли веб-сайты работать без JS или нет.

Сегодня я хотел бы поделиться с вами парой мыслей и идей по этому вопросу, которые уже давно крутились у меня в голове.

TL;DR: Javascript как зависимость — это хорошо, и иногда отказ от поддержки пользователей, не использующих JS, является достойным компромиссом.

Что такое прогрессивное улучшение?

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

Маяк

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

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

Однако многие разработчики доводят это до крайности, говоря, что «любой веб-сайт должен работать без JS» (включая сложные веб-приложения, такие как Facebook). В то время как многие другие, кажется, думают, что мы должны полностью отказаться от Progressive Enhancement и игнорировать те случаи, когда Javascript дает сбой, а пользователей встречают только с пустым экраном.

Оказывается, это не так просто, как бинарный выбор.

Помните, для кого вы строите

Цитирую себя: «Прагматизм (не путать с простым плохим кодом) всегда должен брать верх над идеализмом. В конце концов, мы создаем не для себя, а для пользователей и бизнеса».

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

«Я твердо верю в прогрессивное улучшение, но также и в то, что на каждом этапе улучшения нужен пользователь».

Джейк Арчибальд

Доступность

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

Помимо меток и нескольких других простых фрагментов кода, большинству расширенных ARIA компонентов требуется Javascript для правильного доступа к вспомогательным технологиям (таким как программы чтения с экрана). Например: HTML и CSS недостаточно для обеспечения надлежащей функциональности клавиатуры или сообщения сжатых/расширенных состояний.

Разделение интересов

Нет смысла заменять сплошной Javascript на CSS-хаки. Особенно учитывая, что с CSS также возникают кросс-браузерные проблемы.

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

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

Представление

Большинство веб-сайтов, основанных на содержании, по-прежнему могут извлечь выгоду из подхода «начните с HTML, затем постепенно добавляйте CSS и Javascript». В конце концов, вам не нужен JS, чтобы сделать содержимое вашего небольшого блога или маркетингового веб-сайта доступным для браузера.

Однако веб-приложения — это совсем другая история.

Такие модели, как сначала оффлайн и архитектура оболочки приложения, теперь дают нам возможность создавать надежные приложения с действительно хорошей производительностью. Это особенно важно для пользователей с медленным, ненадежным и прерывистым интернет-соединением (в основном в развивающихся странах).

Единственным недостатком является то, что эти модели часто трудно «постепенно улучшать», что делает практически невозможным доступ к основным функциям без Javascript. Да, это было бы идеально. Нет, это не всегда возможно.

Теперь вы сталкиваетесь с выбором: либо отказаться от поддержки пользователей, не использующих js, либо предоставить разочаровывающий, некачественный опыт для пользователей с лживым Wi-Fi и медленным сетевым подключением.

Согласно исследованию, проведенному Yahoo! в 2010 году от 0,25% (Бразилия) до 2% (США) людей в Интернете отключили JavaScript.

Рейтинг Akamai за 3 квартал 2015 года включает 16 стран со средней скоростью интернет-соединения менее 5 Мбит/с. Сюда входит Китай со средней скоростью 3,7 Мбит/с, что составляет около 22% от общей численности интернет-пользователей.

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

Последние мысли

  • Это не бинарный выбор. На этот вопрос нет простого ответа.
  • Оставайтесь прагматичными. Помните, что каждому усовершенствованию нужен пользователь. Если нет пользователя, то и смысла нет.
  • Не делайте Javascript большей зависимостью, чем нужно, но и не избегайте его. Javascript может быть потрясающим для доступности и производительности.

Дальнейшее чтение

Понравилась эта статья? 👏🏻 чтобы его прочитало больше людей (или Наймите меня 🔥)