Comments 71
У меня наверно глупый вопрос. Я смотрел на вашу демку tip calculator, там есть qr код для девайса. Я отсканил его и на wp8 девайсе, она открыласб в браузере устройства — выглядит оно далеко не так как на экране.
А есть какая нибудь более существенная демка, мне любопытно насколько это шустро работает.
А есть какая нибудь более существенная демка, мне любопытно насколько это шустро работает.
phonejs.devexpress.com/Demo — там три демки. Kitchen Sink например показывает все виджеты которые у нас есть.
Насчет того что выглядит не так как на экране — не очень понятно. Если не так как на скриншоте — это потому что по-умолчанию для iOS, Андроид и WP8 применяются разные темы — приложение будет выглядеть так, как «принято» на данном устройстве.
Насчет того что выглядит не так как на экране — не очень понятно. Если не так как на скриншоте — это потому что по-умолчанию для iOS, Андроид и WP8 применяются разные темы — приложение будет выглядеть так, как «принято» на данном устройстве.
А как же qooxdoo mobile (http://demo.qooxdoo.org/current/mobileshowcase/index.html)?
На мой взгляд, неплохой продукт получился.
Конечно, у них пока нет поддержки WinPhone, да и реализация под Android не столь красива, но работает она вполне стабильно.
На мой взгляд, неплохой продукт получился.
Конечно, у них пока нет поддержки WinPhone, да и реализация под Android не столь красива, но работает она вполне стабильно.
Хмм. Честно говоря совсем не нативные ощущения на iOS.
А это первое, что ожидается от такого фреймворка.
А это первое, что ожидается от такого фреймворка.
А разве на JS+HTML5 можно написать что-то, что будет настолько же отзывчивым как и native?
Попробовал демки — на iOS работает очень шустро, субъективно — шустрее чем sencha.
Скажите, а на демке с кухней (раздел Формы), у вас кнопки не подтормаживают, при нажатии?
У меня в Файерфоксе на ноуте подтормаживает на 1-2 секунды.
На айфоне немного пошустрее, конечно, но совсем немного.
У меня в Файерфоксе на ноуте подтормаживает на 1-2 секунды.
На айфоне немного пошустрее, конечно, но совсем немного.
На lumia 520 жуткие тормоза. я бы не пользовался прилложением, которое так работает
Да уж очень сыро. С начала всё вроде хорошо, и походу на встроенное приложение, но когда доходит дело до контров, понятно, что это не то. Ну и…
> Взяли jQuery, потому что сегодня для многих это синоним слова JavaScript.
Ещё не понял, кого мне больше жаль, вас или их.
> Взяли jQuery, потому что сегодня для многих это синоним слова JavaScript.
Ещё не понял, кого мне больше жаль, вас или их.
Дизлайк.
Ваши амбиции не совместимы с jQuery программированием.
Ваши амбиции не совместимы с jQuery программированием.
У кого баттхерт? У разработчиков либы?
Или фанатов jQuery?
Использовать заведомо медленные подходы в разработке мобильных приложений на HTML это фейл и мне больно видеть, как благодаря таким проектам жизнеспособная парадигма хоронится живьем. Это антиреклама платформы.
Использовать заведомо медленные подходы в разработке мобильных приложений на HTML это фейл и мне больно видеть, как благодаря таким проектам жизнеспособная парадигма хоронится живьем. Это антиреклама платформы.
Ну, мы ускорим где надо. Если где тормозит, то это не факт что jQuery виновато, мы и сами с усами :-). Не все сразу дается, особенно на разных платформах. Мы не обязаны везде jQuery использовать, мы взяли его за некую основу/базу чтобы людям позволить оставаться в знакомых парадигмах, а не так как у Sencha Mobile.
если не секрет, почему не взяли Zepto.js вместо jQuery?
Например, у Zepto ситуация с поддержкой существующих браузеров сложнее, нежели у jQuery.
If you need to support Internet Explorer, you can fall back on jQuery.
Знакомые парадигмы это хорошо.
Однако в случае с мобильным вебом играет большее значение скорость, оптимизация.
IMHO — вам стоит избавиться от jQ и это будет лучшей рекламой чем ее присутствие. На jQuery достаточно jQM который по факту нигде не используется из за низкой скорости работы и излишней универсальности, которая тоже давит на производительность.
А jquery.js при необходимости любой подключить может…
Однако в случае с мобильным вебом играет большее значение скорость, оптимизация.
IMHO — вам стоит избавиться от jQ и это будет лучшей рекламой чем ее присутствие. На jQuery достаточно jQM который по факту нигде не используется из за низкой скорости работы и излишней универсальности, которая тоже давит на производительность.
А jquery.js при необходимости любой подключить может…
Ну, кто знаком с ExtJS, тому вполне удобно с Sencha Touch, вроде бы. И подход jQuery им вообще непривычен и неудобен :)
habrahabr.ru/company/mailru/blog/188254/ вы бы тесты производительности посмотрели прежде чем на jq что то делать для мобильных
Как раз вчера натыкался на ваш сайт в поисках подобного решения, но хочу сказать, что для юзера, который не первый день знаком с платформой сразу видна разница: контролы, навигейшн.
Основная проблема таких фреймворков в том, что простые ситуации можно решать и без них, а сложные с ними становятся еще сложнее:
Во-первых, часто задачу можно решить с помощью мобильных версий веб-сайтов, при этом на более простых и доступных условиях: на рынке множество специалистов, никто не принуждает завязываться на какой-то дополнительный фреймворк, не нужно пытаться мимикрировать под нативные контролы каждой из Ос (при том, пользователь все равно найдет отличия между нативными и цссными элементами и будет раздражен), нет нужды публиковать приложения во всевозможных сторах, единые каналы продвижения с основным сайтом, если он есть и т.д. Остаемся в рамках своей компетенции и решаем знакомые задачи.
Во-вторых, решение задач вида: работа в фоне, нотификации, разрешения, адаптация под версию Ос, интеграция с какими-то другими приложениями, работа с системными вызовами и т.д. вызывают множество проблем, очень часто сводящихся к «дописать какой-то код на нативном API целевой платформы». Т.е. нам все равно прийдется лезть в дебри каждой из платформ и иметь в штате людей, которые умеют и Java и C#, и Obj-C. Т.е. забыть про красивую сказку «write once, run anywhere» и быть готовым к изучению минимум трех SDK, покупке Мака, Виндоус; вам прийдется осилить вим или быть готовым к паре-тройке разных IDE и т.д. А еще спецов, готовых писать на js и при этом хорошо знающих целевые платформы можно пересчитать по пальцам.
При этом постоянные тормоза и лаги на сложных UI не покрываются увеличивающейся производительностью системы, а на некоторых платформах, ваше HTML приложение будет работать в заведомо худших условиях, чем аналогичный код, запущенный в дефолтном браузере (привет, Сафари). Будут ли окупаться все эти нехилые затраты — решать вам.
Пишу на основании длительного опыта общения с такими фреймворками, из всего многообразия, меня порадовал только impact.js с его попыткой приблизится к нативным играм по производительности, но политика автора «сначала купи лицензию, потом смотри исходники» не всех устраивает.
Во-первых, часто задачу можно решить с помощью мобильных версий веб-сайтов, при этом на более простых и доступных условиях: на рынке множество специалистов, никто не принуждает завязываться на какой-то дополнительный фреймворк, не нужно пытаться мимикрировать под нативные контролы каждой из Ос (при том, пользователь все равно найдет отличия между нативными и цссными элементами и будет раздражен), нет нужды публиковать приложения во всевозможных сторах, единые каналы продвижения с основным сайтом, если он есть и т.д. Остаемся в рамках своей компетенции и решаем знакомые задачи.
Во-вторых, решение задач вида: работа в фоне, нотификации, разрешения, адаптация под версию Ос, интеграция с какими-то другими приложениями, работа с системными вызовами и т.д. вызывают множество проблем, очень часто сводящихся к «дописать какой-то код на нативном API целевой платформы». Т.е. нам все равно прийдется лезть в дебри каждой из платформ и иметь в штате людей, которые умеют и Java и C#, и Obj-C. Т.е. забыть про красивую сказку «write once, run anywhere» и быть готовым к изучению минимум трех SDK, покупке Мака, Виндоус; вам прийдется осилить вим или быть готовым к паре-тройке разных IDE и т.д. А еще спецов, готовых писать на js и при этом хорошо знающих целевые платформы можно пересчитать по пальцам.
При этом постоянные тормоза и лаги на сложных UI не покрываются увеличивающейся производительностью системы, а на некоторых платформах, ваше HTML приложение будет работать в заведомо худших условиях, чем аналогичный код, запущенный в дефолтном браузере (привет, Сафари). Будут ли окупаться все эти нехилые затраты — решать вам.
Пишу на основании длительного опыта общения с такими фреймворками, из всего многообразия, меня порадовал только impact.js с его попыткой приблизится к нативным играм по производительности, но политика автора «сначала купи лицензию, потом смотри исходники» не всех устраивает.
Естественно, у данного продукта есть очень четкая ниша применимости, о которой мы подробно порассуждаем в последующих постах. Эта ниша не пуста, наоборот, бурно растет и мы сделали этот продукт не для того чтобы рискнуть, а для того чтобы удовлетворить потребност вот таких людей: www.grobmeier.de/would-you-use-phonegap-again-18052013.html#.Ua4SApVZjlI
Очень правильный комментарий, особенно первое предложение. Две мои руки вверх.
Версия для Android выглядит ну совсем не нативно.
Да фиг с ней, как она выглядит. Лично меня останавливает, что скорость работы черезчур далека от нативной
А ещё нет плюшек наподобие виртуализации списков (когда элемент списка создаётся только тогда, когда он попадает в видимую часть прокрутки).
На HTML5 это было бы ужасно медленно, к сожалению. Считать смещения в DOM так затратно…
Таки в Sencha Touch сделали в версии 2.1. Пруф
Здорово. Разве оно у вас быстро работает с большими списками (больше 100 пунктов) на мобильных устройствах?
То-то и оно, что работает практически одинаково как на 10 элементах, так и на 100 элементах, так и на 1000. Но у нас в приложении, когда пробовали на 2.1 переехать, то работать все стало гораздо хуже, но памяти стало жрать заметно меньше. Но списки скроллились с дерганием при показе нового элемента, и рендерились они очень странно (и анимация в целом везде странно стала работать), поэтому откатились обратно на 2.0.
Вы версию для Windows Phone не видели :)
<script type="text/javascript" src="js/jquery-1.9.1.min.js"></script>
<script type="text/javascript" src="js/knockout-2.2.1.js"></script>
<script type="text/javascript" src="js/globalize.min.js"></script>
<script type="text/javascript" src="js/dx.phonejs.js"></script>
Вот это паровозик у вас получился… А почему jquery 1.9? Ведь на дворе уже 2.0.2 и 1.10 с поддержкой старых IE, которая вроде как ни к чему в вашем случае…
Ваша библиотека весит почти в два раза больше своих зависимостей.
Чем всё это лучше той же jquerymobile, кроме маскировки интерфейса под платформу мобильной ОС?
Продукт будет развиваться, и с выходом новых версий будет обновляться идущий в комплекте jQuery. В своем проекте разработчик может подложить версию поновее самостоятельно, главное не напороться на несовместимости (например, мы знаем что не всякая версия Knockout совместима с jQuery)
А что в Kitchen Sink такие списки маленькие? Как работает с 100 элементами в списке? На IPad 2, правда, заметно подтормаживают в Хроме и с таким количеством элементов
Мое мнение что универсальные решения никогда не будут приемлемыми для всех абсолютно платформ.
Я, как пользователь WP8, очень раздосадован тем фактом, что вся оптимизация под платформу свелась только к изменению стилей контролов.
Хочу акцентировать внимание что каждая платформа имеет свою специфику в построении архитектуры интерфейса, а Вы пытаетесь пересадить всех на идеологию iPhone UI, которая, в свою очередь, очень сильно отличается от подхода WP8.
Тут есть два варианта:
— либо нужно копать намного глубже, например контрол навигации для айфона лучше сделать пивотом или панорамой для винфона
— либо не заниматься ерундой и интерфейс затачивать под каждую платформу отдельно
Кстати, Вы пробовали открыть свои примеры на восьмом винфоне? Увиденное очень Вас огорчит.
Я, как пользователь WP8, очень раздосадован тем фактом, что вся оптимизация под платформу свелась только к изменению стилей контролов.
Хочу акцентировать внимание что каждая платформа имеет свою специфику в построении архитектуры интерфейса, а Вы пытаетесь пересадить всех на идеологию iPhone UI, которая, в свою очередь, очень сильно отличается от подхода WP8.
Тут есть два варианта:
— либо нужно копать намного глубже, например контрол навигации для айфона лучше сделать пивотом или панорамой для винфона
— либо не заниматься ерундой и интерфейс затачивать под каждую платформу отдельно
Кстати, Вы пробовали открыть свои примеры на восьмом винфоне? Увиденное очень Вас огорчит.
Все мы пробовали, конечно. WP8 SDK появился поздновато для нашего цикла выпуска, да и, положа руку на сердце, сейчас им в мире пользуются меньше людей чем, скажем, Blackberry, под который мы темы вообще не делали. Допилим в этом году до нужного состояния. Вроде даже некое подобие пивота и панорамы получается сделать.
это реально лучше, чем Adobe Air? (кроме поддержки вин8)
Основная цель альтернативных подходов — позволить разработчику пользоваться знакомыми инструментами. Если вы хорошо владеете технологиями Adobe (Flash), то для вас Air, наверно, будет лучше и проще (но есть минус: упакованное Air-приложение включает runtime, размер которого десятки мегабайт). Если вы веб-разработчик, владеющий HTML/CSS/JS, то Air для вас будет чужим и не даст преимуществ.
Я думаю, что основная проблема с Air — неуверенность разработчиков что с ним все будет хорошо. Apple не любит Adobe и успешно портит им бизнес. Самое главное что и Adobe не уверен в будущем и фактически оплачивает разработку свободного Apache Cordova aka PhoneGap — платформы для гибридных приложений типа показанного выше.
Мы не стали писать PhoneJS с нуля. Взяли jQuery, потому что сегодня для многих это синоним слова JavaScript
Мы не стали писать UI с нуля. Взяли iOS, потому что сегодня для многих это синоним слова UI.
Все правильно, но тут ключевое слово кросс-платформенный фреймворк. Ну вот у вас, не знаю, служба такси, например — вы же не напишете приложение только под iOS. Придется писать на все смартфоны что у ваших потенциальных клиентов на руках. Стало быть, для России это iOS, Android, Windows Phone и если захочется BlackBerry.
Сегодня наша основная задача на основной работе — проработка кроссплатформенного юзабилити на HTML5. Поэтому я Вас понимаю.
Но одно дело таксопарк, который хочет взять максимально готовое. А другое дело — серьёзные ребята берутся за дело и называют это «кроссплатформенный фреймворк». Соответственно, тут другие ожидания.
А в том, что DevExpress — серьёзные ребята, я не сомневаюсь, я юзал их продукцию ещё в 90-х.
Но одно дело таксопарк, который хочет взять максимально готовое. А другое дело — серьёзные ребята берутся за дело и называют это «кроссплатформенный фреймворк». Соответственно, тут другие ожидания.
А в том, что DevExpress — серьёзные ребята, я не сомневаюсь, я юзал их продукцию ещё в 90-х.
Ну наши цели — упереться в пределы производительности WebView (мы еще до этого не дошли), максимально скрыть проблемы юзабилити чтобы UI отзывался всегда и было понятно что происходит.
Ну а еще мы каждое утро молимся что железо и браузеры подтянутся.
Ну а еще мы каждое утро молимся что железо и браузеры подтянутся.
Что ж, успехов вам, не завязнуть в перечисленных целях, а быстро их пройти и двигаться дальше, чтобы в итоге получился действительно кроссплатформенный фреймфорк, включая UI kit (первый в мире, если я правильно нагуглил). Ну, вы поняли, чтобы один и тот же HTML отображался на iOS как стандартный список с группами, а на WP в виде панорамы и т.д.
Так, а в чем ваши конкурентные преимущества перед Sencha Touch?
Я напишу чем мы отличаемся.
У нас более привычный для веб-разработчика подход — HTML+JavaScript, не все в коде, при этом PhoneJS заставляет использовать MVVM, позволяющий получить хороший тестируемый код.
С точки зрения UI мы стараемся адаптировать стиль и даже структуру UI под стандарты платформы, тогда как приложение на Sencha Mobile выглядит везде одинаково. Хорошо это или нет — уже решать программисту, но мы, по крайней мере даем больше гибкости в этом вопросе.
Есть еще десятки нюансов, но для понимания их лучше, все-таки поисследовать propertycross.com.
У нас более привычный для веб-разработчика подход — HTML+JavaScript, не все в коде, при этом PhoneJS заставляет использовать MVVM, позволяющий получить хороший тестируемый код.
С точки зрения UI мы стараемся адаптировать стиль и даже структуру UI под стандарты платформы, тогда как приложение на Sencha Mobile выглядит везде одинаково. Хорошо это или нет — уже решать программисту, но мы, по крайней мере даем больше гибкости в этом вопросе.
Есть еще десятки нюансов, но для понимания их лучше, все-таки поисследовать propertycross.com.
С Айфоном совсем не вышло. Киллер-фича Айос — это гладкость и отзывчивость. В мире Айос, когда пользователь касается экрана всё замирает. Сначала на всё реагирует интерфейс, а потом уже делаются какие-то действия.
В это потеряли, сделав ровно наоборот. В результате на Айфоне получился Андроид. Всё тормозит и постоянно есть желание нажать на кнопку 2-3 раза.
Планируете над этим поработать?
В это потеряли, сделав ровно наоборот. В результате на Айфоне получился Андроид. Всё тормозит и постоянно есть желание нажать на кнопку 2-3 раза.
Планируете над этим поработать?
Ну, это не мы сделали наоборот, это так сейчас браузеры работают. Мы какие только ухищрения не делаем чтобы обойти особенности работы браузеров, обработки событий и т.п. Свои косяки мы выловим конечно.
Есть надежда что ситуация не будет ухудшаться, а наоборот на запросы мобильного сообщества разработчики браузеров будут реагировать.
На последних моделях телефонов/планшетов все не так плохо — приемлемо для бизнес приложений вида списки-формы.
Есть надежда что ситуация не будет ухудшаться, а наоборот на запросы мобильного сообщества разработчики браузеров будут реагировать.
На последних моделях телефонов/планшетов все не так плохо — приемлемо для бизнес приложений вида списки-формы.
А почему выбрали knockout, а не angular? Последний для одностраничых приложений больше подходит, и роутинг там есть и вьюшки с лэйаутами и урезанный jquery.
В HTML based кроссплатформенных фреймворках все еще стоит указывать жирным шрифтом в мануале, что их есть смысл использовать только для простых, незамысловатых приложений, иначе вы рискуете потерять уйму времени и денег, разбираясь с проблемами производительности. Мы с командой не так давно прошли путь PhoneGap + Backbone.js. Это была авантюра.
Наверное так. У нашей компании основная аудитория — разработчики бизнес-приложений, и PhoneJS под это затачивался. Поэтому, наверное глаза замыливаются и мы забываем что есть и другие ниши.
Я бы не стал писать на PhoneJS игру или, скажем социальное приложение типа foursquare. А, например, приложение для авиакомпании (посмотреть расписание, зарегистрироваться на рейс) — почему нет? Да, его можно и просто руками на HTML написать, но граблей много собрать придется, поэтому PhoneJS тут вполне себе сэкономит время.
В ближайших планах есть статья о позиционировании, напишем.
Я бы не стал писать на PhoneJS игру или, скажем социальное приложение типа foursquare. А, например, приложение для авиакомпании (посмотреть расписание, зарегистрироваться на рейс) — почему нет? Да, его можно и просто руками на HTML написать, но граблей много собрать придется, поэтому PhoneJS тут вполне себе сэкономит время.
В ближайших планах есть статья о позиционировании, напишем.
Я правильно понимаю, что WinPhone 7 не поддерживается?
habrastorage.org/storage2/d9a/370/d52/d9a370d522bdfcd58e4a963b65418470.jpg
habrastorage.org/storage2/d9a/370/d52/d9a370d522bdfcd58e4a963b65418470.jpg
Имел дело с ASP.NET html контролами от DevExpress, так там в разметке был ужасный бардак (использовались таблицы для всего чего можно и нельзя). Разметка была очень тяжелой. Интересно, в этой библиотеке они не тем же путем пошли!?
Тех людей уже уволили :-) (На самом деле не всех, самые умные учавствовали в PhoneJS).
Ну и надо понимать, что ASP контролы писались еще под какой-нибудь IE5, и люди требовали чтобы работало и все тут.
А потом через тройку лет и переписать уже можно было бы, да нельзя — обратная совместимость и все такое.
Здесь HTML5, CSS3, webkit. Люди опытные пишут. Ну и DOM для виджетов динамически создается. Если там что и не оптимально — говорите, с радостью поправим.
Ну и надо понимать, что ASP контролы писались еще под какой-нибудь IE5, и люди требовали чтобы работало и все тут.
А потом через тройку лет и переписать уже можно было бы, да нельзя — обратная совместимость и все такое.
Здесь HTML5, CSS3, webkit. Люди опытные пишут. Ну и DOM для виджетов динамически создается. Если там что и не оптимально — говорите, с радостью поправим.
Фреймворк довольно молодой, есть ли примеры успешных проектов на нем? Как обстоят дела с исправлением ошибок, релизами?
Ошибки исправляем, минорные релизы выпускаются примерно раз в месяц. Мажоры два раза в год. Команда опытная, достаточно большая чтобы оперативно реагировать, инженеры поддержки работают, отвечают на вопросы. Компании DevExpress 15 лет почти, это не стартап какой.
Примеры приложений которые вот можно поставить и посмотреть мне пока неизвестны (они может быть и есть, но нам не всегда говорят). Люди в основном внутренние бизнес-приложения пишут. Но люди пишут что-то — вопросы задают, баги репортят.
Примеры приложений которые вот можно поставить и посмотреть мне пока неизвестны (они может быть и есть, но нам не всегда говорят). Люди в основном внутренние бизнес-приложения пишут. Но люди пишут что-то — вопросы задают, баги репортят.
Сравнивали PhoneJS и Kendo UI на андроид версии. Смотрели официальные демки.
Скролинг\переключалки и т.п в PhoneJS пока отстают по производительности, прокрутка заметно дергается.
Хотя конечно у вас более интересная ценовая политика и проект моложе.
Скролинг\переключалки и т.п в PhoneJS пока отстают по производительности, прокрутка заметно дергается.
Хотя конечно у вас более интересная ценовая политика и проект моложе.
Жалко Вы не упомянули конкретные демки, т.к. в идеале, конечно, сравнивать лучше на одном и том же приложении, которое написано на различных фреймворках. В этом плане официальные демки KendoUI минималистичны и заточены именно под перформанс, что с точки зрения продаж, более правильно. Люди обычно выбирают такого рода продукты именно исходя из производительности. Но это чревато разочарованием на последующих стадиях разработки, когда скоро выпускать продукт, а оказывается, что все тормозит. Мы же попытались сделать наши демки реальными приложениями, которые будут писать люди и которыми уже можно пользоваться (за исключением Kitchen Sink) и оценить реальную производительность. Ну и как уже было неоднократно сказано, мы уже знаем некоторые наши узкие места и сейчас работаем над их устранением, и некоторые из них постараемся включить в ближайшие миноры. В любом случае, спасибо за отзыв.
Извиняюсь, похоже ошибся веткой. Это ответ на этот комментарий.
Демки с официальных страниц:
Kendo
demos.kendoui.com/mobile/overview/index.html
PhoneJS
phonejs.devexpress.com/Demos/?url=KitchenSink&sm=3
Kendo
demos.kendoui.com/mobile/overview/index.html
PhoneJS
phonejs.devexpress.com/Demos/?url=KitchenSink&sm=3
Sign up to leave a comment.
PhoneJS — Новый HTML5-фреймворк для мобильных приложений