QA Fest — конференция №1 по тестированию и автоматизации. Финальная программа уже на сайте >>
×Закрыть

HTML5 (web) vs Hybrid vs Native mobile apps

После криков фейсбучека, шо они переписали все на нативный код, тема нативные/хтмл5 приложения как-то обострилась. Вот последний попавшийся мне на глаза наброс(ок) goo.gl/CfiwI

Есть и такие мнения goo.gl/5TLNz

У кого какие мысли по этому поводу?

P.S. Если че, я считаю что html5 (web/hybrid) наше фсе.

P.S.S. И немного понудю: Где аппликейшн ДОУ? :)

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Ссылки не читал, но т.к. участвую в разработке hybrid платформы, отпишу своё мнение зачем нам понадобились гибриды.
Итак, почему не HTML5
1) HTML5 до сих пор очень ограничены по доступу к ресурсам железа, тот же блютуз, камера, компас и т.д. Кое-какая поддержка есть, но даже она мало где уже реализована нормально, да и практика показала что то, что описано в стандартах не покрывает всех запросов заказчиков
2) Вообще современный веб слишком безопасный, в итоге некоторые казалось бы простые задачи приходится решать через одно место. Кто когда-нибудь пробовал напрямую из веб приложения обратиться к стороннему soap сервису (естественно другой домен и невозможность прописать CORS) знает, как это может быть непросто. Плюс попапы, https и прочая лабуда, которая при «опасном» использовании блокируется браузером
3) Как оказалось, пользователям намного проще работать с приложениями, даже если это простой сайт визитка. Ссылки теряются постоянно, закладки никто не делает, на домашний экран не перетаскивает. В то же время если приложение установили, то мало кто его удаляет (из практики наших клиентов).

Почему не нативные приложения:
Тут всё проще — дешевле и быстрее заплатить за разработку одного решения, чем пилить 3-4 под разные платформы. Плюс на разных платформах есть куча нюансов, из-за которых разработка фичи на андроиде может потребовать в 2-5 раз больше времени, чем на iOS, или наоборот. Пример, поддержка bluetooth на iOS или работа приложения в фоне. В то же время если есть платформа, которая уже решила все эти проблемы, всегда можно относительно точно отэстимейтить затраты на разработку приложения.
Сейчас основных платформ 3, уже в этом году их может быть 5. Что дальше — хз, но если кол-во платформ будет расти, то затраты на написание нативных приложений будет только расти.

Мне гибриды сильно напоминают потуги изобретателей и концернов сделать автомобиль-самолет. История экспериментов уже лет 50 и сотни попыток, но неизменно выходит хреновый самолет с хреновым автомобилем.

В то же время если есть платформа, которая уже решила все эти проблемы,
Вы серьезно считаете, что такое в принципе возможно? Что команда гибрида сможет влегкую на повороте обойти команды всех производителей на их же платформах? Да еще и свести воедино все видения развития ОС и устройств от них?
Вы серьезно считаете, что такое в принципе возможно?
Я это уже практикую, определённых успехов мы уже добились
Что команда гибрида сможет влегкую на повороте обойти команды всех производителей на их же платформах?
Мне кажется мы о разных вещах говорим. При чём здесь команды всех производителей разных платформ?
Посмотрите PhoneGap, Cordova.
Смысл в том, что есть некое приложение-контейнер, которое позволяет веб-приложению (HTML5) расширить свои возможности до уровня нативного приложения.
Конкуренция не с производителями, а с разработчиками мобильных приложений.
Например, хочет клиент сделать скажем приложение для заказа пиццы для мобильников. Он может нанять 3 команды разработчиков под 3 платформы, поиметь гемор с тем, что у каждой платформы свои видения юзабилити, свои сложности реализации, и на выхлопе получить 3 абсолютно разных приложения по цене 3-х. Или он может нанять одну команду веб-разработчиков, которые сделают один одинаковых продукт для всех трёх платформ по цене 1 продукта + надбавка за пользование контейнером, что в любом случае выйдет дешевле. Очень важно, что при внесения изменений в продукт, это нужно будет делать в одном месте, а не в трёх.
определённых успехов мы уже добились
«Определенных успехов» на этом поприще много кто добился. Однако по итогу пока все они сводились к более-менее успешной дойке неопытных разработчиков и не более того. Не в обиду будет сказано (это о существующих решениях).
При чём здесь команды всех производителей разных платформ?
Потому что элементы даже UI в разных платформах и вебе просто разные. С разными концепциями, нижележащими библиотеками, обработкой событий, делегатами и т.д. И каждая команда делала их такими не просто так, а имея цельную концепцию и учитывая кучу факторов, в том числе особенностей конкретных ОС и железяк. «Гибридники» же считают себя почему-то умнее всех этих команд и надеются создать (или пригнуть под хтмл5) все эти подходы и вариации. В итоге как правило дропается 60% функциональности, которая не совпадает на разных ОС и платформах, а оставшаяся становится жутко сенситивной к любым изменениям нативных библиотек и вся конструкция начинает разваливаться еще до конца не собравшись.
Если же опуститься на самые низкие уровни и ваять с нуля все контролы и их протоколы, то работы будет больше, чем у разработчиков любой из моно-платформ, а результат (если он вообще выйдет и через сколько лет) скорее всего напомнит QT под виндовс.
Посмотрите PhoneGap, Cordova.
Яркие примеры эпик фейлов. На них пишут только корпоративные приложения, существующие «для галочки», которыми никто в своем уме потом не пользуется. Ни одно приложение на этих фреймворках никогда не занимало и не займет топы аппстора или плея. По причине адской тормознутости, жуткой зависимости от канала (на гпрс скорее всего вообще до главного экрана не дойдет) и кривизны контролей.
сделают один одинаковых продукт для всех трёх платформ по цене 1 продукта + надбавка за пользование контейнером, что в любом случае выйдет дешевле.
Беда в том, что работать оно не будет ни на одной из платформ. И та пиццерия, где не поленятся нанять нэйтив команду с дизайнером UI, идеально знающим особенности конкретной платформы, разрабами, работающими по гайдам и выжимающими максимум по скорости и «красивостям», нейтральность к версиям ОС сделает это приложение на порядок быстрее, красивее и лучше первого.
Никто не мешает вести разработку, кстати, в параллель для разных платформ — серверная часть одинаковая.
А первое 99% юзеров поставят, убедятся за 3-4 минуты что работать в нем никак, и сотрут.
Ни одно приложение на этих фреймворках никогда не занимало и не займет топы аппстора или плея.
Допустим, и? У нас нет цели попасть в топ апстора, у нас есть цель заработать денег. А в корпоративном сегменте, в котором я в основном и работаю, заказчику важна не популярность в апсторах, а выполнения функция для автоматизации бизнеса, а также важна скорость разработки решения и его цена, в которую нужно включать ещё и цену внедрения — одно дело обучать персонал пользоваться 3-мя разными продуктами, другое дело — одним. Плюс возможность усилиями девелоперов заказчика самим что-то изменить\добавить, всё таки найти трёх синьёров под все платформы не так и просто в наше время )
И каждая команда делала их такими не просто так
Каждая команда считала себя умнее других )) И всё было придумано до них тем же w3c. Лично меня напрягает, что для выполнения одних и тех же действий на разных платформах мне нужно выполнять разные действия — тут смахни влево, тут вправо, тут потряси а тут нарисуй двумя пальцами восьмёрку. Нет, я хочу простую кнопку!
Если же опуститься на самые низкие уровни и ваять с нуля все контролы и их протоколы
Выше писал, никаких контролов, webview и html, в том и суть — берём любого верстальщика и он может сваять вполне себе работающее решение
Никто не мешает вести разработку, кстати, в параллель для разных платформ
Никто не мешает, разница в цене и результате, и ещё в переносимости
У нас нет цели попасть в топ апстора, у нас есть цель заработать денег.
Аппстор и плей это (с определенной коррекцией) показатель качества приложения и отношения к нему пользователей.
(корпоративному) заказчику важна не популярность в апсторах, а выполнения функция для автоматизации бизнеса
До боли знакомо. Тотальная унификация и полное подчинение корпоративным правилам и стандартам.
В поседнее время сей, казалось бы, нерушимый принцип начал резко трещать по всем швам. Начиная с «работа на работе с 8 до 6 для всех» и заканчивая «одна модель одного производителя с одной операционкой для всех». Если заказчик так ценит унификацию — он может купить всем сотрудникам одну модель телефона/планшета, запретить обновлять ОС и ставить сторонние приложения и спокойно разработать одно приложение.
Но ему ж уже нажужжали в уши про BYOD! Тут-то шаблон начинает давать трещины, но можно попытаться этого не замечать какое-то время.
Каждая команда считала себя умнее других )) И всё было придумано до них тем же w3c.
Гы! Чето-то напоминает «интернет был придуман майкрософт».
Тот же cocoa пришел из NextStep, который чуть старше WWW консорциума, в основе всех трех мобильных операционок лежат разработки 70-80 годов, на прикладном уровне до сих пор в спецификациях w3c нет ничего, что нужно для бизнес приложений. Адоб с флешем не просто ж так существует и здравствует, хотя он скорее из игрового и медиа мира.
МС в свое время разработал потрясающую вещь для корпоративного ПО — Silverlight. Практически готовый набор блоков фронта для 90% бизнес-приложений, удобный, быстрый и очень приятный в разработке и развертывании.
.
Гибриды на сегодня представляют адское поле из граблей, которые еще и имеют свойство рандомно менять дислокацию при малейших изменениях вебкитов в операционках.
Примитивная для нэйтива задача «грид медленно скроллится, т.к. картинки грузятся синхронно» практически нерешаема в гибриде.
Не говоря уже о проблемке типа «поле ввода уехало под клавиатуру» и подобных.
.
Мобильные устройства используются совсем по другому, чем стационарные компы и пытаться натянуть концепции от первых ко вторым — гарантированный провал.
Лично меня напрягает, что для выполнения одних и тех же действий на разных платформах мне нужно выполнять разные действия
А вот пользователей этих платформ — нет. Ибо это BYOD — именно из-за таких фич люди и покупают эти устройства. Иначе — велкам закупить централизованно и раздать всем одинаковое.
Нет, я хочу простую кнопку!
Да ради бога. Только в случае с гибридом эта кнопка срендерится в самом неожиданном месте неожиданного размера и уедет куда-нибудь за экран при повороте устройства. Да — еще графика кнопки будет минут 5-6 грузиться на гпрс-е, юзер успеет выматериться, выйти и стереть нафиг это приложение.
Или она таки отрендерится, но при нажатии не отреагирует, либо отреагирует с сильной задержкой и юзер успеет ее еще раза 4 топнуть за это время с предсказуемым результатом.
webview и html
Тут еще предстоит долгий путь как по увеличению мощности процов, так и по унификации браузерных частей. Сейчас нормально не работает.
Пример — примитивный список из пары сотен блюд той же пиццерии с картинками и возможностью быстрой сортировки и поиска. На гпрс.
Для нэйтива — примитивная задача на 2 часа работы (ну еще час-два на натягивание «обалденной шкурки» от дизайнера). Если связь хреновая — придет только текст, шустро отрисуется, сортировка и поиск рабочие, картинки будут потихоньку ехать и отрисовываться по готовности.
На вебките — не решаемо в принципе.
Если заказчик так ценит унификацию — он может купить всем сотрудникам одну модель телефона/планшета, запретить обновлять ОС и ставить сторонние приложения и спокойно разработать одно приложение.
Некоторые до сих пор так и поступают. Я знаю довольно крупную компанию, у которой до сих пор всё под j2me и не чешутся переходить на ведроиды с яблоками. Это конечно крайности, но это их дело
Адоб с флешем не просто ж так существует и здравствует
Не долго осталось, учитывая отсутствие поддержки на IOS. Я лично хз сколько уже работаю без их плагина
МС в свое время разработал потрясающую вещь для корпоративного ПО — Silverlight.
Хороший пример эпик фейла.
Гибриды на сегодня представляют адское поле из граблей, которые еще и имеют свойство рандомно менять дислокацию при малейших изменениях вебкитов в операционках.
Мне кажется Вы понятия не имеет о чём говорите, называется слышал звон
Только в случае с гибридом эта кнопка срендерится в самом неожиданном месте неожиданного размера и уедет куда-нибудь за экран при повороте устройства. Да — еще графика кнопки будет минут 5-6 грузиться на гпрс-е, юзер успеет выматериться, выйти и стереть нафиг это приложение.
Откуда этот бред? Вы о чём вообще? Какие 5-6 минут, что будет грузиться? Графика вся грузится при установке приложения. И даже если бы она грузилась онлайн — это тот же сайт по сути, у Вас часто сайты грузятся по 5-6 минут?
Для нэйтива — примитивная задача на 2 часа работы (ну еще час-два на натягивание «обалденной шкурки» от дизайнера). Если связь хреновая — придет только текст, шустро отрисуется, сортировка и поиск рабочие, картинки будут потихоньку ехать и отрисовываться по готовности.
На вебките — не решаемо в принципе.
Причину напишите пожалуйста, а то я тут уже как веб-разработчик не пойму в чём у Вас проблема это сделать?
Хороший пример эпик фейла.
Могу ошибаться, но МС перепозиционировал его как основное средство UI для Win8 Mobile. По крайней мере читал об этом где-то у них. Не знаю результатов, но от первого лица знаю почему он провалился на дектопах. Там техническая часть и близко не лежала — внутренняя политика большой корпорации.
Мне кажется Вы понятия не имеет о чём говорите,
У меня тут десяток корпоративных гибриднх приложений на телефонах. Пять из них дальше первой страницы показывают полный мусор или загружают что-то до бесконечности, три — тупо не запускаются или показывают пустой экран по причине «чуть не той версии андроида» на корпоративном HTC (коих аж три модели бывает), остальные два работают как-то только в WiFi сети.
И даже если бы она грузилась онлайн — это тот же сайт по сути, у Вас часто сайты грузятся по 5-6 минут?
Проведите простой эксперимент и отпишите результаты:
1. Отключаем WiFi на iPhone, остаемся на GPRS.
2. Открываем сафари и грузим korrespondent.net (при том, что в сафари модифицированный по производительности и фишкам webkit).
3. Закрываем сафари и грузим нативное приложение korrespondent.net
.
Разница будет вполне очевидна, не говоря уже о юзабилити. И учтите, что это нативное приложение еще отнюдь не образец производительности — тот же вк-клиент вылизан заметно лучше.
Причину напишите пожалуйста
Просто напишите или дайте пример. Уходим из предметной области.
У меня тут десяток корпоративных гибридных приложений на телефонах.
У нас наверно разные гибридные приложения ) Я о Cordova\PhoneGap (у нас свой продукт, но он аналогичен), а Вы о чём? Может Вы о Xamarine? Так это не гибрид
Проведите простой эксперимент и отпишите результаты:
Проведите простой эксперимент — откройте в браузере гугл докс и скачайте и установиет полный пакет MS Office, и отпишите что получилось быстрее)) Не надо сравнивать тёплое с мягким, сайт у кора под мобилы не оптимизирован, а приложение писалось специально для мобил. Откройте m.liga.net и посмотрите как может работать нормальный новостной сайт.
А теперь вычтите время на первоначальную загрузку лиги, которой не будет в случае гибрида, и Вы получите то же (почти), что и в нативном приложении у корра. Я не спорю что нативные приложения будут работать быстрее гибридных (в идеальном случае, когда программисты с головой дружат), но новостные сайты и грид на 200 айтемов — явно не те случаи, где это будет заметно.
Причину напишите пожалуйста
Просто напишите или дайте пример. Уходим из предметной области.
Не, ну нормально? У меня нет проблемы грид вывести, а у Вас есть, и я хотел узнать что за проблемы. Мне что на кофейной гуще гадать? Ок, напишу как у меня это получается — JSON и генерация разметки на клиенте, всё летает, даже на 2 андроиде.
Проведите простой эксперимент — откройте в браузере гугл докс и скачайте и установиет полный пакет MS Office, и отпишите что получилось быстрее))
Ключевое слово — GPRS!
Отключите-ка интернет и поработайте с гугл-доксом и прочим азуром. Или выедете за пределы Украины и потрудитесь в роуминге по 100000грн за гигабайт.
Мобильное устройство, в отличие от корпоративного компа, к эзернету не подключено и 90% всего времени находится в зоне весьма неустойчивой сети передачи данных. А также в любой момент может сеть потерять (обычная езда на поезде, авто и т.д.).
Откройте m.liga.net и посмотрите как может работать нормальный новостной сайт.
Вы сами пробовали? С отключенным Wi-Fi? Попробуйте!
Список статей вы увидите и более-менее быстро, вот только внутрь статьи скорее всего вообще не попадете.
Их нэйтив приложение обладает встроенным прохлопом дизайна — оно грузит не список/асинхронно картинки/по выбору статью, а сразу и список и все статьи в нем. Корровское получше в этом плане, но тоже до оптимизации клиента вк ему еще далеко.
JSON и генерация разметки на клиенте, всё летает,
Картинки асинхронно грузятся? Изменение сортировки к рефрешу страницы не приводят? Поиск предвывод после набора каждой буквы каким образом выводит? Рефреш при этом происходит? Записи и картинки кэшируются между сессиями броузера? Поворот устройства отрабатывает нормально?
А теперь все это же еще на хроме для любого разрешения (там из полсотни) и ИЕ для Вин? Все фичи работают? Не приходится для каждого броузера кучу своего кода писать (как во всех сайтах с фичами)?
.
К чему я веду — такая штука для обычного иос-андроид-вин программера займет 2 часа, пускай это в сумме 6 часов. Сколько аналогичная функциональность займет для гибрида (на все эти платформы) по времени?
И воторое (это просто вопрос — я никогда не видел реализаций) — подгрузка меню в локальный сторадж и выбор в офлайне на гибриде легко реализуются? Карты с пиццериями с учетом текущей геопозиции?
Было бы лучше, если бы вы просто ткнули на несколько удачных гибридных приложений на посмотреть, т.к. я таких не встречал вообще и потенциальные возможности и реальные результаты никак у меня не сходятся.
Ключевое слово — GPRS!
Ну так Вы ж меня не слушаете, писал уже — всё необходимое в гибриде есть локально, грузятся только то же, что и в нативном грузилось бы. Т.е. можно вообще ничего не грузить
Вы сами пробовали? С отключенным Wi-Fi? Попробуйте!
Да я всё время с телефона на GPRS на Киевстаре с его пингами по 700 мс и да — лига один из основных новостных сайтов, которые я читаю с мобилы, и статьи открываются так же как и на корре, который тоже если не успел всё сразу загрузить, подгружает иногда секунд по 20, часто зайду в статью, потом выйду и листаю дальше заголовки, а потом только возвращаюсь к статье, чтоб она успела загрузиться, это про аппликуху кора
Картинки асинхронно грузятся?
Грузятся, не на всех платформах, это реализовано самим вебкитом
Изменение сортировки к рефрешу страницы не приводят? Поиск предвывод после набора каждой буквы каким образом выводит? Рефреш при этом происходит?
Откройте для себя JavaScript
Сколько аналогичная функциональность займет для гибрида (на все эти платформы) по времени?
Вы не уловили суть, не важно сколько это займёт у разработчиков платформы, важно что это не займёт практически ничего у разработчика конечного решения.
подгрузка меню в локальный сторадж и выбор в офлайне на гибриде легко реализуются?
У нас да, как в других не знаю. Простой селект с фильтрами, сортировками, что угодно. Возвращает быстро, фильтрацяи\сортировка происходит на стороне натива. Вообще гибрид для этого не обязателен, просто на нём можно сделать больше и быстрее.
Было бы лучше, если бы вы просто ткнули на несколько удачных гибридных приложений на посмотреть
Чужими не пользуюсь, только теми что сами делаем. ХЗ как их определять, на чём оно сделано )) У нас например не отличишь визуально

А що скажуть ті люди які гадають, що HTML 5 лайно як в цілом так і в цьому конкретному випадку?

у тонких клиентов есть одна проблема — скорость света, например, если до сервера 9000 км то пинг меньше 60 невозможно получить

чем поможет толстый клиент в борьбе за скорость света?

Только вчера выпустили небольшой обзор на эту тему: shakuro.com/...ile-development

Если кратко: может быть за html5 и будущее, но пока серьезные вещи желательно(по крайней мере мы для себя так решили) делать на нативных SDK. Нужно дать HTML5 и т.п. больше времени.

Только вчера выпустили небольшой обзор на эту тему

Где сводная таблица?!!

Особиста думка:

Покищо воно сире і не готове, але за цим майбутнє.

Сам написав маленький апп з допомогою Cordova — для мої[ маленьких цілей воно підійшло ідеально (це маленький інформер — що повідомляє про нові події ), є нюанси — але загалом працює.

І звичайно — нативний код буде ще довго рулити.

И тому, и другому есть свои применения.

Верный признак вычислить идиота — это категоричные высказывания вроде «HTML5 is dead» или «Native — отстой». К сожалению, среди IT журналистов и блоггеров, да и среди программистов тоже, таких немало.

Опыт Facebook — это опыт Facebook. Есть и другой опыт, и другие задачи. Опять же, я и сегодня могу зайти на вэ-вэ-вэ-фейсбук-ком из мобильного браузера и увидеть HTML версию, и многие заходят именно так. Или переходят по ссылкам.

среди IT журналистов и блоггеров,

У них работа такая, заголовок «Мы все умрем» более броский чем «Еще одно сравнение А и Б».

Не понятно как в случае HTML5 использовать In-App Purchase.

Есть подозрение что через адаптер к нативному коду, но я таким вопросом не задавалсо.

хтмл-то универсальнее, но до сих пор около 50% андроид пользователей сидят на версии 2.3 (хотя динамика ок, за 3 месяца 15% перешли на 4.х), это в большинстве случаев слабенькие девайсы и иногда при нативной разработке даже ради простых эффектов приходится делать финты ушами, чтобы держать отклик на уровне. что уж говорить про ненативный код

мое мнение такое, что через пару лет хтмл5 возьмёт своё, если к тому времени не появится еще какой-то универсальной альтернативы

Имхо, у html5 ниша очевидна: интерактивные сайты, для приложений он никак не годится. Если нужно сделать кросплатформенную игру игру, это или юнити или флэш, или мармелад, манки еще можно. В случае фундаментального приложения а -ля фотошоп для планшетов нативные языки

HTML5 — отстой потому что:
1. JS более тормозной чем вдякие нативные языки
2. JS менее прегоден для масштабной разработки чем java/c#, из-за динамической типизации, отсутствия нормальной поддержки ide, всяких хаков, и минимума либ для мобильной разработки поддерживаемых серьезными компаниями и бюджетами.

3. Я не сильно разбираюсь, но вроде ж оно(хтмл5) еще не стандартизировано.

Ок, противоположное мнение, знать все будет не так уж и скучно. :)

1. JS более тормозной чем вдякие нативные языки

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

2. JS менее прегоден для масштабной разработки чем java/c#, из-за динамической типизации, отсутствия нормальной поддержки ide

Про ИДЕ — не аргумент (по разным причинам).

По поводу остального: а надо ли оно? Я не большой спец по мобилочкам, но, на сколько мне известно, там не такие уж и гиганские масштабы. Да и веб-интерфейсы разухабистые как-то же пишут.

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

От тут таки печалька.

3. Я не сильно разбираюсь, но вроде ж оно(хтмл5) еще не стандартизировано.

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

Второй момент. Платформа (в контексте ХТМЛ5 + мобайл) по факту одна — WebKit.

Про ИДЕ — не аргумент (по разным причинам).
Хм, тогда вопрос к боле опытным, а как вы дебажите приложения на миллионы строк?
при том что в JS сокращение имен, пробелов идт для уменьшения размера кода уменьшает и читабельность

а как вы дебажите приложения на миллионы строк?

А как вы дебажите код в продакшн окружении? Аналогично логироавнием и тестами.
Но тут даже проще. Если баг в логике, а не специфичен для оболочки по типу фонгеп, то отладка прикрасно ведется в браузере (хром — покруче, ФФ+фаербаг — для старперов удобнее).

Но, кстати, самому интересно было бы услышать альтернативные способы.

при том что в JS сокращение имен, пробелов идт для уменьшения размера кода уменьшает и читабельность

2 окружения: дев и релиз. В дев, как не сложно предположить, ничего не обфускейтитсо и не минифаитсо.

да в броузере все ок, вот с node.js отладка дааа прикольная

да в броузере все ок, вот с node.js отладка дааа прикольная

Люди говорят шо github.com/.../node-inspector вполне юзабелен, но мне хватает и логов :)

ФФ+фаербаг — для старперов удобнее
Це ж як... я теж старпьор... *вийняв вставну щелупу і пішов сьорбати манку*

в JS сокращение имен, пробелов идт для уменьшения размера кода уменьшает и читабельность

в нормальной разработке js пишется в нормальном читабельном виде — файлики все такое. в продакш пускается после автоматической минификации.

а разве не бывает так что вот в продакшене у пользователя валиться, а у девелопера не воспроизводиться и по логам не ясно?

а разве не бывает так что вот в продакшене у пользователя валиться, а у девелопера не воспроизводиться и по логам не ясно?

Бывает что угодно. Но как правило, минимизация и обфускация тут наименьшая проблема, ибо это значит что или баг завязан на конкретные настройки пользователя (тут проще), или что причину не видно в кучах гуанокода (и тут дебагер не поможет, так как девелопер разобьет монитор до того как найдет баг)

за 4 года было 2 раза — опера турбо режим. воспроизвели, второй раз какой-то хромовый плагин все ломал

бывает хуже — ie начинает ругаться в духе «ошипка, чините» но без данных — где, когда, откуда ... вот тут сложнее, но вроде в 9 не было

по факту одна — WebKit.
WebKit — WebKit-у рознь. Звучит, конечно, смешно...но каждый вендор его соберает как хочет, от того и ожидать от него можно чего угодно. В общем, для того чтобы добиться консистентности поведения web-base приложения на всевозможных версиях платформы, помноженных на различных вендоров + кастомные сборки — по итогу, бабла и времени убьется еще больше, чем если просто нанять отдельные команды для каждой из платформ. Как уже кто-то писал, ниша подобных приложений — это простенькие аналоги информационных вэб-порталов, с примитивными дизайном и без какой-либо притензии на уникальность или наличие килер-фич. P.S.: Написать, за раз, одно приложение для всех платформ, звучит, конечно, круто, но на практике — не одна платформа в мультиплатформенности не заинтересована. Почему? Да потому, что у каждого есть свой рынок, большой или не очень, на котором он хозяин... а теперь представьте, что вам к вам на рынок начинают заползать всякие проходимцы с других платформ и сбивать/размывать цену сервиса... зачем оно вам надо?) Более того, явно вырисовывается тенденция ухода в «песочницу» по всем платформам... iOS из неё и не вылазил, Android — ужесточил правила маркета и, ходят слухи, что выпиливает приложения интегрированные с сервисами — конкурентами сервисов googl-а, Майкрософт в 8-ке замкнет экосистему mobile-tablet-pc-xbox и посмотрим насколько решения под неё будут себя чувствовать хорошо на других платформах ;-) Итого: рынком делиться никто не хочет...

WebKit — WebKit-у рознь.

Как и Андроид-Андроиду или скорее иОС_Х-иОС_У. Все же серьезных отличий по фичам я не замечал.

Для какого-нибудь корпоративного приложения или «показовалки отчетов» разницы быть явно не должно. Или я что-то упускаю?

Все, что Вы описали — правда. И JS тормозной и неудобный, и HTML5 еще поддердживается везде по-разному.
Но беда в том, что альтернатива еще хуже. Одно дело написать HTML5 приложениие, которое пусть мендленно и кривовато, но будет работать на большинстве мобильных устройств. А совсем другое: написать 3-4 приложения на разных языках под разные платформы.
И самое печальное: платформы эти постоянно меняются. То выйдет новая версия ОС, кто-то новое устройтсво выпустит. В погоне за новым никто о совместимости не заботится. Поэтому эти 3-4 приложения еще и под каждую версию подгонять придется.

Так что лучше такой «недостандарт» HTML5, чем вообще никакого.

Почему никакого? Если нужно делать обычное формошлеперство с мобильной версткой то и html4 вполне справляется. А если нужна native отзывчивость и богатство интерфейса то только джава и objectovec

Если нужно делать обычное формошлеперство с мобильной версткой то и html4 вполне справляется.

Ну формошлепство можно на чем угодно сделать. А вот осилишь портировать Contre Jour на HTML 4 ?

www.contrejour.ie/...bid=4O1exzXp2n5

А если нужна native отзывчивость и богатство интерфейса то только джава и objectovec

Уже 2 команды надо. А выйдет MS Surface — уже 3. Получится втрое дороже (не считая что надо еще девелоперов с нужными скилами найти \ переманить).

Уже 2 команды надо. А выйдет MS Surface — уже 3. Получится втрое дороже (не считая что надо еще девелоперов с нужными скилами найти \ переманить).

Да конечно ;-) Цифры для сравнения в студию. P.S.: Был непосредственным участником достаточно не тривиального проекта, который изначально пытались написать на JS+HTML. По итогу, команда нативных разработчиков за чуть больше чем 3 месяца заимплементила столько же функционала и с сходным качеством что и команда web разработчиков работавших почти год. Количественный состав команд одинаковый, качественный — в вэб команде опытных девов даже было побольше. Да, по завершению этого этапа, кастомер продолжил работу исключительно с нативными командами.

Ну формошлепство можно на чем угодно сделать. А вот осилишь портировать Contre Jour на HTML 4 ?

А ты осилишь прочитать то что я написал выше?

Уже 2 команды надо. А выйдет MS Surface — уже 3. Получится втрое дороже (не считая что надо еще девелоперов с нужными скилами найти \ переманить).

Такова селяви

Дык есть ведь и флеш, и haxe, и юнити — чем плохо?

Подписаться на комментарии