В дискуссиях о будущем мобайла постоянно звучит тезис о том, что «в конце концов останутся только мобильные приложения под iOS или Android». Старший менеджер по продукту в Intercom Хью Даркин решил с этим поспорить. Он считает: у многих, кто говорит об этом, есть личная заинтересованность в выживании нативных мобильных приложений.
Статья переведена компанией-локализатором Alconost
Заявления о том, что будущее принадлежит нативным мобильным приложениям, игнорируют тот факт, что браузеры и веб быстро становятся мобильной операционной системой будущего, а нативные приложения медленно вымирают.
Нативные приложения хороши, но не для всего
Безусловно, нативные приложения прекрасно подходят для определенных вещей. Например, для частых интенсивных задач вроде общения с друзьями, семьей и коллегами — того, что мы делаем каждый день множество раз. Таким приложениям, как Snapchat, WhatsApp, Facebook Messenger, нужен доступ к камерам, микрофонам и непосредственно к операционной системе. В этом случае создание нативных приложений под iOS и Android имеет смысл.
Но нужна ли на самом деле нативная установка любым другим типам приложений? Мобильный веб и сегодняшние браузеры могут легко справиться почти со всем, что нам может понадобиться. Давайте не забывать о том, что нативные мобильные приложения были временным решением для краткосрочных проблем с подключением. В мире с 4G и повсеместным Wi-Fi этих проблем больше нет.
Благодаря развитию возможностей и стандартов мобильного веба такие компании, как Patagonia, уже попрощались со своими нативными мобильными приложениями.
— Adam Kmiec (@adamkmiec) June 1, 2016
What was that about websites being irrelevant and this being an app only future?
Время прощаться.
–––––
Спасибо за поддержку приложения Patagonia для iPhone. Теперь наш сайт красив и удобен в любом мобильном браузере, а это приложение мы больше не поддерживаем — можете удалить его со своего устройства.
Посетить Patagonia.com
*
Адам Кмеч @adamkmiec
Кто там говорил, что сайты неуместны и будущее исключительно за приложениями?
Мы проводим в мобильных браузерах больше времени, чем кажется
От нативных приложений отказываются не только компании: сегодняшний средний американец скачивает ноль приложений в месяц. Это мало связано с тем, сколько времени мы проводим со своими смартфонами — сопоставьте эту усталость от приложений с количеством времени, которое мы проводим в браузерах.
Всем знакомы Firefox, Chrome, Safari и Internet Explorer — «традиционные» браузеры с адресной строкой, поисковой функциональностью и кнопками перехода вперед и назад. Но это не единственные браузеры, которыми мы пользуемся каждый день.
Мы проводим все больше времени в мессенджерах и социальных сетях, которые сами являются оболочками для мобильного веба. На самом деле они — браузеры. И эти браузеры дают нам тот социальный контекст и те связи, к которым мы стремимся, но которых не дают традиционные браузеры.
Например, Facebook — наш браузер для социального веба. Он упрощает просмотр и поиск друзей, компаний и потенциально интересного для нас контента. Не мы «вытягиваем» контент традиционными браузерами, а Facebook «доставляет» нам контент, исходя из наших интересов и интересов наших друзей. Обратите также внимание на ряд эстетических перемен: например, несколько новых особенностей приложения Facebook для iOS, которые приближают его к настоящему браузеру.
?
У встроенного в приложение Facebook браузера есть кнопки перехода вперед и назад, он также позволяет делать закладки и вводить свой URL.
Тогда как Slack — это наш браузер для работы. Он упрощает поиск документов, обсуждений и данных. В прошлом нам приходилось запрашивать необходимые сведения у своих коллег, при этом мы просто упускали ту информацию, которая могла бы пригодиться, но мы ничего не знали о ней. Сегодня наши коллеги «доставляют» нам документы и обновления с помощью браузеров вроде Slack, что делает наши рабочие будни проще и согласованнее.
WhatsApp — наш браузер для близких друзей. Будь то общение один на один или в маленьких группах, мы просматриваем и потребляем персонализированный контент от ближайших друзей, которые «доставляют» его нам. Мы доверяем их рекомендациям — это самый персонализированный способ просматривать веб.
Перечисленные мессенджеры — все нативные приложения, конечно. Но критично то, что они включают новые функции, заменяющие действия, которые раньше выполнялись в других нативных приложениях или где-то еще. Они предлагают головокружительный набор возможностей на основе миллионов умных интеграций с продуктами сторонних разработчиков программного обеспечения, и всякая необходимость покидать этот новый тип браузеров практически исчезает.
На самом деле эти социальные браузеры настолько успешны, что нам достаточно всего трех, чтобы находить и потреблять весь нужный нам контент. Неудивительно, что Facebook, Google и многие другие ставят на это. Если вы владеете браузером, вы владеете аудиторией.
Время, проведенное в приложениях, которыми пользуется средний американец
Номер в рейтинге / Время в приложении относительно общего времени со смартфоном
Согласно comScore, 50% времени пользователи проводят в одном самом используемом приложении и почти 80% времени — в трех самых используемых
Боты — новый способ просмотра
Самое увлекательное в этих новых браузерах то, как много всего в них до сих пор меняется.
Закладки были в основе операционных систем с 1990-х — в виде иконок на рабочем столе и стартовых меню. По мере того, как мы стали проводить больше времени в традиционных браузерах, мы стали полагаться на новый тип закладок. Мы сохраняли адреса веб-страниц и доменные имена. Мы устанавливали панели инструментов для доступа к сервисам вроде MSN News, поиска Google, почты Yahoo! Mail. Мы собственноручно отбирали контент для себя.
Что касается мобильных технологий, мы наблюдаем становление ботов как нового типа динамических закладок для мобильных браузеров. Вместо того, чтобы каждый раз набирать в адресной строке URL и ждать загрузки контента, мы используем ботов, способных доставлять контент тогда, когда он нам нужен. Они могут подстроиться под наше взаимодействие с контентом и со временем подавать все более подходящий для нас. Они отбирают контент для нас.
Например, опция music в мессенджере Telegram: бот использует встроенную панель управления, которая позволяет вам находить и слушать музыку, даже не отправляя никаких сообщений. А также обновляет свои собственные сообщения на лету по мере вашего продвижения по результатам поиска.
Так что вам не понадобится а) устанавливать отдельное нативное мобильное приложение (типа Spotify) или б) искать музыку в браузере вроде Chrome: вместо этого боты смогут обеспечить любые нужды пользователя, — зарезервировать столик в ресторане или купить что-нибудь, — в пределах социального приложения или мессенджера.
?
Со временем боты станут для нас способом сохранять свои интересы и варианты поведения. Доставляемый нам контент подразумевает действия. Мы можем бронировать и покупать что-то. Мы можем что-то читать. Отбор всего этого будут определять сети наших близких друзей и искусственный интеллект.
Что это значит для завтрашних стартапов
Самой популярной операционной системой в мире всегда будет веб — не iOS или Android. Важно, чтобы следующее поколение производителей программного обеспечения не ограничивалось созданием только нативных версий веб-приложений под iOS и Android.
Просто обеспечьте, чтобы веб-приложения хорошо выглядели и работали в новом типе мобильных браузеров — мессенджерах. Не создавайте под iOS или Android только ради мнимых возможностей распространения. Распространять надо там, где люди проводят большую часть своего времени: в социальных приложениях и мессенджерах — новых мобильных браузерах оснащенного ботами мира.
###
Перевод статьи выполнен в Alconost.
Alconost занимается локализацией приложений, игр и сайтов на 60 языков. Переводчики-носители языка, лингвистическое тестирование, облачная платформа с API, непрерывная локализация, менеджеры проектов 24/7, любые форматы строковых ресурсов.
Мы также делаем рекламные и обучающие видеоролики — для сайтов, продающие, имиджевые, рекламные, обучающие, тизеры, эксплейнеры, трейлеры для Google Play и App Store.
Давайте обсудим ваш проект прямо сейчас: https://alconost.com
Комментарии (72)
renskiy
24.01.2017 11:28+4Так не произойдёт ни в ближайшее время, ни в обозримом будущем. Вендоры (Apple, Google, Microsoft и др.) всегда будут продвигать свои способы не только оптимизации приложений (из-за которых нативные приложения всегда будут работать на порядок быстрее и экономичнее по отношению к заряду аккумулятора), но и свои способы взаимодействия с пользователем. Последние всегда будут отличаться, и не только из-за ограничений патентов на тот или иной способ, но и потому что каждый вендор будет стремиться реализовать свой собственный уникальный интерфейс, который по их мнению должен быть лучше (не без оснований можно быть уверенным), чем у конкурентов.
В итоге, продвигая свою платформы, вендоры будут всячески тормозить процессы стандартизации и развития браузерных технологий. Такое поведение мы можем наблюдать на примере скорости развития JavaScript (то огромное количество новых возможностей, что в нем появилось за последние 20 лет) и скорости появления новыхкостылейфреймворков, что только подчеркивают всю обреченность такого подхода.
eugef
24.01.2017 13:49+1Как раз таки Google активно продвигает идею веб-приложений как замену нативных — прочитайте про Progressive Web Apps.
Просто Google умеет очень хорошо монетизировать веб, но не нативные приложения.khim
25.01.2017 01:06А вы почитайте про Instant Apps.
Гугл вообще редко складывает яйца в одну корзину. Кто выиграет в этом соревновании — пока непонятно.
sokrat-nn
24.01.2017 13:49+2Просто оставлю это здесь https://developers.google.com/web/progressive-web-apps/. Весело получается когда вендор браузера и платформы одно и тоже лицо.
renskiy
24.01.2017 13:56Полагаю, что в этом случае вендор просто продвигает те веб технологии, под которые оптимизирована платформа и движок браузера. Я бы назвал это нечестной конкуренцией, но кого сейчас этим удивишь, ничего другого сейчас ожидать и не приходится.
nikitastaf1996
24.01.2017 15:01+1Вот еще недавняя ссылка.
https://www.reddit.com/r/Android/comments/5piod1/deeply_integrated_progressive_web_apps_webapks/
andreymal
24.01.2017 11:46+6Пожалуйста, не надо, я и на десктопе уже вдоволь настрадался с этими тормозящими и жрущими оперативу «веб-приложениями»™, автор теперь хочет чтобы я и на мобильнике страдал?
мы наблюдаем становление ботов
И как обычно игнорируется, что подобные боты существуют ещё с 80-х, я сам их клепал и юзал вместо браузера на мобильнике лет восемь назад будучи ещё школьником. (С музыкой, правда, боты раньше вроде не работали, но всё-таки)
VolCh
24.01.2017 13:30+1Стараюсь использовать нативные приложения, даже если это просто какой-то вебвью для сайта. Зашёл в плэй, нашёл и установил навсегда. Закладки менее удобны. Что до чат ботов, то даже гуглом и навигацией по целевому сайту обычно быстрее заказать такси или пиццу, не говоря о нативном приложении.
FirExpl
24.01.2017 13:49+8Это всё влажные мечты руководителей компаний, желающих сэкономить на нативной разработке :)
Woit
24.01.2017 21:53+2Неистово плюсую!
Да, я разрабатываю нативные приложения и, конечно же, заангажирован в пользу нативной разработки. Но, справедливости ради, отмечу, что работал долгое время и по другу сторону этого разлома. И сейчас, как и в комментарии 3-х летней давности, повторю свой тезис:
Веб-приложения вместо нативных — это хорошо, ровно до тех пор, пока от них требуется сделать что-то детское, например показать пару новостей (не ленту!) или поставить лайк. Как только требования повышаются (работа с железом, геолокация, нагруженные вычисления, гироскоп, аудовход и проч.), веб-приложения награждают вас адским *непечатное_слово*
Сейчас все больше встречаю смуззи-потребителей-стартапщиков, которые вроде начинают понимать, что нативная разработка это дело дорогостоящее. И мне это нравится. А вот им наоборот, ведь «че там сайт накидать да бутстрапом под мобилки заризинить» это же дешевле, да? ;)
kAIST
24.01.2017 22:11+2Как только требования повышаются (работа с железом, геолокация, нагруженные вычисления, гироскоп, аудовход и проч.),
Фиг с ним с железом, дайте мне хоть что то сделать оффлайн! Этим, кстати, бывает и разработчики нативных приложений грешат, я уж не говорю про браузерные приложения, которые без интернета превращаются в тыкву.
svanichkin
24.01.2017 13:49Очень надеюсь что всё будет как раз наоборот. Веб вымрет наконец и останутся нормально написанные нативные приложения заточенные под конкретную платформу, а не фонгапы, ксамарины и прочая кроссплатформенная вебдванольная ерунда.
Viacheslav01
24.01.2017 14:29+1Ну справедливости ради xamarin не web based, что не уменьшает моего к нему негативного отношения.
Logos_Intellect
24.01.2017 13:49+2Что-то я себе не очень представляю безболезненный переход от таких языков как Java(Kotlin) и Swift на JavaScript
savelichalex
27.01.2017 13:40очень легко, уже многие компилируются в JavaScript, в том числе и Kotlin
ElectroGuard
24.01.2017 14:15+1По своему опыту. Скайп, es проводник, навител, PowerAmp, курсы валют, калькулятор, вайбер, мобайл VoIP, букинг — всё нативное. В браузере, да, бывает — брожу по сайтам. Я, наверно, какой-то неправильный юзер.
StanKo
24.01.2017 15:16Он считает: у многих, кто говорит об этом, есть личная заинтересованность в выживании нативных мобильных приложений.
А тех, кто подобные статьи пишет, можно обвинять ровно в том же — они заинтересованы как раз в веб, а так же в основании, на котором можно заказчику оправдать, разработки его проекта как веб-приложения или на каком-то «фонгепе», которое будет тормозить, выедать батарею, греть девайс и полностью зависеть от того, какой браузер и какой версии установлен на смартфоне.
Ладно хоть в ведре теперь в основном хром, а в версиях до лолипопа каждый производитель пихал туда свою реализацию браузера и по этой причине такое приложение могло вовсе не работать и приходилось (или так оно и осталось?) в приложение тянуть еще и браузер свой. Это я еще не говорю за полную ущербность самой системы. На примере андроида: ОС запускает ява-машину, в ней запускает приложение веб-браузер, затем в этом браузере запускается конечное приложение. Это как запускать на компе виртуальную машину, а в ней уже запускать игру и ожидать, что производительность будет хотя бы сравнима с запуском напрямую.
Браузерные/фонгепные аппы в андроиде видно сразу по корявому интерфейсу и тормозам, они всегда ущербные. Пока браузер не станет ОС, такого не будет, а когда станет, то еще придется вытеснить с рынка существующие ОС, иначе повторит судьбу винды.darksith
24.01.2017 15:45+1Пока браузер не станет ОС, такого не будет, а когда станет, то еще придется вытеснить с рынка существующие ОС, иначе повторит судьбу винды.
У Firefox OS не вышло… Хотя система была весьма занятная, по случаю пришлось попробовать ее, когда угрохал свой основной девайс. Немного даже писал под нее, ради интереса… Честно говоря и уходить то не хотелось, но не устроили некоторые характеристики самого девайса.
DaylightIsBurning
24.01.2017 15:16+1Движение идёт с двух сторон. Браузер стаёт всё более похож на native (webassembly, webgl), а разработка под native движется в направлении универсальности(Qt/QML,Xamarin,...). В результате не исключено что native и «браузерные» подходы сольются. Представим себе, что Qt/QML приложение (нормальное, с применением C++) можно будет запустить в браузере и это будет нормально работать. Где тогда разница между native и браузером?
Разница между native и браузером в том, откуда берётся код/ресурсы — непосредственно из интернета или в основном с локальных носителей. Интернет никогда не будет так же быстр и надёжен как локальные носители, так что какой-то элемент native всегда будет.Woit
24.01.2017 21:56>>Представим себе, что Qt/QML приложение (нормальное, с применением C++) можно будет запустить в браузере и это будет нормально работать. Где тогда разница между native и браузером?
Разница в том, что не будет.
Kant8
24.01.2017 23:59+1Не знаю в какой вселенной у вас браузер всё больше приближается к нативным приложениям.
Почему у меня экселевский файлик из недавной статьи https://habrahabr.ru/post/320116/ на десктопе открывается и отрисовывается мгновенно и вызывает лишь небольшой всполох на графике загрузки процессора, а если его открыть из онлайн экселя, приходится ждать полторы минуты, пока браузер усердно поедает ОДНО ядро из четырех?
Как была скорость браузеров во всем, что отличается от отображения текста, не выше улитки, так и осталась.DaylightIsBurning
25.01.2017 00:44Ну я же привёл примеры движения браузеров в сторону native — webassebly и webgl. Первый ещё не готов (потому и «движение»), но второй даже пощупать можно, даже квейк3 вроде кто-то запускал. Так что работа в этом направлении идёт, а там видно будет.
khim
25.01.2017 01:15Где тогда разница между native и браузером?
Разница в том, что одно будет выжирать батарейку за час, а другое за два.
Все эти бесконечные слои абстракций современные устройства «перемалывают» неплохо, но чудес ведь не бывыет — если делается дополнительная работа, то требуется больше энергии.
Так что приложения, в которых люди будут зависать часами всегда будут нативными.
P.S. Правда есть и такие нативные приложения, которые жрут больше браузерных (Facebook, например) — но это уже и разряда «сдуру можно и х$й сломать».DaylightIsBurning
25.01.2017 01:39одно будет выжирать батарейку за час, а другое за два.
с чего бы? Если это так сейчас — не значит, что так будет всегда.
если делается дополнительная работа, то требуется больше энергии.
Если. Дополнительная работа не обязательна, тем более не обязательно её выполнять на мобильном устройстве.khim
25.01.2017 03:29Дополнительная работа не обязательна, тем более не обязательно её выполнять на мобильном устройстве.
Это, я извиняюсь, как? Web — это по определению ненативный (с точки зрения CPU) код. И кто-то, как бы, должен его транслировать. Эта разница и чисто теоретически никуда деться не может, а практически — разница в лучшем случае в 20-30% обеспечена (это в теории, в будущем, когда webassembly получит популярность), а практически — речь скорее идёт о 3-10 разах сегодня (через asm.js). Причём это очень условно «web-технлогия» — скорее это способ загнать нативный код «в прокрустово ложе web'а». Использование же разнообразных фремворков доводит разницу до десятков раз! При этом в случае с настольным устройствами и даже всякими ноутами это может быть не критично (экран ноута может больше жрать, чем CPU!), то в случае с мобильгиками всё это сразу превращается в «удар по батарейке».
Но на мобильных устройствах нет проблем выдать «настоящий» мобильный код.DaylightIsBurning
25.01.2017 14:02Web — это по определению ненативный (с точки зрения CPU) код
Это не так. Сейчас web де-факто ненативный, но нет никаких фундаментальных причин, что бы так было всегда.
Эта разница и чисто теоретически никуда деться не может
Может, и консорциум крупных игроков уже занялся технической реализацией этой идеи.ElectroGuard
25.01.2017 15:55+1Если в вебе будет нативный код, зачем тогда вообще браузер? Запустил на операционке и работай, зачем лишние прослойки, которые сами по себе создают дополнительные сложности? Какие преимущества могут дать браузеры по сравнению с чистой OS? Зачем продираться через тернии прослоек к OpenGL? К другому железу? Если просто собрал, запустил и работает? Я не с целью потроллить, но реально обсудить.
khim
25.01.2017 16:50Какие преимущества могут дать браузеры по сравнению с чистой OS? Зачем продираться через тернии прослоек к OpenGL? К другому железу? Если просто собрал, запустил и работает? Я не с целью потроллить, но реально обсудить.
Чтобы «два раза не вставать». Операционок типа много, а Web — один. Только нифига это не работает. Web-приложения работают везде — но везде одинаково убого.
Через эти «качели» индустрия регулярно проходит. Когда персональные компьютеры только-только появились тоже подобные попытки были (P-код, SCUMM и т.д. и т.п.), но после появления стандарта (вернее двух: Windows и MacOS) всё это постепенно отошло на второй план.
На рынке мобильных платформ тоже всё давно устаканилось, так что вряд ли сейчас это заинтересует кого-то, кто может разрабатывать нативные вещи на языка типа C/C++/Fortran/etc (а другие с webassembly не работают, JavaScript туда не засунуть).
DaylightIsBurning
25.01.2017 17:57Если в вебе будет нативный код, зачем тогда вообще браузер?
Я об этом и говорю:
В результате не исключено что native и «браузерные» подходы сольются.
Браузер — это универсальный формат, если аналогичный универсальный формат для нативных приложений удастся внедрить — разницы не будет.khim
25.01.2017 21:28Если аналогичный универсальный формат для нативных приложений удастся внедрить — разницы не будет
Этот поезд уехал очень и очень давно.
Топ-менеджмент, руководящий разработкой браузеров из Apple, Google, Mozilla, и Microsoft категорически против. Не в духе «это несвоевременно», а в духе «только через мой труп».
Я собственно участсовал в попылке продвинуть нечто подобное лет 7 назад. Заявление в духе «открытый Web никогда не будет привязан ни к одной ISA» было произнесено в весьма категоричной форме и за прошедшие 7 лет ничего не изменилось. А если вы готовы ограничиться одним «магазином» (неважно — Chrome Web Store или addons.mozilla.org), то вы немедленно теряете самое главное преимущество: возможность использовать всё это на миллиардах устройств.DaylightIsBurning
25.01.2017 21:50Эту организационную проблему, возможно, удастся обойти через webasm. Я вижу следующий механизм: сначала внедряется компилируемый формат webasm, приобретает распространение, но браузеры всё ещё вынуждены компилировать это все либо траслировать (2018-2019). В любом случае скомпилированное представление будет кешироваться. Далее остаётся один шаг — кешировать скомпилированное представление на стороне «веб-сайта» и, соответсвенно, поддержать его загрузку на стороне браузера (2020-?). Всё, native web готов. Такими маленькими шагами шансов на внедрение больше, имхо.
khim
25.01.2017 23:23-1Эту организационную проблему, возможно, удастся обойти через webasm.
Собственно webasm и появился как ответ на этот ультиматум.
Далее остаётся один шаг — кешировать скомпилированное представление на стороне «веб-сайта» и, соответсвенно, поддержать его загрузку на стороне браузера (2020-?).
Мы всё равно остаёмся с промежуточным, ограниченным, байткодом и по-прежнему не можем использовать даже все возможности CPU (не говоря уже обо всём остальном, что можем нативное приложение).
А также появляется куча проблем с приватностью, безопасностью и прочим (так как раздавать бинарники по-прежнему нельзя, то «сервис компиляции» должен быть предоставляться кем-то ещё).
Всё, native web готов.
Неа. Уже 7 лет прошло с момента появления работающего решения — за это время много чего произошло, но главное — разработчики уже давно «забили» на Web и клепают нативные решения.
Тот факт, что ограничение «чисто организационное» не делает его фигнёй. Иные «организационные» решения сложнее изменить, чем своротить горы.
khim
25.01.2017 16:40-1Сейчас web де-факто ненативный, но нет никаких фундаментальных причин, что бы так было всегда.
Нежелание разработчиков браузеров это допускать — фундаментальная причина или нет?
Может, и консорциум крупных игроков уже занялся технической реализацией этой идеи.
Вы бы хоть первую фразу из статьи, на которую вы ссылаетесь прочитали, а? Низкоуровневый бинарный компилируемый формат — изобретён как раз из-за категорического нежелания допускать нативный код в Web.DaylightIsBurning
25.01.2017 18:07Нежелание разработчиков браузеров это допускать — фундаментальная причина или нет?
Организационная.
Вы бы хоть первую фразу из статьи, на которую вы ссылаетесь прочитали, а? Низкоуровневый бинарный компилируемый формат — изобретён как раз из-за категорического нежелания допускать нативный код в Web.
Хамства не надо. Низкоуровневый бинарный компилируемый формат — это по сути технический способ сделать универсальный native, чем по сути native web и должен быть. Нужно просто договорится, в каком формате native должен быть описан. На практике, наверное, можно будет даже для разных платформ разный код отдавать, как это сейчас по сути делается под разные браузеры (или аналогично разные версии эппов под разные платформы в магазине приложений). Главное только что бы платформа понимала, что ей отправляют нативный код и как его запускать.khim
25.01.2017 21:16Низкоуровневый бинарный компилируемый формат — это по сути технический способ сделать универсальный native
Не бывает. Либо у вас native, в том или ином виде, либо у вас бинарная трансляция. Которая требует в разы больше ресурсов. Особенно для использования в виде «запустил, посмотрел, закрыл».
На практике, наверное, можно будет даже для разных платформ разный код отдавать
Нельзя. Тут как раз мы упираемся в «несерьёзную» «организационную» проблему, описанную выше. Из-за которой Native Client был ограничен Chrome Web Store (а потом и удавлен ибо только в Chrome Web Store он мало кому нужен). Реакция разработчиков из Mozilla Foundation по уровню истерики напоминала реакцию сторонников Клинтон на инагурацию Трампа.
В результате сегодня Web принудительно загнан в рамки, в которых он гарантированно проигрывает по скорости и энергопотреблению нативным приложениям.DaylightIsBurning
25.01.2017 21:55Либо у вас native, в том или ином виде, либо у вас бинарная трансляция
По-любому появится JIT compilation, а там и до AOT и прекомпилированных объектов рукой подать.
Тут как раз мы упираемся в «несерьёзную» «организационную» проблему, описанную выше.
Думаю, постепенно это решиться само собой.khim
25.01.2017 23:41По-любому появится JIT compilation, а там и до AOT рукой подать.
webassembly изначально затачивается под AOT, не в этом дело. AOT никогда не сравнится с нативным кодом просто потому, что железо меняется, а консорциумы, разрабатывающие всё это — отстают. Отстают не на месяцы — на годы.
прекомпилированных объектов
А вот этого — не будет.
На основании чего вы так думаете? Посмотрите, чёрт побери, сюда — и обратите внимание на дату! Всё ваши чудеса, о которых вы тут вещаете, уже были реализованы — много лет назад! Удивительное рядом… но оно — запрещено!!!Тут как раз мы упираемся в «несерьёзную» «организационную» проблему, описанную выше.
Думаю, постепенно это решиться само собой.
Pазработчикам сказали: «память — поглощать, баратейку — жрать, нативному коду не бывать» — и точка. Усё. То, что было разработано с тех пор даже близко не приближается по степени удобства и эффективности к тому, что было реализовано семь лет назад (скоро уже восемь). Но зато — кроссплатформенность, нету нативного кода, нирванна.DaylightIsBurning
26.01.2017 12:27+1AOT никогда не сравнится с нативным кодом просто потому, что железо меняется
Что мешает развитию AOT вместе с железом?
Удивительное рядом… но оно — запрещено!!!
То, что один раз усилиями отдельного игрока не отдалось пропихнуть идею, ещё не значит, что никому и никогда это не удастся. Может быть теперь время пришло.khim
26.01.2017 14:38-1Что мешает развитию AOT вместе с железом?
Грубо? WHATWG. SSE2 — 2001й год, NEON — 2009й, WebAsseembly — 2014й. Задержка — порядка 10 лет. А у нас тут уже всякие новые новые плюшки на походе — которые тоже будет 10 лет стандартизовываться.
То, что один раз усилиями отдельного игрока не отдалось пропихнуть идею, ещё не значит, что никому и никогда это не удастся.
Может кому-нибудь в следующем тысячелетии и удастся, но для этого сначала новые игроки должны появиться. Существующим — это не нужно. У Гугла, как я уже сказал, альтернативная технология есть, Apple и Microsoft — всячески стараются загнать всех в свои магазины, а Mozilla — вечный «борец за чистоту Web'а». И? Кто остался? Кто будет вашу идею пропихивать и, главное, зачем?
Может быть теперь время пришло.
Наоборот. Время уже почти ушло. Приход смартфонов Web-технологии уже просрали, теперь осталось дождаться пока Android придёт на десктоп — и всё: смысла во всех этих прослойках не будет снова.
BupycNet
24.01.2017 18:37+1Мы тоже согласны с этой точной зрения. Например весь наш проект (PushAll) задумывался с той лишь целью, чтобы можно было не городить приложение чисто ради пушей, т.к. 90% всего плейстора это веб-вью + пуши. Если отделить пуши в отдельное приложение и предоставить их в любом удобном для пользователя виде на любой платформе, то мы получаем, что пользователь может кликать по пушу и попадать на сайт, хорошо адаптированный для мобильного устройства, или кликнув на компьютере — для ПК. Иначе сейчас имеем например ситуацию, когда есть инстаграм, у которого из поддержки только мобилки, растянутое на айпаде и нет возможности управлять всем с компьютера, даже нормально смотреть кто тебе что там поставил. Многие компании пилят чисто приложения — и с компьютера они недоступны, и все это под фразы, что компьютером сейчас никто не пользуется.
kAIST
24.01.2017 21:23+1Соглашусь с вами. Сейчас делаю небольшой сервис, который хорошо работает в браузере, но единственное что надо, это пуши пользователям. Хотел уже завернуть все это дело в phonegap и сделать пуши, но вспомнил про одного вашего конкурента, пробую юзать сторонний сервис. Единственное, что — устанавливать стороннее приложение и там регистрироваться, немного сложновато для некоторых пользователей.
BupycNet
24.01.2017 21:24А про какого конкурента? Не знаю ни одного который бы поддерживал и веб-пуши и мобильные уведомления на Android, iOS плюс у нас и телерам бот есть.
И у нас нет регистрации — точнее есть вход через гугл аккаунт в один клик, и опционально есть рега, но ей пользуется менее 1% человекkAIST
24.01.2017 21:45Pushbullet — есть все, кроме telegram бота. Так же вход через аккаунт гугла. Возможности у вас похожи, я смотрел вас тоже, но не только на российскую аудиторию хочу ориентироваться.
BupycNet
24.01.2017 22:15Так пока да :) к слову можно и то и то брать. К слову у пушбулета вроде как веб пушей нет. У них именно расширение только под браузеры. Плюс приложение перегружено. И там разве можно выборочно отправлять уведомления отдельным пользователям канала или списку людей из канала? У них вроде каналы всегда на всех идет рассылка.
Мы сделаем поддержку английского на всем сайте в течении пары месяцев скорее всего.
Пушбулет сильно не из той оперы. У них таки сервис для шаринга пушей с телефона на комп. Каналы это отдельная функция дополнительная.kAIST
24.01.2017 22:41Там и не нужно по каналам слать, у них есть 0auth, то есть я могу от имени юзера слать ему же пуши.
Мне как раз таки это показалось более логичным, чем возиться с каналами.BupycNet
24.01.2017 22:49А про это я забыл. Все таки если у вас неайтишная аудитория то мало подойдет т.к. все на английском. Но вот то что оно от имени юзера летит тоже так себе. Не видел кстати в РФ ни у кого через пушбулет уведомления
Shamov
24.01.2017 19:18+1Мне нравится его уровень концептуализации. Боты — это новые закладки. Но, на самом деле, если так рассуждать, то нативные приложения — это ни что иное, как толстые закладки. Боты — тонкие, а приложения — толстые. Вообще всё, что как-то работает с вебом, — это в каком-то смысле закладки. Просто сам веб устроен таким образом, что в нём нельзя сделать ничего концептуально иного, кроме ресурсов и закладок на эти ресурсы. Можно лишь по-разному распределять функциональность. Если оттянуть большую часть в сторону веб-ресурса, то получится связка ресурс + тонкая закладка (текстовый бот/приложение в браузере). Если же оттянуть значительную часть функционала в сторону клиента, то получится связка ресурс + толстая закладка, называемая нативным приложением.
prostovovan
27.01.2017 13:40100%! А так как любой сервис заинтересован в «привязке» клиента, то и перспективы у приложений гораздо лучше. Конечно, если не свершится какой-то веб-революции…
aamonster
24.01.2017 19:50+1Хм… Беда в том, что если у вас не супер-пупер-дупер офигенная команда и куча денег на разработку — то browser-like приложение будет кривым недобраузером.
Характерный пример — приложение aliexpress, в котором даже табов (чуть ли не основной функционал для современного браузера) нет. И осовная польза от него — скидки за заказ в мобильном приложении. Найти товар на сайте и заказать через приложение — оригинально-с.
Так что если ваше приложение построено вокруг webview — это повод задуматься, нужно ли оно вообще.
Shamov
25.01.2017 00:24Более того, даже если у вас супер-пупер-дупер офигенная команда и куча денег на разработку, то приложение всё равно будет голимым куском говна. Характерный пример — приложение Youtube. Если я при просмотре ленты добавляю какое-нибудь видео в список "Посмотреть позже", а затем перехожу на экран, где этот список отображается, то это видео, только что добавленное через соседний экран, я в этом списке вот так вот сразу не вижу. Чтобы его увидеть, мне нужно вручную сделать рефреш.
ilya_pu
24.01.2017 20:01«Средний американец скачивает 0 приложений в месяц» — вы уверены?
Во-первых: «Most smartphone users download zero apps per month» переводится на русский не как «средний пользователь смартфона скачивает 0 приложений в месяц», а как «большинство пользователей смартфонов скачивает 0 приложений в месяц».
При этом среднее число установок в расчёте на 100 пользователей составляет примерно 110 (1 приложение — 8,4%, 2 приложения — 8,9%, 3 приложения — 6,2%, 4 приложения — 3,7%, от 5 до 7 приложений (берём среднее, 6) — 4,8%, 8 и более приложений (закрываем интервал по аналогии с соседним, то есть предполагаем, что этот интервал — от 8 до 10 приложений в месяц, и берём его середину — 9) — 2,4%. В итоге, перемножив число приложений на проценты, получаем 110 приложений, которые приходятся на 100 пользователей смартфонов, или в среднем — 1,1 приложение в месяц).
То есть по-настоящему «средний» пользователь смартфона всё-таки скачивает по одному приложению в месяц! И, кстати, вот что на том сайте пишут (немного вольный перевод с помощью гугля):«Это не значит, что приложения не являются полезными, просто более половины американских пользователей смартфонов (по данным ComScore) работают с приложениями каждый день. И это не вызвано тем, что они слишком дороги: большинство приложений являются бесплатными, а цены на приложения, как известно, начали соревноваться в гонке на понижение сразу после того, как App Store дебютировал. Так в чем же дело? Одним из возможных объяснений этого является то, что людям просто не нужно множество приложений, а приложения, которые уже у людей есть, подходят для большинства функций. Почти все владельцы смартфонов используют приложения, и „ошеломляющие 42% всего времени, потраченного на приложения смартфона, происходит в работе с одним, наиболее часто используемым приложением“, сообщает ComScore. Новые приложения приходят и уходят, особенно игры, но, возможно, прорывные приложения будут все более редкими. Посмотрите на топ-25 наиболее часто используемых приложений: в основном это зрелые компании, такие как Facebook, Google, Pandora и Yahoo.
Другой вероятной причиной является то, что всё ещё нелегко найти и загрузить новые приложения. App Store от Apple получил критику за свои негодные функции обнаружения, заставляющие пользователей в значительной степени полагаться на топ-25 списков, плохой поисковой системы, а также несколько функций редактирования. В основном, это помогает богатым становятся богаче, и затрудняет новым умным приложениям сделать так, чтобы их заметили. Apple имеет право гордиться своим приложением по установке программ — это было одним из самых важных изобретений в истории программного обеспечения, и Google сделал приличную работу копирования. Но есть, конечно, место для совершенствования.
Что привело к сокращению числа скачиваний? На мой взгляд, прежде всего — падение интереса ко всему новому. Приложения, конечно, обладают некоторой новизной, но их объединяет нечто большее — платформа, и раз уж пользователь знаком с платформой, принципами её работы и основными параметрами приложений, создаваемых для этой платформу, он сделает вполне логичный вывод, что и остальные приложения от известных ему не сильно отличаются. То есть, впервые купив себе телефон с андроидом, человек может скачать сотню однотипных программ (ну, например, фоторедакторов), однако в какой-то момент он достигает состояния насыщения, становится гораздо более разборчив, а следовательно — перестаёт бездумно устанавливать программы по пачке в день (и действительно, те 2/3 респондентов, которые заявили, что в среднем устанавливают в месяц 0 программ, вполне себе могут устанавливать программы — просто не чаще 1 программы в 2-3 месяца… вы себе на компьютере чаще программы новые устанавливаете?).
Первый телефон на андроиде появился у меня лет эдак 6 назад. Сегодня моему рабочему смартфону 3 года, он пережил 2 замены аккумуляторов (живут как раз в районе года, потом начинают греться и терять ёмкость) и штуки три — переустановки системы. Сколько приложений я скачал за 3 года жизни последнего моего смартфона — ну, может, штук 100, не больше. Причём как скачивал — когда купил телефон три года назад, закачал всё, что хотел (на 6 или 7 экранов по 20 иконок, причём это — с нативными приложениями — специально их сейчас пересчитал, оказалось немногим больше 40 штук), а перед переустановками андроида просто чистил список оставляемого софта (сначала в топку полетели не понравившиеся приложения, потом — игрушки, под конец — то, что не использую, а устанавливал — чтобы посмотреть, что это за оно).
Сегодня я придерживаюсь стратегии минимализма: всё, чем не пользуюсь, стараюсь удалить или отключить. После крупных „удалялок“ софта делаю хард ресет, чтобы „накатить“ чистую систему, и уже поверх неё — нужные мне приложения. Результат — смартфон живёт, здравствует (и, надеюсь, будет продолжать меня радовать своей работой ещё пару-тройку лет). Да, бывает, раз в 3-5 месяцев я узнаю про какую-то программу, которая может оказаться полезной мне — устанавливаю, тестирую, а потом — решаю, оставлять или нет после очередного хард-резета…
Кстати, я свой смартфон в ближайшее время менять не собираюсь — по своим параметрам модель будет давать фору многим собратьям среднего ценового сегмента ещё пару лет как минимум… Конечно, смартфон „держит заряд“ только один день, телефонные разговоры не записывает (для телефонного общения ведь можно и простую „трубку“ купить, верно? и заряд она будет держать не часы, а недели), но от него это и не требуется…skssxf
25.01.2017 19:19Вот как раз одна из ключевых проблем нативных приложений: если сходить на 100 сайтов, то система медленнее работать не станет, а если установить для «попробовать» 100 приложений, то падение производительности может быть существенным. Каждое нативное приложение несёт в себе рекламный или следящий модуль, которому очень хочется всё знать, все они подписываются на всевозможные события, при подключении к сети дружно начинают ломиться, чтобы отдать статистику, обновить данные и т.п. По крайней мере, для андроида 4-х это так. Средний пользователь никогда не будет делать полных сбросов к заводским настройкам, он будет страдать от тормозов, а потом купит новый аппарат, и на него устанавливать будет уже по-минимуму, тем более, что ключевые социальные сети обычно предустановлены.
ElectroGuard
25.01.2017 21:58Судя по данным в этой же статье, по сто приложений уже давно никто не устанавливает. Поэтому проблема надумана.
skssxf
25.01.2017 22:36Возможно, неудобства, связанные с установкой, являются одной из причин того (хоть и не главной). Когда установка как таковая станет процессом размытым, легковесным и скрытым от глаз пользователя, похожим на посещение сайта, есть шанс, что приложения будут запускать чаще. Так, бытует мнение, что средний пользователь посещает как раз порядка 100 сайтов в месяц.
ElectroGuard
25.01.2017 22:51Главная причина, думаю, всё таки в том, что пользователю редко нужно множество похожих программ. По своему опыту и моих знакомых — это один браузер, один навигатор, один калькулятор, один (максимум — несколько) текстовых редакторов. Если телефон используется геймером — ну может пяток игрушек. Сайты всё таки намного более разнообразны, чем программы, в сотню сайтов в месяц верю. В сотню программ — нет :)
Woit
24.01.2017 22:08Разговора с копипастой нить иди…
Важно, чтобы следующее поколение производителей программного обеспечения не ограничивалось созданием только нативных версий веб-приложений под iOS и Android.
Важно кому? Бизнесу, например, важно в первую очередь сделать качественный продукт. И нативный продукт, объективно, качественнее
Не создавайте под iOS или Android только ради мнимых возможностей распространения.
Логическая подмена (см. «чучело»). Полагаются не на возможности распространения (и они не мнимые!)
Burleh
27.01.2017 13:40Коллеги, честно, уровень знаний многих из вас реально зашкаливает. Это не сарказм и не наезд. Приятно читать было. НО НО НО вы забываете одну простую вещь — сегментация рынка была есть и будет.
Какие бы технические преимущества не имели нативные апы… они не нужны в массовом бизнесу… они нужны для закрытия специализированных задач, бесспорно… а вот для закрытия самых простых задач — мобильного обслуживания своего конечного потребителя, они бизнесу не нужны… и для массового круга других вопросов тоже… Тут выше кто то сказал — что мол наконец бизнес начинает понимать, что за нативные апы надо платить больше. Да не начал он это понимать, потому что НЕ нужно это бизнесу — платить больше, я вам как основатель двух работающих самостоятельно и владелец еще одной нетехнологических компаний говорю. Всегда искал и буду искать способ платить меньше или вообще не платить, чтобы закрыть ту проблему которая у меня есть, а не запустить ракету в космос, где все четыре ядра будут загружены и батарея будет в два раза дольше жить… бла бла бла :) ну честно :)…
Поэтому мой третий стартап, то есть текущий, и уже технологический — Mobsted Inc, занимается почти два года уже законченной платформой для решения именно этой проблемы. Клиенты вроде бы и хотят получать сервис с экрана на ладони, но качать, ставить и регаться не хотят. Бизнес вроде бы и хочет "обслуживать" клиентов со смартфона, но стоимости разработки и поддержки ТУПО НЕОКУПАЕМЫ даже для компаний с оборотом 10-20-30+ млн рублей в месяц и даже с 200+ оборотом есть несколько клиентов которые это поняли и ушли на нас! И вот об этот простой факт все технические аргументы просто, извините, но в хлам ломаются.
khim
27.01.2017 19:22НО НО НО вы забываете одну простую вещь — сегментация рынка была есть и будет.
Авторы обсуждаемой тут статьи тоже об этом забывают.
Всегда искал и буду искать способ платить меньше или вообще не платить, чтобы закрыть ту проблему которая у меня есть, а не запустить ракету в космос, где все четыре ядра будут загружены и батарея будет в два раза дольше жить… бла бла бла :)
Это зависит от бизнеса, сошласитесь? Если мой банк-клиент будет работать в 10 раз дольше и жрать батареи в 10 раз больше — я вполне переживу. Это ж мой телефон на целых 10 минут в неделю меньше проработает — это не проблема ни разу. А вот если у меня будет в 2 раз дольше работать приложение, с которым я работаю постоянно (да госсподи… читалка книг какая-нибудь), то я поищу что-нибудь другое.
Подавляющему большинства бизнеса не нужны программы, с которыми пользователь будет работать часами — тут вы правы. Но утверждать на этом основании, что нативные приложения умрут… Два платформы, где они были запрещены… BlackBerry и Windows Phone 7 — не подскажете, где они?Burleh
31.01.2017 14:04Это зависит от бизнеса, сошласитесь?
Да, 100% зависит от бизнеса. Я и говорю — не нужны массовому бизнесу. Я и не утверждаю что они вымрут, все равно будут кейсы где либо к железу нужен доступ, либо например к контактам очень нужен (это даже chrome на ведре не дает сейчас, что нам например рушит часть кейсов для PWA). Речь о том что, золотой век апов завершился
Два платформы, где они были запрещены… BlackBerry и Windows Phone 7 — не подскажете, где они?
Не согласен с примером! (1) BB просто очень долго держались за свой BBM, а приложения можно было еще и на Symbian ставить, что я и делал, и где они? Там другие совершенно причины провала. (2) история себя не всегда повторяет, и с ростом мобильных скоростей и возможностей браузера причиной очередной "бизнес ошибки" уже может быть не тупость человеческая, а чистый технологический distrupt, каким бы заезженным в стартаперских кругах не был этот термин.
khim
01.02.2017 00:10BB просто очень долго держались за свой BBM, а приложения можно было еще и на Symbian ставить, что я и делал, и где они?
Уничтожены по воле владельца вместе с компанией. Ещё в 2010м у Symbian'а было почти 50 процентов рынка, но его убили как раз в угоду Windows Phone 7.
с ростом мобильных скоростей и возможностей браузера причиной очередной «бизнес ошибки» уже может быть не тупость человеческая, а чистый технологический distrupt, каким бы заезженным в стартаперских кругах не был этот термин.
Теоретически — не исключено. А практически — попытки внедрить платформы без поддержки нативного кода продолжаются уже не первое десятилетие и на том погорели уже много компаний, а успеха всё нет. Поддержка всяких интерпретаторой и JITов — хорошо, невозможность использовать BLAS == смерть платформе.
VolCh
28.01.2017 08:21а вот для закрытия самых простых задач — мобильного обслуживания своего конечного потребителя, они бизнесу не нужны…
Бизнесу не нужны лояльные клиенты? Например, службе такси не нужен клиент, который будет запускать приложение "*Такси", а не гуглить «такси» и переходить на первый попавшийся сайт?Burleh
31.01.2017 13:55Когда речь идет о PWA приложениях, то есть обеспечивается повторяемость входа (это один из принципов progressive), то я считаю что не нужны. Ну и плюс (1) лояльность клиента не достигается ОДНИМ фактором, и апы это микро способ способ поднять лояльность и это не есть точка продаж для апа имхо,… мы пока сталкиваемся только с вопросами типа — что я могу сэкономить — от не тратить бумагу и время до быстрее получать оплаты (2) статистика говорит, что уровень отказа 95% в среднем после установки и первого запуска. Причины разные, от клиент забыл где оно и как оно, до не понравилось — то есть — воронка продаж и до установки то тяжелая, а после дак вообще ахтунг… вспомните недавно Волож младший — как не бились, не более 10% выручки из апов, а косты не адекватные, и тоже ушел на web apps.
sargeras55
01.02.2017 00:22Я не понимаю людей, которые категорично занимают определенную сторону в вопросе и рассматривают все с одной стороны. Какое приложение нужно, можно выявить только исходя из политики, сферы деятельности вашей организации(организациям одной сферы деятельности вообще могут понадобится разные виды приложения), учитывая, что я занимаюсь нативной разработкой под Android и iOS, понимаю, что не всегда у организации есть средства на такую разработку(т.к. порой она обходится в несколько раз дороже), либо она вовсе им ненужна, в некоторых случаях вполне подойдет kordova, xamarin и прочие технологии. Бывают моменты, когда приложение лучше не делать вообще, чем сделать его не нативным, приложения в которых важна высокая скорость, четкость и плавность анимации, надежность, устойчивость к высоким нагрузкам, все то, что не могут дать кросплатформенные, браузерные аналоги. И вообще в последнее время чувствуется тенденция перехода работы с приложениями через помощники(google assistant, siri и т.д.)
ElectroGuard
01.02.2017 17:27Можно вспомнить того же Цукерберга (согласитесь, далеко не последний человек и компания в IT):
Цукерберг признал ошибочность использования HTML5 в мобильных клиентах Facebook
В ходе общения с Майклом Аррингтоном (Michael Arrington) на конференции TechCrunch Disrupt глава Facebook Марк Цукерберг (Mark Zuckerberg) признал, что его компания совершила немало ошибок. Одной из самых серьезных в последнее время оказалось решение использовать HTML5 на мобильных платформах, сообщает The Verge.
В рамках интервью с основателем самой популярной в мире социальной сети речь шла о применении HTML5 вместо родного кода для мобильных платформ. Результатом этого была очень нестабильная и неэффективная работа клиентов Facebook для iOS и Android. Фактически, по словам Цукерберга, компания потеряла впустую два года, пытаясь довести до ума HTML5-версии своих мобильных программ.
sargeras55
01.02.2017 17:45Говоря о «браузерных», я имел ввиду cordova, соглашусь не совсем верно, но стек технологий тот же
Burleh
01.02.2017 17:59Позиция ровно такая же — нативный нужны ровно тогда когда они нужны. Нагрузки такие как FB или мессенджеры, это естественный выбор. Апы для банков, ну как бы нууууу, как бы ну ладно, разве что ради безопасности. Но например, сфера ЖКХ, автосалоны, медицина, обучающие центры, да и апы для собственных сотрудников компаний наконец? Логичней, быстрее и дешевле сделать progressive web? Разе нет? И даже вопросы "работает оффлайн" решаются! Как я сказал ранее — сегментация работает всегда. Рынок "мобильных взаимодействий между бизнесом и потребителем" фактически значительно больше чем то, что имеет экономический смысл окучивать именно нативом.
VolCh
03.02.2017 07:09Когда речь идет о PWA приложениях, то есть обеспечивается повторяемость входа (это один из принципов progressive), то я считаю что не нужны.
Не понимаю фразы. Бизнесу не нужна повторяемость входа? Или нужна, но он больше доверяет SEO, а не списку приложений на девайсе пользователя?
sand14
Если тенденция сохранится, то веб-приложения и станут новыми нативными, а браузеры превратятся в среду для исполнения JS и рендеринга HTML (или того, что придет им на смену)
estin
webassembly/wasm например