Comments 187
Только ситхи все возводят в абсолют.
А вот «native apps are doomed» из источника для меня звучит, как будто уже произошедшее и скоро похороны.
Родные приложения никогда не умрут, скорее сотрется грань между нативными и ПВА.
Нативные приложения обречены. Отныне я не буду больше создавать нативные приложения
Ну да, теперь точно обречены. Куди им без автора?
А уж если всякие WebAssebly-фишки допилят…
Браузерное гавно превращается…
Превращается браузерное гавно…
В нативное приложение на c/с++!!!
Возможно это ДМА обречены?
Чем это будет отличаться от native тогдаЛишними слоями, большими тормозами, худшей интеграцией, нестандартизованным интерфейсом. Т.е. все плюшки native пропадут (да, мы говорим не о том native, который на уровне системы. а о том, который внутри JVM и уже имеет под собой слои абстракции, т.е. уже получил часть тормозов, но не стоит усугублять).
Application Cache является устаревшей технологией и, скорее всего, будет со временем удалена поддержка сего в браузерах. Service Worker является ее заменой. localStorage для чего-то более-менее простого, для более сложных вещей — IndexedDB.
В LocalStorage или в IndexedDB хорошая карта не поместится (у многих броузеров есть ограничения на объём). Тут вебхрень ваша не работает. Другой пример: хранилка паролей к различным сервисам. Хранить пароли на мобильнике — вообще неразумно, а вот хранить те же пароли где-то в интернетах, в кэше какой-то веб-странички… Ну, кхм, кхе...!?"№!??
Конкретно у ПВА есть еще один минус — привязка к онлайну.
Вы ошибаетесь. Одна из ключевых идей PWA, в отличие от классических веб-приложений, — обязательная поддержка работоспособности в оффлайне, это явно указано во всех руководствах по созданию PWA. Как минимум, при отсутствии сети, приложение должно нормально стартовать и отстроить пользовательский интерфейс. Как максимум — позволить пользователю нормально работать с ранее закэшированными данными и синхронизировать все изменения позже, когда появится сеть. Для поддержки offline-режима предусмотрен ряд новых технологий вроде service worker'ов и проч.
Посмотрим как оно пойдет, может мне не попадались такие PWA, а может я не замечал что это именно они.
Буду благодарен если посоветуете какие приложения PWA с хорошим офлайн режимом посмотреть. Можно в личку, если тут нельзя постить прямые ссылки.
С рекламой юзеры уже проголосовали, многие устанавливают блокировщики рекламы.
Ждём массовых реакций от юзеров на удаления аккаунтов и возмущения от постоянно требуемых абоненток.
3636
4848
6060 (значок Apple touch на iPhone)
7272
7676 (значок Apple touch на iPad)
9696
120120 (значок Apple touch на iPhone retina)
152152 (значок Apple touch на iPad retina)
180180 (значок Apple touch для iOS 8+ )
192192
512*512
Всем стандартам стандарт, да. Кто сказал SVG? Нет, ты должен подготовить по картинке под каждый тип устройства.
Есть для каждой из ос стайл-гайды к которым пользователи привыкли.
Нативные будут явно быстрее, меньше проблем с тем, что для pwa надо будет на 25 браузерах все отлаживать или же прийдется писать «ой, сарян бро, но мы только под хром сделали»
Или же, «ну мы типа не следовали стайлгайдам дройда, эпла, майкрософта», поэтому запилил вам свой собственный, хоть он и гавно по вашему мнению, но по нашему он огонь и нам не надо делать Х разных скинов, под разные платформы, а если делать, это ж сколько надо писать дополнительного кода.
«А че оно так лагает?» — ну понимает, это кросс-платформенное, поэтому мы его сделали 1 раз и везде показывается, но за это приходиться поплатиться скоростью.
«А че оно вылетает?» — ну мы где-то накосячили и браузер крашится, но мы поправим.
«Да, но на дройдет не вылетает!» — ну там типа хром лучше отработал.
Ну и так далее.
Однако есть очень популярные ниши, где PWA вряд ли в ближайшее время будут:
1. 3D и прочие очень анимированные игры,
2. Напоминалки и другие приложения, которые гоняют бэкграунд-сервисы на девайсах. Пуши же ведь только при подключении к интернету работают :)
3. САМОЕ имхо ВАЖНОЕ — приложения, которым не нужны сайты! Да-да. Таких полмаркета.
Потому, что человек рекомендует не потому, что доволен сервисом, а потому, что получает бонус за обман других людей.
Участие в реферальной программе означает, что словам рекомендателя нельзя доверять.
То, что он им пользуется не значит, что он им доволен.
Говорит он правду или ложь — останется на его совести. Но словам его нельзя доверять, так как его положительная рекомендация мотивирована материальной выгодой.
А если про ангажированность нам ничего не известно, то в дело вступает презумпция невиновности.
В качестве вишенки на торте к этому прилагались жутко дотошные ревьюеры (в отличие от Эпла, русскоязычные приложения проверялись русскоязычными ревьюерами, и они реально докапывались до каждой буквы на кнопках), странные решения в некоторых местах (попробуйте, например, локализовать название приложения) и дикие ограничения платформы.
Не могу винить разработчиков за то, что они отказались участвовать в этом филиале ада ради прироста аудитории на 1-3%.
http://caniuse.com/#feat=web-app-manifest
Что тут еще можно сказать...
Я с удовольствием посмотрю на пользователей, которые при посещении какого-то сайта будут обнаруживать, что у них включается BlueTooth.
Non-standard
This feature is non-standard and is not on a standards track. Do not use it on production sites facing the Web: it will not work for every user. There may also be large incompatibilities between implementations and the behavior may change in the future.
А в Вашем случае, даже если я ткну «разрешить» я разрешу включать блютуз не приложению, а сайту. Сегодня, хозяин сайта, ради эфемерной возможности подсадить меня на подписку не даёт мне оффлайн версии, только с онлайна. Завтра этот предприниматель может решить, что его сервис мало окупаем, лучше соорудить ботнет. И никто его сайт проверять не будет.
По этой причине я могу дать доступ софту к оборудованию, а сайту не хочу. Но это теория, нет такого доступа у сайтов, совсем нет.
В случае онлайн приложения — я не могу никак контролировать, что приложение не обновилось. Более того, я вообще не могу быть уверен, что при втором запуске это будет то же самое приложение, а не что-то другое. Я не только не могу помешать ему обновиться, я даже не узнаю об этом. Отзывы пользователей тоже не помогут — они-то будут для старой версии приложения.
Собственно то, что вы не понимаете этой разницы и делает ваши доводы глупыми.
Хотя бы потому, что злоумышленники редко строят такие далекоидущие планы.
Тут вы тоже заблуждаетесь, нормальные группировки строят именно далеко идущие планы, используют социальную инженерию для совершения точечных ударов.
А эвристический анализ — это попытка компьютерной имитации человеческого анализа. И, как любая имитация — она хуже оригинала.
И, как любая имитация — она хуже оригинала
Но она быстрее, и направлена на то, что бы выяфить факта попытки по определенным критериям. В эврестический анализ входит анализ кода и разрешений. С анализом кода эвристика справится гараздо лучше и быстрее в некоторых случаях, так как при большом объеме кода человеку трудно будет найти нужный участок.
Если я стану интересен по каким-либо параметрам — я буду пользоваться только простыми звонилками, причём каждый раз буду звонить с нового телефона.
Я не подразумевал того, что вы станете супер мега крутым и за вами начнут охотится, интересным вы можете стать будучи работая в банке даже простым секретарем, или еще какую либо должность занимать будете в финансовом или стратегическом учреждении. А то что вы написали это из разряда шпионских игр.
Речь идёт о среднем пользователе, а не о персонализированной атаке.
Как раз средние пользователи и попадают под направленную атаку, как минимум что бы угнать денег по больше, как максимум что бы подобраться к тому у кого их можно угнать. Связать человека с кругом лиц с которым он плотно общается не составляет никакого труда, для этого даже не нужно быть гуглом, достаточно установить ему простенькое приложение, которое просто проанализирует ваше поведение, данные, и тд, и сводную информацию отдаст хозяину, более того, можно сделать так что вы сами предоставите этой программе эти привелегии. Социальная инженерия творит чудеса.
От тюрьмы и от сумы не зарекайся…
Сегодня я считаю самой безопасной системой iOS, но и при этом понимаю что она не безупречна
Способ удостоверится очень простой — пользоваться и наблюдать за поведением.
Очень интересует момент каким образом вы наблюдаете за поведением приложения? В предвкушении ответа думаю вы наблюдаете какие сервисы приложения работают в фоне, сколько ест батареи и интернета, скажу сразу это обходится на раз два, даже без напряга. Что бы выявить злонамеренное действие необходимо декомпилировать приложение и выявить зловредный код. Даже отключение интернета не поможет!
Помимо моего опыта — есть ещё опыт людей, писавших отзывы на маркете.
Я бы не рекомендовал вам смотреть на отзывы как на что то авторитетное, их накрутка не дорогая, особенно для злоумышлеников, какие то 100-2000 это совсем копейки.
В случае, если приложение обновлялось — я буду об этом знать
Тут вы тоже заблуждаетесь. Есть такая штука как динамическая подгрузка библиотеки, особенно это в андроид хорошо реализовано, более того это идеология андроида, посмотрите как грузят ресурсы игры после установки и запуска, если приложение больше 100мб. Так же можно подгрузить библиотеку и выполнить код размещенный в библиотеки, и тут вы тоже ничего не поймете.
Все вышесказанное относительно онлайн приложений касается и нативных приложений. Даже логику нативного приложения можно изменить в любой момент без обновления приложения, достаточно заранее заложить функционал
Ну вот, теперь вы разбудили моего внутреннего параноика. Выходит ситуация в андроиде ещё хуже, чем я думал. В любом случае, спасибо за информацию.
законы будут обязывать владельца сайта повторно запрашивать разрешение при изменении функционала сайта, связанного с этим разрешением?
Потому что:
1. такой закон должен быть во всех странах (а это уже сложно)
2. трудно проследить выполнение и доказать нарушение (да, у меня изначально этот функционал был, просто не включался/включался реже/включался, но вы не обращали внимание)
3. никому это не нужно
4. это создает сложности хорошим разработчикам и никак не мешает мошенникам (приблизительно как с оружием. Оно запрещено в общем виде, но все серьёзные преступники имеют по боевому пистолету, а хорошие люди получить его не могут).
Кстати сказать все тоже самое касается и приложений, создатель приложения мржет изменить самое приложение (как я писал выше), и для этого даже не нужно обновлять приложение в маркете, и в этом нет ничего противозаконного.
Другое дело если приложение требует каких либо разрешений для доступа к апаратным средствам телефона/планшета. Это можно реализовать в самой оболочке браузера, как это сейчас реализовано на уровне платформы Android. Этакая песочница, которая не даст что либо делать пока пользователь не разрешит. Например зачем PWA доступ к смс? — это уже потенциальная угроза, подобный функционал можно сразу же исключить.
Самое разумное это сделать разделение между идеологией PWA и нативных приложений. Если владелец ресурса не посчитал нужным (или не хватило средств) что бы сделать нативное приложение, то надеятся на то, что он проследит за безопасностью своей системы не стоит. Веб плох тем, что взломать сервер, и засунуть в него зловредный сплоит не особая проблема сегодня, большинство сайтов взламываются. А вот взломать аккаунт сторов сложнее, там часто срабатывает детект и аккаунт холдится.
Так что законодательство тут не нужно, нужна правильная песочница для исполнения PWA, с разумным списком разрешений, и правильно построенном уровне доступа к этим разрешениям, к таким разрешениям кстати можно отнести и коцептуальное изменение приложения, и многие проблемы решаться сами собой
А вот решить ту же проблему на уровне браузеров и стандартов — вполне. Чтобы при доступе к «железячным» API запрашивалось разрешение, как сейчас происходит при запросе к гео-апи и к апи уведомлений. По-моему, довольно логичное и здравое решение.
Зато расчёты на видеокартах впечатляют. Памяти стало больше.
Armv7 Neon (2012) 2c/2t 1GHz 300kb/s
Intel HT (2005) 1c/2t 3GHz 300kb/s
Amd APU (2012) 2c/4t 4GHz 3000kb/s
Режимы разные естественно — максимальное сжатие и максимальное количество потоков.
Арм и интел в два потоках, амд в 4 потока. В 2012 не было rar5. Только амд использовал 64-х битный набор инструкций, который явно полнее и быстрее 32-х битного.
Но процессоры шагнули далеко вперед: самый дешевый медленный мобильный амд в 10 раз обходит топовый десктопный интел, который старше на 7 лет. Это показатель.
Интелы 2012 в 8 потоков достигали 8000кб/с. А сейчас пошли 12 и 16 поточные интелы.
Т.е. отрыв не только по частоте и потокам, но и по эффективности: больше инструкций на такт, и инструкции более эффективные, обрабатывают больше данных за раз.
Любопытно другое: 2Вт смартовский арм эффективнее 150Вт десктопного интела, раза в три. Не смотря на явный проигрыш в железе: арм — простейшая железка без каких-либо «взрослых» систем, которые и сьедают миллиарды транзисторов.
Прогресс определенно есть, и огромный.
И это был срез 2005-2012, а сейчас на дворе почти 2017. Современное железо должно быть просто космической мощности.
Сейчас я это бросил.
WinRAR
Armv7 Neon (2012) 2c/2t 1GHz 300kb/s
Intel HT (2005) 1c/2t 3GHz 300kb/s
Amd APU (2012) 2c/4t 4GHz 3000kb/s
Amd Ryzen 7 (2020) 8c/16t 5GHz 32000kb/s (3300kb/s single thread)
Все первые тесты в многопотоке были. Рост за 15 лет впечатляет, 2 порядка.
Половина современного ядра по вычислительной мощности превосходит совокупно все ядра прошлых поколений, работающие вместе.
А все-таки интересно услышать сторонников PWA.
Мнения против, действительно, ценны, но тут либо дискуссию начинать, либо во второй статье смысла не будет.
Свежих аргументов в ней наверняка не прибавиться.
Я сторонник. (Я frontend). Собственно есть куча "бизнес" приложений. У каждого ресторана по приложению, у магазина типа АШАН по приложению, и так далее. Тысячи их.
Приведу пример возможных PWA:
словарь слов на англ для изучения.(типа lingoleo)
приложение кинотеатра(новые фильмы, цены, забронить билет)
приложение ресторана(новые блюда, цены, забронить столик)
приложение соц.сетей
записная книжка
интернет магазины(новые товары, цены, купить)
почта
хабр, гиктайм, сайты типа thequestion.ru
расписание общетсвенного транспорта, карты метро, приложение аеропорта
slack, skype
счетчик калорий.
погода
подбор одежды по настроению
читалка книг.
музыка, Ютуб
стековерфлов
Какие например преимущества PWA даст для записной книжки и читалки книг? Первое должно открываться как можно быстрее, а второе как можно меньше садить батарею. PWA ничему из этого не способствует.
Первое должно открываться как можно быстрее
Нативное откроется и загрузит данные на много быстрее, конечно зависит еще от типа данных, но все равно быстрее
а второе как можно меньше садить батарею
Сегодняшняя реальность такова, что в большинстве случаев PWA быстрее посадит батарею, так как рендеринг WebView очень прожорлив
Так это, у меня нет желания устанавливать весь тот "мусор" что я выше перечислил. Особенно когда у каждого интернет магазина по приложению, у каждого ресторана по приложению. А если это будет PWA на которое я набрел в инете, сразу увидел, и уже потом решил добавить ярлык на рабочий стол то будет гораздо круче. Я сначала нашел крутой ресторан, и только его добавил на рабочий стол.
Собственно основная фишка PWA что оно берет свои плюсы от двух вещей — нативный и веб приложений, а именно:
от веба: друг скинул в соц.сети ссылку — мы сразу перешли, видим результат, ничего не нужно скачивать, ждать. Кроссплатформенность(в будущем если взлетит).
от приложений: возможность работать в офлайне, ярлык на рабочем столе. Производительность телефоном растет, а огромная куча приложений (как тот мусор что я перечислил выше) сложнее не становятся. Счетчик калорий и интернет магазин уж точно лагать не должен, даже на относительно старых устройствах.
Счетчик калорий и интернет магазин уж точно лагать не должен
Ну что уж лукавить, давайте вообще забьем на производительность!? Как разработчик натива могу сказать что стараюсь выжать из кода максимум что бы и отзывчивость была лучше, и потребление ресурсов меньше. Отзывчивость в PWA будет еще ой как не скоро, какие бы показатели небыли у смартфонов. Многие смартфоны так напичканы, что на них можно шатл запустить при желании, но веб все равно не отзывчив. Да что уж говорить о мобильных ресурсах, на десктопах веб еще не на столько отзывчив что бы можно было хоть как то задуматься о том что бы им заменить все и вся!
У всего должна быть своя нисша, к примеру мне вообще не нужно приложение ресторана, ну вот вообще извините меня, когда надо открыл сайт и нашел что нужно, я даже иконку не буду на рабочий стол ставить что бы не захламлять его, а вот на доставку еды любимую я лучше поставлю приложение, так как оно отработает быстрее нежели PWA и не будет бесить своей неотзывчивостью, я не для этого тратил десятки тысяч на аппарат что бы наблюдать как что-то тормозит жудко, тоже самое касается и интернет магазинов, и музыки, да и практически всего что необходимо для регулярного использования
Как писал в одном из комментариев тут, буквально сегодня в нативе нужно было сделать окно с WebView в котором открывалась страничка, страничка подгружается моментально, но вот в сравнение в 1 приложении, отзывчивость самого приложения во много раз лучше нежеле страничка в webview в том же приложении
Погодите, ресурсы как батарея мы конечно потеряем. Но вот 60 FPS и отзывчивость на счетчике калорий получить с PWA не так уж и сложно.
А в интернет маганизе, вы уверены что она нужна? Ну если я нажму на карточку товара, а пока она развернутся в детальную пройдет секунда — то черт с ним. Это не настолько большой минус для меня как скачивания приложения(ожидания порядка 15-45 секунд), и последующее захламление памяти устройства.
Но вот 60 FPS и отзывчивость на счетчике калорий получить с PWA не так уж и сложно
FPS может и не сложно получить, а вот с отзывчивостью будет все равно беда, ну или опровергните это, сделайте пример. Я не видел не 1 веб приложение которое хоть сколько бы близко было по отзывчивости схоже с нативом. Я как раз перешел от веб разработки на мобильные платформы, и решил делать все нативно а не накостылях
Я пилю на работе обычный сайт, cf.ua (версия не актуальна, я пилю на виртуалке), у него также есть приложения.
Тестирую сайт я с айфона — отзывчивость вида "показать полный текст статьи", "открыть попап", "открыть меню гамбургер". Отрабатываются на глаз мгновенно. Переход по ссылкам — порядка секунды(тут дело от инета зависит больше). Открытие всяких дропдаунов — мгновенно.
Просто мы немного забываем, что по мимо мегаполисов есть еще и переферия, где интернет оставляет желать лучшего, да и аппараты далеко не у всех топовые
Тут еще может быть такое дело что вы хороший java разработчик, но плохой javascript.
Может вы сравниваете качественное, оптимизированное приложение на java, против говнокода на javascript написаного на коленке за 2 часа?
И да, я считаю что оно может работать 60 fps, по поводу отзывчивости, что имеется в виду? Как быстро открывается попап после нажатия на кнопку? Тут трудно сказать.
Я сейчас делаю обычный вебсайт который тестирую на iphone 6 и nexus(хз какой) — все очень плавно (скролл в контейнерах, анимация нажатия, открывашка popup-ов). Это при том что я особо не оптимизировал ничего для телефона.
Ах да, еще я пользуюсь мобильной версией вк с ipod 2gen (очень старое устройства, 400 MHz), скролл плавный, похоже что 60 фпс. Отзывчивость (переход в пункт меню после клика на этот пункт меню) конечно хуже, порядка 1-2 секунд. Но это же старое устройство!
Как быстро открывается попап после нажатия на кнопку? Тут трудно сказать.
Именно, под отзывчивостью я имею введу реакцию отклика приложения на действия пользователя.
Тут еще может быть такое дело что вы хороший java разработчик, но плохой javascript.
Может вы сравниваете качественное, оптимизированное приложение на java, против говнокода на javascript написаного на коленке за 2 часа?
Я на swift и на java стараюсь писать код максимально отлаженый и вылизаный, да и когда веб разработкой занимался и javascript старался так же отлаживать, на десктопе отзывчивость была более менее приемлемой для меня, но это был максимум что можно было выжать, в то время как этот же код в мобильных устройствах работал крайне тормознуто. Сделать отрисовку 60fps в наше время это не особо сложное дело, а вот сделать реакцию на действие пользователя такой же как и в нативе не получится.
Вы видимо не берете в расчет тот факт что 60fps на более менее нормальном устройстве превратяться в 30-40 на устройстве 2х летней давности
Ну а что бы опровергуть мои слова кто нибудь бы привел хоть 1 пример такого приложения которое бы работало так же быстро как и натив
Я не в коем случае не против этой технологии, я против того утверждения что веб готов заменить натив в полной мере, мало того не готов, так это еще и не скоро произойдет, не в ближайшие 5-10 лет как минимум
вконтакте?
Так я же на 6 айфоне тестирую, а уже 7 вышел. Как раз два года получается)
Дома нет айфона — открыл с айпада — время открытия попапов на глаз немного заметно, порядка пол секунды, может чуть меньше. Возможно это из-за того что браузер 300мс ждем чтоб определить что это клик, а не дабл клик.
А что вы имеете ввиду под "дает больше свободы"?
PWA отлично впишется для всяких твиттеров и прочих социалочек. Я бы с удовольствием заменил, например, монструозный facebook messenger каким нибудь легковесным PWA.
Забавно, что речь всё время идёт о форме приложений, а не об их содержании. Типа, приложение может делать что угодно. Если оно нативное, то оно обречено, а вот если веб-прогрессивное, то его неминуемо ждёт успех. К сожалению, я совсем не интересуюсь мобильными приложениями и пользуюсь в основном десктопными. А то я бы покритиковал эту позицию более предметно.
телефоны развиваются, процессоры в них ускоряются,
нативные приложения* тем самым работают еще быстрее и меньше требуют батарейки
и тут бац, Progressive Web Apps, и всё по-новой.
Каждый раз когда выходит новый уровень абстракции, приложения из 3х кнопочек снова тормозят.
*прошлый уровень абстракции
Время покажет, но мое мнение таково, что конечно технологии будут развиваться, но при этом будут развиваться не только веб технологии, а это значит что и возможности PWA станут шире, но при этом и нативные приложения будут шагать вперед и по прежнему опережать самые разные универсальные решения.
Ураа первый раз на хабре зоголовок соответствует статье, и статья полнейшая чушь и зоголовок каждой букой об э том говорит. Я уж думал: "О опять желтый заголовок, поди о наболевшем..", а не нет. :)
Во вторых HTML не является языком программирования, это язык разметки. Если говорить о PWA как о замене нативных приложений, то мы как раз и возвращаемся в эпоху языков разметок, и интерпретируемых языков. с типами спрайт, фон, цвет, прозрачность, скин это вам в фотошоп, или CSS
Вы мыслями соберитесь. Вы даже не представляете что можно делать на x86. Тут битность системы не играет никакую роль для типизации или интерпретации данных, только величины исчислений и объемы памяти меняется.
Но вот интересно, когда была эта эпоха — языков разметок?
Эпоха языков разметок была, есть, и еще очень долго будет. Веб никуда не уйдет, просто для всего должно быть свое применение.
Мне просто интересно на чем вы собрались делать PWA приложения если выкинули языки разметки в мусорку?
Возьмите любую IDE в которых есть конструктор интерфейсов, xCode, Android Studio, Visual Studio, во всех них для построения интерфейса используются языки разметки
Надеюсь вам объяснять не нужно что такое нативная разработка? На всякий случай скажу, это не на языках разметки!
И меня все же очень интересует вопрос
особенно если писать можно будет на нормальном языке
Что же это за такие нормальные языки где не нужна типизация, и на которых можно делать нормальные приложения?
Они должны оперировать не с типами int & float, с типами спрайт, фон, цвет, прозрачность, скин и.т.д.
В pascal есть пользовательские типы. Не то?
Потому что х86 может считать только бухгалтерские типы. Для веба он никуда не годится.
человек не знает, что такое: пользовательские типы, процедуры или объекты возвращающие значения, неявное приведение типов. Ну или читал рекламу про pyton, что указывать тип переменной не круто, а считать пробелы круто (сарказм).
Вторая часть перевода планируется?
Нативные приложения обречены (часть 1)