Qu'est-ce qui empêche les applications HTML5 et JS de fonctionner aussi bien que les applications natives?

D'après ce que je comprends,

• HTML est un langage de balisage, tout comme le contenu de XAML, XIB et de tout ce qu'Android utilise et d'autres cadres de développement d'interface utilisateur natifs.
• JavaScript est un langage de programmation utilisé avec lui pour gérer les scripts côté client qui comprendra des choses comme la gestion des événements, les validations côté client et tout ce que font C #, Java, Objective-C ou C ++ dans divers cadres de ce type.
• Il existe des modèles MVC / MVVM disponibles dans des cadres de formulaire comme Sencha, Angular, etc.
• Nous avons localStorage sous forme de sqlite et de magasin de valeurs-clés comme les autres frameworks et vous avez des spécifications API pour presque tout ce qui manque.
• Chaque fois qu'un framework d'interface utilisateur natif doit rendre l'interface utilisateur, il doit analyser un balisage similaire et rendre l'interface utilisateur.

Répartition des questions

• Qu'est-ce qui empêche de faire de même en HTML et JS lui-même?
• Au lieu d'avoir un contrôle Web ou un navigateur comme couche intermédiaire, pourquoi HTML (avec CSS) et JS ne peuvent-ils pas être exécutés de la même manière?
• Même s'il existe une couche, le runtime .net et la JVM le sont également dans d'autres cas où C ++, C n'est pas utilisé.
• Prenons donc le cas d'Android, comme Dalvik, pourquoi Chromium ne peut-il pas être une autre option (avec dalvik et NDK) où HTML fait ce que le balisage Android fait et JavaScript est utilisé pour faire ce que Java fait?

La question est donc,

Même si les implémentations actuelles ne sont pas aussi bonnes, mais théoriquement est-il possible d'obtenir des applications basées sur HTML5 pour fonctionner comme d'autres applications natives spécialement sur mobile?

LinkedIn, l'affiche des applications HTML5, est devenu natif début 2013. Dans l' interview de VentureBeat, ils expliquent pourquoi.

Je pense que c'est la partie la plus pertinente pour votre question:

Prasad a déclaré que les problèmes de performances ne provoquaient pas de plantages ni ne ralentissaient l'application. Ce qu'il a dit montre que HTML5 pour le Web mobile a encore un bel avenir - mais seulement si les développeurs sont prêts à construire les outils pour le prendre en charge.

...

Il y a quelques éléments qui manquent cruellement. La première est la prise en charge des outils: disposer d'un débogueur qui fonctionne réellement, d'outils de performance qui vous indiquent où la mémoire s'épuise. Si vous regardez Android et iOS, il y a deux très grandes sociétés qui se concentrent sur la création d'outils pour donner beaucoup d'informations détaillées lorsque les choses tournent mal en production. Du côté du Web mobile, il est vraiment difficile de faire fonctionner ces outils de bureau pour les appareils mobiles. Le deuxième gros morceau avec lequel nous nous débattons est l'opérabilité, les informations de diagnostic d'exécution. Même maintenant, lorsque nous créons HTML5, nous le construisons comme une application côté client. Il s'agit plus d'une architecture client-serveur. … L'opérabilité de cela, nous donnant des informations lorsque nous sommes distribués à un grand nombre d'utilisateurs, il n'y a pas autant d'excellents outils pour le supporter aussi.

[Prasad a également noté que les outils de développement et d'exploitation pour résoudre rapidement les problèmes «n'existent pas».]

Parce que ces deux choses n'existent pas, les gens retombent chez les autochtones. Ce n'est pas que HTML5 n'est pas prêt; c'est que l'écosystème ne le supporte pas. … Il y a des outils, mais ils sont au début. Les gens ne font que comprendre les bases.

L'absence d'une bibliothèque standard Javascript est un horrible inhibiteur. Il existe d'excellents cadres comme jQuery, Dojo, YUI, pour n'en nommer que quelques-uns, mais tous sont uniquement axés sur la couche de présentation et XHR.

Voulez-vous une journalisation configurable, des outils cryptographiques, des algorithmes graphiques, des générateurs UUID, des cartes, des ensembles, des arbres, des modèles, la gestion des dépendances, la manipulation de la date, la localisation / internationalisation, les opérations matricielles, l'injection de dépendances, les tests unitaires, la réduction de carte, le traitement XML? Trivial pour les langages JVM ou .NET - en Javascript, vous devez souvent lancer votre propre implémentation.

Une des raisons pour lesquelles Javascript est lent est son manque total de sécurité de type. Toute variable peut être de tout type à tout moment. De plus, la plupart des opérations sont valides avec de nombreux types différents, mais ont une sémantique différente . Un terme simple

a += b;

n'est pas anodin pour l'interprète, car aet bpourrait être des nombres ou des chaînes. Lorsque les deux sont des nombres, c'est un ajout arithmétique. Lorsque les deux sont des chaînes, il s'agit d'une concaténation de chaînes. Lorsque l'un est une chaîne et l'autre est un nombre, le nombre doit être formaté avant d'effectuer une concaténation de chaîne. Ce sont des opérations complètement différentes qui nécessitent d'interpréter les arguments différemment.

Selon les types de aet b, le type de apeut maintenant être entier, double ou String, quel que soit le type qu'il était auparavant.

Étant donné que les variables dans JS peuvent changer de type à tout moment, l'interpréteur ne parvient presque pas à évaluer les types chaque fois que cette instruction est appelée pour éviter de faire la mauvaise opération. Cela nécessite des cycles CPU supplémentaires.

Les autres fonctionnalités qui rendent l'optimisation beaucoup plus difficile sont les tableaux clairsemés ou la collecte des ordures et les gestionnaires d'événements qui peuvent se déclencher à tout moment.

Jetez un œil à asm.js - C'est un sous-ensemble de Javascript qui permet une bien meilleure optimisation en se débarrassant de certaines fonctionnalités JS, notamment la frappe dynamique.