05.08.2015

Статьи, Теория

Хватит толкать веб вперед

SelenIT

Перевод статьи Stop pushing the web forward с сайта www.quirksmode.org, c разрешения автора — Питера Пола Коха.

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

С недавних пор я в глубоких сомнениях по поводу всего этого подталкивания веба вперед. Зачем толкать его вперед? И вперед к чему именно? Нужен ли нам такой веб, к чему мы его толкаем? Вам не доводилось слышать эти вопросы.

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

Ну-ка, назовите сходу все новые функции, выпущенные браузерами в 2015! Видите? Не можете. В этом-то и проблема.

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

Я не думаю, что это то, к чему надо толкать веб вперед. Нативные приложения всегда будут намного лучше в нативных задачах, чем браузер. Вместо этого нам надо бы сосредоточиться на сильных сторонах веба: простоте, URLах и доступности.

Машина инноваций на всех парах мчит не туда. Нам нужен перерыв. Нам нужна возможность «с чувством, с толком» разобраться с теми функциями, что у нас уже есть — без инструментов! Кроме того, нам нужно время для основательного обсуждения, куда мы хотим толкать веб вперед. Годовой мораторий на новинки дал бы нам это время.

Текущая ситуация

Раз вы такие молодцы, вот современный браузер в представлении художника:

Современный браузер и его возможности в представлении художника

Разработчики браузеров и веб-разработчики сосредотачиваются на функциях и забывают о деле.

Пример: переходы между страницами (Navigation Transitions)

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

Звучит круто, но зачем оно нам надо? Мы годами обходились без этого. Что еще важнее, конечные пользователи годами обходились без этого и вполне привыкли к легкой задержке при загрузке новой страницы.

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

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

Занятно, что Микрософт добавил аналогичную функцию в IE4 и отменил ее в IE9. Идея не прижилась, потому что в те дни никто не хотел эмулировать нативные приложения (которых попросту не было), а значит, никого особо не беспокоило, что пользователям приходилось чуть подождать следующей страницы.

Стадия приоритета функций

Джаред Спул создал трехэтапную модель развития рынка ПО, которая подходит и к браузерам (см. тж. его статью 1997 года).

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

Подумайте о браузере как о продукте. Подумайте о веб-разработчиках (не о конечных пользователях!) как о пользователях. Чего ждут веб-разработчики от браузера?

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

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

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

Стадия приоритета опыта

Джейк Арчибальд сформулировал это лучше всех:

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

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

Веб-компоненты (или любое другое заманчивое новое предложение, не суть важно) — это «фича», и она всем нравится. Прогрессивное улучшение — это опыт, и его считают «нереалистичным», поскольку всё равно никто не выключает JavaScript (это далеко не чистая правда, но об этом как-нибудь в другой раз).

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

Мораторий

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

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

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

Хрому досталось бы от моратория намного сильнее, чем другим браузерам, поскольку именно Гугл сегодня предлагает больше всего новых функций. Возможно, это было бы не совсем справедливо, но это неизбежное следствие сегодняшнего положения Хрома как браузера №1 — не только по доле рынка, но и по поддерживаемым функциям. А то, что состояние гугловской документации находится где-то между отвратным и полным ее отсутствием, не облегчает его участь.

Торможение инноваций

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

Другой контраргумент — «но нам же нужна функция X!». У каждого найдется своя любимая планируемая функция, которая может пострадать от моратория — у меня это возможность автономной работы. Но добавочный раунд аргументации за функцию X без каких-либо отсылок к нативным приложениям кажется мне хорошей идеей.

Последний контраргумент — IE6. Веб-разработка серьезно забуксовала в те пять лет, когда Микрософт отказывался обновлять браузер. Новые функции приходили в другие браузеры, но не в IE.

И всё же, означала ли нехватка новых функций отсутствие инноваций? Не совсем. Как подытожил это Джеймс Эдвардс:

Ограничения подстегивают творчество. Я вспоминаю о том периоде с воодушевлением.

Необходимость обходить проблемы IE6 требовала изрядной выдумки, и, хотя не все решения выдержали испытание временем (большинство библиотек и фреймворков той поры, например), она всё же оказалась стимулом для наших творческих сил.

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

Было бы неплохо вернуться на время к той установке на творческое решение проблем. Не на пять лет — это явно слишком долго — но перерыв примерно на год звучит что надо.