Должен ли сайт работать без JavaScript?

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

Сам вопрос стоит пересмотреть. Почему мы говорим о том, чтобы сайты работали именно таким образом? Должны ли наши сайты работать без HTML? Должны ли наши сайты работать без баз данных? Возможно, мы больше всего нацелены на JavaScript, потому что JavaScript стал самым значительным узким местом в веб-производительности (даже в большей степени, чем условия сети!), и нас волнует сбой JavaScript больше, чем любой другой тип сбоев (за исключением, возможно, когда не загружается весь сайт) (или иконки шрифтов, господи).

Я с улыбкой наблюдаю всю эту неразбериху вокруг терминологии «веб-приложения» и «веб-сайты». Это так странно. Ведь так легко представить себе разницу: это как Facebook или блог! Но когда вы начинаете пытаться определить ее точно, все становится очень расплывчатым, и различие теряет любое значение, если оно начинало имело смысл.

Доступность, безусловно, присутствует во всех разговорах о сети, но, вероятно, она не может быть широко применена здесь. Существует мнение, что вспомогательные технологии не запускают JavaScript, поэтому сайт, для которого требуется JavaScript, для этих пользователей на 100% не будет работать. Насколько я знаю, это уже совсем не так. Мы можем до смерти спорить о роли JavaScript в проблемах доступности, но только тот факт, что для запуска конкретного сайта требуется JavaScript, сам по себе не делает сайт недоступным.

Достаточно легко отключить JavaScript, просмотреть веб-страницы, найти неработающие вещи и исправлять их. Но этот сайт или его функция можно спроектировать так, чтобы работать без JavaScript. Правило наименьшего сопротивления. Это сложно. Легко не заботиться о человеке, который намеренно отключил часть веб-браузера и все еще хочет, чтобы все работало. Меня это не волнует. Но аспект устойчивости более интересен. Если вы создаете часть сайта так, чтобы она работала без JavaScript, она будет работать как до, так и после того, как JavaScript выполняет, что довольно здорово.

Концепция построения функционального контента и функций без JavaScript и улучшения работы с помощью JavaScript называется прогрессивным улучшением. Я и фанат, и в то же время скептик того, что все на земле всегда должно быть построено таким образом (см. пункт выше). Существуют ситуации, когда прогрессивное улучшение увеличивает и уменьшает техническую сложность. Единственный общий момент — я бы сказал, что это стоит делать это, пока сложность не станет слишком высокой.

Существует промежуточный момент с прогрессивным улучшением. Если функция работает без JavaScript, это означает, что, скорее всего, вы откладываете загрузку этого JavaScript для повышения производительности. Но это в конечном итоге должно быть загружено и выполнено. Что происходит за это время? Есть производительность и затраты UX. В лучшем случае они ничтожно малы. В худшем случае вы нарушаете функцию в это промежуточное время.

Я нахожу более интересным обсуждать подобные вещи на индивидуальной основе. Голотипы приложений могут быть интересным способом для этого. Часто ссылаются в качестве примера на Slack, который является идеальным выбором. Как бы вы создали сайт с обзором фильмов из 20 авторов? Как бы вы разработали социальный и медиа-сайт, такой как Dribbble? Как бы вы создали выпадающее меню навигацию? А как насчет сайта на одну страницу, где клиенту нужен параллакс? Как насчет приложения для авиакомпаний, которому также необходимо встроенное мобильное приложение? И, конечно, это заставляет вас думать о сайтах, над которыми вы работаете. Работает ли CodePen на правильном наборе технологий? А CSS-Tricks?

Если сайт «отображается на стороне клиента» (CSR), это означает, что JavaScript выполняет выборку данных, создает DOM и все такое. Если мы говорим о веб-сайтах, «работающих» или не работающих с JavaScript или без него, то сайт, отображаемый на стороне клиента, на 100% не будет работать без JavaScript. Это своего рода противоположность «рендеринга на стороне сервера» (SSR), когда документ передается в виде HTML прямо с сервера. SSR почти наверняка быстрее для первой загрузки. CSR, как правило, быстрее при навигации по сайту после загрузки (например, «одностраничное приложение» или SPA).

Это не просто выбор между SSR и CSR — здесь целый спектр. Все чаще и чаще можно увидеть, как сайты пытаются использовать лучшее из обоих миров. Например, Next/Nuxt/Gatsby, или быструю загрузку Ember.

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