O que impede que os aplicativos HTML5 e JS tenham um desempenho tão bom quanto os aplicativos nativos?

Pelo que entendi,

• HTML é uma linguagem de marcação, assim como o conteúdo de XAML, XIB e o que o Android usar e outras estruturas de desenvolvimento de UI nativas.
• JavaScript é uma linguagem de programação usada junto com ele para lidar com scripts do lado do cliente, que inclui itens como manipulação de eventos, validações do lado do cliente e tudo o mais que C #, Java, Objective-C ou C ++ fazem em várias estruturas.
• Existem padrões MVC / MVVM disponíveis em estruturas de formulário como Sencha, Angular etc.
• Temos localStorage na forma de armazenamento sqlite e key-value como outras estruturas e você tem especificação de API para quase tudo o que está faltando.
• Sempre que uma estrutura de interface do usuário nativa precisar renderizar a interface do usuário, ela precisará analisar uma marcação semelhante e renderizar a interface do usuário.

Pergunta break-down

• O que impede de fazer o mesmo no HTML e no próprio JS?
• Em vez de ter um controle da web ou navegador como uma camada intermediária, por que HTML (juntamente com CSS) e JS não podem ser executados da mesma maneira?
• Mesmo se houver uma camada, o tempo de execução .net e a JVM estão em outros casos em que C ++, C não está sendo usado.
• Vamos considerar o caso do Android, como o Dalvik, por que o Chromium não pode ser outra opção (junto com o dalvik e o NDK) em que o HTML faz a marcação do Android e o JavaScript é usado para fazer o Java?

Então a pergunta é:

Mesmo que as implementações atuais não sejam tão boas, mas teoricamente é possível fazer com que aplicativos baseados em HTML5 funcionem como outros aplicativos nativos, especialmente em dispositivos móveis?

O garoto-propaganda dos aplicativos HTML5, o LinkedIn se tornou nativo no início de 2013. Na entrevista no VentureBeat, eles explicam o porquê.

Eu acho que essa é a parte mais relevante para sua pergunta:

Prasad disse que problemas de desempenho não causavam falhas ou faziam o aplicativo rodar lentamente. O que ele disse mostra que o HTML5 para a Web móvel ainda tem um futuro brilhante - mas apenas se os desenvolvedores estiverem dispostos a criar as ferramentas para suportá-lo.

...

Existem algumas coisas que estão faltando criticamente. Uma é o suporte a ferramentas - ter um depurador que realmente funciona, ferramentas de desempenho que informam onde a memória está acabando. Se você observar o Android e o iOS, existem duas grandes empresas focadas na criação de ferramentas para fornecer muitas informações detalhadas quando as coisas dão errado na produção. No lado móvel da Web, é realmente difícil conseguir essas ferramentas de desktop para dispositivos móveis. O segundo grande pedaço com o qual estamos lutando é a operabilidade, informações de diagnóstico em tempo de execução. Mesmo agora, quando criamos o HTML5, criamos como um aplicativo do lado do cliente. É mais uma arquitetura cliente-servidor. … A operacionalidade disso, fornecendo informações quando estamos distribuídos a um grande volume de usuários, também não existem muitas ferramentas excelentes para suportar isso.

[Prasad também observou que as ferramentas de desenvolvimento e operações para solucionar problemas rapidamente "não existem".]

Como essas duas coisas não existem, as pessoas estão voltando ao nativo. Não é que o HTML5 não esteja pronto; é que o ecossistema não suporta isso. ... Existem ferramentas, mas elas estão no começo. As pessoas estão apenas descobrindo o básico.

A falta de uma biblioteca padrão Javascript é um inibidor horrível. Existem excelentes estruturas, como jQuery, Dojo, YUI, para citar algumas, mas todas estão focadas apenas na camada de apresentação e no XHR.

Deseja registro configurável, ferramentas criptográficas, algoritmos de gráficos, geradores UUID, mapas, conjuntos, árvores, modelos, gerenciamento de dependências, manipulação de datas, localização / internacionalização, operações matriciais, injeção de dependência, testes de unidade, testes de unidade, redução de mapa e processamento XML? Trivial para linguagens JVM ou .NET - em Javascript, você frequentemente precisa rolar sua própria implementação.

Uma das razões pelas quais o Javascript é lento é a total falta de segurança do tipo. Qualquer variável pode ser de qualquer tipo a qualquer momento. Além disso, a maioria das operações é válida com muitos tipos diferentes, mas semânticas diferentes . Um termo simples

a += b;

não é tão trivial para o intérprete, porque ae bpoderia ser números ou strings. Quando ambos são números, é uma adição aritmética. Quando ambos são string, essa é uma concatenação de string. Quando um é uma sequência e um é um número, o número deve ser formatado antes de executar uma concatenação de sequência. Essas são operações completamente diferentes que exigem a interpretação dos argumentos de maneira diferente.

Dependendo dos tipos de ae b, o tipo de aagora pode ser inteiro, duplo ou String, independentemente do tipo que era antes.

Como as variáveis ​​em JS podem alterar seu tipo a qualquer momento, o intérprete dificilmente avalia os tipos sempre que essa instrução é chamada para evitar a operação incorreta. Isso requer ciclos adicionais da CPU.

Outros recursos que tornam a otimização muito mais difícil são matrizes esparsas ou coleta de lixo e manipuladores de eventos que podem ser acionados a qualquer momento.

Dê uma olhada no asm.js - é um subconjunto de Javascript que permite uma otimização muito melhor, eliminando alguns recursos de JS, principalmente a digitação dinâmica.