Чи є обмеження ідеалістичного веб-додатку HTML5

Припустимо, що наступні два припущення є істинними.

• Уся ваша база користувачів всюди має широкосмуговий доступ
• Існує уявний браузер X, який реалізує всю проектну специфікацію груп HTML5 та WHATWG, послідовно і всі користувачі використовують браузер X.

Які внутрішні обмеження комерційного загальнодоступного веб-додатку HTML5, для чого нам потрібні комерційні публічні настільні додатки?

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

Можливі обмеження, які не застосовуються:

• Бази даних? У нас є WebSQL та indexedDB.
• Файл IO? У нас є API файлу HTML5, який робить і читання, і запис.
• Швидкість? З недавньою гонкою двигуна JavaScript браузер вже не повільний. Рідний C ++ лише в 3 рази швидший від хромового двигуна 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 / тощо для додаткових функцій, а також не покладаються на додатки браузера для додаткових функцій.

Гаразд, ось ось що: Цей браузер за своєю суттю буде незахищеним. Тож ви просите нас укласти угоду між двома. Однак, подолавши це, і припускаючи, що у нас є JavaScript (про який ви згадували у своєму дописі), то відповідь, що не існує програми, яка не може бути написана за допомогою HTML5 / Javascript. Однак ми припускаємо, що браузер не заважає.

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

Єдиний справжній недолік - швидкість. Знадобиться час для здійснення цих HTTP-дзвінків API до інших систем (баз даних). Пройде час, щоб обробити FILE (COM1 :) запити (наприклад, для читання серійного пристрою в Windows), тому я б очікував проблемних областей. Звичайно, я також припускаю, що драйвери записуються як файли, що я впевнений, що це вже не так. Але вони могли викрити такий механізм;)

Користувачеві багато чого буде зовсім не так.