Was hindert HTML5- und JS-Apps daran, so gut wie native Apps zu funktionieren?

Von dem, was ich verstehe,

• HTML ist eine Auszeichnungssprache, ebenso wie der Inhalt von XAML, XIB und allen von Android verwendeten und anderen nativen UI-Entwicklungsframeworks.
• JavaScript ist eine Programmiersprache, die zusammen mit der Verarbeitung von clientseitigem Scripting verwendet wird. Dazu gehören beispielsweise die Ereignisbehandlung, clientseitige Validierungen und alles andere, was C #, Java, Objective-C oder C ++ in verschiedenen solchen Frameworks tun.
• Es gibt MVC / MVVM-Muster, die in Form-Frameworks wie Sencha, Angular usw. verfügbar sind.
• Wir haben localStorage in Form von SQLite- und Schlüsselwertspeichern wie andere Frameworks und Sie haben API-Spezifikationen für fast alles, was fehlt.
• Immer wenn ein natives UI-Framework die Benutzeroberfläche rendern muss, muss es das Markup ähnlich analysieren und die Benutzeroberfläche rendern.

Aufschlüsselung der Fragen

• Was hindert Sie daran, dasselbe in HTML und JS selbst zu tun?
• Warum können HTML (zusammen mit CSS) und JS nicht auf die gleiche Weise ausgeführt werden, anstatt ein Websteuerelement oder einen Browser als Ebene dazwischen zu haben?
• Selbst wenn es eine Ebene gibt, werden .net-Laufzeit und JVM in anderen Fällen verwendet, in denen C ++, C nicht verwendet werden.
• Nehmen wir also den Fall von Android wie Dalvik. Warum kann Chromium nicht eine andere Option sein (neben Dalvik und NDK), bei der HTML das tut, was Android-Markup tut, und JavaScript verwendet wird, um das zu tun, was Java tut?

Die Frage ist also:

Auch wenn aktuelle Implementierungen nicht so gut sind, ist es theoretisch möglich, HTML5-basierte Anwendungen wie andere native Apps speziell auf Mobilgeräten zum Laufen zu bringen?

LinkedIn, der Aushängeschilder für HTML5-Apps, wurde Anfang 2013 geboren. Im Interview in VentureBeat erklären sie, warum.

Ich denke, dies ist der Teil, der für Ihre Frage am relevantesten ist:

Prasad sagte, dass Leistungsprobleme keine Abstürze verursachten oder die App langsam laufen ließen. Was er gesagt hat, zeigt, dass HTML5 für das mobile Web noch eine glänzende Zukunft hat - aber nur, wenn Entwickler bereit sind, die Tools zu entwickeln, um dies zu unterstützen.

...

Es gibt einige Dinge, die kritisch fehlen. Eine davon ist die Tooling-Unterstützung - ein Debugger, der tatsächlich funktioniert, Leistungstools, die Ihnen mitteilen, wo der Speicher knapp wird. Wenn Sie sich Android und iOS ansehen, gibt es zwei sehr große Unternehmen, die sich darauf konzentrieren, Tools zu erstellen, die viele detaillierte Informationen liefern, wenn in der Produktion Probleme auftreten. Auf der mobilen Webseite ist es sehr schwierig, diese Desktop-Tools für mobile Geräte zum Laufen zu bringen. Der zweite große Teil, mit dem wir zu kämpfen haben, ist die Funktionsfähigkeit und Informationen zur Laufzeitdiagnose. Selbst jetzt, wenn wir HTML5 erstellen, erstellen wir es als clientseitige App. Es ist eher eine Client-Server-Architektur. … Die Funktionsfähigkeit davon, die uns Informationen liefert, wenn wir an eine große Anzahl von Benutzern verteilt werden, gibt es nicht so viele großartige Tools, die dies ebenfalls unterstützen.

[Prasad bemerkte auch, dass Entwickler- und Operations-Tools zur schnellen Lösung von Problemen "nicht existieren".]

Weil diese beiden Dinge nicht existieren, fallen die Menschen auf Eingeborene zurück. Es ist nicht so, dass HTML5 noch nicht fertig ist. Es ist so, dass das Ökosystem es nicht unterstützt. … Es gibt Werkzeuge, aber sie stehen am Anfang. Die Leute finden nur die Grundlagen heraus.

Das Fehlen einer Javascript-Standardbibliothek ist ein schrecklicher Hemmstoff. Es gibt großartige Frameworks wie jQuery, Dojo, YUI, um nur einige zu nennen, aber alle konzentrieren sich ausschließlich auf die Präsentationsebene und XHR.

Möchten Sie konfigurierbare Protokollierung, kryptografische Tools, Diagrammalgorithmen, UUID-Generatoren, Karten, Mengen, Bäume, Vorlagen, Abhängigkeitsmanagement, Datumsmanipulation, Lokalisierung / Internationalisierung, Matrixoperationen, Abhängigkeitsinjektion, Komponententests, Kartenreduzierung, XML-Verarbeitung? Trivial für JVM- oder .NET-Sprachen - In Javascript müssen Sie häufig Ihre eigene Implementierung ausführen.

Ein Grund, warum Javascript langsam ist, ist der völlige Mangel an Typensicherheit. Jede Variable kann jederzeit von einem beliebigen Typ sein. Außerdem sind die meisten Operationen mit vielen verschiedenen Typen gültig , haben jedoch unterschiedliche Semantiken . Ein einfacher Begriff

a += b;

ist für den Interpreter nicht so trivial, weil aund bkönnte Zahlen oder Zeichenfolgen sein. Wenn beide Zahlen sind, ist es eine arithmetische Addition. Wenn beide Zeichenfolgen sind, ist dies eine Zeichenfolgenverkettung. Wenn eins eine Zeichenfolge und eins eine Zahl ist, muss die Zahl formatiert werden, bevor eine Zeichenfolgenverkettung durchgeführt wird. Dies sind völlig unterschiedliche Operationen, bei denen die Argumente unterschiedlich interpretiert werden müssen.

Abhängig von den Typen von aund bkann der Typ von ajetzt Integer, Double oder String sein, unabhängig davon, welcher Typ zuvor war.

Da Variablen in JS ihren Typ jederzeit ändern können, kann der Interpreter die Typen kaum auswerten, wenn diese Anweisung aufgerufen wird, um eine falsche Operation zu vermeiden. Dies erfordert zusätzliche CPU-Zyklen.

Andere Funktionen, die die Optimierung erheblich erschweren, sind spärliche Arrays oder Garbage Collection- und Event-Handler, die jederzeit ausgelöst werden können.

Schauen Sie sich asm.js an - Es handelt sich um eine Teilmenge von Javascript, die eine viel bessere Optimierung ermöglicht, indem einige JS-Funktionen, insbesondere die dynamische Typisierung, entfernt werden.