Практичность разработки сайтов в которых не используется JavaScript

Одним из моих любимых хоть и не всегда практичных подходов создания сайтов является разработка с полным исключением каких-либо JS скриптов на клиенте используя только возможности HTML + CSS + SVG и других нативных браузерных технологий. Иногда для такого подхода я встречал термины "No JS" или "JS Free" но в общем насколько я знаю никакого устоявшегося определения нет поэтому далее в статье я буду называть этот подход условно "No-JS".

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

В какой-то степени No-JS подход имеет что-то общее с прогрессивным улучшением (Progressive Enhancement) и даже Graceful Degradation но тем не менее это разные по своей сути подходы. No-JS это всё-таки больше про максимальное раскрытие базовых возможностей браузеров, без использования всеобъемлющего JavaScript.

Примером применения подхода No-JS является мой сайт olegbarabanov.ru, где на клиенте не используется JavaScript. Конечно пример не самый наглядный поскольку сайтик у меня простой но в интернете можно найти намного более красочные примеры.

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

Положительные стороны No-JS подхода

Вообще No-JS подход принуждает более глубоко осваивать остальные браузерные технологии. Например независимо от того, используется JavaScript или нет, практически на всех сайтах используется классическая связка HTML + CSS и к ним опционально всякие SVG и различные специфические медиаформаты (например APNG), сложные шрифты и множество других технологий. Все эти технологии не стоят на месте и тоже по своему развиваются и обрастают новыми возможностями и это приводит к вопросу, а насколько хорошо вы знаете их текущие возможности?

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

Да и вообще современный CSS в плане гибкости и возможностей очень прогрессирует. Появление в CSS переменных, псевдокласса :has, вложенности, условных операторов (пока еще не во всех браузерах) и т.д., все это позволяет делать короткий и лаконичный код без использования JavaScript, а также расширяет применимость CSS даже там, где мог использоваться только JS. И CSS заметьте продолжает развиваться и дальше в плане возможностей.

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

Недостатки подхода No-JS

Хотя мне подход No-JS и нравится, но в нем также есть и недостатки из-за которых этот подход малоприменим в коммерческой разработке.

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

Также использование каких-то HTML+CSS трюков может как упростить, так и серьезно усложнить верстку, в сравнении с использованием простейших скриптов. И при этом эта перемудренная верстка вполне может сильно нагружать браузер, что потребует в свою очередь кропотливой работы с профилировщиком. Ну и семантика HTML-документа тоже может быть попорчена.

Но большей проблемой наверное является то, что даже если вы знаете кучу способов, как делать верстку без JS, то не факт что другие специалисты, которые потом будут поддерживать ваш код, будут также ловко знать все эти трюки с HTML/CSS/SVG/... .

Думаете каждый веб-разработчик например знает трюки с использованием скрытых <input type="checkbox" /> (или type="radio") и связанных с ними тегов <label> для создания тех же всплывающих меню? Матерые фронтендеры обычно знакомы с такими трюками, а вот фронтендеры попроще скорее всего будут смотреть на всё это как на колдовство и в случае каких-либо правок скорее побыстрому захардкодят какой-нибудь костыль, чем будут разбираться в нюансах. А там и до появления всех проблем теории разбитых окон в проекте недалеко.

В следствие этого можно сказать, что No-JS подход в чистом виде малоприменим в коммерческой разработке. Как минимум JavaScript нужен для аналитики (Yandex Metrika, Google Analytics и т.д.) что в коммерческих проектах немаловажно. Я уж молчу про то что в коммерческих сайтах наоборот стараются не ограничивать себя в инструментах, ибо заказчикам важен итоговый результат за приемлемые деньги, а то что и как там под капотом разработчики наделали их обычно мало интересует.

Перспективы No-JS

Как ни странно, но No-JS подход вполне имеет перспективы в плане применимости. И CSS и HTML и остальные браузерные технологии активно развиваются, что расширяет возможности применения No-JS подхода. И вполне может наступить момент, когда какие-то вещи, которые делались громоздко только с помощью JS, можно будет делать легко на чистом CSS или даже HTML.

Когда-то такой путь уже проходился на примере JavaScript анимаций, которые использовались повсеместно еще во времена популярности JQuery. Но потом появились CSS Transitions и CSS Animation которые были намного более производительны и со временем многие JS библиотеки стали под капотом использовать именно CSS переходы.

Почему я вспомнил пример с CSS анимациями? Лично я впервые с CSS анимациями познакомился с момента реализации их в браузере Firefox, которым тогда пользовались все веб-разработчики из-за наличия плагина Firebug. Так вот в 4-ой версии в Firefox реализовали CSS переходы которые тогда меня очень заинтересовали. Я в то время работал в одной web-студии PHP-разработчиком и в свободное время накидал несколько веселых примеров с использованием CSS переходов и CSS трансформаций, где один из примеров делал плавное переворачивание всего сайта на 360°, что в то время выглядело очень необычно. Я показал эти примеры своим коллегам но многие тогда отнеслись к этим технологиям со скептицизмом, типа зачем изучать этот уродливый CSS если вон в JQuery всё есть готовое. Но как показало время именно CSS решения в веб-разработке стали предпочтительней.

Я это рассказал к тому, что уже были ситуации, когда веб-разработчики слепо верили во всемогущество популярнейшего тогда JQuery и особо не интересовались развитием других технологий. Поэтому и сейчас, во времена обширного применения React/Vue/Angular/AlpineJS, я не удивлюсь, что со временем в HTML или CSS могут появиться новые нативные возможности которые смогут перекрыть часть функционала вышеупомянутых фреймворков.

Заключение

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

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

В качестве компромиссного решения, когда и JavaScript нужен и при этом хочется его максимально избегать, можно использовать такие решения как AlpineJS, HTMX и т.д., которые стремятся применять нативный декларативный подход. В таком случае мы с помощью этих библиотек расширяем декларативные возможности HTML/CSS/SVG для оптимального форматирования и подачи материала. При этом JavaScript будет использоваться только там, где он по своей сущности наиболее оптимален, как например для реализации бизнес-логики или для интерактивного взаимодействии с другими устройствами и серверами. На мой взгляд это вполне оптимальный подход, который я сам постоянно использую в своей деятельности.