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

К настоящему времени

• Программное обеспечение для настольных ПК работает быстрее (вам не нужно выходить в сеть для чтения / записи / обработки данных)

• Доступ к оборудованию проще и предпочтительнее, чем выполнять локально, потому что безопасность

• Не нужно подключение к Интернету может быть хорошо (например, ноутбук, которому необходимо подключение к Интернету для прослушивания mp3 или просмотра ваших собственных фотографий, не будет быстрее и недостаточно конфиденциальным)

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

Я устал от постоянного разделения "веб-приложение против настольного приложения".

Не существует такого понятия, как "веб-приложение" - HTML и JavaScript выполняются на вашем рабочем столе браузером; они просто доставляются по запросу, когда вы переходите по URL. Но даже это может быть неправдой, если они случайно окажутся в кэше.

То, что люди обычно считают "веб-приложением", - это приложение, размещенное в браузере, которое манипулирует ресурсами, размещенными в облаке; и довольно часто эта манипуляция включает код, выполняемый на сервере.

Но ничто не мешает "настольному приложению" быть просто богатым фронтэндом для пользователя, манипулирующего облачными ресурсами. Просто посмотрите на все существующие клиенты Twitter на WPF, Air и Objective-C.

Также ничто не мешает вам создать браузерное приложение на базе HTML5/JS, которое манипулирует только локальными ресурсами. Просто посмотрите на3 канонический пример "веб-приложения" - Gmail и его способность работать автономно, без доступа к сети.

Не говоря уже о том, что со всеми достижениями в браузерах и RIA платформах (как Flash, так и Silverlight) - удаление хрома браузера, разделение вкладок в процессах, поддержка внебраузерного исполнения, то, что сегодня считается "веб-приложением", быстро переходит в то, что лучше назвать "легким настольным приложением" или "портативным настольным приложением". :-)

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

В этом контексте ваш вопрос становится спорным. Выбор презентационного слоя полностью ортогонален выбору расположения ресурсов, которыми манипулирует ваше приложение.

Не существует прямой связи между настольными приложениями и веб-разработкой/облаком. Независимо от того, является ли слой пользовательского интерфейса веб-сайтом или приложением, облако все равно может поддерживать ваше приложение. Я думаю, что тонкие клиенты находятся на подъеме, и такие технологии RIA, как silverlight, являются лишь одним из их посредников.

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

Одна из причин - производительность. Веб-приложения всегда будут работать в "песочнице" и не будут иметь полного доступа к родным ресурсам. Таким образом, они не могут быть такими же быстрыми, как настольные приложения. Это очень важно для таких приложений, как IDE, CAD-системы и игры.

Это зависит от среды. Можно ожидать, что корпоративный пользователь будет в сети все/почти все время, в то время как кто-то дома может не быть постоянно подключен. Кроме того, у вас есть различные проблемы безопасности, контроля и обновления, с которыми вы сталкиваетесь с каждым приложением. В бизнес-среде веб-приложения отлично подходят, потому что вы можете обновить приложение один раз, и все сразу же увидят изменения. Сейчас я занимаюсь именно такой работой. Но большинство приложений - это веб-приложения, управляемые данными. Для чего-то графического или процессороемкого вам лучше работать на настольном уровне (как несколько других людей, упомянутых выше).

Приложения, которые я использую прямо сейчас:

• excel
• wirehark
• winzip
• файловый менеджер
• несколько консолей ssh

Я не вижу, какой пользы от любого из них (возможно, без Excel - но если вы когда-либо пытались создать большую сводную таблицу с html + ajax, вы просто раздражали своих пользователей) в качестве веб-приложения. Люди создают множество приложений с похожими потребностями. Также было бы глупо принудительно устанавливать сетевое / веб-соединение для приложений, которым оно не требуется.

Silverlight - это нечто среднее, я не уверен, что считаю его типичным «веб-приложением», скорее веб-приложением с некоторой «песочницей» - хотя различия становятся нечеткими.

Хорошо спроектированное настольное приложение обычно значительно удобнее, чем хорошо спроектированное веб-приложение. Это связано с тем, что веб-приложение ограничено тем, что разрешено браузером, ограничено тем фактом, что в браузере есть элементы управления (кнопки панели инструментов, меню и т. Д.), Которые не связаны с приложением, ограничены задержкой, присущей сети, и т. д.

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

Под «веб-приложением» я подразумеваю приложение, пользовательский интерфейс которого основан на браузере и который взаимодействует с моделью данных, которая в основном распространяется по сети. Под «настольным приложением» я подразумеваю приложение, использующее собственные элементы управления, взаимодействующее с локальной моделью данных или приложение в локальной сети.