Re[2]: Ресурсы компьютера и сценарии использования, вот что решает при выборе: - Архитектура программного обеспечения

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

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

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

А>>Пока вижу 2

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

А>>2) hotkeys — веб приложение не может полноценно обрабатывать hotkey часть из них забирает броузер.
G>В эпоху тач устройств не важно.
Тач устройства пока не используются в промышленном виде, например когда приходишь в какуюнить контору ( банк например ) там операционист не на планшете твои данные вбивает, и врятли будет на планшете вбивать, требования к по в сбере например — любые действия чтобы можно было сделать по кнопкам без мыши. так быстрее.
Когда вот будут электронные карты, когда ничего вводить не нужно будет, тогда и может и хоткей будет менее востребован.
Хотя разработчикам в тех же visual studio, 3dmax, без hotkey думаю будет тяжело

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

А>>>2) hotkeys — веб приложение не может полноценно обрабатывать hotkey часть из них забирает броузер.
G>>В эпоху тач устройств не важно.
А>"тач устройства" только для баловства, а приложения бывают для работы

Работа, не связанная с набиранием текста, легко делается на тач устройствах.

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

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

А>>>>2) hotkeys — веб приложение не может полноценно обрабатывать hotkey часть из них забирает броузер.
G>>>В эпоху тач устройств не важно.
А>>"тач устройства" только для баловства, а приложения бывают для работы

G>Работа, не связанная с набиранием текста, легко делается на тач устройствах.

photoshop, autocad, 3dmax легко ? ( если забыть про требуюмую мощность и размер экрана для производительной работы )

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

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

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

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

А>>>Пока вижу 2

А>>>1) javascript — открытый код, то есть где он не будет удовлетворять требованиям безопасности придется отказываться от ajax в данных формах, в результате замедление отклика интерфейса.
G>>Как связаны ajax и безопасность?
А>ajax — реализация некой логики в javascript, который открыт для просмотра и изменения.
Для начала стоит посмотреть определение этого термина хотябы в википедии.

А>так и связаны, что можно подменить скрипт.
А>Если будешь сумму кошелька вычислять и хранить в javascript, то это врятли будет считаться безопасным решением.
В таком подходе у тебя много проблем и до безопасности будет.
А если ты сделаешь корректное приложение, то "подмена скрипта" уже не будет вектором атаки.

А>>>2) hotkeys — веб приложение не может полноценно обрабатывать hotkey часть из них забирает броузер.
G>>В эпоху тач устройств не важно.
А>Тач устройства пока не используются в промышленном виде, например когда приходишь в какуюнить контору ( банк например ) там операционист не на планшете твои данные вбивает, и врятли будет на планшете вбивать, требования к по в сбере например — любые действия чтобы можно было сделать по кнопкам без мыши. так быстрее.
Для скорости ввода хоткеи тоже не нужны. нужно использование клавиш Tab, Enter и пробел.

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

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

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

А>>>>>2) hotkeys — веб приложение не может полноценно обрабатывать hotkey часть из них забирает броузер.
G>>>>В эпоху тач устройств не важно.
А>>>"тач устройства" только для баловства, а приложения бывают для работы

G>>Работа, не связанная с набиранием текста, легко делается на тач устройствах.

А>photoshop, autocad, 3dmax легко ? ( если забыть про требуюмую мощность и размер экрана для производительной работы )

У этих приложений интерфейс не адаптирован под тач, а вообще проблем не вижу.

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

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

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

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

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

А>>>>Пока вижу 2

А>>>>1) javascript — открытый код, то есть где он не будет удовлетворять требованиям безопасности придется отказываться от ajax в данных формах, в результате замедление отклика интерфейса.
G>>>Как связаны ajax и безопасность?
А>>ajax — реализация некой логики в javascript, который открыт для просмотра и изменения.
G>Для начала стоит посмотреть определение этого термина хотябы в википедии.

А>>так и связаны, что можно подменить скрипт.
А>>Если будешь сумму кошелька вычислять и хранить в javascript, то это врятли будет считаться безопасным решением.
G>В таком подходе у тебя много проблем и до безопасности будет.
G>А если ты сделаешь корректное приложение, то "подмена скрипта" уже не будет вектором атаки.
В асинхронных приложениях как правило не брезгуют кэшем значений и пр. , поэтому казалось бы только ассинхронность что тут опасного, но в любом случае для выполнения асинхронных запросов через javascript , одно дело когда отправил запрос http://mysite?page=10 и получил целиком страницу. Друое дело когда у тебя страница загружается ajax запросами, каждый торчащий лишний метод — уже дополнительная дырка для атаки.

А>>>>2) hotkeys — веб приложение не может полноценно обрабатывать hotkey часть из них забирает броузер.
G>>>В эпоху тач устройств не важно.
А>>Тач устройства пока не используются в промышленном виде, например когда приходишь в какуюнить контору ( банк например ) там операционист не на планшете твои данные вбивает, и врятли будет на планшете вбивать, требования к по в сбере например — любые действия чтобы можно было сделать по кнопкам без мыши. так быстрее.
G>Для скорости ввода хоткеи тоже не нужны. нужно использование клавиш Tab, Enter и пробел.
Для скорости ввода нужны хоткеи , чтобы бысро переключаться между группами контролов , если 40 полей — вместо того чтобы перейти к нужному полю по Alt-(ключслово) , придется 40 раз нажать tab ? нет спасибо.

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

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

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

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

А>>>>>>2) hotkeys — веб приложение не может полноценно обрабатывать hotkey часть из них забирает броузер.
G>>>>>В эпоху тач устройств не важно.
А>>>>"тач устройства" только для баловства, а приложения бывают для работы

G>>>Работа, не связанная с набиранием текста, легко делается на тач устройствах.

А>>photoshop, autocad, 3dmax легко ? ( если забыть про требуюмую мощность и размер экрана для производительной работы )

G>У этих приложений интерфейс не адаптирован под тач, а вообще проблем не вижу.
А чем же он тогда не адаптирован под тач ? Проблем много, одно дело когда нужно нажать 2 кнопки на клавиатуре, другое когда нужно лазить по меню.

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

А>В асинхронных приложениях как правило не брезгуют кэшем значений и пр. , поэтому казалось бы только ассинхронность что тут опасного, но в любом случае для выполнения асинхронных запросов через javascript , одно дело когда отправил запрос http://mysite?page=10 и получил целиком страницу. Друое дело когда у тебя страница загружается ajax запросами, каждый торчащий лишний метод — уже дополнительная дырка для атаки.
Смешались в кучу кони, люди...
Давай по отдельности:
1) Как кеширование значений влияет на безопасность?
2) Как количество эндпоинтов влияет на безопасность?

Вообще сейчас придет Владимир Кочетков и расскажет где ты неправ.

G>>Для скорости ввода хоткеи тоже не нужны. нужно использование клавиш Tab, Enter и пробел.
А>Для скорости ввода нужны хоткеи , чтобы бысро переключаться между группами контролов , если 40 полей — вместо того чтобы перейти к нужному полю по Alt-(ключслово) , придется 40 раз нажать tab ? нет спасибо.
Если у тебя 40 контролов и тебе более 80% надо ввести, тогда хоткеи тебе не помогут, все равно все надо вводить данные.
Если у тебя 40 контролов, но вводить надо <20%, то на кой на форме тогда 40 контролов, а не 8?

При правильном проектировании форм хоткеи не нужны, а при плохом и хоткеи не помогут.

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

А>>>photoshop, autocad, 3dmax легко ? ( если забыть про требуюмую мощность и размер экрана для производительной работы )

G>>У этих приложений интерфейс не адаптирован под тач, а вообще проблем не вижу.
А>А чем же он тогда не адаптирован под тач ? Проблем много, одно дело когда нужно нажать 2 кнопки на клавиатуре, другое когда нужно лазить по меню.
1) Модальностью интерфейса. Типа клик это одно, а ctrl+click другое.
2) Ориентацией на нажатие ПКМ.
3) Слишком маленькими anchor_ами для клика, в которые пальцем не попадешь.
4) Ориентацией на клавиатурный ввод.

Рекомендую глянуть OneNote MX и Grapholite приложения в Windows Marketplace. Они в правильном направлении идут.

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

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

PD>Примитивизм. Достаточно сравнить MS Office и Google Docs.

Лучше сравни атлук и аутлук веб, оффис и оффис веб. Для многих разница незначительна.

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

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

А>>>>photoshop, autocad, 3dmax легко ? ( если забыть про требуюмую мощность и размер экрана для производительной работы )

G>>>У этих приложений интерфейс не адаптирован под тач, а вообще проблем не вижу.
А>>А чем же он тогда не адаптирован под тач ? Проблем много, одно дело когда нужно нажать 2 кнопки на клавиатуре, другое когда нужно лазить по меню.
G>1) Модальностью интерфейса. Типа клик это одно, а ctrl+click другое.
G>2) Ориентацией на нажатие ПКМ.
G>3) Слишком маленькими anchor_ами для клика, в которые пальцем не попадешь.
G>4) Ориентацией на клавиатурный ввод.

Дело тут не в ориентации нажатий на ПКМ, и прочем.
Например чтобы добавить новую сцену и создать на ней объект нажму Ctrl-N, Ctrl-O. Этого никакими концепциями OneNote MX не заменить.

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

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

А>>В асинхронных приложениях как правило не брезгуют кэшем значений и пр. , поэтому казалось бы только ассинхронность что тут опасного, но в любом случае для выполнения асинхронных запросов через javascript , одно дело когда отправил запрос http://mysite?page=10 и получил целиком страницу. Друое дело когда у тебя страница загружается ajax запросами, каждый торчащий лишний метод — уже дополнительная дырка для атаки.
G>Смешались в кучу кони, люди...
G>Давай по отдельности:
G>1) Как кеширование значений влияет на безопасность?\
можно подменить значение на клиенте и вмешаться в логику работы, а как это влияет на безопасность думаю объяснять не надо
G>2) Как количество эндпоинтов влияет на безопасность?
тут вопрос риторический, если знаком с теорией вероятностей то ответ очевиден. Каждый ендпоинт — дыра с определенным % критичных проблем, больше endpoint — больше общий % и возможностей для маневра.

G>>>Для скорости ввода хоткеи тоже не нужны. нужно использование клавиш Tab, Enter и пробел.
А>>Для скорости ввода нужны хоткеи , чтобы бысро переключаться между группами контролов , если 40 полей — вместо того чтобы перейти к нужному полю по Alt-(ключслово) , придется 40 раз нажать tab ? нет спасибо.
G>Если у тебя 40 контролов и тебе более 80% надо ввести, тогда хоткеи тебе не помогут, все равно все надо вводить данные.ъ
Ага, а если я ввел неправильно фамилию в 1м контроле , потом на середине это замечено и нужно исправить ? Табом лезть 20 нажатий ? Иногда при таком подходе случайно можно пролететь мимо и опять круг в 40 контролов давать. Нет уж спасибо.
Если обращал внимание на всех нормальных формах у лейблов есть подчеркнутая буква, которая является как раз быстрым хоткеем для данного поля.

G>Если у тебя 40 контролов, но вводить надо <20%, то на кой на форме тогда 40 контролов, а не 8?
Даже 8 контролов хоткей не помешает по причине приведенной выше. Если контролы раскиданы по закладкам то быстрый переход от одной закладки к другой тоже важен.

G>При правильном проектировании форм хоткеи не нужны, а при плохом и хоткеи не помогут.
Неверно. Хоткеи нужны практически всегда. Если это не программа перделка с одной кнопкой. Чтобы обеспечить быстрый доступ к сотне функций приложения.

Из рекомендаций MS:
Используйте насыщенные клиентские приложения, если:
 Приложение должно поддерживать сценарии без подключения или без постоянного подключения.
 Приложение будет развертываться на клиентских ПК.
 Приложение должно обеспечивать высокий уровень интерактивности и минимальное время отклика.
 UI приложения должен обеспечивать насыщенную функциональность и взаимодействие с пользователем, но без расширенных графических возможностей или возможностей воспроизведения мультимедиа RIA.
 Приложение должно использовать ресурсы клиентского ПК.

Используйте Веб-приложения, если:
 Приложению не требуется поддерживать насыщенный UI и мультимедиа, что предлагает насыщенное Интернет-приложение.
 Требуется обеспечить простую модель развертывания в Веб.
 Пользовательский интерфейс должен быть независимым от платформы.
 Приложение должно быть доступным через Интернет.
 Требуется максимально сократить зависимости на стороне клиента и потребление ресурсов, таких как дисковое пространство или вычислительные мощности процессора.

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

А>Впринципе о любых, которые нельзя выносить наружу.

Речь о standalone client-side приложениях или все же о полноценных веб, с серверной частью и HTTP-запросами?

... << RSDN@Home 1.2.0 alpha 5 rev. 72>>

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

G>А с другой стороны есть facebook\vk\linkedin, десктопные клиенты которых до сих пор очень далеки до веб-версии. Просто исторически так сложилось, как и с Office.

Может быть, да, исторически сложилось. Но это как раз аргумент в мою пользу. Ну не сделали такой десктопный клиент, не надо.
А вот сделать все же Word/Excel в web-исполнении — не получается. Сделали бы, надо, но не могут.

PD>>Ну а насчет аналогов Photoshop или Autocad или чего-то вроде DevStudio, и т.д. в web-исполнении я не слышал. Если есть — дай ссылку.
G>Я тоже не слышал, но это абсолютно ни о чем не говорит.

А вот их, судя по всему, при нынешнем подходе к web-приложениям, просто нельзя сделать. Заметь, я не говорю "вообще нельзя". В принципе ясно, что можно. Только здесь надо заново продумать, что будет делаться на клиенте, а что на сервере, и как они обмениваться данными будут.

Вот есть такой текстовый редактор UltraEdit. Редактирует текстовые файлы любой длины, я с его помощью редактировал csv в сотни Мб. Ясно, что механизм отсылки этого файла на сервер и редактирования там с последующей отсылкой результата на клиент не проходит. Но на клиенте он вполне мог бы редактироваться и в web приложении, если бы web-приложение имело право прямо писать на клиент. А оно не имеет права по известным причинам...

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

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

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

G>>Давай по отдельности:
G>>1) Как кеширование значений влияет на безопасность?\
А>можно подменить значение на клиенте и вмешаться в логику работы, а как это влияет на безопасность думаю объяснять не надо
Если значение кеша влияет на логику, то это уже не кеш, а что-то странное. У тебя быстрее другие проблемы возникнут при таком подходе.

G>>2) Как количество эндпоинтов влияет на безопасность?
А>тут вопрос риторический, если знаком с теорией вероятностей то ответ очевиден. Каждый ендпоинт — дыра с определенным % критичных проблем, больше endpoint — больше общий % и возможностей для маневра.
Модель угроз не строится на теории вероятностей.

G>>>>Для скорости ввода хоткеи тоже не нужны. нужно использование клавиш Tab, Enter и пробел.
А>>>Для скорости ввода нужны хоткеи , чтобы бысро переключаться между группами контролов , если 40 полей — вместо того чтобы перейти к нужному полю по Alt-(ключслово) , придется 40 раз нажать tab ? нет спасибо.
G>>Если у тебя 40 контролов и тебе более 80% надо ввести, тогда хоткеи тебе не помогут, все равно все надо вводить данные.ъ
А>Ага, а если я ввел неправильно фамилию в 1м контроле , потом на середине это замечено и нужно исправить ? Табом лезть 20 нажатий ? Иногда при таком подходе случайно можно пролететь мимо и опять круг в 40 контролов давать. Нет уж спасибо.
Про shift+tab не в курсе?

G>>Если у тебя 40 контролов, но вводить надо <20%, то на кой на форме тогда 40 контролов, а не 8?
А>Даже 8 контролов хоткей не помешает по причине приведенной выше. Если контролы раскиданы по закладкам то быстрый переход от одной закладки к другой тоже важен.
Закладки на формах ввода надо выжигать и делать клеймо тем, кто их придумал туда воткнуть.

G>>При правильном проектировании форм хоткеи не нужны, а при плохом и хоткеи не помогут.
А>Неверно. Хоткеи нужны практически всегда. Если это не программа перделка с одной кнопкой. Чтобы обеспечить быстрый доступ к сотне функций приложения.
Приложение с сотней функций делать нет смысла. Большинство из них не будут использованы.
Почитай about face алана купера.

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

PD>>Примитивизм. Достаточно сравнить MS Office и Google Docs.

I>Лучше сравни атлук и аутлук веб, оффис и оффис веб. Для многих разница незначительна.

Согласен, многих устраивает. Я же не говорю, что они вообще никуда не годятся. Просто они примитивны по сравнению с десктопными. Но многих, да, этот примитив устраивает.
Кого-то и Word времен MS-DOS вполне устраивал.

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

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

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

А>>>>>photoshop, autocad, 3dmax легко ? ( если забыть про требуюмую мощность и размер экрана для производительной работы )

G>>>>У этих приложений интерфейс не адаптирован под тач, а вообще проблем не вижу.
А>>>А чем же он тогда не адаптирован под тач ? Проблем много, одно дело когда нужно нажать 2 кнопки на клавиатуре, другое когда нужно лазить по меню.
G>>1) Модальностью интерфейса. Типа клик это одно, а ctrl+click другое.
G>>2) Ориентацией на нажатие ПКМ.
G>>3) Слишком маленькими anchor_ами для клика, в которые пальцем не попадешь.
G>>4) Ориентацией на клавиатурный ввод.

А>Дело тут не в ориентации нажатий на ПКМ, и прочем.
А>Например чтобы добавить новую сцену и создать на ней объект нажму Ctrl-N, Ctrl-O. Этого никакими концепциями OneNote MX не заменить.

А ты вообще смотрел OneNote mx прежде чем писать? Похоже что нет.

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

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

G>>А с другой стороны есть facebook\vk\linkedin, десктопные клиенты которых до сих пор очень далеки до веб-версии. Просто исторически так сложилось, как и с Office.

PD>Может быть, да, исторически сложилось. Но это как раз аргумент в мою пользу. Ну не сделали такой десктопный клиент, не надо.
PD>А вот сделать все же Word/Excel в web-исполнении — не получается. Сделали бы, надо, но не могут.
А ты webapps не видел? Сделали уже, около 40% функций десктопной реализует. Для аутлука почти 100%.потому что owa появилась в 1996 году, а webapps в 2010.

Причём если бы изначально офис делали для веба, то ситуация получилась бы обратная.

PD>>>Ну а насчет аналогов Photoshop или Autocad или чего-то вроде DevStudio, и т.д. в web-исполнении я не слышал. Если есть — дай ссылку.
G>>Я тоже не слышал, но это абсолютно ни о чем не говорит.

PD>А вот их, судя по всему, при нынешнем подходе к web-приложениям, просто нельзя сделать. Заметь, я не говорю "вообще нельзя". В принципе ясно, что можно. Только здесь надо заново продумать, что будет делаться на клиенте, а что на сервере, и как они обмениваться данными будут.
Да все можно, на сервере надо минимум.

PD>Вот есть такой текстовый редактор UltraEdit. Редактирует текстовые файлы любой длины, я с его помощью редактировал csv в сотни Мб. Ясно, что механизм отсылки этого файла на сервер и редактирования там с последующей отсылкой результата на клиент не проходит. Но на клиенте он вполне мог бы редактироваться и в web приложении, если бы web-приложение имело право прямо писать на клиент. А оно не имеет права по известным причинам...
Ты про FileApi не в курсе? Твои знания устарели года на 3, почитай что браузеры сейчас умеют, удивишься...

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

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

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

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

G>>>Давай по отдельности:
G>>>1) Как кеширование значений влияет на безопасность?\
А>>можно подменить значение на клиенте и вмешаться в логику работы, а как это влияет на безопасность думаю объяснять не надо
G>Если значение кеша влияет на логику, то это уже не кеш, а что-то странное. У тебя быстрее другие проблемы возникнут при таком подходе.

Кэш в любом случае влияет на логику, т.к. он используется в каком либо коде, иначе он не нужен вообще.

G>>>2) Как количество эндпоинтов влияет на безопасность?
А>>тут вопрос риторический, если знаком с теорией вероятностей то ответ очевиден. Каждый ендпоинт — дыра с определенным % критичных проблем, больше endpoint — больше общий % и возможностей для маневра.
G>Модель угроз не строится на теории вероятностей.
Ага, только причем тут модель угроз, речь о вероятности взлома, которая увеличивается от количества дырок.

G>>>>>Для скорости ввода хоткеи тоже не нужны. нужно использование клавиш Tab, Enter и пробел.
А>>>>Для скорости ввода нужны хоткеи , чтобы бысро переключаться между группами контролов , если 40 полей — вместо того чтобы перейти к нужному полю по Alt-(ключслово) , придется 40 раз нажать tab ? нет спасибо.
G>>>Если у тебя 40 контролов и тебе более 80% надо ввести, тогда хоткеи тебе не помогут, все равно все надо вводить данные.ъ
А>>Ага, а если я ввел неправильно фамилию в 1м контроле , потом на середине это замечено и нужно исправить ? Табом лезть 20 нажатий ? Иногда при таком подходе случайно можно пролететь мимо и опять круг в 40 контролов давать. Нет уж спасибо.
G>Про shift+tab не в курсе?
Какая разница 20 нажатий вверх, или вниз. Проблемы которые описаны остануться.

G>>>Если у тебя 40 контролов, но вводить надо <20%, то на кой на форме тогда 40 контролов, а не 8?
А>>Даже 8 контролов хоткей не помешает по причине приведенной выше. Если контролы раскиданы по закладкам то быстрый переход от одной закладки к другой тоже важен.
G>Закладки на формах ввода надо выжигать и делать клеймо тем, кто их придумал туда воткнуть.

G>>>При правильном проектировании форм хоткеи не нужны, а при плохом и хоткеи не помогут.
А>>Неверно. Хоткеи нужны практически всегда. Если это не программа перделка с одной кнопкой. Чтобы обеспечить быстрый доступ к сотне функций приложения.
G>Приложение с сотней функций делать нет смысла. Большинство из них не будут использованы.
G>Почитай about face алана купера.
Скажи как сделать 3дмакс из 3х функций, потом говори глупости

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

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

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

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

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

G>>>>Давай по отдельности:
G>>>>1) Как кеширование значений влияет на безопасность?\
А>>>можно подменить значение на клиенте и вмешаться в логику работы, а как это влияет на безопасность думаю объяснять не надо
G>>Если значение кеша влияет на логику, то это уже не кеш, а что-то странное. У тебя быстрее другие проблемы возникнут при таком подходе.

А>Кэш в любом случае влияет на логику, т.к. он используется в каком либо коде, иначе он не нужен вообще.
А что мешает кеш в толстом клиенте поправить у десктопного приложения, если он на логику влияет? В чем разница с вебом будет?

G>>>>2) Как количество эндпоинтов влияет на безопасность?
А>>>тут вопрос риторический, если знаком с теорией вероятностей то ответ очевиден. Каждый ендпоинт — дыра с определенным % критичных проблем, больше endpoint — больше общий % и возможностей для маневра.
G>>Модель угроз не строится на теории вероятностей.
А>Ага, только причем тут модель угроз, речь о вероятности взлома, которая увеличивается от количества дырок.
Если у тебя нет модели угроз, то как ты можешь вероятность чего-либо найти? Прочитай чтонить про ИБ для начала. У тебя очень дилетантские суждения.

G>>>>>>Для скорости ввода хоткеи тоже не нужны. нужно использование клавиш Tab, Enter и пробел.
А>>>>>Для скорости ввода нужны хоткеи , чтобы бысро переключаться между группами контролов , если 40 полей — вместо того чтобы перейти к нужному полю по Alt-(ключслово) , придется 40 раз нажать tab ? нет спасибо.
G>>>>Если у тебя 40 контролов и тебе более 80% надо ввести, тогда хоткеи тебе не помогут, все равно все надо вводить данные.ъ
А>>>Ага, а если я ввел неправильно фамилию в 1м контроле , потом на середине это замечено и нужно исправить ? Табом лезть 20 нажатий ? Иногда при таком подходе случайно можно пролететь мимо и опять круг в 40 контролов давать. Нет уж спасибо.
G>>Про shift+tab не в курсе?
А>Какая разница 20 нажатий вверх, или вниз. Проблемы которые описаны остануться.
Промахнуться не проблема, а кнопку tab можно ооооочень быстро нажимать. Не обращал внимание как в ПФ в досовском интерфейсе данные вбивают?

G>>Почитай about face алана купера.
А>Скажи как сделать 3дмакс из 3х функций, потом говори глупости
Ты же не 3dmax делаешь, даже близко не похожее на него.
Почитай купера, там многие ответы на твои вопросы.

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

G>А ты webapps не видел? Сделали уже, около 40% функций десктопной реализует. Для аутлука почти 100%.потому что owa появилась в 1996 году, а webapps в 2010.

Outlook не аргумент, почта — примитив по сравнению с редактированием. В сущности, в почтовом десктопном клиенте уже лет 15 по большому счету ничего не меняется, нечего там менять.

G>Причём если бы изначально офис делали для веба, то ситуация получилась бы обратная.

Вряд ли. Во времена DOS, когда Word начался, его просто не могли делать. Да и до Word редакторов хватало, и до Excel электронные таблицы были, так что MS должна была уже тогда как минимум их возможности повторить. А Web тогда был в состоянии статических страниц.

PD>>А вот их, судя по всему, при нынешнем подходе к web-приложениям, просто нельзя сделать. Заметь, я не говорю "вообще нельзя". В принципе ясно, что можно. Только здесь надо заново продумать, что будет делаться на клиенте, а что на сервере, и как они обмениваться данными будут.
G>Да все можно, на сервере надо минимум.

Можно, но именно минимум. А сейчас не минимум.

PD>>Вот есть такой текстовый редактор UltraEdit. Редактирует текстовые файлы любой длины, я с его помощью редактировал csv в сотни Мб. Ясно, что механизм отсылки этого файла на сервер и редактирования там с последующей отсылкой результата на клиент не проходит. Но на клиенте он вполне мог бы редактироваться и в web приложении, если бы web-приложение имело право прямо писать на клиент. А оно не имеет права по известным причинам...
G>Ты про FileApi не в курсе? Твои знания устарели года на 3, почитай что браузеры сейчас умеют, удивишься...

Не был в курсе. Спасибо. Посмотрел. Только вот такой вопрос

http://www.w3.org/TR/FileAPI/

FileReader там есть. А вот FileWriter я не нашел. Его нет ? Если нет, то для редактирования на клиенте это не годится — см. выше мой пример с UltraEdit хотя бы, да и не только.

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

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

G>>А ты webapps не видел? Сделали уже, около 40% функций десктопной реализует. Для аутлука почти 100%.потому что owa появилась в 1996 году, а webapps в 2010.

PD>Outlook не аргумент, почта — примитив по сравнению с редактированием. В сущности, в почтовом десктопном клиенте уже лет 15 по большому счету ничего не меняется, нечего там менять.
Word\Excel за последние 8 лет тоже не сильно поменялись функционально, вот только в вебе их почти никто не делал, поэтому убого. А почта в вебе давно существует, поэтому с дсктопом почти паритет.

G>>Причём если бы изначально офис делали для веба, то ситуация получилась бы обратная.

PD>Вряд ли. Во времена DOS, когда Word начался, его просто не могли делать. Да и до Word редакторов хватало, и до Excel электронные таблицы были, так что MS должна была уже тогда как минимум их возможности повторить. А Web тогда был в состоянии статических страниц.
Ну вот ты сам видишь какие причины были тогда. А сейчас они есть? Вообще-то нет.

PD>>>А вот их, судя по всему, при нынешнем подходе к web-приложениям, просто нельзя сделать. Заметь, я не говорю "вообще нельзя". В принципе ясно, что можно. Только здесь надо заново продумать, что будет делаться на клиенте, а что на сервере, и как они обмениваться данными будут.
G>>Да все можно, на сервере надо минимум.

PD>Можно, но именно минимум. А сейчас не минимум.

PD>>>Вот есть такой текстовый редактор UltraEdit. Редактирует текстовые файлы любой длины, я с его помощью редактировал csv в сотни Мб. Ясно, что механизм отсылки этого файла на сервер и редактирования там с последующей отсылкой результата на клиент не проходит. Но на клиенте он вполне мог бы редактироваться и в web приложении, если бы web-приложение имело право прямо писать на клиент. А оно не имеет права по известным причинам...
G>>Ты про FileApi не в курсе? Твои знания устарели года на 3, почитай что браузеры сейчас умеют, удивишься...

PD>Не был в курсе. Спасибо. Посмотрел. Только вот такой вопрос

PD>http://www.w3.org/TR/FileAPI/

PD>FileReader там есть. А вот FileWriter я не нашел. Его нет ? Если нет, то для редактирования на клиенте это не годится — см. выше мой пример с UltraEdit хотя бы, да и не только.
http://www.w3.org/TR/file-system-api/

Вот только не поддерживается пока никем: http://caniuse.com/#feat=filesystem
Поэтому делают storage на сервере и webdav

Для начала нужно определиться, что считать веб-приложением.

RSDN@HOME это веб-приложение или нет?
Приложения, поднимающие локальные HTTP-сервера, это веб или нет?
Приложения на Flash, Silverlight, ActiveX, Java Applets?

Есть, например, такое поделие для электронного документооборота — DocsVision от Digital Design. Это приложение работает в окне браузера (IE only), но UI у него сделан из обычных формочек a la Windows Forms. С другой стороны все данные живут на сервере. Это веб-приложение?

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

PD>>Outlook не аргумент, почта — примитив по сравнению с редактированием. В сущности, в почтовом десктопном клиенте уже лет 15 по большому счету ничего не меняется, нечего там менять.
G>Word\Excel за последние 8 лет тоже не сильно поменялись функционально, вот только в вебе их почти никто не делал, поэтому убого.

Ну как же никто ? И Google, и MS. Но убого. Уж MS-то сделать хотела бы не хуже, чем Word, да вот не может. Впрочем, Google тоже — десктопного редактора-то у них нет, отобрать бы весь рынок у MS Office — дело святое. Да вот не получается.

>А почта в вебе давно существует, поэтому с дсктопом почти паритет.

Задача относительно более простая, чем редактирование. В сущности, 95% — это перекачка файлов, просмотр их и простенький текстовый редактор. За всем остальным (хотя бы просмотр вложений) — в обоих случаях десктопное приложение (или нативный плугин) извольте иметь)

G>>>Причём если бы изначально офис делали для веба, то ситуация получилась бы обратная.

PD>>Вряд ли. Во времена DOS, когда Word начался, его просто не могли делать. Да и до Word редакторов хватало, и до Excel электронные таблицы были, так что MS должна была уже тогда как минимум их возможности повторить. А Web тогда был в состоянии статических страниц.
G>Ну вот ты сам видишь какие причины были тогда. А сейчас они есть? Вообще-то нет.

Я же не говорю, что сделать _в_принципе нельзя. В принципе можно. Но нет их пока. Я и в первом ответе не сказал, что в принципе убого. На данный момент убого.

G>Вот только не поддерживается пока никем: http://caniuse.com/#feat=filesystem
G>Поэтому делают storage на сервере и webdav

Ну вот и попробуй этот самый csv на сотни Мб гонять с сервера на клиент... Или картинку пусть даже в десятки Мб. Или (о ужас!) фильм какой-нибудь.

А работать на клиенте не получается именно из-за запрета записи на клиент. Вот тут принципиальная проблема. Если я запускаю десктопную программу, скачанную с сайта MS, то я знаю, что она от MS, им я доверяю, и программу запускаю. Конечно, баги возможны, в том числе и всякие уязвимости, но тем не менее я запускаю программу, которой можно доверять. А вот если у меня в броузере работает JS, то доверять ему нельзя, так как нет никакой гарантии, что он не от MS, а бог знает откуда. Пока эту проблему не решат — о серьезной работе с FS на клиенте речи идти не может.

А второй момент — идея работы на сервере вообще-то достаточно неразумна. Чем он, сервер, лучше моей машины ? Там Intel и здесь Intel, у меня 8 Гб, так и там мне не 256 Гб дадут, да и не нужны они мне. Словом, у меня машина ничем не хуже, чем одна машина из их кластера, почему же надо операции на сервере делать ? На сервере минимум должен делаться, а тяжелые действия на клиенте.

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

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

>>А почта в вебе давно существует, поэтому с дсктопом почти паритет.
PD>Задача относительно более простая, чем редактирование. В сущности, 95% — это перекачка файлов, просмотр их и простенький текстовый редактор. За всем остальным (хотя бы просмотр вложений) — в обоих случаях десктопное приложение (или нативный плугин) извольте иметь)
Посмотри с другой сторны. Facebook например или вконтактик. Очень пригодилось бы дестопное приложение, которое локально закачивает основные ресурсы и позволяет оффлайново смотреть + минимальный трафик для пересылки сообщений.
Апи вроде уже давно есть, а нормальных приложений днем с огнем не найти.

Тоже исторический фактор. Чтобы сейчас сделать десктоп версию, сравнимую с веб надо вбухать десяток человеколет. Оно как минимум не окупится. Поэтому никто не занимается.
Это и называется историческим фактором. Функционал тут совершенно не при чем.

G>>>>Причём если бы изначально офис делали для веба, то ситуация получилась бы обратная.

PD>>>Вряд ли. Во времена DOS, когда Word начался, его просто не могли делать. Да и до Word редакторов хватало, и до Excel электронные таблицы были, так что MS должна была уже тогда как минимум их возможности повторить. А Web тогда был в состоянии статических страниц.
G>>Ну вот ты сам видишь какие причины были тогда. А сейчас они есть? Вообще-то нет.

PD>Я же не говорю, что сделать _в_принципе нельзя. В принципе можно. Но нет их пока. Я и в первом ответе не сказал, что в принципе убого. На данный момент убого.
А какая разница? Когда соберешься приложение делать ты будешь смотреть на опыт 10-летней давности или на современные возможности?

G>>Вот только не поддерживается пока никем: http://caniuse.com/#feat=filesystem
G>>Поэтому делают storage на сервере и webdav

PD>Ну вот и попробуй этот самый csv на сотни Мб гонять с сервера на клиент... Или картинку пусть даже в десятки Мб. Или (о ужас!) фильм какой-нибудь.
Зачем весь файл гонять? Гоняй кусками. Например office 2013 это уже делает с SharePoint 2013. Передает не вейсь файл, а только изменившиеся части. А частичная закачка в HTTP всегда была.

PD>А работать на клиенте не получается именно из-за запрета записи на клиент. Вот тут принципиальная проблема. Если я запускаю десктопную программу, скачанную с сайта MS, то я знаю, что она от MS, им я доверяю, и программу запускаю. Конечно, баги возможны, в том числе и всякие уязвимости, но тем не менее я запускаю программу, которой можно доверять. А вот если у меня в броузере работает JS, то доверять ему нельзя, так как нет никакой гарантии, что он не от MS, а бог знает откуда. Пока эту проблему не решат — о серьезной работе с FS на клиенте речи идти не может.
HTTPS не? SOP не для тебя придумали?
Ты довольно слабо ориентируешься в веб-технологиях, чтобы судить о таких вещах.
Кстати при использовании доступа к ФС тебя спросят дополнительно. Причем левые скрипты, загруженные из других источников, не получат доступ к твоему компу.

PD>А второй момент — идея работы на сервере вообще-то достаточно неразумна. Чем он, сервер, лучше моей машины ? Там Intel и здесь Intel, у меня 8 Гб, так и там мне не 256 Гб дадут, да и не нужны они мне. Словом, у меня машина ничем не хуже, чем одна машина из их кластера, почему же надо операции на сервере делать ? На сервере минимум должен делаться, а тяжелые действия на клиенте.
Зависит от приложения, тут однозначно ничего сказать нельзя.

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

G>Посмотри с другой сторны. Facebook например или вконтактик. Очень пригодилось бы дестопное приложение, которое локально закачивает основные ресурсы и позволяет оффлайново смотреть + минимальный трафик для пересылки сообщений.
G>Апи вроде уже давно есть, а нормальных приложений днем с огнем не найти.

Ну как сказать. Для RSDN вроде есть оффлайн-клиент. Почему там нет — не знаю. Но это опять же : перекачка плюс просмотр. Больше практически ничего. Перекачка в любом случае сетевая, а просмотр довольно примтивен. Может, поэтому и нет оффлайн-клиента.

G>Тоже исторический фактор. Чтобы сейчас сделать десктоп версию, сравнимую с веб надо вбухать десяток человеколет. Оно как минимум не окупится. Поэтому никто не занимается.
G>Это и называется историческим фактором. Функционал тут совершенно не при чем.

Не соглашусь. Во-первых, десяток человеко-лет — это не то, что немного, а совсем немного. Команда из 10 человек на год для MS — пустяк. Сделали бы без проблем, если бы смысл был.

PD>>Я же не говорю, что сделать _в_принципе нельзя. В принципе можно. Но нет их пока. Я и в первом ответе не сказал, что в принципе убого. На данный момент убого.
G>А какая разница? Когда соберешься приложение делать ты будешь смотреть на опыт 10-летней давности или на современные возможности?

Обсуждалось нынешнее состояние web приложений. Причем именно состояние, а не потенциальные возможности. Они пока что потенциальны, а не реальны. Когда будет иное состояние — будет иной разговор.

PD>>Ну вот и попробуй этот самый csv на сотни Мб гонять с сервера на клиент... Или картинку пусть даже в десятки Мб. Или (о ужас!) фильм какой-нибудь.
G>Зачем весь файл гонять? Гоняй кусками. Например office 2013 это уже делает с SharePoint 2013. Передает не вейсь файл, а только изменившиеся части. А частичная закачка в HTTP всегда была.

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

G>HTTPS не? SOP не для тебя придумали?
G>Ты довольно слабо ориентируешься в веб-технологиях, чтобы судить о таких вещах.

Наверное да, это не моя тематика. Я просто сужу о факте — обработки на клиенте нет.

G>Кстати при использовании доступа к ФС тебя спросят дополнительно. Причем левые скрипты, загруженные из других источников, не получат доступ к твоему компу.

Хорошо, если так. Пример можно ? Посмотрю.

PD>>А второй момент — идея работы на сервере вообще-то достаточно неразумна. Чем он, сервер, лучше моей машины ? Там Intel и здесь Intel, у меня 8 Гб, так и там мне не 256 Гб дадут, да и не нужны они мне. Словом, у меня машина ничем не хуже, чем одна машина из их кластера, почему же надо операции на сервере делать ? На сервере минимум должен делаться, а тяжелые действия на клиенте.
G>Зависит от приложения, тут однозначно ничего сказать нельзя.

Однозначно, конечно, нет, мало ли что там нужно сделать. Но для того, что делает Фотошоп — однозначно да. Делает же он

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

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

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

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

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

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

G>>>>>Давай по отдельности:
G>>>>>1) Как кеширование значений влияет на безопасность?\
А>>>>можно подменить значение на клиенте и вмешаться в логику работы, а как это влияет на безопасность думаю объяснять не надо
G>>>Если значение кеша влияет на логику, то это уже не кеш, а что-то странное. У тебя быстрее другие проблемы возникнут при таком подходе.

А>>Кэш в любом случае влияет на логику, т.к. он используется в каком либо коде, иначе он не нужен вообще.
G>А что мешает кеш в толстом клиенте поправить у десктопного приложения, если он на логику влияет? В чем разница с вебом будет?
Разница в том что легко подменить логику создав новый скрипт или в режиме отладки изменить. Для подобного действия с скомпилированным кодом , при наличии защиты от отладки требуется намного большие компетенции.

G>>>>>2) Как количество эндпоинтов влияет на безопасность?
А>>>>тут вопрос риторический, если знаком с теорией вероятностей то ответ очевиден. Каждый ендпоинт — дыра с определенным % критичных проблем, больше endpoint — больше общий % и возможностей для маневра.
G>>>Модель угроз не строится на теории вероятностей.
А>>Ага, только причем тут модель угроз, речь о вероятности взлома, которая увеличивается от количества дырок.
G>Если у тебя нет модели угроз, то как ты можешь вероятность чего-либо найти? Прочитай чтонить про ИБ для начала. У тебя очень дилетантские суждения.
Пока что дилетант это ты, т.к. не понимаешь простых вещей, что любой метод торчащий наружу это находка для злоумышленника, и какието демагогии про модели, модель тут банальнейшая — возможность отправить кривые данные

G>>>>>>>Для скорости ввода хоткеи тоже не нужны. нужно использование клавиш Tab, Enter и пробел.
А>>>>>>Для скорости ввода нужны хоткеи , чтобы бысро переключаться между группами контролов , если 40 полей — вместо того чтобы перейти к нужному полю по Alt-(ключслово) , придется 40 раз нажать tab ? нет спасибо.
G>>>>>Если у тебя 40 контролов и тебе более 80% надо ввести, тогда хоткеи тебе не помогут, все равно все надо вводить данные.ъ
А>>>>Ага, а если я ввел неправильно фамилию в 1м контроле , потом на середине это замечено и нужно исправить ? Табом лезть 20 нажатий ? Иногда при таком подходе случайно можно пролететь мимо и опять круг в 40 контролов давать. Нет уж спасибо.
G>>>Про shift+tab не в курсе?
А>>Какая разница 20 нажатий вверх, или вниз. Проблемы которые описаны остануться.
G>Промахнуться не проблема, а кнопку tab можно ооооочень быстро нажимать. Не обращал внимание как в ПФ в досовском интерфейсе данные вбивают?

Чем быстрее жмешь тем больше шансов пролететь мимо, в досовском также есть ярлыки для полей как правило

G>>>Почитай about face алана купера.
А>>Скажи как сделать 3дмакс из 3х функций, потом говори глупости
G>Ты же не 3dmax делаешь, даже близко не похожее на него.
G>Почитай купера, там многие ответы на твои вопросы.
Откуда тебе знать что я делаю, телепат блин, я делаю многофункциональные приложения которые содержат сотни юзкейсов и операций.

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

Вот уж действительно, "смешались в кучу люди, кони..."

G>>>>>>2) Как количество эндпоинтов влияет на безопасность?

Ентрипоинтов. И то, что вы здесь обсуждаете называется защищенностью, а не безопасностью

А>>>>>тут вопрос риторический, если знаком с теорией вероятностей то ответ очевиден. Каждый ендпоинт — дыра с определенным % критичных проблем, больше endpoint — больше общий % и возможностей для маневра.

Это примерно то же самое, что сказать: "каждый метод — баг с определенным процентом критичных проблем", аргументируя необходимость минимизировать число методов в коде

G>>>>Модель угроз не строится на теории вероятностей.

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

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

Вероятность реализации той или иной угрозы (т.е. "взлома") не зависит от количества уязвимостей, т.к. равна 1.0 при появлении первой же из них.

G>>Если у тебя нет модели угроз, то как ты можешь вероятность чего-либо найти? Прочитай чтонить про ИБ для начала. У тебя очень дилетантские суждения.
А>Пока что дилетант это ты, т.к. не понимаешь простых вещей, что любой метод торчащий наружу это находка для злоумышленника, и какието демагогии про модели, модель тут банальнейшая — возможность отправить кривые данные

Во-первых, не стоит хамить друг-другу и пытаться уличить в некомпетентности. Замечание к обоим.

Во-вторых, Аноним вполне справедливо утверждает, что рост количества методов приводит к увеличению плоскости потенциальной атаки. А если быть точным, то не только и не столько методов, сколько их параметров, которыми может манипулировать атакующий. Т.е. отказ от ajax в пользу классической модели синхронных запросов ничего не даст — количество методов просто перейдет в количество их параметров, плоскость от этого не изменится. Слегка неправ Аноним в своем суждении о моделировании угроз. Стоило бы ознакомиться хотя бы с http://download.microsoft.com/download/9/3/5/935520EC-D9E2-413E-BEA7-0B865A79B18C/Introduction_to_Threat_Modeling.ppsx, прежде чем называть угрозой "возможность отправить кривые данные" (которая, к слову сказать, имеет место в сетевых приложениях вообще всегда, безотносительно веба и гуи). И совсем неправ Аноним в том, что считает будто на клиенте просто обязана быть реализована хоть какая-то бизнес логика, критичная к требованиям защищенности. Ничего не мешает реализовать такую логику на стороне сервера и получить вполне защищенное веб-приложение.

... << RSDN@Home 1.2.0 alpha 5 rev. 72>>

- Веб интерфейс не может на 100% использовать вычислительную мощь современных компьютеров, устанавливаемых у конечных пользователей.

— Нужно подстраиваться под разные браузеры. У каждого браузера есть особенности работы с HTML и javaScript.

— В RIA бизнес логика просачивается на уровень представления (на клиента в JavaScript).

— Ввиду того что веб сервисы это наборы методов (процедур), программирование часто становится процедурным. Полноценно использовать ООП в Web тяжело.

— JavaScript не типизированный, тяжело отлаживать, рефакторить

http://rsdn.ru/forum/job/4547080.1

Здесь про облака, но разговор с maxkar ушел в эту тему:
http://rsdn.ru/forum/design/5149465.1

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

IB>- Веб интерфейс не может на 100% использовать вычислительную мощь современных компьютеров, устанавливаемых у конечных пользователей.

IB>- Нужно подстраиваться под разные браузеры. У каждого браузера есть особенности работы с HTML и javaScript.
Особенности нивелируются фреймворками.

IB>- В RIA бизнес логика просачивается на уровень представления (на клиента в JavaScript).
Это хорошо или плохо? или просто написано?

IB>- Ввиду того что веб сервисы это наборы методов (процедур), программирование часто становится процедурным. Полноценно использовать ООП в Web тяжело.
Это неправда, посмотри data access фреймворки. Там ООП даже больше, чем стоило бы.

IB>- JavaScript не типизированный, тяжело отлаживать, рефакторить
Неактуально, есть typescript\script#\gwt\coffescript\dart.

G>Особенности нивелируются фреймворками.
G>Это неправда, посмотри data access фреймворки. Там ООП даже больше, чем стоило бы.
G>Неактуально, есть typescript\script#\gwt\coffescript\dart.
То, что в десктопном клиенте
можно достичь средствами строго типизированного ООП ЯП и GUI-ядром ОС (то есть уже встроенное, родное),
в Web
можно достичь только через всякие сторонние фреймворки, часть из которых сырая или не поддерживается.

G>Там ООП даже больше, чем стоило бы.
Правильного ООП много не бывает.

G>Это хорошо или плохо? или просто написано?
А как у нас топик называется?

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

G>>Особенности нивелируются фреймворками.
G>>Это неправда, посмотри data access фреймворки. Там ООП даже больше, чем стоило бы.
G>>Неактуально, есть typescript\script#\gwt\coffescript\dart.
IB>То, что в десктопном клиенте
IB>можно достичь средствами строго типизированного ООП ЯП и GUI-ядром ОС (то есть уже встроенное, родное),
IB>в Web
IB>можно достичь только через всякие сторонние фреймворки, часть из которых сырая или не поддерживается.
Конкретнее?

G>>Там ООП даже больше, чем стоило бы.
IB>Правильного ООП много не бывает.
Что считать "правильным" ?

G>Конкретнее?
Конкретней ты сам уже написал.

G>>>Там ООП даже больше, чем стоило бы.
IB>>Правильного ООП много не бывает.
G>Что считать "правильным" ?

Не считаю возможным ответить на данный вопрос кратко. Почитай соответствующую литературу.

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

G>>>>Там ООП даже больше, чем стоило бы.
IB>>>Правильного ООП много не бывает.
G>>Что считать "правильным" ?
IB>

IB>Не считаю возможным ответить на данный вопрос кратко. Почитай соответствующую литературу.
Эта фраза потрясающе соотносится с твоей подписью.

На этом видимо можно заканчивать, адекватных аргументов больше не будет.

G>Эта фраза потрясающе соотносится с твоей подписью.
Ребенку то на кошках и собаках я объясню, чтобы у него было представление.
Но ребенок не программист и правильно программировать средствами ООП от этого не научится.
Ты хотел своим вопросом меня привести к тому, что правильного ООП не существует.
Доказывать обратное я тебе здесь не собираюсь.

BB>Используйте Веб-приложения, если:
BB> Требуется обеспечить простую модель развертывания в Веб.
BB> Приложение должно быть доступным через Интернет.

Немного не актуально: есть ClickOnce и xbap

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

BB>>Используйте Веб-приложения, если:
BB>> Требуется обеспечить простую модель развертывания в Веб.
BB>> Приложение должно быть доступным через Интернет.

IB>Немного не актуально: есть ClickOnce и xbap

Да нет, актуально, просто четкой границы нет и критериев больше, а это были основные.
xpab и ClickOnce там тоже рассматривается: http://apparchguide.ms/

KV>Это примерно то же самое, что сказать: "каждый метод — баг с определенным процентом критичных проблем", аргументируя необходимость минимизировать число методов в коде

Правильно, чем меньше методов, тем проще архитектура, тем лучше, проще поддерживать, быстрее работает.
Программист должен бороться за простоту, а не за сложность.
Код должен настолько простым чтобы выполнять возложенные на него задачи, не проще и не сложнее.
Если допустить, что код выполняет возложенные задачи, то есть проще не получится,
то остается минимизация количества кода, то есть методов.

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

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

А>>Впринципе о любых, которые нельзя выносить наружу.

KV>Речь о standalone client-side приложениях или все же о полноценных веб, с серверной частью и HTTP-запросами?

Да изначально я думал только о клиент-серверных приложениях, где сервер находится не на одном компьютере с клиентом, но впринципе мнения по оффлайн тоже интересны

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

IB>то остается минимизация количества кода, то есть методов.

Минимизация количества методов еще не говорит о минимизации количества кода. Выше речь шла именно об этом.

... << RSDN@Home 1.2.0 alpha 5 rev. 72>>

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

PD>Я может быть, тебя не понял, или ты меня не понял. На мой взгляд Google Docs — примитив по сравнению с MS Office. А Google Docs, пожалуй , одно из самых продвинутых в этом плане приложений. Они действительно сумели в окне броузера сделать что-то такое, что по крайней мере сравнимо с Windows 3.x или даже в чем-то с Windows 95.

.
Рекомендую ещё глянуть Office Web Apps. Google Docs аскетичен, как всё гугловое.

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

PD>Outlook не аргумент, почта — примитив по сравнению с редактированием. В сущности, в почтовом десктопном клиенте уже лет 15 по большому счету ничего не меняется, нечего там менять.
А что там такого ракетного в "редактировании"?
Грубо говоря, Outlook — это Word внутри редактора письма + ещё в 9 раз больше функций (просмотр списка сообщений, календарь, майлтипы, статусы, и прочее).

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

S>А что там такого ракетного в "редактировании"?

Да в общем-то, ничего. Но различия все же есть

.

Твою просьбу посмотреть в сторону Office Web Apps выполняю. Вот сравнение его с Word. Учти при этом, что у меня стоит Office 2010 Starter, так что здесь не все.

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

PD>Да в общем-то, ничего. Но различия все же есть

.
Ну, то есть уже понятно, что различия не из-за веба как такового, а просто потому, что не до всего дошли руки?
В 2013 различий ещё меньше. Например, плагины для нового офиса пишутся единым способом, который делает их доступными и на десктопе, и в вебе.

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

PD>>Да в общем-то, ничего. Но различия все же есть

.
S>Ну, то есть уже понятно, что различия не из-за веба как такового, а просто потому, что не до всего дошли руки?

Во-первых, не уверен, что все можно реализовать.
Кстати, если уж говорить о Web — надо, чтобы все реализовалось средствами web. А пока что то и дело подключается вполне нативный модуль. Для печати, например. Как насчет печати без использования нативного драйвера ? Web — так web, ну и печатайте джаваскриптом прямо на мой HP

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

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

А для всего остального — изволь ставить вполне нативное приложение.

А это значит, что в действительности имеет место смесь web и нативного кода, и еще вопрос, какого больше.

Во-вторых, вопрос был о текущем состоянии. Будет иначе — посмотрим.

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

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

Веб технологии хорошо подходят для потребления контента. Например, всеми нами любимый RSDN@Home, в котором сейчас пишется это сообщение, использует браузер для отображения текста сообщения. Потому что, чтобы сделать шоб было красиво гораздо проще на html.

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

Тут в качестве десктоп примера приводят Аутлук. У меня есть другой пример. Давайте представим себе во что выльется веб-версия таких вещей как Visual Studio и Resharper. Уверен, что на JS это неподъёмное решение.

... << RSDN@Home 1.2.0 alpha 5 rev. 69>>

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

PD>Во-первых, не уверен, что все можно реализовать.
PD>Кстати, если уж говорить о Web — надо, чтобы все реализовалось средствами web. А пока что то и дело подключается вполне нативный модуль. Для печати, например. Как насчет печати без использования нативного драйвера ?
Вопрос мне непонятен. Я всё время печатаю из Web — хотя бы те же посадочные талоны на самолёт. Никакими "нативными модулями" там и не пахнет.

PD>Web — так web, ну и печатайте джаваскриптом прямо на мой HP

Ну да. А в чём проблема? Вы хотите, чтобы я прямо железкой управлял? Так уже даже в нативе никто не делает лет двадцать как. Готовишь метафайл — а его печатает инфраструктура. Я понятно намекаю?

PD>Но вот печатать на сервере я никак не могу

А зачем печатать на сервере? Не, ну если хочется — то можно, см. например сайты печати фотографий. Тысячи их.

PD>Ну и обработка всяких разных типов файлов. Что там броузер умеет показывать (не говорю редактировать) самостоятельно, а ?

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

PD>Во-вторых, вопрос был о текущем состоянии. Будет иначе — посмотрим.
Ну так и ответ про текущее состояние. Технологически осталось не очень много ограничений.

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

IT>Тут в качестве десктоп примера приводят Аутлук. У меня есть другой пример. Давайте представим себе во что выльется веб-версия таких вещей как Visual Studio и Resharper. Уверен, что на JS это неподъёмное решение.
https://c9.io/site/features/

Пока оно в зайчаточном состоянии, но на будущее я бы не зарекался.

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

BB>>Используйте Веб-приложения, если:
BB>> Требуется обеспечить простую модель развертывания в Веб.
BB>> Приложение должно быть доступным через Интернет.
IB>Немного не актуально: есть ClickOnce и xbap
За любой из них — расстрел на месте надо бы уже давать.

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

C>Пока оно в зайчаточном состоянии, но на будущее я бы не зарекался.

Напомнило ME и времена DOS. Думаю, речь идёт о довольно далёком будущем.

... << RSDN@Home 1.2.0 alpha 5 rev. 69>>

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

C>>Пока оно в зайчаточном состоянии, но на будущее я бы не зарекался.
IT>Напомнило ME и времена DOS. Думаю, речь идёт о довольно далёком будущем.
Мы тут недавно всей конторой зарубались в Quake. Который работает в браузере — на JavaScript (с помощью emscripten).

Так что, будущее может быть и совсем рядом. А ещё pNaCl есть, который на ХромойОС вполне себе неплохо работает.

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

C>Мы тут недавно всей конторой зарубались в Quake. Который работает в браузере — на JavaScript (с помощью emscripten).

Поздравляю. Мы всей конторой зарубались в Квейк ещё 20 лет назад. У тебя есть шанс через 20 лет зарубиться всей конторой в Crysis 3 или Metro: Last Light в браузере. Очень перспективно.

C>Так что, будущее может быть и совсем рядом. А ещё pNaCl есть, который на ХромойОС вполне себе неплохо работает.

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

... << RSDN@Home 1.2.0 alpha 5 rev. 69>>

C>За любой из них — расстрел на месте надо бы уже давать.

Интересно, с чего такой радикализм?

S>Вопрос мне непонятен. Я всё время печатаю из Web — хотя бы те же посадочные талоны на самолёт. Никакими "нативными модулями" там и не пахнет.

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

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

C>>За любой из них — расстрел на месте надо бы уже давать.
IB>Интересно, с чего такой радикализм?
Может не так категорично, но смысл тот же — Friends don’t let friends use ClickOnce.

IT>С другой стороны, всё, что выходит за рамки потребления контента и требует наличия интеррактивных возможностей или нетривиальной логики приводит к резкому увеличению сложности решения.

А если мне требуются интерактивные возможности и кроссплатформенность? А еще я воспользуюсь этими интерактивными возможностями один раз в жизни и не хочу себе ничего ставить на компьютер?
Например, интернет магазин по продаже кухонь предлагает своим клиентам прямо на сайте нарисовать кухню.
Все элементы фурнитуры и мебели из ассортимента данного магазина.
После рисования клиенту рассчитывается смета.
Причем мне не хочется ставить никакое ПО и плагины на мой компьютер, скорей всего воспользуюсь услугами этого магазина один раз в жизни.
Или например сайт предназначенный для обучения, например физике ил английскому, здесь важна интерактивность и кроссплатформенность.
Тут тоже не хочется ставить никакое ПО и плагины на компьютер ученика, скорей всего он пройдет курс обучения на этом сайте и больше к этому сайту не обратится.
И вообще я предполагаю, что в будущем потребление контента будет все более интерактивным, тенденция прослеживается.
Сейчас определяющим критерием области применения Веб является, является
1) необходимость платформонезависимости
К сожалению сейчас, единственной технологией ориентированной на платформонезависимость является Web. В будущем возможно что-то измениться. Появится какой-нибудь стандарт на GUI ядра ОС. Еще этот финансовый вопрос, неизвестно что дороже сделать несколько толстых клиентов под разные ОС, или сделать один под Web.
2) готов ли пользователь что-то ставить себе на компьютер
К сожалению сейчас чтобы поставить толстого клиента на компьютер нужно время и скачку и собственно установку. В будущем возможно что-то измениться в этом направлении. Появятся межплатформенные протоколы инсталяции приложений. Сейчас пользователь за день может посетить 20 интерактивных сайтов. Если для всех устанавливать ПО на компьютер будет нехорошо.
3) безопасность
Чем больше ПО я себе устанавливаю на компьютер, тем больше вероятность заражения.
Сейчас ситуация такова, что Веб ориентирован на выполнение в ограниченном контексте безопасности, десктоп в менее ограниченном. В будущем возможно что-то изменится. Появятся межплатформенные стандарты безопасности.

Из этого можно сделать вывод что область применения Web это одноразовые платформонезависимые приложения.
А вот корпоративные приложения лучше делать десктопными. В компаниях есть IT политика по применению конкретной ОС: платформонезависимость не нужна. Корпоративные приложения не одноразовые. Ими как правило пользуются каждый день одни и те же люди. Корпоративному приложению можно доверять и выполнять его в расширенном контексте безопасности.

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

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

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-интерфейс.
А главное он многооконный, позволяет заметку открыть в отдельном окне.

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

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

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

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

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

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

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

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

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

... << RSDN@Home 1.2.0 alpha 5 rev. 69>>

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

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

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

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

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

... << RSDN@Home 1.2.0 alpha 5 rev. 69>>

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

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

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

... << RSDN@Home 1.2.0 alpha 5 rev. 69>>

Здравствуйте, 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.

... << RSDN@Home 1.2.0 alpha 5 rev. 69>>

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

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

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

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

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

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

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

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

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

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

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

... << RSDN@Home 1.2.0 alpha 5 rev. 69>>

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. Так что откладывать твой "другой разговор" некуда.

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

S>Кстати, в gmail встроен вьювер PDF-ов, который работает без Adobe. Так что откладывать твой "другой разговор" некуда.
Ну или если совсем некуда деваться — https://github.com/mozilla/pdf.js

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

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

В HTML непосредственно когда, конечно, нет. Но есть встроенный туда js, он и есть код. Или код ActiveX, или код для flash-player. Вот это и есть код web-приложения (на клиентской стороне).

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

Увы, это ликбез необходим. Аргументов у тебя не нашлось. Если я плохо понимаю, как из web-а печатают — OK, расскажи. Вот в web-приложении (страница, открытая в броузере) код js или чего-то еще мне там пункт меню Print нарисовал) я этот пункт меню выбрал и ... что дальше ? Расскажи, хотя бы в применении к Windows, этого вполне достаточно.

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

S>Это всё очень хорошо, но с точки зрения практики, это означает, что все рассуждения про "недоступность печати для веб приложений" — малоинтересная ерунда.

Не передергивай. Где я говорил про недоступность ? Не было такого! Я говорил, что реализует ее нативный код.

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

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

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

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

Код JS или ActiveX или flash. В общем, код, пришедший с сервера. Код, который загружается в исполняющую среду.

S>Кстати, в gmail встроен вьювер PDF-ов, который работает без Adobe. Так что откладывать твой "другой разговор" некуда.

На этот раз я не понял. То есть я могу не устанавливать Adobe и смотреть на своей машине pdf ? И при чем тут gmail ?

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

PD>В HTML непосредственно когда, конечно, нет. Но есть встроенный туда js, он и есть код. Или код ActiveX, или код для flash-player. Вот это и есть код web-приложения (на клиентской стороне).
Ок, хорошо.

PD>Увы, это ликбез необходим. Аргументов у тебя не нашлось. Если я плохо понимаю, как из web-а печатают — OK, расскажи. Вот в web-приложении (страница, открытая в броузере) код js или чего-то еще мне там пункт меню Print нарисовал) я этот пункт меню выбрал и ... что дальше ? Расскажи, хотя бы в применении к Windows, этого вполне достаточно.
Дальше у тебя на экране оказался диалог печати, предоставленный браузером. Там ты проводишь платформенно-специфичную настройку параметров печати, и предоставленный веб-приложением контент уезжает на принтер. Пересекая, при этом, несколько уровней абстракции.
Вариантов этого процесса очень много, далеко за пределами форумного поста. Главное — что с точки зрения разработчика веб-приложения, всё это могут с тем же успехом делать офисные гномы. Его работа закончилась на подготовке контента для печати.

PD>Не передергивай. Где я говорил про недоступность ? Не было такого! Я говорил, что реализует ее нативный код.
Цитирую:

Кстати, если уж говорить о Web — надо, чтобы все реализовалось средствами web

Ну и далее про нативный драйвер. Я, наверное, не так понял — но откуда взялось вот это требование "чтобы всё реализовывалось средствами web"?

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

PD>На этот раз я не понял. То есть я могу не устанавливать Adobe и смотреть на своей машине pdf ? И при чем тут gmail ?
Именно, что можешь смотреть на своей машине pdf безо всякого Adobe. А Gmail — это такое малоизвестное веб-приложение, оборудованное этой возможностью. Добро пожаловать в реальный мир.

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

S>Ок, хорошо.

PD>>Увы, это ликбез необходим. Аргументов у тебя не нашлось. Если я плохо понимаю, как из web-а печатают — OK, расскажи. Вот в web-приложении (страница, открытая в броузере) код js или чего-то еще мне там пункт меню Print нарисовал) я этот пункт меню выбрал и ... что дальше ? Расскажи, хотя бы в применении к Windows, этого вполне достаточно.
S>Дальше у тебя на экране оказался диалог печати, предоставленный браузером. Там ты проводишь платформенно-специфичную настройку параметров печати, и предоставленный веб-приложением контент уезжает на принтер. Пересекая, при этом, несколько уровней абстракции.

Вот именно, что пересекая.

Диалог выведен с помощью DialogBox или ее аналогов. Вывел его браузер. Настройку печати браузер не может делать, не его это уровень. Диалоги настройки выводит ПО принтера. Потом все же StartDoc , TextOut и т.д., потом EndDoc, вызываемые браузером. А браузер — не часть web-приложения. Так что печатает не web-приложение, а его исполняющая среда.

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

Да могут в принципе. кто же спорит. Добавьте в JS вызов этого диалога и пусть интерпретатор JS его вызывает. Криминального тут ничего нет. вызывает же его код на C# через свои классы. Вот и пусть js выхывает, а интерпретатор js компилирует (интерпретирует) этот вызов и показывает диалог.

Это никому не нужно, скажешь ты. Правильно, не нужно. Это вообще бессмысленно, так как проще переадресовать это среде исполнения. Не спорю. Но я просто фикисровал факт — web-приложение большей частью требует нативного кода исполняющей системы.

PD>>Не передергивай. Где я говорил про недоступность ? Не было такого! Я говорил, что реализует ее нативный код.
S>Цитирую:
S>

S>Кстати, если уж говорить о Web — надо, чтобы все реализовалось средствами web

И где тут про недоступность ?

S>Ну и далее про нативный драйвер. Я, наверное, не так понял — но откуда взялось вот это требование "чтобы всё реализовывалось средствами web"?

Тут просто твое непонимание того, что мы обсуждаем. Я изначально просто две вещи сказал : что web-приложения примитивны пока что, и что они опираются на нативный код, то есть в действительности большая часть их возможностей обеспечивается отнюдь не web-кодом. Требования такого вовсе нет, естественно, просто есть констатация факта — в собственно web-коде делается на клиенте очень немного, большая часть — в нативных приложениях/модулях.

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

Ну это уже просто попытка заняться забалтыванием вопроса. Уходом в сторону. Мы не с точки зрения программиста, пищущего этот код, рассуждали, а с точки зрения того, как этот код устроен.

S>Ну так вот разработчики Windows-приложений уже двадцать с лишним лет не пишут свои драйвера принтеров.

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

У них есть некоторая абстракция, которой они пользуются. Так и разработчики веб-приложений не пишут свои драйвера принтеров, а пользуются готовой абстракцией.

PD>>На этот раз я не понял. То есть я могу не устанавливать Adobe и смотреть на своей машине pdf ? И при чем тут gmail ?
S>Именно, что можешь смотреть на своей машине pdf безо всякого Adobe. А Gmail — это такое малоизвестное веб-приложение, оборудованное этой возможностью. Добро пожаловать в реальный мир.

Лучше ссылку дай, тогда и последую. Для меня Gmail — это только почта, остальное проходит как google.com. У меня на виртуалке как раз никакого pdf-вьюера нет. Давай ссылку, попробую и пойду в реальный мир в малоизвестные приложения.

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

PD>Диалог выведен с помощью DialogBox или ее аналогов. Вывел его браузер. Настройку печати браузер не может делать, не его это уровень. Диалоги настройки выводит ПО принтера. Потом все же StartDoc , TextOut и т.д., потом EndDoc, вызываемые браузером. А браузер — не часть web-приложения. Так что печатает не web-приложение, а его исполняющая среда.
Ну и что. Точно так же настройки печати и всё остальное в нативном приложении делает не нативное приложение, а платформенный код. Вообще печатает светодиод, управляемый кодом на платформе, которую ни ты ни я в жизни не видели. Это как-то делает нативные приложения неполноценными?

PD>Тут просто твое непонимание того, что мы обсуждаем. Я изначально просто две вещи сказал : что web-приложения примитивны пока что, и что они опираются на нативный код, то есть в действительности большая часть их возможностей обеспечивается отнюдь не web-кодом.
Да, действительно, я совершенно не понимаю, что мы тут обсуждаем.
Дело в том, что вообще все возможности веб-приложений обеспечиваются отнюдь не веб-кодом. Вот я написал простейшее приложение: <html><body>Hello world!</body></html>. Всё, что оно делает — выводит текст. И вот этот вывод текста (о, ужас!) выполняется самым что ни на есть нативным кодом. Потому что никакого доступа к дисплею у веб-приложения нет.
А код работает крайне сложный — он строит DOM модель документа, подгружает default style sheet, парсит правила в этом style sheet, и вводит в действие движок такой запутанности, что у освоивших его реализацию шерсть на яйцах приобретает характерный серебристый оттенок. Это ещё до того, как собственно вступит в действие платформенная часть — та, где начинается рендер текста со всеми модными ClearType и прочим всяким.

А веб код — он что? Даже JavaScript — это так, буковки. Он сам вообще ничего сделать не может — его интерпретирует интерпретатор. В отличие от Java и C#, в JS не так уж много кода, который можно реально скомпилировать — из-за слабой типизации.

PD>Требования такого вовсе нет, естественно, просто есть констатация факта — в собственно web-коде делается на клиенте очень немного, большая часть — в нативных приложениях/модулях.
Как мы уже выяснили, в "веб-коде" не делается вообще ничего. Всё делается исключительно в нативных приложениях и модулях, одним из которых является JS-engine.
Поэтому ценность такого наблюдения близка к нулю.

PD>Опять ты демонстрируешь непонимание. Не то, что не пишут, а не могут писать. Драйвер в нулевом кольце исполняется, а разработчикам приложений под Windows (NT линии) туда хода нет.

Начиная с Win2k драйвер принтера может работать в третьем кольце. Начиная с Vista — только в третьем. Это так, про "хода нет".
Не говоря уже о том, что нет никаких проблем поставлять и кернелмодный драйвер вместе с приложением. Было бы желание. Поэтому только отсутствие желания останавливает разработчиков.

PD>Лучше ссылку дай, тогда и последую. Для меня Gmail — это только почта, остальное проходит как google.com. У меня на виртуалке как раз никакого pdf-вьюера нет. Давай ссылку, попробую и пойду в реальный мир в малоизвестные приложения.

Ну, собственно рендер выполняется через Google Docs.
Вот я закачал документ: https://docs.google.com/file/d/0B8E17Ogt_3nfSTZBY0lVcVVpVDQ/edit?usp=sharing

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

S>Вот я написал простейшее приложение: <html><body>Hello world!</body></html>. Всё, что оно делает — выводит текст.

Тут возникает вопрос, что такое "приложение"?
Вот я запустил нотепад и открыл текстовый документ. Текстовый документ в этом случае — это приложение, которое выводит на экран текст — я правильно понимаю ваш ход мысли?

Здравствуйте, Yoriсk, Вы писали:
Y>Вот я запустил нотепад и открыл текстовый документ. Текстовый документ в этом случае — это приложение, которое выводит на экран текст — я правильно понимаю ваш ход мысли?
Не совсем.
Вот у меня есть приложение, вполне себе нативное. Оно ставит вместе с собой файлик EULA.txt. И ссылка на него (шорткат) прописывается инсталлером в Start меню рядом с приложением.
Когда я кликаю на эту ссылку, документ открывается в дефолтном приложении (которым совершенно случайно является Notepad, если у пользователя не стоит какого-нибудь более модного UltraEdit или ещё чего).

С точки зрения приложения, мы реализуем сценарий — "показать пользователю соглашение". А для реализации сценария выбран вот такой вариант, в котором Notepad — это всего лишь низкоуровневый инструмент по выводу текста на экран.

Ход мысли понятен?

Понятно, что ровно те же EULA.txt и Notepad.exe играют совершенно другие роли, когда я (разработчик) подготавливаю файл во время разработки приложения?

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

S>Здравствуйте, Yoriсk, Вы писали:
Y>>Вот я запустил нотепад и открыл текстовый документ. Текстовый документ в этом случае — это приложение, которое выводит на экран текст — я правильно понимаю ваш ход мысли?
S>Ход мысли понятен?

Нет, не понятен. Давайте попроще пока, без сторонних приложений, eula, сценариев и т.д.

Какая разница между показом вашеим приложением(страница "Hello world" в броузере) и моим (текст "Hello world" в ноутпаде)? Можно ли Hello_world.txt считать приложением наравне с Hello_world.htm и если нет — то почему?

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

Y>Какая разница между показом вашеим приложением(страница "Hello world" в броузере) и моим (текст "Hello world" в ноутпаде)? Можно ли Hello_world.txt считать приложением наравне с Hello_world.htm и если нет — то почему?
В общем случае — можно.

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

Ладно, давай заканчивать. Результат наших дискуссий — как всегда

За тобой последнее слово. Я продолжать не буду.

S>Ну и что. Точно так же настройки печати и всё остальное в нативном приложении делает не нативное приложение, а платформенный код. Вообще печатает светодиод, управляемый кодом на платформе, которую ни ты ни я в жизни не видели. Это как-то делает нативные приложения неполноценными?

S>Дело в том, что вообще все возможности веб-приложений обеспечиваются отнюдь не веб-кодом. Вот я написал простейшее приложение: <html><body>Hello world!</body></html>. Всё, что оно делает — выводит текст. И вот этот вывод текста (о, ужас!) выполняется самым что ни на есть нативным кодом. Потому что никакого доступа к дисплею у веб-приложения нет.
S>А код работает крайне сложный — он строит DOM модель документа, подгружает default style sheet, парсит правила в этом style sheet, и вводит в действие движок такой запутанности, что у освоивших его реализацию шерсть на яйцах приобретает характерный серебристый оттенок. Это ещё до того, как собственно вступит в действие платформенная часть — та, где начинается рендер текста со всеми модными ClearType и прочим всяким.

S>А веб код — он что? Даже JavaScript — это так, буковки. Он сам вообще ничего сделать не может — его интерпретирует интерпретатор. В отличие от Java и C#, в JS не так уж много кода, который можно реально скомпилировать — из-за слабой типизации.

S>Как мы уже выяснили, в "веб-коде" не делается вообще ничего. Всё делается исключительно в нативных приложениях и модулях, одним из которых является JS-engine.

В чем-то ты, конечно, прав. В сущности вопрос можно и иначе поставить. Что входит в состав десктопного приложения ? EXE — безусловно. DLL той же фирмы — безусловно. DLL 3-ей фирмы, поставляемые вместе с EXE или shared ? По-видимому, да. А kernel32.dll ? Она часть Windows, но ее работа в приложении по существу ничем не отличается от работы какой-то собственной DLL. Если и она входит, то почему на ntdll.dll ? А если ntdll.dll, то почему не ntoskrnl.exe ? Так можно и всю Windows в приложение записать.

Ну а если пойти по этому пути, то надо отказаться от твоей точки зрения, что броузер есть исполняющая система и признать его частью web-приложения. Потом его плугины, потом прочие программы и так до ntoskrnl.exe. В итоге действительно теряется предмет дискуссии.

А тем не менее, говоря о десктопных приложениях, никому в голову не придет причислить к ним ядро ОС вместе с драйверами (за исключением разве что его собственных драйверов, если они есть), и даже kernel32.dll. Может, не слишком точно, и уж во всяком случае не формально, но мы всегда отдаем себе отчет, что именно относится к данному приложению, а что — к его поддержке в ОС или иными средствами.

Вот и в web-приложении есть код, выполняющийся на сервере (мы о нем не говорили, но тут сомнений нет), и код JS и т.п, выполняющийся на клиенте. Вот этот JS и т.п. и лежит по одну сторону, а броузер и все, что ниже или параллельно ему — по другую. И в этом смысле броузер и остальные есть среда, а не сама программа.

И основную работу тут именно среда делает. Те же картинки рендерит. В отличие от десктопной программы, которая их сама рендерит (конечно, не без помощи gdi32.dll и т.д.)

PD>>Лучше ссылку дай, тогда и последую. Для меня Gmail — это только почта, остальное проходит как google.com. У меня на виртуалке как раз никакого pdf-вьюера нет. Давай ссылку, попробую и пойду в реальный мир в малоизвестные приложения.

S>Ну, собственно рендер выполняется через Google Docs.
S>Вот я закачал документ: https://docs.google.com/file/d/0B8E17Ogt_3nfSTZBY0lVcVVpVDQ/edit?usp=sharing

Согласен. Не знал.

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

PD>В чем-то ты, конечно, прав. В сущности вопрос можно и иначе поставить. Что входит в состав десктопного приложения ? EXE — безусловно. DLL той же фирмы — безусловно. DLL 3-ей фирмы, поставляемые вместе с EXE или shared ? По-видимому, да. А kernel32.dll ? Она часть Windows, но ее работа в приложении по существу ничем не отличается от работы какой-то собственной DLL. Если и она входит, то почему на ntdll.dll ? А если ntdll.dll, то почему не ntoskrnl.exe ? Так можно и всю Windows в приложение записать.

Вопросы ты ставишь совершенно верные. Однако делаешь совершенно неожиданные выводы.

PD>Ну а если пойти по этому пути, то надо отказаться от твоей точки зрения, что броузер есть исполняющая система и признать его частью web-приложения. Потом его плугины, потом прочие программы и так до ntoskrnl.exe. В итоге действительно теряется предмет дискуссии.
Именно.

PD>А тем не менее, говоря о десктопных приложениях, никому в голову не придет причислить к ним ядро ОС вместе с драйверами (за исключением разве что его собственных драйверов, если они есть), и даже kernel32.dll. Может, не слишком точно, и уж во всяком случае не формально, но мы всегда отдаем себе отчет, что именно относится к данному приложению, а что — к его поддержке в ОС или иными средствами.
Совершенно верно.

PD>Вот и в web-приложении есть код, выполняющийся на сервере (мы о нем не говорили, но тут сомнений нет), и код JS и т.п, выполняющийся на клиенте. Вот этот JS и т.п. и лежит по одну сторону, а броузер и все, что ниже или параллельно ему — по другую. И в этом смысле броузер и остальные есть среда, а не сама программа.
Да, это разделение совершенно корректно.

PD>И основную работу тут именно среда делает. Те же картинки рендерит. В отличие от десктопной программы, которая их сама рендерит (конечно, не без помощи gdi32.dll и т.д.)
А вот тут начинается какая-то чушь. Ситуации для нативного приложения и для веб-приложения совершенно одинаковы. Десктопная программа тоже "сама" практически ничего не делает. Доступа к железу у неё нет. Десктопная программа полагается на исполняющую среду, и большинство нативных программистов имеют весьма смутное представление о том, что "на самом деле" происходит в
этой среде ниже уровня прикладного винапи.
И это как раз хорошо — потому что позволяет разработчикам платформы развивать её более-менее независимо от приложений. И потому, что позволяет разработчикам приложений сосредоточиться на полезностях, а не на борьбе с элементарщиной.

Термином "основная работа" ты сам себя гипнотизируешь. В том смысле, что, например, для банковского приложения основная работа — это перевод денег. А вовсе не рендер картинок. Поэтому совершенно неважно, как именно рендерятся картинки в приложении.
А если захочется доказать себе, что уж нативное-то приложение имеет больше возможностей по рендеру картинок, то придётся почитать про тег canvas, который представляет собой аналог DeviceContext из GDI, и разница вообще сотрётся до неразличимой.

PD>>>Лучше ссылку дай, тогда и последую. Для меня Gmail — это только почта, остальное проходит как google.com. У меня на виртуалке как раз никакого pdf-вьюера нет. Давай ссылку, попробую и пойду в реальный мир в малоизвестные приложения.

S>>Ну, собственно рендер выполняется через Google Docs.
S>>Вот я закачал документ: https://docs.google.com/file/d/0B8E17Ogt_3nfSTZBY0lVcVVpVDQ/edit?usp=sharing
PD>Согласен. Не знал.
Это только пример. Первые варианты у них были чудовищные — скажем, результаты анализов InVitro невозможно было прочитать. Постепенно допилили движок, сейчас всё работает вполне себе приемлемо. Принципиальных причин не сделать ещё и редактор нету.

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

Обещал не отвечать, но пришло в голову одно замечание.

S>>>Вот я закачал документ: https://docs.google.com/file/d/0B8E17Ogt_3nfSTZBY0lVcVVpVDQ/edit?usp=sharing
PD>>Согласен. Не знал.
S>Это только пример. Первые варианты у них были чудовищные — скажем, результаты анализов InVitro невозможно было прочитать. Постепенно допилили движок, сейчас всё работает вполне себе приемлемо. Принципиальных причин не сделать ещё и редактор нету.

Тебе не кажется. что этот пример несколько играет против твоих рассуждений ?

Сравним 2 случая

1. pdf рендерится Goggle Docs
2. pdf рендерится с помощью Adobe плугина.

Есть разница ? ИМХО все же есть. В одном случае это делает что-то там (я не знаю что, то ли js, то ли еще что-то) в самой странице, присланной с сервера, а в другом — сторонний нативный код. Я не говорю о том, как рендерится, тут и, верно, можно до ntoskrnl.exe дойти. Я лишь сам факт отмечаю — рендерит либо код внутренний, либо внешний.

Если следовать твоей логике, то и в случае внешнего рендеринга мы имеем web-приложение. Тогда зачем переделывать под внутренний рендеринг ? Это же ничего не добавит в идее (именно в идее, о технической стороне я не говорю).

Но если внешний рендеринг pdf находится в рамках концепции web-приложения, то почему бы не объявить web-приложением некий pdf, находящийся на совершенно статическом сайте без единой строчки кода ? В одном случае сайт делает мне pdf, я его загружаю с помощью Adobe и рендерю. В другой случае сайт присылает мне pdf, я его запускаю с помощью Adobe и рендерю. В чем отличие ? Только в том, что во втором случае pdf не генерируется по моей просьбе с моими данными, а статичен ? Так и в первом случае мне могли бы присылать некий статичный pdf иногда.

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

PD>Обещал не отвечать, но пришло в голову одно замечание.
Да ладно. Будем считать, что это было необязывающее обещание

PD>Тебе не кажется. что этот пример несколько играет против твоих рассуждений ?
Неа.

PD>1. pdf рендерится Goggle Docs
PD>2. pdf рендерится с помощью Adobe плугина.

PD>Есть разница ? ИМХО все же есть.
Да. Основная разница — требования к клиентской платформе.

PD>В одном случае это делает что-то там (я не знаю что, то ли js, то ли еще что-то) в самой странице, присланной с сервера, а в другом — сторонний нативный код. Я не говорю о том, как рендерится, тут и, верно, можно до ntoskrnl.exe дойти. Я лишь сам факт отмечаю — рендерит либо код внутренний, либо внешний.
Понятия "внутреннего" и "внешнего" кода могут быт разными. С точки зрения пользователя, "внутренний" код — это тот, который приложение "принесло с собой" невидимым для пользователя образом. А "внешний" — это тот код, который приложение рассчитывает обнаружить. Если уточнять дальше, то начинаются неприятные нюансы — например, ActiveX будет "внутренним", если удалось его поставить без унижения пользователя. А если страничка рендерит заглушку типа "для продолжения вам нужно скачать убермегакомпонент с сайта злоумышленники.ком и проигнорировать десяток ворнингов" — то код внешний.
Хотя с точки зрения процедуры исполнения оба кода устроены совершенно одинаково.

Есть и обратная штука — тот же самый Flash играется в IE при помощи ActiveX, и типичное веб-приложение рассчитывает на его наличие. Тем не менее, его penetration ratio близок к 99%, поэтому для большинства пользователей flash-приложение никакого "внешнего" кода не требует.

PD>Если следовать твоей логике, то и в случае внешнего рендеринга мы имеем web-приложение. Тогда зачем переделывать под внутренний рендеринг ? Это же ничего не добавит в идее (именно в идее, о технической стороне я не говорю).
Совершенно правильный вопрос. Большинство профессиональных веб-приложений, которые хотят выводить документы на печать, генерируют PDF. Просто потому, что в чистом HTML (и других кросс-платформенных форматах, напрямую поддерживаемых браузером) управление видом документа на печати слишком ненадёжно, а PDF реализован для чуть менее чем всех платформ.
Гугл решал совсем другую задачу — у него казуальные пользователи, и ему важнее была всеобщая доступность (включая те 2% людей, у кого нет Adobe), а не точное соблюдение полиграфических ожиданий автора документа.

PD>Но если внешний рендеринг pdf находится в рамках концепции web-приложения, то почему бы не объявить web-приложением некий pdf, находящийся на совершенно статическом сайте без единой строчки кода ? В одном случае сайт делает мне pdf, я его загружаю с помощью Adobe и рендерю. В другой случае сайт присылает мне pdf, я его запускаю с помощью Adobe и рендерю. В чем отличие ?
Совершенно верно — нет никаких отличий. На стороне клиента отличить статический PDF от динамического решительно невозможно.
И таких приложений в реальной практике — тысячи. Вот, например, Билайн присылает мне счета в PDF, и даёт их же скачать через их "личный кабинет". Я понятия не имею, хранят ли они эти файлы в какой-то файловой системе, или создают On demand всякий раз, как я их запрашиваю (то есть практически никогда). У меня и способа-то нет никакого отличить эти ситуации друг от друга.

Граница между "веб сайтом" (коллекцией документов, ссылающихся друг на друга) и "веб приложением" весьма условна. Это и есть основная причина успеха веба.

В "десктопе" простые случаи выглядят симметрично. Результаты

start helloworld.txt

start helloworld.exe

будут удивительно похожи (если я зарегистрирую в качестве дефолтной команды для .txt запуск cmd.exe с командой type %1).
Незнакомый с программированием человек может считать это двумя неразличимыми версиями одной и той же программы, хотя всё в программисте будет бунтовать против такой трактовки.
Различия начнутся в тот момент, когда мы захотим интерактивности. helloworld.exe легко доработать так, чтобы в ответ на

start helloworld.exe Pavel

она выводила

Hello Pavel!

А вот helloworld.txt такому трюку не подвержен.
А в вебе всё гораздо размытее. Можно идти-идти по сайту, и постепенно оказаться по уши в приложении. А можно иметь приложение, 70% контента в котором отдаётся с веб-сайта.

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

PD>>Обещал не отвечать, но пришло в голову одно замечание.
S>Да ладно. Будем считать, что это было необязывающее обещание

Ну раз так, отвечу еще раз. На один пункт.

PD>>Но если внешний рендеринг pdf находится в рамках концепции web-приложения, то почему бы не объявить web-приложением некий pdf, находящийся на совершенно статическом сайте без единой строчки кода ? В одном случае сайт делает мне pdf, я его загружаю с помощью Adobe и рендерю. В другой случае сайт присылает мне pdf, я его запускаю с помощью Adobe и рендерю. В чем отличие ?
S>Совершенно верно — нет никаких отличий. На стороне клиента отличить статический PDF от динамического решительно невозможно.

То есть статический сайт, со страницей, где есть линк на их же pdf, ты готов признать web-приложением ?

Тогда пойдем дальше. Пусть есть некий сайт, где разрешен browse directory, и в этом directory лежит некое количество файлов. Вот этот, например

http://www.sai.msu.su/apache/hadoop/common/

Это тоже web-приложение ? Конечно, может там на этом сайте еще что-то есть, но допустим, что больше ничего там нет.

А если это web-приложение, то почему не назвать web-приложением ftp-сервер ? Только из-за того, что там другой протокол ? Да, конечно, этого достаточно, чтобы сказать, что ftp-сервер не принадлежит к http/www. Но делает-то он совершенно то же.

Что-то тут не то...

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

PD>То есть статический сайт, со страницей, где есть линк на их же pdf, ты готов признать web-приложением ?

PD>Тогда пойдем дальше. Пусть есть некий сайт, где разрешен browse directory, и в этом directory лежит некое количество файлов. Вот этот, например
PD>http://www.sai.msu.su/apache/hadoop/common/
PD>Это тоже web-приложение ? Конечно, может там на этом сайте еще что-то есть, но допустим, что больше ничего там нет.

PD>А если это web-приложение, то почему не назвать web-приложением ftp-сервер ? Только из-за того, что там другой протокол ? Да, конечно, этого достаточно, чтобы сказать, что ftp-сервер не принадлежит к http/www. Но делает-то он совершенно то же.

PD>Что-то тут не то...
Веб приложение от веб сайта отличается не технически, а функционально. Сайт — это коллекция документов, обычно квазистатических. Приложение подразумевает некоторую интерактивность.
Поэтому говорят, например, "сайт на sharepoint", хотя с обратной стороны вообще никаких файлов нет (в терминах вроде "browse directory", которые ты используешь).
Или наоборот — например, phpBB, не к ночи будь помянут, на заре своей карьеры работал на основе набора статических файлов (которые он тупо перегенерировал всякий раз, как добавлялся новый пост в форум).

Протокол ftp в веб-приложениях тоже используется, хотя и очень редко. Например, в сервисах батч-процессинга бухгалтерских данных схема "загрузил на ftp, получил письмо со ссылкой на результат — скачал" встречается до сих пор. В основном по историческим причинам — ftp это единственный из популярных протоколов, в который встроена "докачка вверх". А в HTTP из коробки её нету, поэтому загрузка в сервер большого файла может основательно испортить настроение. Не то, чтобы эту докачку невозможно было реализовать, просто это а) требует усилий и б) не будет поддерживаться существующими клиентами. Сейчас каналы гораздо лучше, чем 10 лет назад, поэтому, к примеру, можно заливать фотки для печати по 5 мегабайт размером. А в 2000 году шансы на то, что пятимегабайтный файл влезет в сервер с первой попытки, были призрачными. Потому и ftp, с восстановлением после сбоя.

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

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

IT>А это скриптовый язык, т.е. язык, предназначение которого — лёгкие подпорки и мелкие затычки.

Не согласен, раньше на скриптовых языках писали ОС, компилятор и всю прикладуху, и отлично работало (я имею в виду лисп машины).

IT>Возьмите ради разнообразия какой-нибудь самый обычный энтерпрайз проект на годик и на самых обычных человек на 10 индусов и перепишите его на JS.

Без проблем — сразу уйдет вся суета с маппингом из базы в ОРМ, потом в ДТО, потом в СОАП.

Энтузиаст жабаскрипта

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

PD>>То есть статический сайт, со страницей, где есть линк на их же pdf, ты готов признать web-приложением ?

PD>>Что-то тут не то...
S>Веб приложение от веб сайта отличается не технически, а функционально. Сайт — это коллекция документов, обычно квазистатических. Приложение подразумевает некоторую интерактивность.

Хм...

Рассмотрим три гипотетических сайта

1. Шлет мне форму с TextBox и Submit, по нажатию Submit, возвращает мне pdf с содержимым этого TextBox
2. Шлет мне форму с Submit по нажатию Submit, возвращает мне pdf с чем-то своим, статический pdf
3. Шлет мне страницу, в которой линк на pdf из пункта 2.

Первый по твоему определению — web-приложение. Второй тоже (есть же интерактивность!). А третий, выходит, нет. А в чем разница между вторым и третьим с точки зрения пользователя ? В нажатии кнопки, а не линка ? Так линк можно и в виде кнопки сделать...

S>Протокол ftp в веб-приложениях тоже используется

<skipped>

Не понял ты меня, не для того я его привел, и зачем-то прочитал лекцию по ftp

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

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

А>Пока вижу 2

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

Веб приложения — это не только интернет. Сейчас много интранет приложений переносятся в броузер и такие приложения писать и поддерживать куда как проще чем ГУИ приложение с серверной частью.

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

A>Веб приложения — это не только интернет. Сейчас много интранет приложений переносятся в броузер и такие приложения писать и поддерживать куда как проще чем ГУИ приложение с серверной частью.

Писать и поддерживать их как раз сложнее. Выигрыш там только в развёртывании на клиенте.

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

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

A>>Веб приложения — это не только интернет. Сейчас много интранет приложений переносятся в броузер и такие приложения писать и поддерживать куда как проще чем ГУИ приложение с серверной частью.

Y>Писать и поддерживать их как раз сложнее.

У меня обратное мнение (опыт имею и с тем и с тем, если что)

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

Y> А в ФБ всё это пираццтво зарпещено, чего там качать?

Да хотябы кэшировать ленту новостей.
Щупал я мобильный клиент для фейсбука — на планшетке оно более юзабельно, чем вебсайт, но сделано как-то слишком примитивно. Изрядно раздражает, когда нажимаешь кнопку "назад", а оно грузит страницу заново.
У вконтактика с этим вроде получше, но полгода назад там был перегиб в другую сторону — обновления видео/музыки с сервера до клиента доходили очень нескоро. На сайте видюшка уже добавилась, а мобильный клиент её не показывает. Даже если сам мобильный клиент её и добавил. Лечилось только перезапуском приложения.

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

А>Тач устройства пока не используются в промышленном виде

Давно уже используются. И планшеты, и тачскрины и мелкие сенсорные панельки. И совместно с клавиатурами и отдельно от них.

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

А>можно подменить значение на клиенте и вмешаться в логику работы, а как это влияет на безопасность думаю объяснять не надо

Вёб-приложения тут ни при чём.
Нативное приложение точно также не должно полагаться на достоверность значений, хранимых на клиентской стороне, если речь идёт о безопасности.

А>Ага, а если я ввел неправильно фамилию в 1м контроле , потом на середине это замечено и нужно исправить ? Табом лезть 20 нажатий ? Иногда при таком подходе случайно можно пролететь мимо и опять круг в 40 контролов давать. Нет уж спасибо.
А>Если обращал внимание на всех нормальных формах у лейблов есть подчеркнутая буква, которая является как раз быстрым хоткеем для данного поля.

Вы где-нибудь видели нормальную форму с сорока хоткеями?
Ну мне чисто из любопытства. Букв в английском алфавите 26. Даже если удастся успешно задать имена всем полям, чтобы привязать их к 26 буквам английского алфавита, что будете делать после 26-го хоткея?

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

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

И где они все эти ОС, компиляторы и вся прикладуха?

IT>>Возьмите ради разнообразия какой-нибудь самый обычный энтерпрайз проект на годик и на самых обычных человек на 10 индусов и перепишите его на JS.
А>Без проблем — сразу уйдет вся суета с маппингом из базы в ОРМ, потом в ДТО, потом в СОАП.

А какая там суета? Никакой суеты. Суета была когда сайты писали на серверном JS без ОРМ, ДТО и пр. Вот это была жесть.

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

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

Там из реальных проблем аж одна: работа через прокси. Остальное — бред какой-то, чувак не понимает что это и зачем.

F>Пока легче приклеить то или иное самообновление. Ну а вебу тут равных вообще нет.

Вообще нет равных. "Как не работает? Должно всё быть. Нажмите F5. Нет? Тогда Сtrl+F5. Опять нет? Попробуйте кеш почистить... Что, уже чистили? Ладно, есть такая фича: анонимный режим, ща расскажу как..."

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

IB>>>Да недостатки есть, но они преодолимы и не носят фундаментальный характер. В следующих версиях ClickOnce возможно пофиксят.
F>> 5! Всё можно преодолеть.
Y>Там из реальных проблем аж одна: работа через прокси. Остальное — бред какой-то, чувак не понимает что это и зачем.
Его бред — вполне устоявшееся мнение в массах, а именно не большое желание использовать эту "технологию".

А одной проблемы с прокси — достаточно что бы раз с этим столкнуться и забыть об этой "технологии" навсегда.

F>>Пока легче приклеить то или иное самообновление. Ну а вебу тут равных вообще нет.
Y>Вообще нет равных. "Как не работает? Должно всё быть. Нажмите F5. Нет? Тогда Сtrl+F5. Опять нет? Попробуйте кеш почистить... Что, уже чистили? Ладно, есть такая фича: анонимный режим, ща расскажу как..."
Может настоящая проблема в сервере? Мне вот кеш чистить не нужно что бы пользоваться ни этим сайтом, ни другими более навороченными приложениями.

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

F> Его бред — вполне устоявшееся мнение в массах, а именно не большое желание использовать эту "технологию".

1. Отучаемся говорить за всех.
2. Это реальный бред. Он похоже ниасилил простую как три копейки(это, кстати, её основное достоинство, всё остальное — недостатки) технологию и не врубился зачем это надо.

"packaging format is just a folder of many files ... multi-file affair makes failures due to interrupted connections etc much more problematic, vs just resuming the download of a single package.". Вот ведб проблема, на диалапе без докачки, бедняга, сидит, связь у него рвётся, бида-бида...

Как бы вы отнеслись к бложеку анонима "Почему нельзя пользоваться веб-приложениями":

Packaging format is just a folder of many files.
You can’t separate the update metadata from the update itself.
Random weird sh*t in a small percentage of cases.
You can’t choose where to install the product.
No offline installer.
You can’t install once for everyone on a PC or distribute a bulk install as admin.

??

Кстати всё это(кроме, вероятно, первого) можно применить и к модели распространения через Стим.

Интересно, а "массы" не смущает, что эта бодяга — практически калька с javaWS или как там его?
Вобщем, с такими противниками ClickOnce ему и друзей не надо.

F>Может настоящая проблема в сервере?

Может. А может в браузере. А может в прокси. А может еще где-то. А может везде сразу. Но проблема есть и часто.

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

Y>1. Отучаемся говорить за всех.
Y>2. Это реальный бред. Он похоже ниасилил простую как три копейки(это, кстати, её основное достоинство, всё остальное — недостатки) технологию и не врубился зачем это надо.
Это ты говоришь за всех не разобравшись.

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

То есть для чего-либо сложнее клиента википедии или какого-нибудь выставочного путеводителя нормальными ребятами используется строго native. Нет, какие-нибудь подвальные шарашки могут иметь и другое мнение, но в лучших домах, если на выходе требуется высококачественный продукт, с повышенными расходами на нативную разработку давно уже смирились.

Пример в студию: http://www.siliconrus.com/2013/05/kula-maxim-publishing

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

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

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

интересно, как процесс рисования будет выглядеть

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

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

IB>3) безопасность
IB>Чем больше ПО я себе устанавливаю на компьютер, тем больше вероятность заражения.

Странно, чем больше я вижу на странице флэша, видео и музыки — тем больше вероятность заражения. С софтом больше чем за год ни одна пакость не пришла, зато самые обычные и ПРИВЫЧНЫЕ КАРТИНКИ НА ФОРУМАХ иногда внезапно оказывались вредоносными (гуглим "уязвимость JPEG").

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

А>1) javascript — открытый код, то есть где он не будет удовлетворять требованиям безопасности придется отказываться от ajax в данных формах, в результате замедление отклика интерфейса.
Есть и для javascript обфускаторы это раз. GUI приложения точно так же поддаются реврс-инжинирингу, как и клиентский веб-код.

А>2) hotkeys — веб приложение не может полноценно обрабатывать hotkey часть из них забирает броузер.
Это одно из ключевых отличий. И дело не только в hotkeys. С табуляций, например, тоже есть косяки. То есть в браузете очень сложно организовать достаточное юзабилити для оператора ввода данных. Eсли в ERP оператор только и делает что вбивает данные в формы, то если его работу перенести в браузер, будет не просто удовлетворить все его пожелания. Особенно если это миграция с некоторой старой системы со своими хот-кеями и юзабилити.

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

IB>- Веб интерфейс не может на 100% использовать вычислительную мощь современных компьютеров, устанавливаемых у конечных пользователей.
Зависит от задач. Те же браузерные игры скоро смогут выжать всё нужное из железа. Других задач требующих полной отдачи ресурсов клиента очень мало.
Тут же есть и обратная сторона медали, можно зато использовать на 100% ресурсы облака, доставляя низкопроизводительным клиентам сервис того же уровня что и высокопроизводительным.

IB>- Нужно подстраиваться под разные браузеры. У каждого браузера есть особенности работы с HTML и javaScript.
По-хорошему кросс-платформеный GUI должен поддерживать user experience каждой отдельной взятой оболочки ОС.
Вот тут в докладе рассказывается почему это тоже не просто.
http://vimeo.com/65233400

IB>- В RIA бизнес логика просачивается на уровень представления (на клиента в JavaScript).
Ну, в десктопе ведь то же самое. Нет особой разницы.

IB>- Ввиду того что веб сервисы это наборы методов (процедур), программирование часто становится процедурным. Полноценно использовать ООП в Web тяжело.
Ну, не знаю. Это ведь всего-лишь один единственный слой-фасад между клиентом и сервером. Всё остальное можно и в ООП, на сколько JS позволяет.

IB>- JavaScript не типизированный, тяжело отлаживать, рефакторить
Вот это действительно тяжолое наследие JavaScript, обойти которое не так просто. А если использовать современные мега-фреймверки, то дебаг может стать ещё сложнее. С другой стороны, если реализовать код в более функциональном стили, то и отладки, зачастую, может понадобиться меньше.

	От:	Аноним
	Дата:	19.05.13 13:53
	Оценка:

	От:	Аноним
	Дата:	19.05.13 14:02
	Оценка:	+3 -2

	От:	Lloyd
	Дата:	19.05.13 14:15
	Оценка:	1 (1) +3 -2

	От:	Iʹm OK
	Дата:	19.05.13 14:56
	Оценка:	1 (1) +7 -2

	От:	wallaby
	Дата:	19.05.13 15:51
	Оценка:	+1

	От:	Pavel Dvorkin
	Дата:	19.05.13 15:55
	Оценка:	1 (1)

От:	gandjustas	http://blog.gandjustas.ru/
Дата:	19.05.13 16:47
Оценка:	+1 -1

	От:	Stanislav V. Zudin
	Дата:	19.05.13 17:48
	Оценка:

От:	kochetkov.vladimir	https://kochetkov.github.io
Дата:	19.05.13 18:07
Оценка:

От:	Ikemefula	http://blogs.rsdn.org/ikemefula
Дата:	19.05.13 20:47
Оценка:	+2

	От:	BluntBlind
	Дата:	20.05.13 01:07
	Оценка:	77 (4)

	От:	igor-booch
	Дата:	20.05.13 12:08
	Оценка:	1 (1) +1

	От:	Константин
	Дата:	20.05.13 14:29
	Оценка:	+1

От:	Sinclair	https://github.com/evilguest/
Дата:	22.05.13 10:26
Оценка:

От:	IT	linq2db.com
Дата:	23.05.13 15:29
Оценка:	8 (3) +1

	От:	Yoriсk
	Дата:	31.05.13 13:31
	Оценка:	1 (1) +2

От:	Artem Korneev	https://www.linkedin.com/in/artemkorneev/
Дата:	31.05.13 23:03
Оценка:

От:	Философ	http://vk.com/id10256428
Дата:	23.09.13 11:31
Оценка:

От:	koandrew	http://thingselectronic.blogspot.ca/
Дата:	26.09.13 18:28
Оценка:

	От:	Аноним931
	Дата:	02.10.13 07:24
	Оценка: