Давайте предположим, что следующие два предположения верны.
- Вся ваша база пользователей имеет широкополосный доступ везде
- Существует воображаемый браузер X, который последовательно реализует весь проект спецификации групп HTML5 и WHATWG, и все пользователи используют браузер X.
Каковы внутренние ограничения коммерческого общедоступного веб-приложения HTML5, для которого нам нужны коммерческие общедоступные настольные приложения?
Меня интересуют ограничения веб-приложений без плагинов, которые не используют мосты Flash / Java / SilverLight / etc для дополнительных функций и не используют плагины браузера для дополнительных функций.
Возможные ограничения, которые не применяются:
- Базы данных? У нас есть WebSQL и indexedDB.
- Файл IO? У нас есть HTML5 File API, который выполняет чтение и запись.
- Скорость? С недавней гонкой движка JavaScript браузер больше не работает медленно. Родной C ++ работает только в 3 раза быстрее, чем Chrome V8.
- Инструменты разработки? Сеть повзрослела, и существует целый ряд доступных инструментов, которых слишком много, чтобы перечислять.
- Закрытый источник? Да, весь код с открытым исходным кодом. Это обоюдоострый меч, и существует множество мнений об использовании закрытого или открытого исходного кода. Я лично считаю, что преимущества открытого исходного кода перевешивают недостатки.
- JavaScript / HTML5? Аргументы типа «я лично считаю HTML5 и EcmaScript ужасными платформами разработки» не учитываются.
Известные ограничения:
- Критический код в режиме реального времени / безопасности (совершенно секретно) не принадлежит ни Интернету, ни ему. Он должен быть написан на низкоуровневом, хорошо контролируемом языке, таком как C или C ++.
- Любому инструменту, который должен взаимодействовать с иностранным оборудованием, подключенным к вашему компьютеру, будет трудно общаться с вашим веб-приложением.
Существует также целый набор программ, которые не принадлежат сети. Операционные системы, драйверы, серверное программное обеспечение, API низкого уровня. Я знаю об этом, но я не классифицирую их как «коммерческие публичные» приложения, это тип программного обеспечения, которое может быть предварительно установлено на компьютеры.
Кроме того, я знаю, что эти два предположения ужасно нереалистичны, но мы могли бы достичь их через 5/10/20/30 лет. Меня интересуют типы приложений и функции приложений, которые делают их полностью несовместимыми с Интернетом.
Мотивация:
Точка:
Учитывая множество проблем, где настольное приложение является допустимым решением.
- Почему веб-приложение не является допустимым решением?
- Как определить, могу ли я использовать веб-приложение в качестве решения?
Я пытался устранить основные трудности с веб-приложениями (подключение к Интернету и поддержка браузера), утверждая, что они не существуют.
Кроме того, автономные приложения HTML5 и Modernizr находятся на пути к решению обеих этих проблем.
Каковы другие трудности с разработкой веб-приложений?
Ответы:
С моей головы ...
источник
По сути, все, что может вписаться в модель сервер / клиент, может стать хорошим веб-приложением, и в действительности можно сказать, что обратное также верно. Тенденция к переходу в Интернет исчезла очень быстро, потому что, видя, как большинство программ можно смоделировать в Model / Controller / View, программы могут отделить модель и контроллер от ее представления.
Конечно, по соображениям эффективности, некоторые контроллеры размещаются также на стороне клиента, чтобы избежать перегрузки сервера ошибочными запросами и данными.
Хотя моя точка зрения такова: какие программы не соответствуют архитектуре программного обеспечения модель / контроллер / представление, поскольку они, вероятно, представляют собой те же программы, которые никогда не преобразовывались в веб-приложения. Хорошие примеры, которые приходят на ум, это операционные системы, планировщики задач, командная строка, защита от вирусов, защита от шпионских программ. Каждый из них, вероятно, не реализован на веб-сайте, потому что он не соответствует модели. И не случайно, что каждая из этих программ сильно зависит от вашей системы. Большинству требуется прямой доступ к оборудованию, в то время как другим просто требуется более высокий уровень безопасности, чтобы их можно было запускать, и им нельзя доверять интернет-сайты.
Конечно, Google полностью переоснащает эту концепцию своей новой операционной системой. Предположительно, в отличие от Windows, это не просто система, которая стала использовать Интернет, а скорее система, сильно зависящая от него. Вскоре вы, возможно, увидите, что все эти программы будут доступны через Интернет, предоставляя доступ к вашему аппаратному и программному обеспечению при условии строгой проверки подлинности с помощью сертификата, чтобы предотвратить это мог только любой сайт, а скорее доверенные сайты. Мне не терпится увидеть, что они придумают, так как я думаю, что через 20 лет компьютеры больше не будут производиться с помощью устанавливаемого программного обеспечения. Скорее все услуги будут доступны онлайн.
источник
Программное обеспечение, над которым я сейчас работаю, имеет как настольный, так и сетевой аспекты именно потому, что ему нужно собирать данные со сторонних периферийных устройств. Необходима разработка драйверов и клиентской настольной программы для преодоления разрыва между устройством и сетью.
Однако это не исключает веб-приложений, поскольку подобные настольные приложения могут быть тонкими, поскольку логика находится в основном на сервере.
С другой стороны, с точки зрения облачных вычислений и массовой виртуализации можно сказать, что ни одно приложение не должно быть обязательно ограничено ограничениями и дырами в безопасности веб-технологий. Запуск настольных приложений из виртуализированной среды на немом терминале (во многом похожем на Citrix) стал намного проще в достижении и может стать следующей «прихотью» разработки.
Суть в том, что сейчас есть больше вариантов, чем когда-либо прежде, и гораздо больше говорящих голов, которые используют технологию будущего как «лучший» способ.
источник
Хорошо, тогда вот в чем проблема: этот браузер по самой своей природе будет небезопасным. Итак, вы просите нас найти компромисс между ними. Однако, если мы пройдем мимо этого и предположим, что у нас есть javascript (на который вы ссылались в своем посте), тогда ответим, что нет приложения, которое нельзя написать, используя только HTML5 / Javascript. Тем не менее, мы предполагаем, что браузер не мешает.
У этой вещи есть локальное хранилище БД, она может совершать звонки на любую другую платформу, используя HTTP-запросы (которых вам скажет RESTafarian, достаточно) и может рисовать (через Canvas) практически все, что вы захотите. Уже есть 3D-игры, написанные с использованием открытых стандартов (OpenGL ish), и есть API-интерфейсы, позволяющие делать практически все, что вы захотите.
Единственный реальный недостаток - скорость. Для выполнения этих HTTP API-вызовов в другие системы (базы данных) потребуется время. Для обработки запросов FILE (COM1 :) (например, для чтения через последовательное устройство в Windows) потребуется время, поэтому я ожидаю, что это проблемные области. Конечно, я также предполагаю, что драйверы написаны так, чтобы к ним обращались как к файлам, что, я уверен, больше не соответствует действительности. Но они могли бы разоблачить такой механизм;)
Для пользователя не так много будет по-другому.
источник