Нам надо создать веб с чистого листа

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

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

Я попытаюсь немного проанализировать и диагностировать эту ситуацию. Если вы хотите просто прочитать мою обывательскую, непрофессиональную речь о необходимости перезагрузки веба, то можете пропустить эту часть. Идея заключается в том, что мы можем выбрать новый облегчённый (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!