Перевод статьи Regressive Web Apps с сайта adactio.com, опубликовано на css-live.ru с разрешения автора — Джереми Кита.

На конференции Google I/O в этом году было немало докладов о разработке для веба. Приятная перемена по сравнению с прошлыми годами, когда о вебе едва вспоминали и можно было скорей подумать, что  Google I/O — конференция для разработчиков приложений под Андроид.

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

Я долго колебался, не податься ли на Андроид, но после сегодняшней новости, что ссылки с http:// смогут без спроса перехватываться приложениями, я туда ни ногой.

Дейв Руперт (@davatron5000), 18 мая 2016

Питер присмотрелся к «мгновенным Андроид-приложениям» чуть поближе, но, по-моему, озадачен не меньше, чем я. Либо они работают в «песочнице» с примерно такими же разрешениями, что для веба (в таком случае, почему бы просто не использовать веб?), либо же у них больше доступа к нативным API, и тогда безопасность вот-вот накроется медным тазом. Думаю, первый вариант всё же ближе к истине.

Тем временем Гугл наступает на позиции веба и с другой стороны. Сегодня у всех на слуху «Прогрессивные веб-приложения», которые Алекс изначально определил как:

• Отзывчивые
• Не зависящие от наличия соединения
• Реагирующие подобно обычным приложениям
• Актуальные
• Безопасные
• Узнаваемые
• Многоразовые
• Устанавливаемые
• Доступные для ссылок

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

Увы, многие из нынешних примеров так называемых прогрессивных веб приложений могут похвастаться чем угодно, но не этим. Магазин Flipkart и газета The Washington Post сделали прогрессивные веб-приложения, о которых хвалебно отзывается Гугл — но только для мобильных.

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

Алекс привел shop.polymer-project.org как пример прогрессивного веб-приложения, отзывчивого, производительного и устойчивого к сетевым сбоям одновременно. При этом ему необходим JavaScript (а именно, полифил для веб-компонентов — Polymer), чтобы отобразить в браузере текст и картинки. Если у вас «неправильный» браузер — скажем, Opera Mini — вы получите шиш. Прогрессивного в этом мало. Это антипрогрессивно. Результат может выглядеть в точности как нативное приложение, если у вас рекомендованный браузер, но оставлять пользователей других браузеров за бортом — полная противоположность всему тому, за что мы любим веб. Что пользы сайту от украшательств а-ля нативные приложения, если ради них он теряет собственную душу?

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

Лично я не в восторге от принципа программной оболочки. По-моему, он ставит на первое место совершенно не то — интерфейс отображается быстро, а контента приходится дожидаться. Ощущения от этого странные, словно отходняк после Appcache. А еще я заметил, что им прикрываются как индульгенцией, совсем как с «одностраничными приложениями» раньше: «Ой, у меня тут не может быть прогрессивного улучшения, потому что делаю программную оболочку/одностраничник, вы же видите».

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

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

Например, я видел, как люди на своих сайтах отключают зум двумя пальцами мета-тегом viewport. Они мотивируют это тем, что в большинстве нативных приложений нет зума двумя пальцами, так что веб-приложение тоже должно его запрещать. Невозможность зума двумя пальцами в нативном приложении — это баг. Лишая веб-продукты этой функциональности, люди воспроизводят лишние баги. Это выглядит, как какой-то карго-культ в веб-разработке: рабски копировать каждый чих нативных приложений… потому что все знают, что они круче сайтов, так ведь?

Вот еще один пример такого карго-культа с имитацией нативных приложений. В JSON-файле манифеста можно объявить свойство display. Ему можно задать значение browser, standalone или fullscreen. Если установить standalone или fullscreen, то при запуске с экрана приложений сайт не будет показывать адресную строку. Если у свойства display будет значение browser, адресная строка при запуске будет видна. Так вот, лично я предпочитаю, чтобы подобные отличия сайтов от прочего окружения («швы») были видны:

Идея «бесшовности» как того, к чему нужно стремиться при разработке, меня беспокоит. У технологии есть «швы». Пряча эти «швы», мы можем думать, что помогаем конечному пользователю, но при этом мы сознательно идем на то, что вводим его в заблуждение (или как минимум ограничиваем ему возможности).

Другие с этим не согласны. Они считают, что прятать URL логичнее. Они искренне беспокоятся, что пользователь запутается, если сайт с главного экрана вдруг откроется в браузере (не иначе как из-за специфического расстройства памяти у пользователя, что он напрочь забыл, как эта иконка у него на главном экране оказалась, надо полагать).

Пусть так. Люди вправе думать по-разному. Другие могут задавать свойству display свои значения, а я — своё. Веб большой, в конце концов. Нет единственного верного или неверного способа. Для этого ведь и нужны разные значения для свойств.

Или, по крайней мере, так было до недавних пор…

Помните, как я писал про то, как Хром на Андроиде предлагает «добавить на главный экран», если ваше прогрессивное веб-приложение отвечает некоторым критериям?

• Оно отдается по HTTPS,
• у него есть JSON-файл манифеста,
• у него есть сервис-воркер, и
• пользователь заходит на него несколько раз.

Так вот, эти правила теперь поменялись. Теперь есть новый критерий:

• В файле манифеста не должно быть значения browser у свойства display.

Разработчики Хрома решили, что отображение адресов — не «хороший тон». Оно отмечено как баг.

Баг.

Отображение адресов.

Баг.

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

Не поймите меня превратно. Я не утверждаю, что все должны задавать свойству display значение browser. Это было бы слишком уж суровым требованием. Я говорю, что должен быть выбор. Он должен зависеть от конретного сайта. И от того, чего ждут пользователи этого конкретного сайта. Заявление, будто все-все пользователи всех-всех сайтов впадут в ступор от вида URL, звучит настолько нагло и бесцеремонно, что верится в него с большим трудом.

Я бы и не заметил этого изменения политики, если бы не свежевыпущенный инструмент для проверки прогрессивных веб-приложений под названием Lighthouse («Маяк»). Мой проект The Session получил в нем хорошую оценку, но в разделе «Хороший тон» красным цветом отмечено, что на сайте используется display: browser. Судя по всему, это всё-таки официальная генеральная линия Хрома.

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

Я хочу, чтоб адреса можно было копировать. Я хочу, чтоб адреса каждый мог править, словно хакер. Я не стыжусь своих адресов… я ими горжусь.

Стюарт доказывает, что это должно быть на усмотрение создателя:

Манифест приложения объявляет свойства приложения, но свойство display относится не к приложению, а к тому, как, по мнению разработчика, нужно его показывать. Хотите гордо заявить, что это веб-приложение, и его стихия — веб? Не прячьте адресную строку. Хотите скрыть, что это веб-приложение, чтобы оно сильнее походило на нативное? Спрячьте ее.

Пожалуй, в этом что-то есть, но если копнуть глубже, разработчики и дизайнеры не принимают таких решений абстрактно. Обычно они думают, как будет лучше для пользователей. Так что да, однозначно, разным приложениям нужны разные свойства display, но это должно определяться не философией разработчика, а потребностями пользователей — конкретными потребностями конкретных пользователей конкретного приложения. Решение команды Хрома выбрать одну из сторон и волевым постановлением объявить, что одно из решений «правильно» для любого и каждого прогрессивного веб-приложения, что когда-либо появится — это политическое решение. Как по мне, оно здорово смахивает на злоупотребление властью. Такой отказ в праве «добавить на главный экран» попахивает шантажом.

Остальные факторы, влияющие на предложение «добавить на главный экран», вполне логичны:

• Сайты должны отдаваться по защищенному протоколу: и не поспоришь.
• Сайты должны выдерживать перебои с сетью: и это едва ли можно назвать плохой мыслью.
• Сайты должны передавать какие-то метаданные в файле манифеста: пускай, вреда от этого точно не будет.
• Сайты должны скрывать свой URL… опаньки! Это уже явно совсем, совсем другое требование, навязывающее одно определенное мнение каждому, кто хочет стать участником.

И это уже не первый выпад разработчиков Хрома против адресной строки. Это уже начинает действовать мне на нервы.

Вплоть до сего момента я горячо поддерживал прогрессивные веб-приложения. Я воспринимал их как сочетание лучшего от веба (отзывчивость, возможность ссылаться) с лучшим от нативных приложений (возможность устанавливать, независимость от соединения). Но теперь вижу, что равновесие всё больше сползает в сторону нативных, ценой важнейших преимуществ веба. Эх, только бы это равновесие восстановилось, с чуть меньшим акцентом на «приложениях» и чуть большим — на «вебе». Вот это было бы прогрессивно.

P.S. Это тоже может быть интересно:

• CSS-выражения от контейнера для дизайнеров
• Как читать W3C-спецификации
• Не боритесь с каскадом, управляйте им!