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

Этот кризис влияет на платформы, творцов и потребителей.

Я попытаюсь немного проанализировать и диагностировать эту ситуацию. Если вы хотите просто прочитать мою обывательскую, непрофессиональную речь о необходимости перезагрузки веба, то можете пропустить эту часть. Идея заключается в том, что мы можем выбрать новый облегчённый (markdown) формат разметки на замену HTML и CSS, разделить веб на веб документов и приложений, вернув себе скорость, доступность и интересность сети.

В этом посте используется педантическое определение веба. Несколько раз я уже рассказывал о попытках повторного изобретения Интернета. Такие проекты, как dat, IPFS и arweave были задуманы для изобретения заново Интернета или его транспортного слоя и слоя передачи данных. Веб это то, что находится поверх этих слоёв: HTML, CSS, URL, JavaScript, работа в браузерах.

Крушение платформ

На прошлой неделе произошло важное изменение со стороны платформ организация Mozilla уволила 250 сотрудников и заявила, что это повлияет на разработку Firefox. Браузер Firefox не был вторым по популярности им является Safari, в основном из-за подневольной аудитории владельцев iPhone и iPad. Однако он был самым популярным браузером, который люди выбирали.


График с сайта statcounter

Настоящим победителем стал не сам Chrome, а движок Chrome. Одна кодовая база KHTML разделилась на WebKit (Safari) и Blink (Chrome, Microsoft Edge, Opera и т.д.)

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

Специализации и реализации

Веб эволюционировал благодаря комбинированию спецификаций и реализаций. Такие организации, как WHATWG, W3C и IETF были пространствами для сотрудничества независимых разработчиков, корпораций и учёных в области обсуждения потенциала новых возможностей веба. Браузеры тестировали их идеи на множестве разных реализаций.

Это было интересной частью структуры: такая система гарантировала всем нам, что можно развиваться вместе, и что одной из наших целей является возможность вносить вклад в веб для множества участников. Нас расстраивало, когда на caniuse появлялись пустые ячейки, однако в целом идея заключалась в том, что даже если разные браузеры могут быть лучшими в разных аспектах, рано или поздно они друг друга догоняют. Chrome не был первым браузером, который начал вводить новые возможности и оптимизации.

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

Мне кажется, лучше всего это сформулировал Майк Хили:

Вам не кажется, что веб практически монополизирован с точки зрения сложности, если движки рендеринга для него способы создавать только одна-две организации?

Сегодня не только почти невозможно создать новый браузер с нуля если вы всё-таки этого добьётесь, необходимость постоянной гонки за реализацией новых стандартов потребует целого коллектива специалистов. Об этом можно прочитать в статье Дрю Деволта Web browsers need to stop (Веб-браузерам нужно остановиться); также рекомендую прочитать и другие его материалы.

Проблема для творцов

Для веба стало намного сложнее разрабатывать.

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

Лучший способ войти в веб-разработку в 2020 году это выбрать нишу, например Vue.js или React, и надеяться на то, что в команде есть специалист по CSS и доступности.

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

Проблема для потребителей

Мы надеемся, что все инновации создаются ради пользователя, но часто это не так. Похоже, что современные веб-сайты самые большие, медленные и забагованные за всю историю веба. Наши компьютеры почти не становятся быстрее, а скорости Интернет-подключений стагнируют (даже не пытайтесь сказать что-нибудь о 5G). Рост размера веб-страниц обгоняет рост всех остальных параметров.

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

Но я не хочу во всём винить этих веб-разработчиков. Могу поделиться довольно забавной историей с моего прежнего места работы. Мы собирали данные о взаимодействии пользователей с сайтами, чтобы отвечать на простые вопросы типа для загрузки файлов на сервер люди щёлкают на кнопку или пользуются drag & drop? Поэтому мы использовали Segment инструмент, позволяющий при помощи простого скрипта добавлять конвейеры сбора данных. Однако проблема заключалась в том, что у Segment была огромная страница с сотнями поставщиков данных и компаний, занимающихся рекламными технологиями. И, разумеется, те ребята, которые в компании занимаются бизнесом, начали нажимать на все эти кнопки.

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

Возврат к простоте

Невозможно прийти к простой системе, добавляя простоту к сложной системе. Ричард О'Киф

Куда же нам двигаться дальше? Самые умные люди предлагают устроить пересмотр версий веба.

Как же нам сделать веб интересным, удобным для совместного творчества и хорошим?

Во-первых, я подумал, что существуют два веба:

Веб документов

Есть веб документов: блоги, новости, Википедия, Twitter, Facebook. Насколько я понимаю, по сути, это тот веб, каким он виделся изначально (мне тогда было два года). CSS, который мы сейчас воспринимаем как инструмент, с помощью которого дизайнеры могут создавать уникальность бренда и добавлять детали с точностью до пикселя, изначально воспринимался как способ реализации читаемости документов без форматирования, позволяющий читателям этих документов настраивать их внешний вид. На самом деле, этот атрибут какое-то время сохранялся в Chrome в виде пользовательских таблиц стилей и до сих пор работает в Firefox. Однако в современном вебе это будет непростой задачей, ведь он фактически отказался от идеи семантического HTML.

Веб приложений

А ещё есть веб приложений. Он зародился как серверные приложения, построенные на основе чего-то типа Django и Ruby on Rails. До них существовало множество технологий, которые теперь вечно будут жить в корпорациях, например, сервлеты Java.

Backbone.js продемонстрировал, что многие такие приложения можно перенести в браузер, после чего React и многие его SPA-конкуренты создали для веба новый мировой порядок клиентские приложения с высокой степенью интерактивности и сложности.

Война между частями веба

Я утверждаю, что именно такая двойственная природа создаёт магию веба. Но она является и разрушительной силой.

Магия заключается в том, что простой блог может быть средством творчества, великолепным интерактивным способом самовыражения. Мой сайт не такой, но я просто говорю, что это возможно.

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

А веб приложений страдает от характеристик документов интерактивные приложения прилагают огромные усилия к тому, чтобы избегать большинства фундаментальных характеристик HTML и CSS, и используют их только как сырьё полностью избегая непосредственного написания HTML, избегая написания CSS, избегая стандартных функций анимации, заменяя постраничную навигацию на нечто, что выглядит похоже, но работает совершенно иначе. Веб приложений использует JSX, а не HTML, и предпочитает иметь с ним дело и в самом браузере, или использует Svelte вместо JavaScript, и тоже предпочитает его.

Когда я читаю посты в блогах традиционных веб-разработчиков, которых бесит, что HTML и CSS сегодня уже недостаточно и всё стало таким сложным, то я думаю, что в основном так получилось потому, что во многих местах стек разработки приложений в создании веб-сайтов заменил стек создания документов. Там, где бы мы использовали Jekyll или рендеринг на стороне сайта, теперь применяется React или Vue.js. У такого подхода есть преимущества, но для множества веб-сайтов с минимальной интерактивностью это означает отказ от накопленных за десятки лет знаний в обмен на некие преимущества скорости, которые могут быть даже не важны.

Притягательность социальных сетей

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

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

Веб документов 2.0

Разумеется, было бы здорово реализовать объединённую теорию нового веба, в которой достаточно характеристик приложений и достаточно характеристик документов для создания всевозможных гибридных интерактивных документов, с которыми мы сегодня работаем. Но путь к разделённому вебу для нас понятнее, и о нём я подумал в первую очередь, так что давайте немного поговорим о нём.

• Правило 1 не создавать подмножеств. Если заменой веба будут только те функции, которые присутствовали в Firefox 10 десять лет назад, то такая версия никому не понравится.
• Правило 2 не делать его совместимым. Если альтернативный веб будет существовать параллельно, неотличимо от современного веба, то нам никогда не удастся снизить сложность, потому что альтернативные веб-браузеры всё равно будут поддерживать всё, и у людей не будет стимула покинуть старый веб.
• Правило 3 сделать его лучше для всех. Преимущества должны быть для всех, находящихся в экосистеме: для людей, создающих страницы, для людей, читающих их, и для людей, которые создают технологии, позволяющие читать страницы.

Итак, допустим, мы создаём новый веб документов.

Во-первых, нам понадобится минимальный стандартизованный язык разметки для передачи документов. Вероятно, мы захотим начать с lightweight markup language, который будет заточен под генерирование HTML. Достаточно подходящим выбором кажется строгая разновидность Markdown под названием Commonmark. Это язык, на котором я писал все свои посты, самый популярный в своём семействе. Для Markdown есть множество замечательных парсеров и большая экосистема инструментов.

Далее нам нужен браузер. Уже долгое время Mozilla работала над совершенно новым браузером Servo. На прошлой неделе команду разработки уволили, и это печально. Этот проект включает в себя независимые Rust-крейты для рендеринга шрифтов, а также высококлассную реализацию Markdown на Rust и постоянно растущий набор потрясающих фреймворков приложений. Можно ли создать браузер для чистого Markdown, напрямую использующего этот конвейер? Может быть?

Я считаю, что такая комбинация позволит нам в значительной мере вернуть потерянную скорость. Мы могли бы получать страницу на экран за малую долю времени по сравнению с современным вебом. Потребление памяти может быть крошечным. Система по умолчанию будет невероятно доступной. Можно будет создавать отлично выглядящие стандартные таблицы стилей и делиться альтернативными пользовательскими страницами стилей. Благодаря значительно уменьшившемуся объёму мы сможем портировать систему на всевозможные устройства.

А как будут выглядеть инструменты редактирования веб-сайтов (что, наверно, важнее всего)? Они могут быть намного проще.

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

Мы могли бы связать два веба при помощи чего-то вроде файла well-known протокола dat, или использовать заголовок Accept для создания браузера, понимающего HTML, но предпочитающего lightweight-страницы.

Веб приложений 2.0

У меня есть такое ощущение, что какую бы проблему веба я ни упомянул, мне автоматически ответят, что её сможет устранить WebAssembly. Может ли так быть?

Не знаю. WebAssembly на самом деле отличная штука, но должны ли веб-приложения просто рендериться на canvas, а каждое приложение тащить свою собственный графический тулкит? Действительно ли нам нужны различия в реализации сглаживания в веб-приложениях? Приложения в контейнерах существуют, взгляните хотя бы на Qubes, но на самом деле пользователи должны стремиться не к ним. Любой, кто пользовался Blender или Inkscape на Mac, примерно представляет, как бы всё это выглядело.

Или может ли WebAssembly стать новым ядром, а рендеринг UI по-прежнему будет выполняться HTML? Или мы можем создать общую связанную библиотеку, которую будут использовать WebAssembly-приложения. Она бы работала примерно как SwiftUI и предоставляла удобные для приложений стандарты типа ограничений, а не концепции наподобие высоты строки и плавающих элементов, свойственных документам.

Проблема формирования представления о вебе приложений заключается в том, что он сильно разрастается.

Чем хуже становятся Mac App Store, Windows App Store, App Store и Play Store, чем большую долю требуют эти монополии, чем больше затрат необходимо, чтобы быть разработчиком под Mac или Windows, тем активнее эти приложения перемещаются в веб. Разумеется, некоторые приложения лучше в вебе. Но многие уходят туда просто потому, что это единственное оставшееся место, где можно легко, дёшево и свободно распространять или продавать продукт.

Когда-то мы могли устанавливать приложения, давать явное согласие на то, что оно будет выполняться на компьютере и использовать наше оборудование. Это время заканчивается, а веб-страницы сегодня имеют довольно сложные способы получения любой информации, от веб-камер, файлов, игровых контроллеров, синтеза аудио до криптографии и всего того, что когда-то было сферой возможностей .exe и .app. Разумеется, это даёт новую мощь, но ситуация довольно необычная.

Кто над этим работает?

• Beaker Browser частично является повторным изобретением Интернета это простейший способ использования dat для децентрализации, но разработчики также экспериментируют с новыми типам и документов и способами их создания.
• Project Gemini очень интересная альтернатива вебу с отчётливым ретро-колоритом. (Спасибо Джессу за информацию.)
• Меня сильно впечатлил taizen браузер Википедии для командной строки. Он показывает, что работа с текстом может быть действительно интересной.

Что вы об этом думаете?

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

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

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

---

На правах рекламы

Эпичные серверы это виртуальные серверы для размещения сайтов от маленького блога на Wordpress до серьёзных проектов и порталов с миллионной аудиторией. Доступен широкий выбор тарифных планов, максимальная конфигурация 128 ядер CPU, 512 ГБ RAM, 4000 ГБ NVMe!