Cosa impedisce alle app HTML5 e JS di funzionare come le app native?

Il poster boy per le app HTML5, LinkedIn è diventato nativo all'inizio del 2013. Nell'intervista in VentureBeat spiegano perché.

Penso che questa sia la parte più pertinente alla tua domanda:

Prasad said performance issues weren’t causing crashes or making the app run slowly. What he did say shows that HTML5 for the mobile web still has a bright future — but only if developers are willing to build the tools to support it.

...

There are a few things that are critically missing. One is tooling support — having a debugger that actually works, performance tools that tell you where the memory is running out. If you look at Android and iOS, there are two very large corporations that are focused on building tools to give a lot of detailed information when things go wrong in production. On the mobile web side, getting those desktop tools to work for mobile devices is really difficult. The second big chunk we are struggling with is operability, runtime diagnostics information. Even now, when we build HTML5, we build it as a client-side app. It’s more of a client-server architecture. … The operability of that, giving us information when we’re distributed to a large volume of users, there aren’t as many great tools to support that, as well.

[Prasad also noted that dev and ops tools for solving issues quickly "don't exist."]

Because those two things don’t exist, people are falling back to native. It’s not that HTML5 isn’t ready; it’s that the ecosystem doesn’t support it. … There are tools, but they’re at the beginning. People are just figuring out the basics.

La mancanza di una libreria standard Javascript è un inibitore orribile. Ci sono ottimi framework come jQuery, Dojo, YUI, solo per citarne alcuni, ma tutti sono focalizzati esclusivamente sul livello di presentazione e XHR.

Vuoi logging configurabile, strumenti crittografici, algoritmi di grafi, generatori UUID, mappe, insiemi, alberi, modelli, gestione delle dipendenze, manipolazione delle date, localizzazione / internazionalizzazione, operazioni con matrici, iniezione delle dipendenze, unit test, map-reduce, XML in lavorazione? Trivial per linguaggi JVM o .NET: in Javascript devi spesso implementare la tua implementazione.

Uno dei motivi per cui Javascript è lento è la totale mancanza di sicurezza del tipo. Qualsiasi variabile può essere di qualsiasi tipo in qualsiasi momento. Inoltre, molte operazioni sono valide con molti tipi diversi, ma hanno una semantica differente. Un semplice termine

a += b;

non è così banale per l'interprete, perché a e b potrebbero essere numeri o stringhe. Quando entrambi sono numeri, è un'aggiunta aritmetica. Quando entrambi sono string, questa è una concatenazione di stringhe. Quando uno è una stringa e uno è un numero, il numero deve essere formattato prima di eseguire una concatenazione di stringhe. Si tratta di operazioni completamente diverse che richiedono di interpretare gli argomenti in modo diverso.

A seconda dei tipi di a e b , il tipo di a può ora essere intero, doppio o stringa, indipendentemente dal tipo che era prima.

Poiché le variabili in JS possono cambiare il loro tipo in qualsiasi momento, l'interprete difficilmente riesce a valutare i tipi ogni volta che viene chiamata questa istruzione per evitare di fare l'operazione sbagliata. Ciò richiede ulteriori cicli della CPU.

Altre funzionalità che rendono l'ottimizzazione molto più difficile sono gli array sparsi o la raccolta dei rifiuti e i gestori di eventi che possono essere attivati in qualsiasi momento.

Dai un'occhiata a asm.js - È un sottoinsieme di Javascript che consente un'ottimizzazione molto migliore eliminando alcune funzioni JS, in particolare dinamiche digitazione.