Pull to refresh

Comments 66

Да, веб-платформа очень изменилась в плане возможностей в последнее время. В сугубо лучшую сторону. Однако, индустрия веб-разработки, в своей основной массе, пока топчется в рамках ранее выработанных подходов, и многие разработчики, что печально, не держат "руку на пульсе" оставаясь полностью в пределах своих, ранее освоенных, экосистем. Многие не знают, что ES-модули теперь поддерживаются всеми современными браузерами, что есть такие крутейшие штуки как Custom Elements, ShadowDOM, CSS-переменные… А ведь эти вещи очень многое меняют.

Custom Elements, ShadowDOM — почти не поддерживаются.
И вообще, если нужно поддерживать ie10 или и того меньше, то о какой «руке на пульсе» может идти речь?

IE10 не поддерживается и признан устаревшим даже собственным вендором, причем очень давно. Доля IE10 в трафике — 0.1% (https://caniuse.com/usage-table)
Если говорить о нативной поддержке:
Поддержка Сustom Elements — 79.39%
Поддержка ShadowDOM — 79.81%
Как-то это не похоже на "почти не поддерживается", не находите?
Для остальных: https://github.com/WebComponents/webcomponentsjs
Работа в рамках популярных экосистем: https://custom-elements-everywhere.com/


Надоела уже мантра про "не поддерживается", так и сидели бы в каменном веке...

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

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

UFO just landed and posted this here
Ну а у меня вот целая отрасль, где все такие. Помню, два года назад с большим скандалом удалось выкинуть из ТЗ поддержку IE 7. Что теперь, бросать надо российскую науку, идти на фрилансер клепать буржуям сайты?

Очень странный вопрос. Во первых, непонятно причем тут сразу буржуи и фриланс. Разве это единственная альтернатива? Во вторых, никто вас не заставляет. Каждый имеет право выбирать платформу и инструментарий (а также, саму работу), просто следствием вашего выбора будут определённые возможности и ограничения. Задача инженера — взвесить все "за" и "против" самостоятельно. Ну и ужасно удручает технологическое ретроградство в научной среде: на мой взгляд оно там совершенно неуместно. Но это уже огромная системная проблема, с которой я лично бороться бы не стал, ибо смысла не вижу.

Ретроградство объясняется очень просто: штампик от ФСБ на конкретный набор софта получают до года, ещё полгода оно едет к пользователю и внедряется, ну а потом — надо же попользоваться… Вот минимум 4 года задержки на внедрение — и это для бесплатного и открытого Линукса. В результате я в прошлом году писал на Qt 4, потому что доступная у заказчика в дистрибутиве Qt 5.0 была страшно глючная.

Вам легче от того, что маразм как-то объясняется?

Легче мне от зарплаты. А ради неё приходилось соответствовать реалиям.

А зарплату получают только те, кто вынужден терпеть маразм и всякое "ФСБ-головного мозга"? Ерунда какая.

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

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


Пусть предприятия, отстающие в обновлении софта на 10 лет будут сами себе злобные буратино.

А вы когда писали свой первый коммент чего добивались? И так понятно, что в ряде случаев существуют специфические требования, и что абсолютно универсальных решений — нет. Да, кому-то, в редких случаях, нужно поддерживать ископаемое барахло, но это совсем не значит, что ВСЕМ нужно сидеть с своем болотце и не обращать внимания на прогресс. Тут речь шла о технологиях, которые поддерживаются у БОЛЬШИНСТВА пользователей, все цифры приведены. Я больше отвечать не буду, не беспокойтесь.

На цифрах конечно красиво, а по факту ни Firefox ни Edge не поддерживают эти фичи, а Shadow Dom и вовсе только Chrome поддерживает.
Ссылка на Shadow DOM битая. И где вы там 79.81% увидели? 71.96% же
Не поймите меня не правильно, я только ЗА внедрение новых технологий и всегда хочется пощупать самому, но чаще всего это приходится делать на домашний проектах. (
UFO just landed and posted this here

Не в то место смотрите: https://caniuse.com/#feat=shadowdomv1
Нативная поддержка из коробки есть в Chrome (+ mobile), Safari (+ mobile), Opera и еще по мелочи. У вас таблица перед носом, но вы меня будете все равно в своем убеждать… На полифилл я также дал ссылку, у пользователей FF и Edge будет работать, но немного медленнее. У FF нативная поддержка скоро появится, уже зарелижено в найтли. У Edge — в разработке. Я использую это все в боевых проектах, как и многие крупные компании Google, Github и др. Список длинный. Но мне все равно регулярно рассказывают, как ничего нигде не поддерживается. Сюр какой-то.

Shadow DOM.
Supported in Firefox behind the dom.webcomponents.shadowdom.enabled flag.

Так что вполне поддерживается.

Справедливости ради, то, что в FF за флагом — это не поддержка а недоразумение какое-то. С полифиллом (Shady DOM) работает на порядок лучше. Нужно ждать нормальной реализации.

UFO just landed and posted this here

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

Угу… 79% поддержки. То есть 21% за бортом. Вот представляю, как иду к бизнесу и говорю "хочу клевую фичу в коде, но надо 21% пользователей выкинуть. Ок?"
А если мы на рынке каком особенном? SEA, Китай? Там цифры другие и забавнее.

Если по приведенным ссылкам походить, можно на таблицу совместимости наткнуться. Повторю для вас специально: https://github.com/WebComponents/webcomponentsjs
Если у вас "особенный рынок", то ваша ситуация называется "специфические требования". Такое бывает, да. Но такую ситуацию НЕЛЬЗЯ экстраполировать на всю отрасль.

Верно и обратное, нельзя огульно говорить, что 0.1% или 5% или 10% ничего не значат.

Все решают цифры. Если необходимость поддержки 0.1% пользователей, влечет удорожание проекта на 50%, то этот, каждый тысячный условный китаец, должен приносить дофига денег, чтобы окупить затраты. При этом, он сидит за старым компом под старой видной, которую и на помойке уже сложно найти (или он, что более вероятно, бот). Не знаю уж насколько это "огульно", но нахрен этого китайца. Остальные проценты вы взяли с потолка, тут говорить не о чем.

Жаль, что не у всех пользователей современные браузеры и стоит задача охватит максимально количество пользователей, включая тех, кто на старых не современных браузерах.

Web как раз и прекрасен тем, что можно делать прогрессивные улучшения. И для большой части технологий есть полифилы. Поэтому пользователь на IE10 может получить работающую версию сайта с хорошим дизайном и контентом, а люди с новым Chrome'ом или Firefox'ом с Edge получат новые фичи. Если какая-то возможность не поддерживается везде — это не значит что её нельзя использовать. Хороший пример JavaScript. Сейчас подавляющее большинство приложений используют свежие версии стандарта.

На IE10 мир не сошелся.
take.ms/H1Fuf — 3 строка это для меня 5% аудитории, а с другими версиям браузеров все 15 набежит, мне их нафиг высылать? :)

Может у вас еще "все работает локально"?

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

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

Более того, если говорить в контексте мобильных платформ и PWA — все, скорее, очень даже хорошо. Актуальные версии мобильных Chrome и Safari — вообще красавчики, в плане поддержки стандартов.

мобильный сафари — это набор фееричных багов, и собственных "интерпретаций" спецификаций. одно оригинальное понимание того что такое единица vh чего стоит, сводящее на нет вообще ее существование.

С этим соглашусь, сафари — капризный. Есть к нему вопросы и по гридам и еще много по чему. Но в целом, победить его вполне можно. И то, что он, несмотря на любовь Apple к ортодоксальности, в зеленой зоне — не может не радовать.

«Ну и нужно использовать полифилы. Поэтому с обеспечением совместимости конечно есть проблемы, с этим не поспоришь, но всё так плохо.» — но НЕ все так плохо.
UFO just landed and posted this here
Была на Хабре статья, почему PWA выгодны Гуглу и почему они не выгодны всем остальным. По функциональным возможностям мусор + нужен и-нет.

А вы точно ничего не путаете и статья была именно про PWA? Очень бы хотелось посмотреть на такую статью. Потому что обсуждение с позиции выгодности-невыгодности были про AMP. По PWA же есть консенсус, и все вендоры от Apple до Microsoft поддерживают соответствующие старндарты.

Да, вы правы, я ошибся. Перечитал еще раз. В целом, я бы не хотел, чтобы мои и мои любимые приложения были PWA. И Электрон — это Электрон, а браузер Гугл Хром — это браузер Гугла, со всеми его + и заботой о пользователе. Как и Сафарм с Эдж. Ирония. Тем более, в статье дан путанный текст, если ты вообще про PWA не слышал, то звучит как маркетинг. Добавить бы больше деталей.
Писать одно веб-приложение для работы на всех девайсах, вместо нескольких нативных — за этим безусловно будущее. Сейчас ограничением является доступ к операционной системе и аппаратным возможностям, но всё меняется. Возникает другая большая проблема — проблема безопасности. Всё таки приложения в магазине проходят валидацию, а вот с веб-приложением это уже сложнее сделать.

Для меня стало открытием, что PWA имеет немало доступа к аппаратным возможностям Андроида. Я не знаю, насколько стабильно это всё работает, но список впечатляет: https://whatwebcando.today

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

Меня всегда настораживают статьи, где только плюсы и восторги. Клевые технологии, верное направление.
Но подходит ли оно для небольших предприятий? Не google, uber, twitter?
Пример: у нас мобильное приложение, децентрализованный чат с фичами; сделан на react native. Все отлично, быстро был сделан прототип, успешно собраны инвестиции, сберегло в разы времени на разработку. Но эта штука прожорлива. Очень. Батарею не ест, а жрет, как не в себя. Бизнес сначала решил расширить команду более опытными разработчиками на RN. Логично, надо сначала проверить, может варим неправильно. Расширили вдвое 3 -> 6 + внештатные. В итоге более опытные ребята помучались и начали делать все больше и больше вставок в нативном коде внутри RN. Поддержка усложнилась, код быстрее стал, но на проценты, а не в разы. Итог: тупик, где надо принимать волевое решение о написании нативных приложений.
Когда мы говорим про новое, то всегда надо говорить про область и условия применения и про плюсы и минусы в сравнении со "старым".

Вы уверены, что это RN жрет батарейку? Может приложение никогда не засыпает просто? Как сделан обмен сообщениями, по вебсокетам?

Да, уверен. Для того, чтобы быть полностью уверенными мы сделали отдельные замеры по сети, фронту и бэку. Да все так. Дополнительное подтверждение — вставка нативного кода реально помогает, получаем статистические значимые изменения по батарейке на автотестах, обычно это 5-20% при переписывании критичных участков.

Совсем нет. Но, видимо, обжегшись на кипятке, теперь дуют и на воду.

А в чем, по-вашему, между ними принципиальная разница?

ReactNative: код компилируется и собирается в пакет. Установка и обновление через AppStore/PlayMarket, никаких отличий от нативных приложений. В коде можно использовать вставки нативного кода, вызывать любые доступные системные методы


PWA: код пишется на Javascript (или транслируется в него). Устанавливается PWA через кнопку "добавить на рабочий стол" в браузере. Нативный код писать нельзя в принципе, все взаимодействие только через браузерные API (в статье есть ссылки на список возможностей).


Проще говоря, PWA это в первую очередь сайт, который научили сохраняться и работать оффлайн, а ReactNative – это все такие же обычные приложения, в которых есть возможность писать код на React.

UFO just landed and posted this here
Могут.
Пример, хоть и немного странный, но тоже пример :) Аппаратно-программный комплекс для выставок и всяких массовых мероприятий.
Приходят люди и они должны: пройти регистрацию, получить идентификационную карточку и далее этой карточкой взаимодействовать со стендами экспонентов. Стенды регистрации и интерактивные стенды это планшеты с подключенными RFID считывателями. Еще устройства в системе должны уметь распознавать QR коды. Это все должно быть в kioskmode.
Это хозяйство было написано под андроид, но администрирование более 2-3 устройств превратилось просто в ад. В итоге почти все, кроме киоск браузера и считывания RFID, было переделано на JS + HTML + CSS (уж не знаю насколько это PWA я не супер эксперт). Это дало потрясающий эффект! Все работает очень быстро (включая считывание QR кодов), нет проблем с установкой, скорость разработки выросла в РАЗЫ (хотя я Java программист и JS освоил «по ходу»). В итоге нативными остались только: киоск браузер и маленькие безинтерфейсные сервисы-приложения по рассылке СМС и считыванию RFID карт через OTG. Работает на самых дешевых устройствах и очень экономично использует батарейку. Планшет на считывание QR кодов 6000mAh на максимальной яркости работает 12 часов и все это в браузере на JS и HTML.
Пользователи при регистрации получают ссылку и по ней находится сайт-приложение использует ту же технологию. Там правда все немного проще, но в целом работает быстро и хорошо, на всех +- современных телефонах.
Так что не только в кросс-платформенности дело.
Пока я видел только одно приложение на веб технологиях которое бы меня не бесило тормозами, причем даже на более менее нормальном железе — VS code. Что на мобилках веб приложения выжирают батарею и тормозят как не в себя, что на десктопе.
UFO just landed and posted this here
Фронтэндом занимаюсь с 2006 года. Вкратце — действительно делать вебсайт как PWA — это хорошо. Lighthouse полезный инструмент. Сколько ужасающих примеров вроде популярных сайтов но сделанных на уровне 2009 года то есть до пресловутого определения Веб 2.0. Так вот я помню сколько было всяких инициатив и разработчики бросались на амбарзуру и выполняли новомодные требования. Особо мне запомнилась XHTML со своими заморочками. И где она? Или тема Firefox OS и Webapp. Был же даже Store где вы могли распространять свои вебаппы. Потом МС и Гугл стали тянуть одеяло на себя и появилась тема с PWA. Гугл полез со совоим сомнительным AMP. Появились ребята c NWJS и другие с Electron. К чему это я. Делать по новым стандартам но с щепоткой соли.

Мой ответ на вопрос-заголовок. Не могут. И пока это разные хоть и кое в чем пересекающиеся вещи.

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


По теме статьи, понятно, что концепция PWA — это чисто маркетинг. Вот когда все научаться индексировать страницы SPA, тогда это будет какой-то сдвиг, а так от Angular была видна только разметка, с Vue было лучше, но все равно.
SSR — это странная фигня.


Но сама тенденция движения к размытию границы между веб и натив правильная.

Google видит то есть подключает хромиум при сканировании; яндекс нет. Но алгоритм непонятен — ну и хрен с ним — важно что к этому идет.
Между приложениями и индексированием Гуглом очень мало общего. Речь шла о том, что многие приложения, которые сейчас традиционно реализуются нативными средствами, можно реализовать как PWA. Да, индексирование SPA поисковиками — сложная тема, но с индексированием нативных приложений дело обстоит еще хуже.

Да, всегда считал что для PWA в сравнении с нативными приложениями, индексанция поисковиками — это плюс, так как PWA индексируются лучше нативных, а уж с server side rendering — всё вообще прекрасно.

Очень правильное замечание. Хоть большинство PWA и являются SPA, но есть много и таких, которые не SPA, и я и статье специально про это пишу, так как это самое большое заблуждение, наверное, что PWA доллжны быть SPA. Такого требования нет.

Думаю, может. Даже не PWA, а просто WA может.
За одним исключением: когда не нужно запускать камеру. Как говорится, Ha-ha, Classic!:
— делаем WA
— нам нужно фото, запускаем камеру
— веб-браузер выгружается из памяти (Android, iOS — одинаково)
— мы теряем связь поля input с приложением камеры.
Fail неминуем.
Пока единственный хак для android — сделать на странице видео с трансляции с камеры, и с него снять кадр. На iOS такое заблокировано.
Достаточно много всего увидел в комментах, неплохо, на самом деле очень рад что всё больше и больше народу интересуется данной темой. Будущее определённо за PWA.
Большая часть проблем и сложностей которые описаны выше действительно существуют в «классическом» варианте PWA, но слегка отклонившись от классики, можно спокойно решить большую часть всех этих кейсов. Как к примеру сделано у нас в Mobsted.
Типичные примеры решенных кейсов:
— Server side rendering
— Долговременное поддержание авторизации на иконке
И многое другое.
Можно сказать что это даже не «PWA», а «PWA 2.0»
Кстати занимаемся мы этим уже 4 года, начали ещё до того как сам термин PWA был придуман.
И конкуренцию мы составляем очень даже неплохую (~ 5 млн. уникальных посетителей в месяц в различных бизнес сферах)
В скором времени выкатим версию 3.0, и поток вырастет, настолько, что я надеюсь больше ни у кого больше не возникнет вопроса о конкурентоспособности PWA.
Sign up to leave a comment.