Существуют ли ограничения идеалистического веб-приложения на HTML5?

Давайте предположим, что следующие два предположения верны.

• Вся ваша база пользователей имеет широкополосный доступ везде
• Существует воображаемый браузер 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 лет. Меня интересуют типы приложений и функции приложений, которые делают их полностью несовместимыми с Интернетом.

Мотивация:

• Google-приложения
• Microsoft Office365
• Список веб-приложений
• Adobe Aviary

Точка:

Учитывая множество проблем, где настольное приложение является допустимым решением.

• Почему веб-приложение не является допустимым решением?
• Как определить, могу ли я использовать веб-приложение в качестве решения?

Я пытался устранить основные трудности с веб-приложениями (подключение к Интернету и поддержка браузера), утверждая, что они не существуют.

Кроме того, автономные приложения HTML5 и Modernizr находятся на пути к решению обеих этих проблем.

Каковы другие трудности с разработкой веб-приложений?

С моей головы ...

• получить доступ к проприетарному оборудованию, которое экспортирует свои операции ввода-вывода другими способами, кроме файла. Будь то научное оборудование, промышленное оборудование или обычный CD-рекордер и планшет с цифровым планшетом с поддержкой наклона.
• только HTTP и небольшое семейство других протоколов. Вы не можете создавать сокеты по своему желанию, передавая любые двоичные данные, какие пожелаете. Это значительно ограничивает связь с другими системами и сервисами.
• Ни один здравомыслящий разработчик не создаст графику интенсивной игры в Javascript. Широкополосный доступ почти не сопоставим с пропускной способностью DVD / HDD, которая часто требуется. Поддержка 3D в Canvas значительно уступает тому, что вы получаете с игровыми движками. Нет возможности поддерживать джойстик, несколько одновременных нажатий клавиш, открытый характер облегчает читерство. Но в первую очередь падение производительности недопустимо.
• Тяжелая песочница. Вы не получите вещи, которые глубоко интегрируются в ОС. Снимки экрана, антивирус, виртуальные диски, фоновые задачи в системном трее, административные задачи и т. Д.
• не может быть критически важным для миссии. Постоянное использование базового программного обеспечения в зависимости от широкополосной связи не является предпочтительным способом работы большинства компаний.

По сути, все, что может вписаться в модель сервер / клиент, может стать хорошим веб-приложением, и в действительности можно сказать, что обратное также верно. Тенденция к переходу в Интернет исчезла очень быстро, потому что, видя, как большинство программ можно смоделировать в Model / Controller / View, программы могут отделить модель и контроллер от ее представления.

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

Хотя моя точка зрения такова: какие программы не соответствуют архитектуре программного обеспечения модель / контроллер / представление, поскольку они, вероятно, представляют собой те же программы, которые никогда не преобразовывались в веб-приложения. Хорошие примеры, которые приходят на ум, это операционные системы, планировщики задач, командная строка, защита от вирусов, защита от шпионских программ. Каждый из них, вероятно, не реализован на веб-сайте, потому что он не соответствует модели. И не случайно, что каждая из этих программ сильно зависит от вашей системы. Большинству требуется прямой доступ к оборудованию, в то время как другим просто требуется более высокий уровень безопасности, чтобы их можно было запускать, и им нельзя доверять интернет-сайты.

Конечно, Google полностью переоснащает эту концепцию своей новой операционной системой. Предположительно, в отличие от Windows, это не просто система, которая стала использовать Интернет, а скорее система, сильно зависящая от него. Вскоре вы, возможно, увидите, что все эти программы будут доступны через Интернет, предоставляя доступ к вашему аппаратному и программному обеспечению при условии строгой проверки подлинности с помощью сертификата, чтобы предотвратить это мог только любой сайт, а скорее доверенные сайты. Мне не терпится увидеть, что они придумают, так как я думаю, что через 20 лет компьютеры больше не будут производиться с помощью устанавливаемого программного обеспечения. Скорее все услуги будут доступны онлайн.

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

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

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

С другой стороны, с точки зрения облачных вычислений и массовой виртуализации можно сказать, что ни одно приложение не должно быть обязательно ограничено ограничениями и дырами в безопасности веб-технологий. Запуск настольных приложений из виртуализированной среды на немом терминале (во многом похожем на Citrix) стал намного проще в достижении и может стать следующей «прихотью» разработки.

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

Давайте предположим, что следующие два предположения верны.

• Вся ваша база пользователей имеет широкополосный доступ везде
• Существует воображаемый браузер X, который последовательно реализует весь проект спецификации групп HTML5 и WHATWG, и все пользователи используют браузер X.

Каковы внутренние ограничения коммерческого общедоступного веб-приложения HTML5, для которого нам нужны коммерческие общедоступные настольные приложения?

Меня интересуют ограничения веб-приложений без плагинов, которые не используют мосты Flash / Java / SilverLight / etc для дополнительных функций и не используют плагины браузера для дополнительных функций.

Хорошо, тогда вот в чем проблема: этот браузер по самой своей природе будет небезопасным. Итак, вы просите нас найти компромисс между ними. Однако, если мы пройдем мимо этого и предположим, что у нас есть javascript (на который вы ссылались в своем посте), тогда ответим, что нет приложения, которое нельзя написать, используя только HTML5 / Javascript. Тем не менее, мы предполагаем, что браузер не мешает.

У этой вещи есть локальное хранилище БД, она может совершать звонки на любую другую платформу, используя HTTP-запросы (которых вам скажет RESTafarian, достаточно) и может рисовать (через Canvas) практически все, что вы захотите. Уже есть 3D-игры, написанные с использованием открытых стандартов (OpenGL ish), и есть API-интерфейсы, позволяющие делать практически все, что вы захотите.

Единственный реальный недостаток - скорость. Для выполнения этих HTTP API-вызовов в другие системы (базы данных) потребуется время. Для обработки запросов FILE (COM1 :) (например, для чтения через последовательное устройство в Windows) потребуется время, поэтому я ожидаю, что это проблемные области. Конечно, я также предполагаю, что драйверы написаны так, чтобы к ним обращались как к файлам, что, я уверен, больше не соответствует действительности. Но они могли бы разоблачить такой механизм;)

Для пользователя не так много будет по-другому.