Я чувствую, что пора вернуться к дискуссии веб против native и признать поражение – или, по крайней мере, признать, что веб не может и не должен соревноваться с native, когда дело доходит до сложных, подобных приложениям структур.
Я чувствую, что мы зашли слишком далеко в эмуляции native приложений. Признание поражения заставит нас переосмыслить назначение и силу веба.
Я чувствую, что наше желание перевести все на native породило неоправданно сложные toolchain, которые замедляют простые веб-сайты. Особенно я думал о новостных сайтах и аргументирую ниже, что они должны быть native и забыть о вебе.
Возвращение инструментов
Моя недавняя статья об инструментах вызвала много откликов и интересных идей. У меня не было времени, чтобы должным образом ответить, но, к счастью, Джереми написал статью, которую я должен был написать на прошлой неделе. Читайте, и вы будете в курсе нынешней дискуссии.
Sebastian Markbåge написал ясный, продуманный призыв к использованию лучших инструментов. Тем не менее, его статья основывается на предположении, что веб должен эмулировать native UX и native приложения.
Я не разделяю это предположение. Цель веба – эмулировать native добавлением еще больших возможностей? Я сомневаюсь в этом.
Native одерживает победу над веб
Технически, это просто. Веб не может в совершенстве эмулировать native и никогда не сможет. Native приложения напрямую общаются с операционной системой, в то время как веб-приложения общаются с браузером, который общается с ОС. Таким образом, есть дополнительный слой, который веб-приложения должны пройти, что делает их немного медленными и грубыми, чем native приложения. Эта проблема неразрешима.
Тем не менее, мы веб-разработчики потратили последние шесть лет в отрицании этого. Нашим предположением было то, что все веб-сайты должны быть подобны приложениям и, следовательно, напичканы инструментами. Универсальный веб, верно? Тогда это также идеальное средство для пользователей, выполняющих сложные задачи, правильно?
Неправильно. Я так думаю.
Эмуляция native приводит к плохому UX (или, по крайней мере, UX, который является неоптимальной копией родного UX), и неэффективным сайтам, по причине всех библиотек и фреймворков, которые мы считаем нужными. Baldur Bjarnason лучше всего высказался: “Вы разрушаете основное юзабилити, захватывая полосу прокрутки. Вы берете native функциональность (прокрутка, выбор, ссылки, загрузки), которая является быстрой и эффективной, и переписываете ее с современными Javascript инструментами и фреймворками так, что она становится медленной и плохой. Вы раздуваете свои веб-сайты мегабайтами хлама”.
Пора признать, что это неправильный подход. Мы не должны пытаться конкурировать с native приложениями в рамках, установленных native приложениями. Вместо этого, мы должны сосредоточиться на уникальных преимуществах веба: его охват, который включает в себя все native платформы, URL, которые фантастически полезны и не работают в native среде, и его беспроблемное качество.
Беспроблемный веб
Беспроблемный? Что это значит? На самом деле, это довольно интересно.
Недавно Benedict Evans резюмировал обсуждение native и веб в один вопрос: хотят ли люди видеть вашу иконку на своем главном экране?
Если ответ да, перейдите на native. Если нет, перейдите на веб. Но, добавлю, не веб, замаскированный под native.
Это напоминает мне статью Scott Jenson четырехлетней давности, где он привел похожий аргумент. Большинство бизнес структур, которым требуется интернет (небольшие магазины, сантехники и т.п.) не будут в конечном итоге на вашем рабочем столе. Вместо этого, они требуют одного взаимодействия – когда вам нужно узнать их часы работы, номер телефона или меню. Люди ожидают найти эту информацию в Интернете, потому что они не собираются устанавливать их приложение.
На самом деле, это очень хорошая новость для веба. Если пользователь не хочет вашей иконки на своем главном экране, если пользователь хочет одного взаимодействия, им нужен веб – не потому, что он имеет технологическое превосходство, а потому, что это он беспроблемный. Зайдите, почитайте, забудьте. Ничего нежелательного не осталось на вашем телефоне.
Большинство предприятий не имеют шанса оказаться на главных экранах пользователей. Таким образом, они нуждаются в вебе – но не в вебе, который эмулирует native для не определенной цели.
Новостные сайты
Возможно, новостные сайты наиболее зависимы от бесполезного хлама. Не то, чтобы владельцы новостных сайтов хотят хлама, но у них есть причины для размещения кучи объявлений и “призывов к действию” на своих сайтах, и они хотят иметь бессмысленные интерфейсы для того, чтобы… ну, никто не знает, на самом деле. Для того чтобы выглядеть native? Давайте придерживаться этого мнения.
Давайте зададим вопрос Бенедикта Эванса. Хотят ли пользователи иконку новостного сайта на своем главном экране? Для старых газет, да, я думаю, что хотят и даже современные новостные сайты, такие как Next Web или Verge. Так что это одна веская причина для них, чтобы быть native.
Тогда возникает вопрос бюджета. Tim Kadlec справедливо указывает, что если сайт медленный, это потому, производительность не была в приоритете. Время и ресурсы были потрачены на другие функции сайта, а не на то, чтобы сайт быстро загружался.
На что вы тратите бюджет сайта? На производительность или функции? Новостные сайты тратят на функции.
Новостные сайты могут в конечном итоге появиться на многих главных экранах пользователей, и они нуждаются в том, что native могут предложить в плане UX. Кроме того, если они используют native приложения, пользователи будут загрузят фреймворк только один раз, и это позаботится о показе объявлений, призывов к действию, и функциях (и контенте). После этого пользователи должны лишь загрузить фактические объявления (контент). Возможно, native дает лучшую производительность, когда вы заросли хламом.
Именно по этой причине, мы веб-разработчики должны посоветовать новостным сайтам, и фактически любому сайту, который отдает приоритет функциям над выполнением, использовать native, так как они хотят извлечь какую-либо пользу. На самом деле, мы можем оспорить это, так как функции, которые необходимы им уменьшают производительность, веб больше не является лучшей средой для публикации сайтов.
Обновление: только что появился отличный контраргумент: новостным сайтам нужны URL. Очень ценное замечание. Нужно обдумать это.
Конечно, создание двух native приложений дороже, чем создание одного веб-сайта. Но это результат траты бюджета на функции, верно? Выбирайте веб, и ваш опыт будет универсальным, беспроблемным, незахламленным, быстрым, и дешевле. (Этот аргумент нуждается в большем оттачивании, но я надеюсь, что вы понимаете, что я имею в виду.)
Пересмотрите веб
Мне бы хотелось, чтобы к этим размышлениям чаще обращались. Подумайте о вашем нынешнем клиенте, и захотят ли люди видеть их иконку на своем главном экране – и если нет, то почему они настаивают на трате бюджета на бесполезные функции.
Как вы могли бы убедить их либо выбрать native, либо веб с его преимуществами, несмотря на некоторые минусы? К каким аргументам они прислушаются?
Я уверен, что можно сделать больше открытий в этой области, и что мы можем переосмыслить веб и его отношение к native, основанное на реальных сильных и слабых сторонах native и веба, вместо того, чтобы идеализировать веб, что на самом деле не имеет места в реальности.
Для того чтобы сделать это, мы должны признать поражение перед native. Это даст свободу нашим мыслям. Я с нетерпением жду улучшений в вебе!
Высоких конверсий!
