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

Da quello che ho capito,

• L'HTML è un linguaggio di mark-up, così come il contenuto di XAML, XIB e qualsiasi cosa utilizzi Android e altri framework di sviluppo dell'interfaccia utente nativa.
• JavaScript è un linguaggio di programmazione usato insieme ad esso per gestire scripting lato client che includerà cose come la gestione degli eventi, convalide lato client e qualsiasi altra cosa che C #, Java, Objective-C o C ++ facciano in vari framework di questo tipo.
• Esistono modelli MVC / MVVM disponibili in framework di forme come Sencha, Angular ecc.
• Abbiamo localStorage sotto forma di archivio sqlite e valore-chiave come altri framework e hai specifiche API per quasi tutto ciò che manca.
• Ogni volta che un framework di interfaccia utente nativa deve eseguire il rendering dell'interfaccia utente, deve analizzare un markup simile e renderizzare l'interfaccia utente.

Analisi della domanda

• Cosa impedisce di fare lo stesso in HTML e JS stesso?
• Invece di avere un controllo web o un browser come strato intermedio, perché HTML (insieme a CSS) e JS non possono essere fatti allo stesso modo?
• Anche se esiste un layer, lo stesso vale per .net runtime e JVM in altri casi in cui C ++, C non vengono utilizzati.
• Quindi prendiamo il caso di Android, come Dalvik, perché Can't Chromium può essere un'altra opzione (insieme a Dalvik e NDK) in cui HTML fa ciò che fa il markup Android e JavaScript viene usato per fare ciò che fa Java?

Quindi la domanda è:

Anche se le attuali implementazioni non sono altrettanto buone, ma teoricamente è possibile far funzionare le applicazioni basate su HTML5 come altre app native specialmente sui dispositivi mobili?

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

Penso che questa sia la parte più rilevante per la tua domanda:

Prasad ha affermato che i problemi di prestazioni non causavano arresti anomali o rallentavano l'app. Quello che ha detto mostra che HTML5 per il Web mobile ha ancora un futuro brillante, ma solo se gli sviluppatori sono disposti a costruire gli strumenti per supportarlo.

...

Ci sono alcune cose che mancano in modo critico. Uno è il supporto degli strumenti: avere un debugger che funziona davvero, strumenti per le prestazioni che indicano dove si sta esaurendo la memoria. Se guardi Android e iOS, ci sono due società molto grandi che si concentrano sulla costruzione di strumenti per fornire molte informazioni dettagliate quando le cose vanno male nella produzione. Dal punto di vista del Web mobile, far funzionare quegli strumenti desktop per i dispositivi mobili è davvero difficile. Il secondo grosso pezzo con cui stiamo lottando è l'operabilità, le informazioni di diagnostica di runtime. Anche ora, quando costruiamo HTML5, lo costruiamo come un'app lato client. È più un'architettura client-server. ... L'operabilità di questo, dandoci informazioni quando siamo distribuiti a un grande volume di utenti, non ci sono molti ottimi strumenti per supportare anche quello.

[Prasad ha anche notato che gli strumenti di sviluppo e ops per risolvere rapidamente i problemi "non esistono".]

Poiché queste due cose non esistono, le persone stanno tornando ai nativi. Non è che HTML5 non sia pronto; è che l'ecosistema non lo supporta. ... Ci sono strumenti, ma sono all'inizio. Le persone stanno solo scoprendo le basi.

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

Desideri registrazione configurabile, strumenti crittografici, algoritmi grafici, generatori UUID, mappe, set, alberi, modelli, gestione delle dipendenze, manipolazione della data, localizzazione / internazionalizzazione, operazioni con matrici, iniezione di dipendenze, test unitari, riduzione delle mappe, elaborazione XML? Trivial per i linguaggi JVM o .NET: in Javascript spesso devi 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, la maggior parte delle operazioni sono valide con molti tipi diversi, ma hanno una semantica diversa . Un termine semplice

a += b;

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

A seconda dei tipi di ae b, il tipo di apuò ora essere intero, doppio o stringa, indipendentemente dal tipo precedente.

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 un'operazione sbagliata. Ciò richiede ulteriori cicli della CPU.

Altre caratteristiche che rendono molto più difficile l'ottimizzazione sono gli array sparsi o la garbage collection 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 funzionalità di JS, in particolare la digitazione dinamica.