¿Qué impide que las aplicaciones HTML5 y JS funcionen tan bien como las aplicaciones nativas?

Por lo que entiendo,

HTML es un lenguaje de marcado, también lo es el contenido de XAML, XIB y lo que sea que Android use y otros marcos de desarrollo de interfaz de usuario nativos.
JavaScript es un lenguaje de programación que se usa junto con él para manejar las secuencias de comandos del lado del cliente que incluirá cosas como el manejo de eventos, validaciones del lado del cliente y cualquier otra cosa que C #, Java, Objective-C o C ++ hagan en varios de estos marcos.
Hay patrones MVC / MVVM disponibles en marcos de formularios como Sencha's, Angular, etc.
Tenemos localStorage en forma de sqlite y almacén de valores clave como lo tienen otros frameworks y tiene la especificación API para casi todo lo que falta.
Siempre que un marco de IU nativo tenga que representar la IU, debe analizar un marcado similar y representar la IU.

Desglose de preguntas

¿Qué impide hacer lo mismo en HTML y JS?
En lugar de tener un control web o un navegador como una capa intermedia, ¿por qué no se puede hacer que HTML (junto con CSS) y JS funcionen de la misma manera?
Incluso si hay una capa, también lo hacen .net runtime y JVM en otros casos donde C ++, C no se están utilizando.
Así que tomemos el caso de Android, como Dalvik, ¿por qué Can't Chromium puede ser otra opción (junto con Dalvik y NDK) donde HTML hace lo que hace el marcado de Android y JavaScript se usa para hacer lo que Java hace?

Entonces la pregunta es,

Incluso si las implementaciones actuales no son tan buenas, pero en teoría, ¿es posible hacer que las aplicaciones basadas en HTML5 funcionen como otras aplicaciones nativas especialmente en dispositivos móviles?

— Amogh Talpallikar
fuente

refactorice para aclarar cuáles son las declaraciones de las que está comenzando y cuál es la pregunta real.

— funkybro

¿Podría aclarar lo que quiere decir con "¿Qué impide hacer lo mismo en HTML y JS?" No entiendo lo que quieres decir con "lo mismo": has hecho cuatro declaraciones anteriormente y no estoy seguro de a qué te refieres en esa pregunta.

— apsillers

Si tengo una plataforma de desarrollo nativa que usa HTML como marcado en lugar de algo nuevo. y usa JS como lenguaje, ¿será mejor el rendimiento? Google en esta E / S dijo que eran prácticos y usaban Android en el teléfono y no Chrome OS. Entonces, ¿significa que FF OS no es un concepto práctico? ¿Es posible que las aplicaciones FFOS funcionen tan bien como las aplicaciones de Android en las plataformas respectivas si se siguen todas las mejores prácticas?

— Amogh Talpallikar

Echa un vistazo a las aplicaciones de Windows Metro. Son aplicaciones nativas que usan HTML para el diseño de GUI y Javascript para la lógica detrás de él.

— Philipp

El rendimiento de HTML / JS es generalmente más que suficiente para una interfaz de usuario que muestra información y, en función de las acciones del usuario, realiza solicitudes a un servidor externo. Originalmente no fue construido para más que eso, pero ahora es impresionantemente más capaz. Aún así, para situaciones que implican un acceso más directo al dispositivo, la interacción con el código nativo o la interacción con el sistema operativo (es decir, notificaciones), todavía no hay una buena manera de usar tecnologías web de uso general para eso.

— Katana314

Respuestas:

El aficionado de las aplicaciones HTML5, LinkedIn se hizo nativo a principios de 2013. En la entrevista en VentureBeat explican por qué.

Creo que esta es la parte más relevante para su pregunta:

Prasad dijo que los problemas de rendimiento no estaban causando fallas o haciendo que la aplicación se ejecutara lentamente. Lo que dijo muestra que HTML5 para la web móvil todavía tiene un futuro brillante, pero solo si los desarrolladores están dispuestos a desarrollar las herramientas para soportarlo.

...

Hay algunas cosas que faltan críticamente. Uno es el soporte de herramientas: tener un depurador que realmente funcione, herramientas de rendimiento que le indican dónde se está agotando la memoria. Si nos fijamos en Android e iOS, hay dos corporaciones muy grandes que se centran en crear herramientas para brindar mucha información detallada cuando las cosas salen mal en la producción. En el lado web móvil, hacer que esas herramientas de escritorio funcionen para dispositivos móviles es realmente difícil. La segunda gran parte con la que estamos luchando es la operatividad, la información de diagnóstico de tiempo de ejecución. Incluso ahora, cuando creamos HTML5, lo creamos como una aplicación del lado del cliente. Es más una arquitectura cliente-servidor. ... La operatividad de eso, al brindarnos información cuando estamos distribuidos a un gran volumen de usuarios, tampoco hay tantas herramientas excelentes para respaldar eso.

[Prasad también señaló que las herramientas de desarrollo y operación para resolver problemas rápidamente "no existen"]

Debido a que esas dos cosas no existen, las personas están volviendo a ser nativas. No es que HTML5 no esté listo; es que el ecosistema no lo soporta. ... Hay herramientas, pero están al principio. La gente solo está descubriendo lo básico.

— vartec
fuente

No lo entiendo Tenemos corporaciones muy grandes: Google, Microsoft, Apple enfocadas en respaldar Chrome, Safari e IE. Tenemos a Mozilla comprometido con Firefox. Tenemos Chrome Dev Tools, Web Inspector, Firebug. ¿Y Prasad dice que no hay herramientas?

— niutech

@niutech: digamos que quieres una herramienta como Valgrind para la aplicación HTML5. No hay mucho

— vartec

La falta de una biblioteca estándar de Javascript es un inhibidor horrible. Hay grandes marcos como jQuery, Dojo, YUI, por nombrar algunos, pero todos ellos se centran únicamente en la capa de presentación y XHR.

¿Desea un registro configurable, herramientas criptográficas, algoritmos de gráficos, generadores de UUID, mapas, conjuntos, árboles, plantillas, gestión de dependencias, manipulación de fechas, localización / internacionalización, operaciones matriciales, inyección de dependencias, pruebas unitarias, reducción de mapas, procesamiento XML? Trivial para los lenguajes JVM o .NET: en Javascript a menudo tiene que implementar su propia implementación.

— Maros Urbanec
fuente

Agregue informes a eso.

— Alan B

ECMAScript 6 agrega la mayoría de estas características. Google Closure Library es otra solución.

— niutech

Angular proporciona una buena forma declarativa ahora.

— Amogh Talpallikar

Una razón por la que Javascript es lento es su total falta de seguridad de tipos. Cualquier variable puede ser de cualquier tipo en cualquier momento. Además, la mayoría de las operaciones son válidas con muchos tipos diferentes, pero tienen semánticas diferentes . Un término simple

a += b;

No es trivial para que el intérprete, porque a, y bpodría ser números o cadenas. Cuando ambos son números, es una suma aritmética. Cuando ambos son cadenas, esta es una concatenación de cadenas. Cuando uno es una cadena y uno es un número, el número debe formatearse antes de realizar una concatenación de cadenas. Estas son operaciones completamente diferentes que requieren interpretar los argumentos de manera diferente.

Dependiendo de los tipos de ay b, el tipo de aahora puede ser entero, doble o Cadena, independientemente del tipo que fuera antes.

Debido a que las variables en JS pueden cambiar su tipo en cualquier momento, el intérprete difícilmente evalúa los tipos cada vez que se llama a esta instrucción para evitar hacer una operación incorrecta. Esto requiere ciclos de CPU adicionales.

Otras características que hacen que la optimización sea mucho más difícil son matrices dispersas o recolección de basura y controladores de eventos que pueden activarse en cualquier momento.

Eche un vistazo a asm.js : es un subconjunto de Javascript que permite una optimización mucho mejor al deshacerse de algunas características de JS, especialmente la escritura dinámica.

— Philipp
fuente

Los compiladores JavaScript JIT modernos generan código de máquina especializado sobre la marcha para los tipos que está utilizando si son estables en su uso real de tiempo de ejecución. Si realmente está codificando de una manera que apuede ser entera, cadena o doble, etc., tiene razón. Y los navegadores más antiguos que todavía usan intérpretes, por supuesto, tampoco tienen estas optimizaciones.

— Esailija

@Esailija Los entornos JavaScript modernos son mucho, mucho más rápidos que los antiguos. Pero aún son más lentos en comparación con los entornos modernos de tipo estático, como .NET, JVM, ErlangVM, etc.

— David Sergey

@nirth, sí, no estoy diciendo eso, solo digo que esta publicación describe cómo un intérprete / compilador de jit no optimizador lo haría y eso es muy lento.

— Esailija