Comments 92
Индексные базы данныхТермин IndexedDB не переводится, так же как и
Web SQL (так же, как и DOM, например).
UFO just landed and posted this here
Какая-то попытка перевернуть все с ног на голову.
Во-первых необходимо сравнивать сопоставимые вещи. Конечно, в ОС, где все ориентировано под натив, веб-приложению уделяется гораздо меньше внимания, чем следовало бы. И, скорее, это недоделки мобильных браузеров, чем какие-то проблемы веб-приложений.
Давайте будем честными и будем тогда сравнивать Android, iOS и Firefox OS, Tizen, Chrome OS. К слову, последние еще на стадии разработки — факт, но факт еще и в том, что после всего этого натива гиганты индустрии все же смотрят в сторону веб-приложений.
1. Интерфейс работы с оборудованием.
Опять же, я думаю, что в скором времени мы увидим прекрасные расширения стандарта HTML5 для работы с железом.
> По контрасту, парадигма веб-приложений — документо-центрична. Архетипичное веб приложение в основе визуально, находится в своей собственной песочнице и завершается, как только пользователь закрывает соответствующее окно браузера.
Что-то я не заметил, чтобы музыка, играющая на одной из вкладок моего браузера вдруг перестала играть, когда я переключаюсь на другую вкладку браузера, при этом никакой визуализации не требуется. Да, это на десктопном компе, но это опять же говорит не об ограниченности веб-приложений, а об ограниченности браузеров на мобилах.
2. Отсутствие повсеместного доступа в Интернет
А вот это уже чистой воды недостаток мобильных устройств. Не доросли пока мобильники до полноценных устройств.
2. Доступ к многим «видам (поверхностям)» отображения
Опять же, давайте рассматривать все же ОС, ориентированные на веб-приложения.
3. Фоновое управление памятью.
Одна из основных головных болей разработчика натива — управление памятью. Вообще-то когда ОС управляет памятью — это более правильно. Я пишу на Ruby и давным-давно уже забыл все эти «прелести» пожирания памяти, после перехода на системы разработки, где виртуальная машина исполнения сценария (назовем так) сама заботится о правильном выделении и освобождении памяти.
А тут это выдается за преимущество? Что за бред?
Насчет приоритетов приложения, тут тоже надо подумать… есть многозадачность… а то, что Андроид не может проигрывать музыку и тихонько без шума (без паузы) получить сообщение, так это наверное все же проблемы многозадачности Андроид.
4. Внешний вид
Да-да, давайте всех снова загоним под общие интерфейсы. При этом автор лукавит, говоря о фрагментированности веб-приложений, и умалчивая об еще бОльшей фрагментированности натив-приложений — когда даже под одну ОС приходится реализовывать множество версий приложений для конкретных мобильных устройств, отчасти именно благодаря различному разрешению устройств. И это благо? Сомневаюсь.
Возможно, автор просто как и Цукерберг — ниасилил. А точнее будет сказать, что надо подождать еще немного развития именно ОС ориентированных на веб-приложения, а потом уже делать выводы о том, что натив — это хорошо.
Во-первых необходимо сравнивать сопоставимые вещи. Конечно, в ОС, где все ориентировано под натив, веб-приложению уделяется гораздо меньше внимания, чем следовало бы. И, скорее, это недоделки мобильных браузеров, чем какие-то проблемы веб-приложений.
Давайте будем честными и будем тогда сравнивать Android, iOS и Firefox OS, Tizen, Chrome OS. К слову, последние еще на стадии разработки — факт, но факт еще и в том, что после всего этого натива гиганты индустрии все же смотрят в сторону веб-приложений.
1. Интерфейс работы с оборудованием.
Опять же, я думаю, что в скором времени мы увидим прекрасные расширения стандарта HTML5 для работы с железом.
> По контрасту, парадигма веб-приложений — документо-центрична. Архетипичное веб приложение в основе визуально, находится в своей собственной песочнице и завершается, как только пользователь закрывает соответствующее окно браузера.
Что-то я не заметил, чтобы музыка, играющая на одной из вкладок моего браузера вдруг перестала играть, когда я переключаюсь на другую вкладку браузера, при этом никакой визуализации не требуется. Да, это на десктопном компе, но это опять же говорит не об ограниченности веб-приложений, а об ограниченности браузеров на мобилах.
2. Отсутствие повсеместного доступа в Интернет
А вот это уже чистой воды недостаток мобильных устройств. Не доросли пока мобильники до полноценных устройств.
2. Доступ к многим «видам (поверхностям)» отображения
Опять же, давайте рассматривать все же ОС, ориентированные на веб-приложения.
3. Фоновое управление памятью.
Одна из основных головных болей разработчика натива — управление памятью. Вообще-то когда ОС управляет памятью — это более правильно. Я пишу на Ruby и давным-давно уже забыл все эти «прелести» пожирания памяти, после перехода на системы разработки, где виртуальная машина исполнения сценария (назовем так) сама заботится о правильном выделении и освобождении памяти.
А тут это выдается за преимущество? Что за бред?
Насчет приоритетов приложения, тут тоже надо подумать… есть многозадачность… а то, что Андроид не может проигрывать музыку и тихонько без шума (без паузы) получить сообщение, так это наверное все же проблемы многозадачности Андроид.
4. Внешний вид
Да-да, давайте всех снова загоним под общие интерфейсы. При этом автор лукавит, говоря о фрагментированности веб-приложений, и умалчивая об еще бОльшей фрагментированности натив-приложений — когда даже под одну ОС приходится реализовывать множество версий приложений для конкретных мобильных устройств, отчасти именно благодаря различному разрешению устройств. И это благо? Сомневаюсь.
Возможно, автор просто как и Цукерберг — ниасилил. А точнее будет сказать, что надо подождать еще немного развития именно ОС ориентированных на веб-приложения, а потом уже делать выводы о том, что натив — это хорошо.
Автор говорит, что на данный момент нативные приложения можно заточить для пользователя более удачно. Например, что Вы сейчас делаете на десктопе, когда надо поставить на паузу музыку, играющую на неактивной вкладке браузера?
А что Вы делаете, когда у Вас на десктопе нативное приложение, которое проигрывает музыку, свернуто (убрано с экрана) или просто рядом с другим приложением (что проблематично на маленьких экранах мобилок, где экранное пространство на вес золота). Или каким-то чудесным образом оно «услышит» Вас, что вы обращаетесь именно к нему, когда Вы работаете в другом приложении? В любом случае Вы сначала переключаетесь на то приложение, потом ставите на паузу — и уже не столь важно — вкладка это или значок в таскбаре.
Если на десктопе, то ставлю на паузу в трее. Если с телефона, то нажимаю на кнопку на гарнитуре. Надо признать, что интеграция браузера с системным окружением на данный момент оставляет желать лучшего. Я и сам занимаюсь веб разработкой и вижу перспективы и плюсы веба, но с подобными проблемами, к сожалению, приходится иметь дело.
Опять же… немного подождать — появится поддержка всего этого для HTML5 в веб-ориентированных ОС типа Firefox OS, Tizen, Chrome OS.
Ждём-с
Так а пользователям и заказчикам вы также скажете «немного подождать»?
Как уже было сказано, многие ждут с момента выхода первого iPhone, а воз и ныне там…
Как уже было сказано, многие ждут с момента выхода первого iPhone, а воз и ныне там…
Конечно же нет! Не говорите такого… всему свое время… только разработчики это понимают. Если Вам не жалко своих усилий, то можете смело писать мобильные натив-приложения для этого переходного периода мобильных устройств. Но, как правило, пользователи редко задаются вопросом, почему у интернет-магазина, например, нет мобильной версии, пользуются успешно сайтом. Придет время все это успешно вдруг как-будто появится и на мобилах в виде веб-приложений, чего на нативе я пока не особо наблюдаю. Все дело в том, что полноценные мобильные устройства — это совсем не то, что мы сейчас имеем — мобильные телефоны с кучей ограничений. Всему свое время.
Ну что-то этот переходный период затянулся, несмотря на все пророчества, может дать ему какое-то более гордое название, типа «20-ти летка нативных приложений»? Или уж сразу «век нативной разработки», с запасом :)
Это время придет, безусловно, когда скорость мобильной связи догонит и перегонит сегодняшнее оптоволокно и все что только можно. Действительно, нафига нативные приложения, если все крутится в облаках и скорость доступа просто молниеносна.
Но вот у вас хотя бы приблизительная оценка по времени есть когда это случится? Не только в развитых странах, а более менее в большей части мира. «Всему свое время» — слишком смелая оценка :) В это «свое время» и HTML5 может превратиться в HTML15, а может вообще уйдет на покой и ему на смену придет новый стандарт нового Веб 7.0.
А сейчас и скорее всего в течении следующих долгих лет мы имеен нативные приложения, гибриды, которые с трудом поспевают за обновлениями операционок (но тем не менее для определенных задач имеет смысл их использовать) и чистый веб. И вокруг этого вечный спор — что лучше на данный момент. Спорить что будет лучше в будущем — вообще неблагодарное занятие.
Это время придет, безусловно, когда скорость мобильной связи догонит и перегонит сегодняшнее оптоволокно и все что только можно. Действительно, нафига нативные приложения, если все крутится в облаках и скорость доступа просто молниеносна.
Но вот у вас хотя бы приблизительная оценка по времени есть когда это случится? Не только в развитых странах, а более менее в большей части мира. «Всему свое время» — слишком смелая оценка :) В это «свое время» и HTML5 может превратиться в HTML15, а может вообще уйдет на покой и ему на смену придет новый стандарт нового Веб 7.0.
А сейчас и скорее всего в течении следующих долгих лет мы имеен нативные приложения, гибриды, которые с трудом поспевают за обновлениями операционок (но тем не менее для определенных задач имеет смысл их использовать) и чистый веб. И вокруг этого вечный спор — что лучше на данный момент. Спорить что будет лучше в будущем — вообще неблагодарное занятие.
Не путайте кисло с пресно:
— сайт магазина нужен от случая к случаю (и то, те магазины, которые рассчитывают на регулярные покупки и общение с клиентом делают нативные клиенты — Apple AppStore, Google Play Market, Valve Steam, ...), поэтому результативность клиента будет минимальна (я бы в большинстве случаев даже ставить не стал), а расходы велики.
— для контентных сайтов, которые работают/общаются с клиентом постоянно — нативное приложение значительно облегчает жизнь (дропбокс с клиентом — много удобнее, чем Яндекс.Диск без клиента), потому и пользуются ими люди.
А переходный период будет длиться бесконечно — веб-приложения и их возможности будут отставать от нативных — вебу приходится подстраиваться под новые задачи, а для этого требуется время, для нативных ограничений гораздо меньше.
— сайт магазина нужен от случая к случаю (и то, те магазины, которые рассчитывают на регулярные покупки и общение с клиентом делают нативные клиенты — Apple AppStore, Google Play Market, Valve Steam, ...), поэтому результативность клиента будет минимальна (я бы в большинстве случаев даже ставить не стал), а расходы велики.
— для контентных сайтов, которые работают/общаются с клиентом постоянно — нативное приложение значительно облегчает жизнь (дропбокс с клиентом — много удобнее, чем Яндекс.Диск без клиента), потому и пользуются ими люди.
А переходный период будет длиться бесконечно — веб-приложения и их возможности будут отставать от нативных — вебу приходится подстраиваться под новые задачи, а для этого требуется время, для нативных ограничений гораздо меньше.
На десктопе — жму кнопочку «Пауза» (есть такая медиа-кнопка, при этом все медиа-проигрыватели подписываются на прослушивание подобных кнопок). На мобильнике — вытаскиваю поле уведомления и жму паузу, на планшете — жму в трее паузу. И мне не надо искать браузер и вкладку. И ни в одном use-case мне не приходится активировать приложение — только передать ему команду (как минимум на одно действие меньше, для десктопа — на 2-3 действия меньше).
Еще один момент заслуживает внимания.
Насколько это «бывалый веб-разработчик»? Довольно странно, как он все преимущества веб-разработки вмиг позабыл и даже не упомянул о них для честного сравнения. Или это один из тех, кто меняет средства разработки, ОС, технологии в надежде на то, что «вот тут-то у меня точно все получится!»?
К таким очень хорошо подходят слова из басни Крылов И.А. «Квартет»:
А вы, друзья, как ни садитесь;
Всё в музыканты не годитесь
Насколько это «бывалый веб-разработчик»? Довольно странно, как он все преимущества веб-разработки вмиг позабыл и даже не упомянул о них для честного сравнения. Или это один из тех, кто меняет средства разработки, ОС, технологии в надежде на то, что «вот тут-то у меня точно все получится!»?
К таким очень хорошо подходят слова из басни Крылов И.А. «Квартет»:
А вы, друзья, как ни садитесь;
Всё в музыканты не годитесь
Та лох какой-то.
А если серьезно, я не могу судить о его «бывалости» в вебе. В наши дни одного только титула Xoogler достаточно, чтобы показать «крутизну». Как можно объективно судить о его достижениях? Разве что на его старничке говорящие достижения и в Гугле он выдавал на гора что-то гениальное.
Бывший гуглер, основатель стартапов, владелец заводов, газет, пароходов… Ну уж наверное не хрен с горы, что-то из себя представляет.
А если серьезно, я не могу судить о его «бывалости» в вебе. В наши дни одного только титула Xoogler достаточно, чтобы показать «крутизну». Как можно объективно судить о его достижениях? Разве что на его старничке говорящие достижения и в Гугле он выдавал на гора что-то гениальное.
Бывший гуглер, основатель стартапов, владелец заводов, газет, пароходов… Ну уж наверное не хрен с горы, что-то из себя представляет.
HTML5/phonegap — всего лишь вариант архитектуры приложения.
Каким образом внутреняя структура программы (которую вообще не видит никто, кроме разработчика) может повлиять на впечатление пользователей???
Как-то не объективно.
Каким образом внутреняя структура программы (которую вообще не видит никто, кроме разработчика) может повлиять на впечатление пользователей???
Как-то не объективно.
UFO just landed and posted this here
Сами представители Facebook говорили, что мобильных пользователей у них поровну. как с нативного приложения, так и с браузерной странички. А то и больше с веб приложения.
Чем сложнее задача, которую выполняет приложение, тем больше шансов, что оно будет нативным.
Вы действительно полагаете, что сложную задачу будет проще реализовать на натив? Уж не поэтому ли сейчас разработчики берутся за написание натив-приложения в 5 раз дороже, чем веб-приложения, что это как минимум в 5 раз сложнее, а следовательно — еще более усложняет процесс написания и без того сложных задач. Или Вы полагаете, что натив — это волшебная палочка, которая делает сложное — простым? Вот мое мнение, что как раз с точностью до наоборот.
А как у нас там в html, java, etc с реальным временем дела обстоят? Или вообще с любыми критическими секциями. Люди и едят больше денег за счет того, что они умеют с этим делом работать. Но на html5 такие задачи в принципе не исполнимы. Вот вообще никак и совсем.
А с каких это пор у нас Андроид (или iOS) стал системой реального времени? Вы вообще представление хотя бы имеете о том, о чем говорите? Если даже в самой статье было указано на то, что музыка прерывается в момент приема текстового сообщения. В данном случае я бы даже остерегся говорить хотя бы о нормальной многозадачности, какой уж там реалтайм!
«Или вообще с любыми критическими секциями» — конкретнее, пожалуйста, если можно.
«Или вообще с любыми критическими секциями» — конкретнее, пожалуйста, если можно.
Тем не менее, если андроид рутануть и чуть-чуть пошаманить, то у меня задача, которой нужно было мягкое реальное время, работала.
Железо и ось (после напильника) это всё тянет.
Железо и ось (после напильника) это всё тянет.
Но хотя ты прав, мне проще взять Ubuntu Phone, Sailfish OS или новый Boot to Qt и просто на нем работать, чем рутовать андроид, ставить CyanogenMod и давать суперпользователя приложению.
Вот-вот… тут-то и выходят на сцену шаманы на костылях. А как здорово все начиналось — мобильный натив может все!
Если далее рассуждать и продолжить в том же направлении, то можно запросто поставить и веб-сервер, сделать критичные вещи на серверной части, а интерфейс для пользователя — через веб-приложение. И остались от натива рожки, да ножки. Нет, конечно натив есть — серверные скрипты, но, согласитесь, это уже несколько иной натив… совсем уже не Андроид, и совершенно не обязательно ява.
Если далее рассуждать и продолжить в том же направлении, то можно запросто поставить и веб-сервер, сделать критичные вещи на серверной части, а интерфейс для пользователя — через веб-приложение. И остались от натива рожки, да ножки. Нет, конечно натив есть — серверные скрипты, но, согласитесь, это уже несколько иной натив… совсем уже не Андроид, и совершенно не обязательно ява.
Кхм… и вы это называете вебом? Это натив и есть… ещё более извращённый, но натив. А вебом это и не сделать никак, хоть рутуй, хоть чего делай.
1. Реализация интерфейса взаимодействия с пользователем через веб-приложение, вся работа приложения с использованием HTML + CSS + JS, а не нативное приложение.
2. Только если требуется какая-то специальная обработка (о чем было сказано в обсуждении выше) — естественно натив, но натив на любой вкус и цвет, а не только Андроид-API и ява, C# или др., но и они в том числе. Эта серверная часть только для исключительных вещей типа реалтайм.
3. На стороне удаленного сервера точно так же возможна обработка и хранение значительных объемов данных, а работа веб-приложения на стороне клиента — тонкий клиент-приложение.
Будьте внимательнее, пожалуйста, при чтении ветки диалога, прежде чем ляпнуть что-то невпопад.
2. Только если требуется какая-то специальная обработка (о чем было сказано в обсуждении выше) — естественно натив, но натив на любой вкус и цвет, а не только Андроид-API и ява, C# или др., но и они в том числе. Эта серверная часть только для исключительных вещей типа реалтайм.
3. На стороне удаленного сервера точно так же возможна обработка и хранение значительных объемов данных, а работа веб-приложения на стороне клиента — тонкий клиент-приложение.
Будьте внимательнее, пожалуйста, при чтении ветки диалога, прежде чем ляпнуть что-то невпопад.
1. В том и дело, что «вся работа» — только интерфейс почему-то. А логика и процессы у вас оказались в контейнере бекэнда. Реально весь софт, который есть переписать на веб — нереально, есть уйма подмножеств ПО, которое на веб просто не переносимы и требуют для работы как минимум бекэнда.
2. А кто-то говорил «только Android-API»? И этого апи порой нехватает — приходится и рутовать и linux-приложния ставить.
3. В том и дело — это не приложение, а интерфейс. Приложение, которому нужен не только интерфейс написать на вебе зачастую невозможно. Бекэнд — тот же натив, вопрос только в его местоположении.
Вопрос не во внимательности, а, видимо, в различном понимании что считать приложением. Для меня тонкий клиент права называться приложением не заслуживает.
2. А кто-то говорил «только Android-API»? И этого апи порой нехватает — приходится и рутовать и linux-приложния ставить.
3. В том и дело — это не приложение, а интерфейс. Приложение, которому нужен не только интерфейс написать на вебе зачастую невозможно. Бекэнд — тот же натив, вопрос только в его местоположении.
Вопрос не во внимательности, а, видимо, в различном понимании что считать приложением. Для меня тонкий клиент права называться приложением не заслуживает.
1. Видимо, более реально (с Вашей точки зрения) переписать это все заново на мобильный натив. Я согласен, что есть приложения, которые и не стоит переписывать на веб-приложения. Я не утверждаю безусловного господства веб-приложений на мобилах. Ниша приложений будет поделена.
2. Вот на этот счет я и сказал, что далеко не всемогущ этот мобильный натив, как оказывается, вот тут уже и начинается шаманство на костылях с рутом и линукс-приложениями. Опять же, будьте внимательнее.
3. Приложение — это совокупность — серверная часть + клиентская. Все зависит от задач и сложности этого самого приложения. Серверная часть может вообще отсутствовать. А ту же серверную часть, например, я реализую на Ruby, и мне плевать по большому счету на каком сервере этот код будет исполняться — линукс, винда, да пусть даже на самом этом мобильном устройстве. Где же тут натив?
2. Вот на этот счет я и сказал, что далеко не всемогущ этот мобильный натив, как оказывается, вот тут уже и начинается шаманство на костылях с рутом и линукс-приложениями. Опять же, будьте внимательнее.
3. Приложение — это совокупность — серверная часть + клиентская. Все зависит от задач и сложности этого самого приложения. Серверная часть может вообще отсутствовать. А ту же серверную часть, например, я реализую на Ruby, и мне плевать по большому счету на каком сервере этот код будет исполняться — линукс, винда, да пусть даже на самом этом мобильном устройстве. Где же тут натив?
1. Простите
2. Мобильный натив с точки зрения Android — вплоть до ассемблера может углубляться вообще-то. То, что устанавливать будет сложнее, чем обычное приложение — никто не спорит, но дополнительного ПО не потребуется. Всё это обуславливается архитектурой слоёного пирога Android OS.
3. Не надо путать бекэнд и веб. Вы же пытаетесь выдать веб, как панацею от излишней сложности поддержки натива? Так в чём панацея, если вы тут же скатываетесь к управляющему нативу в виде «сервера»? И да, Ruby — ну ни веб никак.
Вы действительно полагаете, что сложную задачу будет проще реализовать на натив?слабо согласуется с
Я не утверждаю безусловного господства веб-приложений на мобилах.. К тому же натив/веб бывает не только на мобильном рынке.
2. Мобильный натив с точки зрения Android — вплоть до ассемблера может углубляться вообще-то. То, что устанавливать будет сложнее, чем обычное приложение — никто не спорит, но дополнительного ПО не потребуется. Всё это обуславливается архитектурой слоёного пирога Android OS.
3. Не надо путать бекэнд и веб. Вы же пытаетесь выдать веб, как панацею от излишней сложности поддержки натива? Так в чём панацея, если вы тут же скатываетесь к управляющему нативу в виде «сервера»? И да, Ruby — ну ни веб никак.
Сложность разработки, сложность поддержки натив — фрагментированность, необходимость учитывать особенности конкретных устройств даже для одной ОС. В веб-приложениях с этим намного проще. Написание самого приложения, логики приложения — тут особой разницы никакой — натив или веб. Но у того же веб есть преимущество — я могу поручить серверу всю объемную часть работы, оставив на клиентской стороне лишь интерфейсную часть. К тому же в клиент-серверной реализации множество плюсов: логика приложения всегда под контролем разработчиков, что обуславливает быстрое исправление ошибок и внесение изменений, нагрузка преимущественно на сервер. В любом случае не пользователю управлять приложением, будь то натив или сервер.
И да, огорчу Вас, Ruby — это давно уже и веб. Ruby on Rails — может слышали о таком? Смею Вас заверить — прекрасные веб-приложения получаются! Хотя да, для Вас же только, что на стороне клиента — приложение. Сказывается, видимо, мышление натив-разработки.
Хотя довольно странно, как это вас слоеность Андроид не смущает, а разделение на серверную и клиентскую часть вы напрочь отвергаете. А вы представьте на мгновение, что в одном из этих слоев этого пирога работает еще и веб-сервер. Да-да, обычный веб-сервер! Локально на мобиле. Сейчас есть шустрые и маленькие веб-серверы. Вот и все веб-приложение переехало на мобильник. Такой вариант Вас устроит, надеюсь, вписывается в рамки Вашего мировозрения?
И да, огорчу Вас, Ruby — это давно уже и веб. Ruby on Rails — может слышали о таком? Смею Вас заверить — прекрасные веб-приложения получаются! Хотя да, для Вас же только, что на стороне клиента — приложение. Сказывается, видимо, мышление натив-разработки.
Хотя довольно странно, как это вас слоеность Андроид не смущает, а разделение на серверную и клиентскую часть вы напрочь отвергаете. А вы представьте на мгновение, что в одном из этих слоев этого пирога работает еще и веб-сервер. Да-да, обычный веб-сервер! Локально на мобиле. Сейчас есть шустрые и маленькие веб-серверы. Вот и все веб-приложение переехало на мобильник. Такой вариант Вас устроит, надеюсь, вписывается в рамки Вашего мировозрения?
Вот объясните мне о какой фрагментированности вы говорите? О каких особенностях конкретных устройств даже для одной ОС? Подробнее, пожалуйста. Ваши общие фразы не приводят к примеру, когда веб (даже если учитывать бекэнд + собственно веб). Клиент-серверная архитектура и тонкие клиенты появились задолго до веба и развивались даже быстрее самого веба. Разницы в пользу веба не наблюдаю.
Простите, но покажите мне браузер, который будет выполнять код Ruby on Rails. Ах, вы про бекэнд? Простите, но он не является веб-приложением. Он является бекэндом, а кто к нему подключится («натив» или «веб») — ему без разницы. Кстати, для справки — бекэнд тоже приложение,… сравнительно нативное (хотя в отдельных случаях с настолько большой натяжкой, что я бы не стал так называть). Серверная часть.
Хорошо, объясню ещё раз: для меня веб и бекэнд разные вещи. Безусловным вебом является только часть, выполняемая браузером. Я специально употребляю слово бекэнд, чтобы вам было легче понять: для меня разница между «сервер» и «веб-сервер» заключается, прежде всего, в формате диалога, поэтому и не отношу оный к «веб-приложению». В том числе и потому, что бекэнду без разницы, кто будет страницы запрашивать — веб-приложение или «натив»-приложение — работать будет и так и так.
Простите, но покажите мне браузер, который будет выполнять код Ruby on Rails. Ах, вы про бекэнд? Простите, но он не является веб-приложением. Он является бекэндом, а кто к нему подключится («натив» или «веб») — ему без разницы. Кстати, для справки — бекэнд тоже приложение,… сравнительно нативное (хотя в отдельных случаях с настолько большой натяжкой, что я бы не стал так называть). Серверная часть.
Хорошо, объясню ещё раз: для меня веб и бекэнд разные вещи. Безусловным вебом является только часть, выполняемая браузером. Я специально употребляю слово бекэнд, чтобы вам было легче понять: для меня разница между «сервер» и «веб-сервер» заключается, прежде всего, в формате диалога, поэтому и не отношу оный к «веб-приложению». В том числе и потому, что бекэнду без разницы, кто будет страницы запрашивать — веб-приложение или «натив»-приложение — работать будет и так и так.
1. Об особенностях особо заморачиваться не стал, чтобы объяснять — гугл+яндекс Вам в помощь! Но вот первые 2 статьи просто навскидку из результатов поиска:
www.mobilecomm.ru/view.php?id=415
www.enterra.ru/blog/mobile_qa/
по мне так достаточно приличный список особенностей, которые надо учитывать в нативе
я понимаю, что Вы будете оспаривать и это, но мне просто незачем искать информацию, чтобы доказать Вам что-то — лишняя и никчемная трата времени.
Ну и так, просто для примера. Что потребуется Вам, чтобы написать клиент-серверное натив-приложение, которое будет взаимодействовать с сервером? И серверную часть, естественно, тоже. Чтобы уж полный комплект был. Хотя нет, наверное все же бэкенд кто-то напишет за Вас, я так полагаю, раз Вы так настойчиво не хотите брать его в расчет полного комплекта приложения. Вперед и с песнями!
www.mobilecomm.ru/view.php?id=415
www.enterra.ru/blog/mobile_qa/
по мне так достаточно приличный список особенностей, которые надо учитывать в нативе
я понимаю, что Вы будете оспаривать и это, но мне просто незачем искать информацию, чтобы доказать Вам что-то — лишняя и никчемная трата времени.
Ну и так, просто для примера. Что потребуется Вам, чтобы написать клиент-серверное натив-приложение, которое будет взаимодействовать с сервером? И серверную часть, естественно, тоже. Чтобы уж полный комплект был. Хотя нет, наверное все же бэкенд кто-то напишет за Вас, я так полагаю, раз Вы так настойчиво не хотите брать его в расчет полного комплекта приложения. Вперед и с песнями!
1. Я так понимаю, что вы не глядя отметаете все мои замечания, потому что смотрите только в мобильный рынок? Так зря — с html5 ни разу фрагментация не уменьшается — очень плохо этот рынок приспособлен для самостоятельных веб-приложений. И не изменится это в дальнейшем — так и будет рынок фрагментарным. Так что native/web в данном случае глупый вопрос — анализируем рынок и потребности и выбираем платформы, которые хотим покрыть, а уж попадут туда только native/только web/обе технологии — дело десятое.
Вот скажите мне, с каких пор крупные приложения с клиент-серверной архитектурой должны писаться одним человеком? Объясняю по буквам: в такой архитектуре и клиент и сервер — отдельные взаимодействующие приложения, составляющие в сумме программное обеспечение/программный продукт. Терминологически так сложилось. А для примера — определюсь с платформами и напишу/найму других, если платформу не знаю/нет времени. Рынок, как бы. И в ближайшем будущем никакой панацеи в виде html5 / иной веб-технологии / иной технологии, способной победить фрагментацию — не ожидается, более того веб-приложения и сейчас сохраняют и в ближайшем будущем будут сохранять ряд недостатков, не позволяющих им соперничать с нативными приложениями в очень широком диапазоне задач.
Вот скажите мне, с каких пор крупные приложения с клиент-серверной архитектурой должны писаться одним человеком? Объясняю по буквам: в такой архитектуре и клиент и сервер — отдельные взаимодействующие приложения, составляющие в сумме программное обеспечение/программный продукт. Терминологически так сложилось. А для примера — определюсь с платформами и напишу/найму других, если платформу не знаю/нет времени. Рынок, как бы. И в ближайшем будущем никакой панацеи в виде html5 / иной веб-технологии / иной технологии, способной победить фрагментацию — не ожидается, более того веб-приложения и сейчас сохраняют и в ближайшем будущем будут сохранять ряд недостатков, не позволяющих им соперничать с нативными приложениями в очень широком диапазоне задач.
Известные мне существующие решения упаковки хтмл приложений очень сильно ограничены в возможностях интеграции с операционной системой. Я не могу назвать приложение хоть сколь сложным, если оно банально не умеет обрабатывать кастомные интенты в андроиде.
А незадолго до этого другой представитель Facebook сказал
But last September at TechCrunch's Disrupt conference, Mark Zuckerberg announced that «betting completely on HTML5 is one of the, if not the biggest strategic mistake we've made».
Важно понимать, что сравнивать надо не сайты, в том виде, в котором они сейчас есть, и натив, а именно веб-приложения под мобильные веб-ОС, такие как Firefox OS, и натив под тот же Андроид.
Сейчас основным и наверное единственным преимуществом натива является работа с оборудованием как бы напрямую (хотя на самом деле все же через определенный API). Погодите совсем немного, будет Вам API такого же плана и для HTML5. Вот тогда и поглядим, что проще и эффективнее для разработки, и как следствие, для появления разнообразных и полезных приложений. Что сейчас может предложить натив? Навигация, музыка, фотки, соцсети, мало-мальские игры… я что-то пропустил?
Сейчас основным и наверное единственным преимуществом натива является работа с оборудованием как бы напрямую (хотя на самом деле все же через определенный API). Погодите совсем немного, будет Вам API такого же плана и для HTML5. Вот тогда и поглядим, что проще и эффективнее для разработки, и как следствие, для появления разнообразных и полезных приложений. Что сейчас может предложить натив? Навигация, музыка, фотки, соцсети, мало-мальские игры… я что-то пропустил?
Напиши мне бэкенд для CNC программы на html+js. ;)
С успехом реализовано inet777.ru/portfolios/57/adminka-ruby-on-rails в довольно короткие сроки. Я даже связываться с натив не хочу — мне чисто-нативных приложений хватило в 90-е, ассемблер — вот где экстрим, вот где натив в чистом виде!
Встречный вопрос к Вам — раелизуЙ мне хотя бы похожий интерфейс на натив?
Встречный вопрос к Вам — раелизуЙ мне хотя бы похожий интерфейс на натив?
А теперь марш в гугл читать про CNC.
Была бы нужда… Вопрос в другом, и я его задал как встречный. Вы же тут пытаетесь утверждать, что невозможно реализовать удобный и понятный интерфейс на HTML + JS. А вы попробуйте хотя бы нечто похоже на натив изобразить. Или все же проще «сам дурак!»?
В нативе обычно немного другого рода интерфейсы делают. И потом, я могу взять qml, который идеологически похож на твой хваленый html5 и настрогать такой интерфейс еще быстрее.
А вот представь себе, что нужда появилась, твои действия? Тебе нужно быстро считать, быстро реагировать на события. У тебя не должно быть никаких недетерменированных происшествий типа вдруг вылезшего сборщика мусора.
Я вот ради эксперимента попробовал посмотреть, справится ли телефон с задачей, где нужно мягкое реальное время, оказалось, что он вполне с ней справляется. Но только в нативе.
А вот представь себе, что нужда появилась, твои действия? Тебе нужно быстро считать, быстро реагировать на события. У тебя не должно быть никаких недетерменированных происшествий типа вдруг вылезшего сборщика мусора.
Я вот ради эксперимента попробовал посмотреть, справится ли телефон с задачей, где нужно мягкое реальное время, оказалось, что он вполне с ней справляется. Но только в нативе.
Во-первых, для систем реального времени я бы выбрал другую ОС, а далее уже надо смотреть — какие средства для построения интерфейса там имеются. Но лучше всего я бы предпочел распределенную систему:
1. система реального времени, которая производит сбор информации, реагирование на события, выдачу управляющих сигналов и передачу информации в систему №2 (если имеются какие-то статистические данные);
2. обработка и хранение информации, взаимодействие с пользователями на уровне интерфейса, а интерфейс я все же предпочел бы на HTML, как ни крути. Лишние головняки с натив мне совершенно ни к чему.
1. система реального времени, которая производит сбор информации, реагирование на события, выдачу управляющих сигналов и передачу информации в систему №2 (если имеются какие-то статистические данные);
2. обработка и хранение информации, взаимодействие с пользователями на уровне интерфейса, а интерфейс я все же предпочел бы на HTML, как ни крути. Лишние головняки с натив мне совершенно ни к чему.
Вот вот, роль html это только интерфейс. Не более того. Лезть писать на нем целиком тяжелые приложения, которые занимаются обработкой данных это глупо.
Вы сами ответили на свой вопрос почти.
В том-то и дело, что реализовать интерфейс, взаимодействие с пользователем гораздо проще на html, чем пилить натив.
И, к тому же, всю бизнес-логику, моделирование, обработку информации в веб-приложении разработчик может реализовать на стороне сервера — как ему удобно и, главное, удобными ему средствами, а не только одним-единственным любезно предоставленным API для натив.
Разделяй и властвуй!
В том-то и дело, что реализовать интерфейс, взаимодействие с пользователем гораздо проще на html, чем пилить натив.
И, к тому же, всю бизнес-логику, моделирование, обработку информации в веб-приложении разработчик может реализовать на стороне сервера — как ему удобно и, главное, удобными ему средствами, а не только одним-единственным любезно предоставленным API для натив.
Разделяй и властвуй!
А если Интернет пропал, то как властвовать?
А когда веб победит, интернет будет везде и быстрый.
Другой вопрос — а когда это будет? Я его уже выше задавал.
Мы так скатились с рассуждениям вроде, принимаем за данность супер быстрые облачные сервисы, кому тогда нужен натив? Все крутится на серваках, на мобиле исключительно веб морда, для того же objective-c в этом мире просто нет места. Вообще все устройства превращаются в терминал для доступа к облаку, это если утрировать.
Но, я повторюсь, когда это будет? В некоторых странах, не будем тыкать пальцем (и нет, я не про Россию :) ), до сих пор в разработке проекты типа National Broadband, т.е. проводной интернет развивается и развиваться будет долго. Что уж говорить про мобильный интернет.
Другой вопрос — а когда это будет? Я его уже выше задавал.
Мы так скатились с рассуждениям вроде, принимаем за данность супер быстрые облачные сервисы, кому тогда нужен натив? Все крутится на серваках, на мобиле исключительно веб морда, для того же objective-c в этом мире просто нет места. Вообще все устройства превращаются в терминал для доступа к облаку, это если утрировать.
Но, я повторюсь, когда это будет? В некоторых странах, не будем тыкать пальцем (и нет, я не про Россию :) ), до сих пор в разработке проекты типа National Broadband, т.е. проводной интернет развивается и развиваться будет долго. Что уж говорить про мобильный интернет.
Ты ужасно узко мыслишь. Вместо сервера может быть C++ плагин для браузера, который добавляет некоторые функции, может быть демон, да что угодно в конце концов.
Не менее глупо реализовывать то же самое на натив. Разницы никакой. Но в случае веб-приложения у меня хотя бы есть выбор — что реализовать на стороне клиента, а что — на стороне сервера. Все механизмы обработки и хранения данных, как правило, реализуются на сервере, задача клиентской части веб-приложения — предоставить эти данные красиво для пользователя.
Вы так яро отстаиваете позицию веб приложений и так сильно пытаетесь принизить преимущества нативных, что остается только удивляться. Да, можно подумать, у нативных приложений одно ничтожное преимущество работы с оборудованием как бы (а почему, кстати, «как бы») напрямую.
Нет, безусловно, и в Apple и в Google сидят толпы зашоренных идиотов, которые ни в какую не хотят признавать силу и могущество веб приложений и продолжают выкатывать iOS 7, Android 4.2 и прочие.
В каждой новой версии оси добавляют новые фичи и т.д.
Каковы аналоги Grand Central Dispatch, XPC, Operation Queues, Core Data и остальных в современных чистых и гибридных HTML5 фреймворках?
Ну хотя бы приблизительно какой из них позволяет создать такой же отзывчивый UI как нативные средства? Какой из гибридов толково умеет работать с main queue в iOS?
Я не буду говорить за все инструменты из этой серии, их уже десятка три, если не больше.
Мне лично приходилось сталкиваться с RhoMobile. В кратце — чур меня, если это считается сравнимым с нативными средствами, то уж извольте… я тоже что-то пропустил.
Что удивляет еще больше, каждая контора считает своим долгом создать свой собственный гибридный HTML5 фреймворк и потом впихивать его под соусом «напиши один раз — работает везде (и поддерживать потом будем годами за твой счет)». Большинство этих средств не успевает за выпусками основных версий мобильных операционок, не успевает добавлять поддержку новых фич в свои гибридные недра. RhoMobile поди до сих пор генерирует проекты для Xcode версии 3.1 (!), которые «из коробки» даже не собираются.
Можете как угодно защищать свою позицию, правда вы в основном пытаетесь агрессивно принизить нативные средства. Хотя да, были люди в истории способные искажать реальность :)
Это как с религией, когда мне докажут что бог реален, я просто начну верить (хотя как можно верить в реальность...). Точно также когда веб одержит безоговорочную победу на мобильных девайсах, я буду в числе первых его адептов.
Нет, безусловно, и в Apple и в Google сидят толпы зашоренных идиотов, которые ни в какую не хотят признавать силу и могущество веб приложений и продолжают выкатывать iOS 7, Android 4.2 и прочие.
В каждой новой версии оси добавляют новые фичи и т.д.
Каковы аналоги Grand Central Dispatch, XPC, Operation Queues, Core Data и остальных в современных чистых и гибридных HTML5 фреймворках?
Ну хотя бы приблизительно какой из них позволяет создать такой же отзывчивый UI как нативные средства? Какой из гибридов толково умеет работать с main queue в iOS?
Я не буду говорить за все инструменты из этой серии, их уже десятка три, если не больше.
Мне лично приходилось сталкиваться с RhoMobile. В кратце — чур меня, если это считается сравнимым с нативными средствами, то уж извольте… я тоже что-то пропустил.
Что удивляет еще больше, каждая контора считает своим долгом создать свой собственный гибридный HTML5 фреймворк и потом впихивать его под соусом «напиши один раз — работает везде (и поддерживать потом будем годами за твой счет)». Большинство этих средств не успевает за выпусками основных версий мобильных операционок, не успевает добавлять поддержку новых фич в свои гибридные недра. RhoMobile поди до сих пор генерирует проекты для Xcode версии 3.1 (!), которые «из коробки» даже не собираются.
Можете как угодно защищать свою позицию, правда вы в основном пытаетесь агрессивно принизить нативные средства. Хотя да, были люди в истории способные искажать реальность :)
Это как с религией, когда мне докажут что бог реален, я просто начну верить (хотя как можно верить в реальность...). Точно также когда веб одержит безоговорочную победу на мобильных девайсах, я буду в числе первых его адептов.
Вы меня немного не правильно понимаете. Я не принижаю натив ниже того уровня, на котором он должен быть, потому как в силу объективных обстоятельств производители ОС для мобильных устройств просто обязаны возвышать натив-приложения, дабы продвинуть свою ОС на как можно большее количество мобильных устройств. Это обусловлено тем, что работая с нативными приложениям, пользователю уже сложнее сменить платформу, задаваясь вопросом — а будет ли тот же самый набор приложений на другом мобильнике, на другой ОС? Ответ чаще всего будет отрицательным. Таким образом мы имеем обычный захват рынка — будь то гугл или эпл — не важно. Только одна причина. Все элементарно просто.
Да и по ходу ответов как раз любители натива более предрасположены называть связку HTML+JS костылями, кривой, неприспособленной и т.д.
Совершенно иная ситуация с веб-приложениями — тут априори считается, что разработчику достаточно один раз написать приложение, правильно, по стандартам написать, и оно будет работать практически везде, где есть браузер, нормально отображающий информацию Интернет. Все механизмы давно испробованы на практике. Множество инструментов для разработки. Интернет. Какие могут быть еще доказательства состоявшейся и работоспособной технологии? Но на данный момент ни один из производителей ОС для мобильных устройств не заинтересован в свободном блуждании пользователей с платформы на платформу, пока рынок не обрел более-менее определенные очертания и процентные соотношения.
И еще один момент. Я считаю, что будут как веб-приложения, так и натив. Тут не будет какого-то абсолютного победителя. Поделят нишу приложений. Но уже и не будет такого убеждения, что для мобильников только натив — наиболее верное решение.
Да и по ходу ответов как раз любители натива более предрасположены называть связку HTML+JS костылями, кривой, неприспособленной и т.д.
Совершенно иная ситуация с веб-приложениями — тут априори считается, что разработчику достаточно один раз написать приложение, правильно, по стандартам написать, и оно будет работать практически везде, где есть браузер, нормально отображающий информацию Интернет. Все механизмы давно испробованы на практике. Множество инструментов для разработки. Интернет. Какие могут быть еще доказательства состоявшейся и работоспособной технологии? Но на данный момент ни один из производителей ОС для мобильных устройств не заинтересован в свободном блуждании пользователей с платформы на платформу, пока рынок не обрел более-менее определенные очертания и процентные соотношения.
И еще один момент. Я считаю, что будут как веб-приложения, так и натив. Тут не будет какого-то абсолютного победителя. Поделят нишу приложений. Но уже и не будет такого убеждения, что для мобильников только натив — наиболее верное решение.
Тут у вас немного теории заговора. По-крайней мере iOS (не знаю насчет полной истории Android) вырос из Mac OS. Не было «элементарно простой» причины — «подсадить» пользователей на платформу, чтобы они никуда не убежали. Не было всемирного заговора любой ценой не использовать веб.
И эти эталонные цитаты.
Мне бы в вашу реальность. Стандарты не меняются что ли? Почему каждый уважающий себя движок имеет какие-то специфичные только для него флаги, разные движки по-своему реализуют новые фичи из стандартов, раньше чем эти фичи стандартом окончательно утверждаются, даже ваш хваленный HTML5 по-прежнему candidate recommendation, и никак не финальная версия. Почему гибридные средства появляются бытсрее, чем грибы после дождя и каждый фреймворк считает своим долгом использовать ЯП отличающийся от всех других и вообще отличаться от остальных? По ходу чтобы наравне с нативными разработчиками появлялись RhoMobile-разработчки или какие-то еще. Как так получается что выбор JS фреймворка становится мини-исследованием, особенно если ему суждено работать на iPad 1?
Никто не ставит под сомнение технологию, когда речь идет о вебе. А когда утверждается что эта технология — идеальное решение для мобильных приложений, возникают вопросы. Да простые доказательства, например подавляющее большинство веб приложений (чистых или гибридов) во всех возможных апсторах, желательно для популярных сервисов, желательно с положительными отзывами. Чем не доказательство, что мешает этому случиться? Армия веб разработчиков есть, стандарты хорошие и прекрасные есть, интернет есть. Все механизмы давно испробованы на практике и вообще космические корабли бороздят просторы вселенной… Нет, блин, конечно заговор, а не объективная реальность.
И эти эталонные цитаты.
тут априори считается, что разработчику достаточно один раз написать приложение, правильно, по стандартам написать, и оно будет работать практически везде
Мне бы в вашу реальность. Стандарты не меняются что ли? Почему каждый уважающий себя движок имеет какие-то специфичные только для него флаги, разные движки по-своему реализуют новые фичи из стандартов, раньше чем эти фичи стандартом окончательно утверждаются, даже ваш хваленный HTML5 по-прежнему candidate recommendation, и никак не финальная версия. Почему гибридные средства появляются бытсрее, чем грибы после дождя и каждый фреймворк считает своим долгом использовать ЯП отличающийся от всех других и вообще отличаться от остальных? По ходу чтобы наравне с нативными разработчиками появлялись RhoMobile-разработчки или какие-то еще. Как так получается что выбор JS фреймворка становится мини-исследованием, особенно если ему суждено работать на iPad 1?
Какие могут быть еще доказательства состоявшейся и работоспособной технологии?
Никто не ставит под сомнение технологию, когда речь идет о вебе. А когда утверждается что эта технология — идеальное решение для мобильных приложений, возникают вопросы. Да простые доказательства, например подавляющее большинство веб приложений (чистых или гибридов) во всех возможных апсторах, желательно для популярных сервисов, желательно с положительными отзывами. Чем не доказательство, что мешает этому случиться? Армия веб разработчиков есть, стандарты хорошие и прекрасные есть, интернет есть. Все механизмы давно испробованы на практике и вообще космические корабли бороздят просторы вселенной… Нет, блин, конечно заговор, а не объективная реальность.
Никто никуда не торопится. И нет тут никакого заговора. Ради Бога, пусть наиграются с нативом, заодно и технологии мобильных устройств подтянутся до такого уровня, когда будет нормальный интернет, нормальные устройства отображения и ввода информации, тогда и придет нормальный Интернет на мобильники — ахнуть не успеете. Как аргумент — появление браузерных ОС. Всему свое время.
Я сам за себя скажу — мне как веб-разработчику просто не интересна эта возня с нативом, мне не нужны эти головняки с множеством версий нативных приложений даже для одной ОС, но множества разных устройств, каждое со своими особенностями. Я занимаюсь своим делом, а мобилы все более корректно отображают сайты (веб-приложения). В то же самое время расширяется стандарт HTML5 для работы с устройствами. Так с какого перепугу я должен бросить все и кидаться головой в навоз(зачеркнуто) натив? Если мобильники уже сами приходят к тому, чтобы нормально, корректно работать с веб-приложениями? Я смотрел на мобилах свои сайты — все прекрасно работает! Придут браузерные ОС — буду писать конкретно под них, благо что очень не многое придется менять в разработке. Надеюсь, я ответил на Ваш вопрос, почему веб-разработчики не бегут и спотыкаются, сломя голову переходить на натив?
Я сам за себя скажу — мне как веб-разработчику просто не интересна эта возня с нативом, мне не нужны эти головняки с множеством версий нативных приложений даже для одной ОС, но множества разных устройств, каждое со своими особенностями. Я занимаюсь своим делом, а мобилы все более корректно отображают сайты (веб-приложения). В то же самое время расширяется стандарт HTML5 для работы с устройствами. Так с какого перепугу я должен бросить все и кидаться головой в навоз(зачеркнуто) натив? Если мобильники уже сами приходят к тому, чтобы нормально, корректно работать с веб-приложениями? Я смотрел на мобилах свои сайты — все прекрасно работает! Придут браузерные ОС — буду писать конкретно под них, благо что очень не многое придется менять в разработке. Надеюсь, я ответил на Ваш вопрос, почему веб-разработчики не бегут и спотыкаются, сломя голову переходить на натив?
Ну есть Chrome OS (и давно уже есть), а толку? Он начал завоевание рынков? Есть Win8 с возможностью использовать html5 как приложения, там технология выстрелила? Через год посмотрим на достижения FirefoxOs…
Мне как веб и десктоп разработчику не раз и не два приходилось сталкиваться с ситуацией, когда фишку просто нет смысла реализовывать из-за невозможности игнорировать часть пользователей или когда ни малейших сомнений не возникало при построении десктоп приложения — на целевых системах заведётся точно. Про мобильные браузеры я просто умолчу — не было необходимости за ними наблюдать, но как пользователь — чаще всего был разочарован. А уж когда Opera объявила о смене движка и, таким образом, угробила кучу фишек (ну не нравится мне, когда по кнопке назад/вперёд, в иных случаях страница перезагружается — не всегда у меня есть интернет, да и когда есть — это же гарантированный сброс всех форм!)
Мне как веб и десктоп разработчику не раз и не два приходилось сталкиваться с ситуацией, когда фишку просто нет смысла реализовывать из-за невозможности игнорировать часть пользователей или когда ни малейших сомнений не возникало при построении десктоп приложения — на целевых системах заведётся точно. Про мобильные браузеры я просто умолчу — не было необходимости за ними наблюдать, но как пользователь — чаще всего был разочарован. А уж когда Opera объявила о смене движка и, таким образом, угробила кучу фишек (ну не нравится мне, когда по кнопке назад/вперёд, в иных случаях страница перезагружается — не всегда у меня есть интернет, да и когда есть — это же гарантированный сброс всех форм!)
Надеюсь, я ответил на Ваш вопрос, почему веб-разработчики не бегут и спотыкаются, сломя голову переходить на натив?
А где я такой вопрос задал? Цитату что ли? Мой вопрос был не совсем такой. Я спрашивал где эти сотни и тысячи чистых веб, а еще лучше гибридных HTML5+JS приложений, которые работают на реальных устройствах (популярных сейчас на рынке) и ни в чем не уступают нативным, а даже превосходят их? Где? Я вовсе не призывал всю армию веб девелоперов сломя голову ломиться в натив, нет уж, сами этот хлеб съедим, спасибо.
До тех пор пока iOS и Android не станут браузерными ОС (aka «всему свое время»), каждый второй PhoneGap и RhoMobile будет нуждаться в Native Extensions чтобы просто-напросто прочитать файлы из файловой системы (привет, offline storage).
И в статье речь идет об iOS, Android и других актуальных операционках на сегодняшний день, никто не говорит о браузерных ОС, какой там вообще «натив vs веб», если натив и есть веб? Вообще нечего обсуждать.
Просто в ваших коментах сквозит исключительная предвзятость, безоговочная уверенность в своей правоте, в том что веб приложения на голову выше по-сравнению с нативными iOS и Android приложениями, просто «все вокруг заблуждаются», как же иначе-то… Вы хоть интересовались какой стек технологий спрятан под капотом iOS или Android? Поинтересуйтесь, найдете для себя объяснение, почему на специалистов в этой области есть спрос, несмотря на ваше видение мира. Зачем эти соскоки в возню с навозом и прочее? Если так тяжело держать себя в руках, попробуйте держать себя сначала правой рукой, а потом левой, а потом опять правой, ну и т.д. — поможет не срываться в какие-то говнистые сравнения.
Вообще-то статья о том, как бывалый плюнул на этот бесперспективный веб и полюбил натив. Предвзятости тут никакой, так ведь, в самой этой статье? И ни слова о преимуществах веб-приложений. Даже удивительно, где это он так долго бывал, автор-то бывалый…
Так вот, и в моих ответах точно так же никакой предвзятости, и уж тем более безоговорочной уверенности. Аргументы, факты, доводы и рассуждения, иногда объяснения. Не более того.
А вы не нервничайте. Попробуйте снова сами эту процедуру наложения на себя рук, раз так хорошо знакомы с ней.
Так вот, и в моих ответах точно так же никакой предвзятости, и уж тем более безоговорочной уверенности. Аргументы, факты, доводы и рассуждения, иногда объяснения. Не более того.
А вы не нервничайте. Попробуйте снова сами эту процедуру наложения на себя рук, раз так хорошо знакомы с ней.
А вы не нервничайте. Попробуйте снова сами эту процедуру наложения на себя рук, раз так хорошо знакомы с ней
А вы предсказуемы :) Не я первый начал мешать другую сторону с говном (зачеркнуто) навозом — вот уж действительно «сильный» агрумент и неоспоримый факт, не более того ) Можно делать это тонко, можно толсто, а можно просто скатиться до оскорблений. Последний вариант — самый простой, но не самый лучший. А нервничать из-за срачей в вебе — извольте, себе дороже.
Мой основной довод, аргумент и факт — объективная реальность на данный момент времени, в разрезе популярных на данный момент мобильных осей, именно в контексте статьи, без прогнозов на будущее браузерных ОС и т.д. И эта реальность — спрос на рынке на разработчиков Android и iOS, который продолжает расти на протяжении последних 7 лет. А вот вы слышали про открытую позицию разработчика Hy5? Вы вообще слышали про Hy5 (Hybrid HTML5, если что)? Почему monster.com (первое что пришло в голову) на запрос «ios developer» выдает 233 совпадения, а «phonegap developer» только 2?
Эта же реальность — количественный перевес нативных приложений в апсторах, быстрые темпы развития как iOS так и Android (в плане средств разработки (ЯП, компиляторы, IDE, я не хочу здесь говорить о внешнем виде и о том что видно пользователю на поверхности — это другое) и т.д. Эти аргументы можно «пощупать» и проверить прямо сейчас, они везде, они, наверняка, лежат у вас на столе в виде смартфона (если это не Firefox OS, конечно же).
Ваши же аргументы — «не наигрались еще», «навоз», «удерживают пользователей», «автор — хер с горы, который ничего из себя не представляет», «автор, как и Цукреберг, ниасилил» и самый частый — «всему свое время». И таких «агрументов и фактов» — большая часть, поэтому и возникает вопрос предвзятости, поэтому почти каждый ваш комент и вызывает флейм.
Android — это linux, с установленной поверх java-подобной-машиной (с песочницами и ещё кучей опций).
А я лично считаю, что HTML5 не самый удачный язык разметки интерфейса, в нем еще сквозят костыли, покрытые пылью времен.
В целом же неважно на чем делать фоновые службы, но в этом случае теряется главное преимущество HTML5 — кроссплатформенность, а вот недостатки вылезают из всех щелей. Итого остается один компромиссный вариант. Делать нативное приложение с мордой на html5, а морду потом переносить на другие платформы дописывая бэкенды. Но если охота учесть UX каждой платформы, то тогда вылезают ржавые костыли HTML.
Поэтому сейчас удел веб приложений это морды ко всяким онлайн службам. Чуть что более серьезное и всё, натив становится единственной альтернативой.
Другим компромиссным вариантом может быть Qt + QML, но и там для каждой платформы придется рисовать заново морду по гайдлайнайм. Но это хотя бы сильно проще и быстрее, чем на HTML5. Но вот приложения на qml на андроиде стартуют неприлично долго, увы.
Но ежели вы хотите писать под Blackberry, Ubuntu, Sailfish, то выбора у вас и не остается. И, кажется, скоро в эту троицу ещё и Tizen попадёт, очень уж активно Qt под неё сейчас пилят.
В целом же неважно на чем делать фоновые службы, но в этом случае теряется главное преимущество HTML5 — кроссплатформенность, а вот недостатки вылезают из всех щелей. Итого остается один компромиссный вариант. Делать нативное приложение с мордой на html5, а морду потом переносить на другие платформы дописывая бэкенды. Но если охота учесть UX каждой платформы, то тогда вылезают ржавые костыли HTML.
Поэтому сейчас удел веб приложений это морды ко всяким онлайн службам. Чуть что более серьезное и всё, натив становится единственной альтернативой.
Другим компромиссным вариантом может быть Qt + QML, но и там для каждой платформы придется рисовать заново морду по гайдлайнайм. Но это хотя бы сильно проще и быстрее, чем на HTML5. Но вот приложения на qml на андроиде стартуют неприлично долго, увы.
Но ежели вы хотите писать под Blackberry, Ubuntu, Sailfish, то выбора у вас и не остается. И, кажется, скоро в эту троицу ещё и Tizen попадёт, очень уж активно Qt под неё сейчас пилят.
Можно подробнее про ржавые костыли HTML5, покрытые пылью времен, которые так мешают, видимо, Вам свободно передвигаться Вашим разработкам? Просто до сих пор как-то ни разу не столкнулся с чем-то, что не смог бы реализовать с помощью Ruby или PHP (серверная часть) + HTML + CSS + JS.
Очень хочется узнать!
Очень хочется узнать!
Посмотри хотя бы на толщину стандарта.
www.w3.org/html/wg/drafts/html/master/
Да возьми любую математику, любой сложный расчет, любое моделирование.
www.w3.org/html/wg/drafts/html/master/
Да возьми любую математику, любой сложный расчет, любое моделирование.
Ну так-то совсем не обязательно использовать весь стандарт, даже не обязательно весь его знать, а обращаться к нему по мере необходимости, во-вторых — толщина стандарта, как мне кажется, говорит о том, что продуманы многие мелочи, что очень даже не плохо.
Математика, моделирование? Да пожалуйста!
habrahabr.ru/post/174659/
Математика, моделирование? Да пожалуйста!
habrahabr.ru/post/174659/
Полноценная работа с лейаутами в хтмл невозможна.
О, да! Это удар наповал! А Вы слышали что-нибудь о CSS?
Слышал и работаю около десяти лет. И что? Создавать полноценные лейауты для приложений на хтмл+цсс — самоубийство.
Да-да, что-то припоминаю… Ваш ник… это мы с Вами кажется обсуждали, что Вы за долгие годы работы так и не научились блок в нужное место поставить с помощью CSS. Хотя я могу и ошибаться, возможно это были и не Вы. Но сути дела это не меняет.
А вы все также не можете делом подтвердить свои слова? Или всё-таки покажете мне свою реализацию интерфейса Google+ под Android без километров костылей на JS?
Вот принципиально для Вас этого делать не буду, хотя прекрасно знаю, что делается все довольно элементарно просто. Я знаю, как это делается, мне этого достаточно. А для Вас пусть это так и останется тайной за семью печатями — раз не дано понять Вам самому, то и я помогать не собираюсь. Вам я ничего доказывать не собираюсь, а тем более тратить время на какие-то примеры специально для Вас.
После того, как я поработал с XAML, HTML/CSS вызывают у меня черную тоску и рвотный рефлекс. То, что HTML/CSS — технологии прошлого века, разработанные для разметки текста, а не для создания полноценных интерфейсов, очевидно. Сплошные ржавые костыли.
Что касается приведенных выше скриншотов админки, сделать на XAML такой интерфейс — семечки.
Что касается приведенных выше скриншотов админки, сделать на XAML такой интерфейс — семечки.
Так сделайте! Я уже второй раз читаю тут, как это легко делается, а что-то никаких готовых решений не наблюдаю. На словах у Вас все легко и просто, только слова и дела у вас все как-то разными дорожками ходят.
К слову, это не просто скриншоты, а реальная и работающая система.
К слову, это не просто скриншоты, а реальная и работающая система.
А вы забавный:
(написано 18 июня 2013 в 10:07) и
(написано чуть ранее — 18 июня 2013 в 06:17).
Вот принципиально для Вас этого делать не буду, хотя прекрасно знаю, что делается все довольно элементарно просто. Я знаю, как это делается, мне этого достаточно.
(написано 18 июня 2013 в 10:07) и
Так сделайте! Я уже второй раз читаю тут, как это легко делается, а что-то никаких готовых решений не наблюдаю. На словах у Вас все легко и просто, только слова и дела у вас все как-то разными дорожками ходят.
(написано чуть ранее — 18 июня 2013 в 06:17).
А как дела обстоят у JavaFx с мобильными ОС?
Самый ценный коммент, спасибо. Сегодня, действительно, кажется разумно создавать нативное приложение, но внутри активно использовать WebView-компоненты для создания частей интерфейса ориентированных на контент. Таким образом, существенная часть приложения может стать переносимой на разные мобильные платформы. Именно по такой модели действует Google на iOs (на примере приложения Gmail). Для большинства пользователей разница между нативными списками и списками на основе WebView почти не заметна, хотя она есть. В такой модели доступно всё многообразие возможностей платформы.
Не понял что означает эта формулировка?
О каких именно костылях речь в данном случае?
Не понял что означает эта формулировка?
Но если охота учесть UX каждой платформы, то тогда вылезают ржавые костыли HTML.
О каких именно костылях речь в данном случае?
Кстати, обратил внимание, что про натив пишет Интел, который участвует в разработке html5 оси Tizen. Как это соотносится? Или там тоже на деле что-то сложнее калькулятора придется таки в нативе делать?
Сорри за оффтоп.
А причем тут картинка?
А причем тут картинка?
Видимо устоявшееся выражение в английском языке — Going Native
Типа автор был воинствующим противником натива и сторонником веб подхода, а теперь «going native» и занимает противоположную позицию, даже игра слов получается, «native» из оригинального выражения также означает «native apps».
Как Лоуренс Аравийский.
Нужно, кстати, посмотреть фильм.
Типа автор был воинствующим противником натива и сторонником веб подхода, а теперь «going native» и занимает противоположную позицию, даже игра слов получается, «native» из оригинального выражения также означает «native apps».
Как Лоуренс Аравийский.
Нужно, кстати, посмотреть фильм.
За месяц работы мобильного приложения мы увидели более чем троекратное увеличение числа подписчиков по сравнению с почти годом работы только веб-версии. Пока у нас нет других контролируемых экспериментов на эту тему, статистика весьма впечатляющая.
А разве недостаточно было выложить в Google Play «приложение», которое бы представляло из себя иконку, открывающую веб-версию в браузере?
Я бы такое снёс после первого запуска… Думаю я не один такой пользователь… А если сервис мной не очень востребован — то вообще бы покинул в виду демонстрируемого неуважения к пользователю.
Я бы такое снёс после первого запуска…
Почему? Если сервис работает отменно и необходим вам — какая разница, работает он в веб-варианте или нативно? Кроме того, разве нет возможности подготовить только нативную оболочку, в которой бы работал веб-контент используя движок встроенного браузера? Я не очень знаком с разработкой под различные платформы, но подобная возможность кажется вполне логичной.
P.S. Впрочем, подобный вариант уже озвучили выше.
Потому что зачем мне ссылка на страницу в качестве ярлыка? С этим отлично справляются закладки/speed dial в любом браузере. Выше озвучили несколько иной вариант — каркас приложения, с натянутым на него webview и прибитым тапками адресом… Это тоже далеко от идеала, но хотя бы не столь откровенное отмашка от клиентов. Впрочем и в этом случае я это безобразие сохранял бы только если бы сервис был мне действительно нужен и в браузере он работает хуже, либо есть какие-то дополнительные плюшки для хранения отдельного приложения (например кэширование большей части необходимых веб-компонент).
Перевод?
И где тут перевод?
Не хватает кармы, а так бы люто минусанул!
И где тут перевод?
Не хватает кармы, а так бы люто минусанул!
Sign up to leave a comment.
Назад к природе. Почему бывалый веб-разработчик в итоге склонился к нативным приложениям