F> Может не так категорично, но смысл тот же — Friends don’t let friends use.

Да недостатки есть, но они преодолимы и не носят фундаментальный характер. В следующих версиях ClickOnce возможно пофиксят.

F> Нажмите Ctrl+P в хроме. Сразу превью печати и сразу же наведено на кнопки принт. Что ещё нужно? А не спрашивать о принтере во время печати — тон явно не хорош. Сейчас я хочу ЧБ, а через 30 секунд — на цветной, а через минуту — напечатать на принтер "соседей", или просто на виртуальный PDF принтер.

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

Здравствуйте, igor-booch, Вы писали:

IB>Да недостатки есть, но они преодолимы и не носят фундаментальный характер. В следующих версиях ClickOnce возможно пофиксят.
5! Всё можно преодолеть. Пока легче приклеить то или иное самообновление. Ну а вебу тут равных вообще нет.

Здравствуйте, Аноним, Вы писали:

А>Какие на ваш взгляд есть недостатки ?

А>Пока вижу 2

А>1) javascript — открытый код, то есть где он не будет удовлетворять требованиям безопасности придется отказываться от ajax в данных формах, в результате замедление отклика интерфейса.
А>2) hotkeys — веб приложение не может полноценно обрабатывать hotkey часть из них забирает броузер.

Состояние десктоп приложения хранится на нем самом, состояние веб приложения как правило сериализуется/десериализуется и хранится на сервере. Как мне кажется это главное отличие, которое повлечет за собой совершенно разные архитектурные решения.

Здравствуйте, IT, Вы писали:

C>>Так что, будущее может быть и совсем рядом. А ещё pNaCl есть, который на ХромойОС вполне себе неплохо работает.
IT>Проблема будущего очень сильно упирается в средства разработки. Веб сам по себе ни плох, ни хорошь. Тем более, что можно писать десктоп приложения, использующие веб-сервисы. А можно писать веб-приложения на C# или нормальной Java. Проблема веба в том, что его слишком усиленно ассоциируют с JS.
Это не проблема.

IT>А это скриптовый язык, т.е. язык, предназначение которого — лёгкие подпорки и мелкие затычки. Вот ты можешь мне сказать, сколько ты сам кода написал на JS? А на других языках?
На JS уже вполне нормально написал. Не самый плохой язык, хотя хорошим его тоже назвать сложно. Ну и нынче его многие рассматривают как промежуточный язык для более высокоуровневого языка (Dart и т.д.).

Пример, Evernote.

Как ни крути, но для меня десктоп клиент удобнее, чем web-интерфейс.
А главное он многооконный, позволяет заметку открыть в отдельном окне.

Для пользователя ключевыми преимуществами десктопа перед веб является, на мой взгляд:
-Отзывчивость интерфейса
-Возможность многооконной работы, не эмуляция.
-Мультимедиа
-Офлайн

Но если идти от требований, то критерии в моем посте выше

Автор: BluntBlind
Дата: 20.05.13

.

Здравствуйте, Cyberax, Вы писали:

C>Это не проблема.

Это проблема. Меня не перестаёт поражать тот факт, что после столких провалов в самых разных областях маркетологи так до сих пор и не поняли, что демонстация возможностей технологии на HelloWorld и делание после этого далеко идущих планов приведёт лишь к очередному провалу. Возьмите ради разнообразия какой-нибудь самый обычный энтерпрайз проект на годик и на самых обычных человек на 10 индусов и перепишите его на JS. Вот тогда и посмотрим ахренительные возможности этой технологии.

C>На JS уже вполне нормально написал. Не самый плохой язык, хотя хорошим его тоже назвать сложно.

Тогда тебе должно быть известно, что хорошим язык делает не только сам язык, но ещё и его окружение и средства разработки. Для меня, например, лучшим языком на сегодняшний день является Nemerle, но использовать его в реальных проектах невозможно по определённым причинам.

C>Ну и нынче его многие рассматривают как промежуточный язык для более высокоуровневого языка (Dart и т.д.).

Ну вот давайте развивать, заменять, эволюционировать и революционировать. Но пока то, что мы имеем в том виде, в котором имеем далеко не улетит.

Здравствуйте, igor-booch, Вы писали:

IB>1) необходимость платформонезависимости
IB>2) готов ли пользователь что-то ставить себе на компьютер
IB>3) безопасность

Это всё домыслы. Мобильные технологии в полный голос утверждают, что:

1) необходимости в платформонезависимости для пользователей не существует, это в чистом виде проблемы разработчиков.
2) пользователи ставят себе на телефоны всякую хрень пачками, зачастую на 5 минут, чтобы посмотреть и тут же удалить.
3) на нормальных платформах проблемы безопасности отсутствуют.

За последние полгода я поставил на свой телефон на порядок больше приложений, чем за пару лет на десктоп, для самых разных, в том числе и одноразовых целей. Часто используемое мной веб-приложение лишь одно — этот сайт, который иногда просматривается на телефоне.

Здравствуйте, diez_p, Вы писали:

_>Состояние десктоп приложения хранится на нем самом, состояние веб приложения как правило сериализуется/десериализуется и хранится на сервере. Как мне кажется это главное отличие, которое повлечет за собой совершенно разные архитектурные решения.

Текущее состояние веб-приложения можно хранить и на клиенте. Но для этого его полностью надо реализовывать на JS.

Здравствуйте, Sinclair, Вы писали:

S>Вопрос мне непонятен. Я всё время печатаю из Web — хотя бы те же посадочные талоны на самолёт. Никакими "нативными модулями" там и не пахнет.
S>Ну да. А в чём проблема? Вы хотите, чтобы я прямо железкой управлял? Так уже даже в нативе никто не делает лет двадцать как. Готовишь метафайл — а его печатает инфраструктура. Я понятно намекаю?
S>Какое-то странное опять утверждение. При чём тут "типы файлов"? Вот, к примеру, какой браузер умеет показывать "файлы" PowerPoint? А тем временем, PowerPoint Web Application прекрасно работает. Я понятно намекаю? Сейчас "браузеры" "показывают" файлы карт Quake.

Хорошо, давай выясним, что входит в состав web-приложения. На клиенте, конечно (что на сервере — другой вопрос).
Браузер входит в web-приложение или нет ?

IT>1) необходимости в платформонезависимости для пользователей не существует, это в чистом виде проблемы разработчиков.
Вы хотите сказать, что необходимость платформо независимости не влияет на выбор архитектуры (Web или Desktop)?

IT>2) пользователи ставят себе на телефоны всякую хрень пачками, зачастую на 5 минут, чтобы посмотреть и тут же удалить.
Вернемся к примеру с магазином кухонь. Предположим сегодня я хочу выбрать магазин где буду заказывать кухню. У меня есть час чтобы посмотреть как можно больше магазинов. Если все странички всех магазинов будут открываться мгновенно, а какой-нибудь один попросит меня потратить, пускай даже 2 минуты на установку софта, я скорей всего не буду тратить время на такой магазин. Время — деньги. Другой дело если человек хочет поиграться с мобильничком — это уже развлекуха, а не дело.


IT>3) на нормальных платформах проблемы безопасности отсутствуют.
Любой спец по безопасности скажет что систем, в которых отсутствуют уязвимости не существует.

А вот программу потребляющую контент я могу и на WPF написать (и на Web конечно).

Здравствуйте, igor-booch, Вы писали:

IT>>1) необходимости в платформонезависимости для пользователей не существует, это в чистом виде проблемы разработчиков.
IB>Вы хотите сказать, что необходимость платформо независимости не влияет на выбор архитектуры (Web или Desktop)?

Я хочу сказать, что это проблемы разработчика, а не пользователя.

IT>>2) пользователи ставят себе на телефоны всякую хрень пачками, зачастую на 5 минут, чтобы посмотреть и тут же удалить.
IB>Вернемся к примеру с магазином кухонь. Предположим сегодня я хочу выбрать магазин где буду заказывать кухню. У меня есть час чтобы посмотреть как можно больше магазинов. Если все странички всех магазинов будут открываться мгновенно, а какой-нибудь один попросит меня потратить, пускай даже 2 минуты на установку софта, я скорей всего не буду тратить время на такой магазин. Время — деньги. Другой дело если человек хочет поиграться с мобильничком — это уже развлекуха, а не дело.

Очень хорошо. Есть веб приложение, в нём есть модуль с рисовалкой. И что это доказывает? Оно, кстати, будет работать на моём телефоне? У меня на телефоне есть куча приложений, аналоги которых на обычном десктопе выполнены в виде веб. А на телефоне это отдельные скачиваемые приложения. Из этого можно сделать вывод, что веб технологии на наиболее современных устройствах не приживаются.

IT>>3) на нормальных платформах проблемы безопасности отсутствуют.
IB>Любой спец по безопасности скажет что систем, в которых отсутствуют уязвимости не существует.

Пусть говорят, это их работа. Я бы даже с удовольствием послушал способ каким можно подхватить какой-нибудь вирус на свой WP.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Браузер входит в web-приложение или нет ?
Нет, браузер является платформой для веб-приложения.

Здравствуйте, Sinclair, Вы писали:

PD>>Браузер входит в web-приложение или нет ?
S>Нет, браузер является платформой для веб-приложения.

Вполне согласен.

Тогда что входит в веб-приложение на клиентской стороне ? Браузер не входит. Плугины его не входят. Всякие сторонние вьюеры всякого рода файлов (например, просмотр pdf или видео) не входят. Запускаемые другие программы (как отдельные процессы) уж тем более не входят. Работа с принтером производится из браузера путем обращений к Win API, значит, тоже не входит. Без всего этого web-приложение делать может не очень много.

Это я и имел в виду, говоря, что большая часть работы при работе с web-приложением выполняется приложениями нативного кода. Если они не инсталлированы — мало что сможеь сделать.

Ок, согласен со всем.
Хочется все-таки понять по поводу потребления контента.
Если меня попросят сделать красивое приложение потребляющее контент, что мне выбрать Web или WPF?
Приложение на полноценном компьютере, не на мобильнике.

Здравствуйте, igor-booch, Вы писали:

IB>Если меня попросят сделать красивое приложение потребляющее контент, что мне выбрать Web или WPF?
IB>Приложение на полноценном компьютере, не на мобильнике.

Зависит от задачи. Но скорее всего Web.

PD>Тогда что входит в веб-приложение на клиентской стороне ? Браузер не входит. Плугины его не входят. Всякие сторонние вьюеры всякого рода файлов (например, просмотр pdf или видео) не входят. Запускаемые другие программы (как отдельные процессы) уж тем более не входят.
С одной стороны, это правда. С другой стороны, многие "Плугины" уже настолько распространены, что считаются частью платформы. Например, так работает Flash — а он установлен практически везде. Поэтому писать веб приложение со, скажем, улучшенным UI загрузки файлов (изкоробочный, прямо скажем, сделан на твёрдую два с минусом) можно на Flash достаточно смело. И так и делают все, кому небезразлична судьба их пользователей.

Или вот, скажем, просмотр видео. Сейчас в большинстве случаев он сделан через Flash — и ничего так, нормально работает для большинства пользователей. Но даже если хочется выкинуть Flash из рассмотрения, то в HTML5 просмотр видео является частью стандарта, т.е. предоставляется браузером.


PD>Работа с принтером производится из браузера путем обращений к Win API, значит, тоже не входит. Без всего этого web-приложение делать может не очень много.
Брр. "Работа с принтером" из браузера производится безо всяких обращений к WinAPI. Павел, ты когда-нибудь покупал авиабилеты через веб? Ведь посадочный талон прекрасно печатается из веб-приложения. Просто не надо забивать себе голову заведомо неверными утверждениями, и вопросы печати отлично решатся из веб-приложения. Даже лучше, чем из нативного — потому что веб-приложение запросто может обнаружить себя на МакОс, где никакого WinAPI вообще нет. При этом посадочный талон по-прежнему можно будет распечатать

PD>Это я и имел в виду, говоря, что большая часть работы при работе с web-приложением выполняется приложениями нативного кода. Если они не инсталлированы — мало что сможеь сделать.
Вот это какое-то странное утверждение. Не то, что большая часть — вообще вся работа выполняется "приложениями нативного кода", тупо потому, что никакого другого кода процессор исполнять не умеет. Если браузер не инсталлирован — то никакого веб приложения запустить не удастся. Но нам же этот случай не интересует, нет?

Здравствуйте, Sinclair, Вы писали:


PD>>Тогда что входит в веб-приложение на клиентской стороне ? Браузер не входит. Плугины его не входят. Всякие сторонние вьюеры всякого рода файлов (например, просмотр pdf или видео) не входят. Запускаемые другие программы (как отдельные процессы) уж тем более не входят.
S>С одной стороны, это правда. С другой стороны, многие "Плугины" уже настолько распространены, что считаются частью платформы. Например, так работает Flash — а он установлен практически везде. Поэтому писать веб приложение со, скажем, улучшенным UI загрузки файлов (изкоробочный, прямо скажем, сделан на твёрдую два с минусом) можно на Flash достаточно смело. И так и делают все, кому небезразлична судьба их пользователей.

Я, конечно, не против flash , но давай будем точными в определениях. Броузер — не часть приложения, а среда для исполнения программы (js и т.д.). Flash-player (после установки де-факто часть броузера) — не часть приложения, а среда для отработки программы для flash. Вот она (программа, загружаемая в плейер) — безусловно относится к web-приложению. Как, впрочем, и код ActiveX или java — апплета. А для последнего JVM есть среда исполнения, и она в web-приложение не входит. Все это нативный код обеспечения.


S>Или вот, скажем, просмотр видео. Сейчас в большинстве случаев он сделан через Flash — и ничего так, нормально работает для большинства пользователей. Но даже если хочется выкинуть Flash из рассмотрения, то в HTML5 просмотр видео является частью стандарта, т.е. предоставляется браузером.

Вот это , конечно, шаг на пути к полноценному приложению. Только вот чем он реализуется, этот просмотр виде (я не силен в HTML5). Если самим HTML (кодом в нем) — это одно, а если просто броузером — тогда мы имеем прежнюю ситуацию. Не все ли равно — встроенный нативный плуги броузера или сам броузер!


S>Брр. "Работа с принтером" из браузера производится безо всяких обращений к WinAPI. Павел, ты когда-нибудь покупал авиабилеты через веб? Ведь посадочный талон прекрасно печатается из веб-приложения. Просто не надо забивать себе голову заведомо неверными утверждениями, и вопросы печати отлично решатся из веб-приложения. Даже лучше, чем из нативного — потому что веб-приложение запросто может обнаружить себя на МакОс, где никакого WinAPI вообще нет. При этом посадочный талон по-прежнему можно будет распечатать

Антон, ты просто плохо понимаешь устройство Windows. Никто и ничто в 3 кольце не может работать с устройствами в Windows минуя Win API (в крайнем случае ntdll.dll, но это только для вызовов ядра). Нет других ворот в этот мир (о Metro не говорю, хотя там тоже Win API, но с изменениями). Хоть на Яве, хоть на C#, хоть на неизвестном нам обоим языке неизвестной нам среды — а все равно дело кончится вызовами OpenPrinter, StartDoc, StartPage и т.д. В данном случае это делает броузер. Можешь запустить dumpbin на его EXE (или какую-то из его DLL). и там будет импорт этих функций (если они импортируются неявно, конечно). А на МакОС местный Safari будет вызывать аналогичные средства от MacOS. И т.д. Другого не дано. Также как нельзя создать файл в Windows, не вызвав в конечном счете CreateFile (или NtCreateFile)- независимо от того, на чем программа написана.

Ну а в данном случае просто броузер берет на себя вызвать эти функции. Больше некому

PD>>Это я и имел в виду, говоря, что большая часть работы при работе с web-приложением выполняется приложениями нативного кода. Если они не инсталлированы — мало что сможеь сделать.
S>Вот это какое-то странное утверждение. Не то, что большая часть — вообще вся работа выполняется "приложениями нативного кода", тупо потому, что никакого другого кода процессор исполнять не умеет. Если браузер не инсталлирован — то никакого веб приложения запустить не удастся. Но нам же этот случай не интересует, нет?

Нет, не пойдет. Речь не о процессоре. а о web-приложении. На твоем любимом дотнете в конечном счете выполняется нативный код, но это же не мешает тебе говорить о программе на дотнете, на C#, а за скобками держать JIT. А уж явисты некоторые вроде как и впрямь уверены, что ниже JVM ничего нет. Так что это не аргумент.

Вот когда код страницы, загруженной в броузер, будет все сам делать (видео исполнять, pdf открывать без Adobe, doc открывать без Word или OO и т.д.) — вот тогда другой разговор будет.

Здравствуйте, IT, Вы писали:

IT>Очень хорошо. Есть веб приложение, в нём есть модуль с рисовалкой. И что это доказывает? Оно, кстати, будет работать на моём телефоне?
Если писали пряморукие — будет.

IT>У меня на телефоне есть куча приложений, аналоги которых на обычном десктопе выполнены в виде веб. А на телефоне это отдельные скачиваемые приложения. Из этого можно сделать вывод, что веб технологии на наиболее современных устройствах не приживаются.
Из этого также можно сделать вывод, что их авторы воспользовались одним из тысяч фреймворков по ускоренной конверсии веб-приложения в "AppStore item". Не все авторы мобильных веб-приложений ограничиваются инструкцией по припиниванию их веб сайта на дашборд.

IT>Пусть говорят, это их работа. Я бы даже с удовольствием послушал способ каким можно подхватить какой-нибудь вирус на свой WP.
А что, WP чем-то уникальна в плане вирусов? Ну, кроме того, что она настолько непопулярна, что вирмейкеры на неё забили болт?
А так — нет никаких проблем написать малварь под iOS. Сдерживает братков только трудность попадания в AppStore, и малый сегмент охвата у Cydia.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Я, конечно, не против flash , но давай будем точными в определениях. Броузер — не часть приложения, а среда для исполнения программы (js и т.д.). Flash-player (после установки де-факто часть броузера) — не часть приложения, а среда для отработки программы для flash. Вот она (программа, загружаемая в плейер) — безусловно относится к web-приложению. Как, впрочем, и код ActiveX или java — апплета. А для последнего JVM есть среда исполнения, и она в web-приложение не входит. Все это нативный код обеспечения.
Ок, отлично.

S>>Или вот, скажем, просмотр видео. Сейчас в большинстве случаев он сделан через Flash — и ничего так, нормально работает для большинства пользователей. Но даже если хочется выкинуть Flash из рассмотрения, то в HTML5 просмотр видео является частью стандарта, т.е. предоставляется браузером.

PD>Вот это , конечно, шаг на пути к полноценному приложению. Только вот чем он реализуется, этот просмотр виде (я не силен в HTML5). Если самим HTML (кодом в нем) — это одно, а если просто броузером — тогда мы имеем прежнюю ситуацию.
Не очень понятен вопрос. В HTML никакого кода нет. Весь просмотр чего угодно реализуется "нативным кодом обеспечения".

PD>Антон, ты просто плохо понимаешь устройство Windows.
Нет, Павел, это ты плохо понимаешь устройство Web. Поэтому нерелевантный ликбез поскипан.

PD>Ну а в данном случае просто броузер берет на себя вызвать эти функции. Больше некому
Это всё очень хорошо, но с точки зрения практики, это означает, что все рассуждения про "недоступность печати для веб приложений" — малоинтересная ерунда. Веб приложению недоступен WinAPI, а вот функции печати — вполне себе доступны. Если есть какие-то сомнения — сходи купи билет хотя бы на аэроэкспресс, и убедишься, что никаких проблем с печатью там нет.

PD>Нет, не пойдет. Речь не о процессоре. а о web-приложении. На твоем любимом дотнете в конечном счете выполняется нативный код, но это же не мешает тебе говорить о программе на дотнете, на C#, а за скобками держать JIT. А уж явисты некоторые вроде как и впрямь уверены, что ниже JVM ничего нет. Так что это не аргумент.

PD>Вот когда код страницы, загруженной в броузер, будет все сам делать (видео исполнять, pdf открывать без Adobe, doc открывать без Word или OO и т.д.) — вот тогда другой разговор будет.
Ничего не понимаю. Что такое "сам"? Что такое "код страницы"? Если уж джавистам можно игнорировать мир ниже JVM, то веб-девелоперам тем более можно забить на то, каким именно образом реализован тег <video> или тег <canvas>.
Кстати, в gmail встроен вьювер PDF-ов, который работает без Adobe. Так что откладывать твой "другой разговор" некуда.