Y a-t-il des limites à une application Web HTML5 idéaliste

Supposons que les deux hypothèses suivantes soient vraies.

• Toute votre base d'utilisateurs dispose d'un accès haut débit partout
• Il existe un navigateur imaginaire X qui implémente l'intégralité du projet de spécification des groupes HTML5 et WHATWG, de manière cohérente et tous les utilisateurs utilisent le navigateur X.

Quelles sont les limites intrinsèques d'une application Web HTML5 publique commerciale pour laquelle nous avons besoin d'applications bureautiques publiques commerciales?

Je suis intéressé par les limitations des applications Web sans plug-in qui ne dépendent pas des ponts Flash / Java / SilverLight / etc pour des fonctionnalités supplémentaires ni des plug-ins de navigateur pour des fonctionnalités supplémentaires.

Limitations possibles qui ne s'appliquent pas:

• Bases de données? Nous avons WebSQL et indexedDB.
• Fichier IO? Nous avons l'API HTML5 File qui fait la lecture et l'écriture.
• La vitesse? Avec la récente course au moteur JavaScript, le navigateur n'est plus lent. Le C ++ natif n'est que 3 fois plus rapide que le moteur V8 de Chrome.
• Outils de développement? Le Web a mûri et il existe toute une gamme d'outils trop nombreux pour être répertoriés.
• Source fermée? Oui, tout le code est open source. Il s'agit d'une épée à double tranchant et il existe de nombreux avis sur l'utilisation du code source fermé ou open source. Je pense personnellement que les avantages du code open source l'emportent sur les inconvénients.
• JavaScript / HTML5? Les arguments comme «Je pense personnellement que HTML5 et EcmaScript sont d'horribles plateformes de développement» ne comptent pas.

Limitations connues:

• Le code critique temps réel / sécurité (top secret) n'appartient pas au Web et ne le peut pas. Il doit être écrit dans un langage de bas niveau, hautement contrôlable comme C ou C ++.
• Tout outil qui doit interagir avec un matériel tiers étranger connecté à votre ordinateur aura du mal à parler à votre application Web.

Il existe également toute une série de programmes qui n'appartiennent pas au Web. Systèmes d'exploitation, pilotes, logiciel serveur, API de bas niveau. J'en suis conscient mais je ne les classe pas comme applications "publiques commerciales", ce sont les types de logiciels qui peuvent être préinstallés sur les ordinateurs.

Soit dit en passant, je sais que les deux hypothèses sont horriblement irréalistes, mais nous pourrions les atteindre dans 5/10/20/30 ans. Je m'intéresse au type d'applications et aux fonctionnalités des applications qui les rendent totalement incompatibles avec le web.

Motivation:

• Applications Google
• Microsoft Office365
• Liste des applications Web
• Adobe Aviary

Le point:

Compte tenu de l'ensemble des problèmes où une application de bureau est une solution valide.

• Pourquoi une application Web n'est-elle pas une solution valide?
• Comment savoir si je peux ou non utiliser une application Web comme solution.

J'ai essayé de supprimer les principales difficultés des applications Web (connexion Internet et support du navigateur) en affirmant qu'elles n'existent pas.

En outre, les applications hors ligne HTML5 et Modernizr sont en passe de résoudre ces deux problèmes.

Quelles sont les autres difficultés avec le développement d'applications Web?

Du haut de ma tête ...

• accéder au matériel propriétaire qui exporte ses E / S par d'autres moyens qu'un fichier. Que ce soit de l'équipement scientifique, des machines industrielles ou un enregistreur de CD ordinaire et une tablette numériseur avec support inclinable.
• uniquement HTTP et une petite famille d'autres protocoles. Vous ne pouvez pas créer de sockets comme vous le souhaitez, en transférant les données binaires que vous souhaitez. Cela limite considérablement la connectivité avec d'autres systèmes et services.
• Aucun développeur sensé ne créera de jeu gourmand en graphiques en Javascript. La large bande n'est pas comparable aux débits DVD / HDD souvent nécessaires. La prise en charge de la 3D dans Canvas est largement inférieure à ce que vous obtenez avec les moteurs de jeu. Aucun moyen de prendre en charge le joystick, plusieurs pressions de touches simultanées, la nature ouverte facilite la triche. Mais surtout, la baisse des performances n'est pas acceptable.
• Sandboxing lourd. Vous n'obtiendrez pas de choses qui s'intègrent profondément dans le système d'exploitation. Captures d'écran, antivirus, lecteurs virtuels, tâches d'arrière-plan dans la barre d'état système, tâches administratives, etc.
• ne peut pas être critique à la mission. Dépendre du haut débit à tout moment pour exécuter leurs logiciels de base n'est pas la manière préférée de la plupart des entreprises.

Essentiellement, tout ce qui peut être intégré dans le modèle serveur / client peut faire une bonne application Web et, inversement, on peut dire que l'inverse est également vrai. La tendance à migrer vers le Web a disparu si rapidement, car en voyant comment la plupart des programmes peuvent être modélisés dans Model / Controller / View, les programmes peuvent séparer le modèle et le contrôleur de sa vue.

Bien sûr, pour des raisons d'efficacité, certains contrôleurs sont également placés côté client afin d'éviter de surcharger le serveur avec des requêtes et des données erronées.

Bien que mon point soit: quels programmes ne correspondent pas à l'architecture logicielle modèle / contrôleur / vue, car ce sont probablement les mêmes programmes qui n'ont jamais été convertis en applications Web. Les bons exemples qui me viennent à l'esprit sont les systèmes d'exploitation, les planificateurs de tâches, l'invite de commande, la protection antivirus, la protection contre les logiciels espions. Chacun d'entre eux n'est probablement pas implémenté sur un site Web car il ne correspond pas au modèle. Et ce n'est pas un hasard si chacun de ces programmes dépend fortement de votre système. La plupart nécessitent un accès direct au matériel tandis que d'autres nécessitent simplement une sécurité plus élevée pour pouvoir être exécutés et ne peuvent pas être approuvés par les sites Web Internet.

Bien sûr, Google réadapte complètement ce concept avec son nouveau système d'exploitation. Soi-disant, contrairement à Windows, ce n'est pas simplement un système qui a grandi pour utiliser Internet, mais plutôt un système qui en dépend fortement. Bientôt, vous verrez peut-être tous ces programmes disponibles en ligne, permettant l'accès à votre matériel et à vos logiciels, étant donné une authentification de certificat stricte pour empêcher n'importe quel site de le faire, mais plutôt des sites de confiance. Je suis impatient de voir ce qu'ils proposent, car je pense que dans 20 ans, les ordinateurs ne seront plus fabriqués avec des logiciels installables. Tous les services seront plutôt disponibles en ligne.

• Tout outil qui doit interagir avec un matériel tiers étranger connecté à votre ordinateur aura du mal à parler à votre application Web.

Le logiciel sur lequel je travaille a maintenant un aspect de bureau ainsi qu'un aspect basé sur le Web précisément parce qu'il doit collecter des données à partir de périphériques tiers. Le besoin de développement de pilotes et d'un programme de bureau client pour combler l'écart entre le périphérique et le Web.

Cela n'exclut cependant pas les applications Web, car ces types d'applications de bureau peuvent être minces avec une logique résidant principalement sur le serveur.

D'un autre côté, on peut dire avec l'aspect du cloud computing et de la virtualisation de masse qu'aucune application ne doit nécessairement être limitée par les limitations et les failles de sécurité de la technologie Web. L'exécution d'applications de bureau à partir d'un environnement virtualisé sur un terminal stupide (un peu comme Citrix) est devenue beaucoup plus facile à réaliser et pourrait être la prochaine «mode» de développement.

L'essentiel est qu'il y a plus de choix maintenant que jamais auparavant et beaucoup plus de têtes parlantes jouant la technologie de demain comme la "meilleure" façon.

Supposons que les deux hypothèses suivantes soient vraies.

• Toute votre base d'utilisateurs dispose d'un accès haut débit partout
• Il existe un navigateur imaginaire X qui implémente l'intégralité du projet de spécification des groupes HTML5 et WHATWG, de manière cohérente et tous les utilisateurs utilisent le navigateur X.

Quelles sont les limites intrinsèques d'une application Web HTML5 publique commerciale pour laquelle nous avons besoin d'applications bureautiques publiques commerciales?

Je suis intéressé par les limitations des applications Web sans plug-in qui ne dépendent pas des ponts Flash / Java / SilverLight / etc pour des fonctionnalités supplémentaires ni des plug-ins de navigateur pour des fonctionnalités supplémentaires.

Ok, alors voici le hic: ce navigateur sera de par sa nature même non sécurisé. Vous nous demandez donc de faire un compromis entre les deux. Cependant, en dépassant cela et en supposant que nous ayons du javascript (auquel vous avez fait allusion dans votre message), la réponse est qu'aucune application ne peut pas être écrite en utilisant simplement HTML5 / Javascript. Cependant, nous supposons un navigateur qui ne gêne pas.

La chose a un magasin de base de données local, peut faire des appels à n'importe quelle autre plate-forme en utilisant des requêtes HTTP (qu'un RESTafarian vous dira suffisantes) et peut dessiner (via Canvas) à peu près tout ce que vous voulez. Il existe déjà des jeux 3D écrits en utilisant des standards ouverts (OpenGL ish) et il y a des API pour faire à peu près tout ce que vous voulez.

Le seul véritable inconvénient est la vitesse. Il faudra du temps pour effectuer ces appels d'API HTTP vers d'autres systèmes (bases de données). Il faudra du temps pour traiter les demandes FILE (COM1 :) (pour lire sur un périphérique série sous Windows par exemple) donc ce sont les problèmes que j'attendrais. Bien sûr, je suppose également que les pilotes sont écrits pour être accessibles comme des fichiers, ce qui, je suis sûr, n'est plus vrai. Mais ils pourraient exposer un tel mécanisme;)

Pour l'utilisateur, peu de choses seront différentes du tout.