¿Qué impide que las aplicaciones basadas en HTML adopten aplicaciones nativas, es decir, en su experiencia, qué impide que las aplicaciones HTML5 / CSS / JS se conviertan en el presente en lugar de en el futuro?

Primero: JavaScript NO es el problema.

Necesito sacar esto del camino, porque hay mucha información errónea aquí. Este artículo ha estado circulando por Internet últimamente, por qué las aplicaciones web para dispositivos móviles son lentas, y creo que se pierde completamente el sentido. Se titula “Por qué las aplicaciones web móviles son lentas”, y luego se despide de por qué JavaScript es lento, y solo asume silenciosa y falsamente que el rendimiento de JavaScript === rendimiento de la aplicación web.

No sé en qué aplicaciones web trabaja el autor de ese artículo durante todo el día, pero trabajo en el reproductor web de Spotify, que creo que es un muy buen ejemplo de una aplicación de complejidad por encima del promedio, y puedo decirle que JavaScript es muy, muy raramente un cuello de botella de rendimiento. Sí, JavaScript es lento, pero en la práctica, es lo suficientemente rápido para lo que está haciendo. En cambio, las ralentizaciones que busco en mi trabajo diario están relacionadas con las llamadas de red y las manipulaciones DOM, y simplemente arrojar montones de código que no deberían hacerse en primer lugar. Nunca tuve un momento en el que dije “Oh, desearía que esta pieza de JavaScript optimizado se ejecutara aún más rápido”.

Ok, entonces, ¿cuál es el problema?

Marco primitivo del ecosistema.
En comparación con las computadoras de escritorio, los dispositivos móviles tienen procesadores pequeños, baterías pequeñas y RAM pequeña. Obtener un rendimiento de 60 FPS en estos dispositivos que no agota la batería en un par de horas requiere MUCHO trabajo. Por lo tanto, Apple y Google han hecho mucho de ese trabajo POR usted, creando componentes ultra optimizados que puede reutilizar en sus aplicaciones. También ofrecen herramientas bastante potentes para depurar y perfilar estos componentes.

Las herramientas equivalentes simplemente todavía no existen para las aplicaciones web. Claro, cosas como jQuery se ha convertido en estándar de facto, y eso ha aumentado diez veces la productividad del desarrollo de aplicaciones web, pero no hay un equivalente de jQuery en un nivel superior: la web sigue siendo un lugar donde usted mismo construye la mayoría de las cosas. La interfaz de usuario de jQuery y otras cosas no existen, pero simplemente no tiene el mismo impacto en las interfaces que jQuery tuvo en el DOM.

Depuración y perfilado.
Las herramientas de desarrollo de Chrome ahora están alcanzando algún tipo de madurez, ofreciendo bastante soporte avanzado de herramientas para sus aplicaciones. Sin embargo, este es un desarrollo muy agradable y no se ha extendido a otros navegadores, y absolutamente no a la depuración del navegador móvil.

Navegadores de mala calidad, especialmente al incrustarlos.
Android acaba de obtener Chrome: antes de eso, tenía algo horrible que dejaría sin nombre con la esperanza de que todos se olvidaran de él para que no se convirtiera en el IE6 del móvil, por así decirlo. Safari en iOS es bastante decente, pero si intentas incrustarlo en tu aplicación (para recibir notificaciones y compras en la aplicación y otras cosas) obtienes una versión aguada y mala, y el mismo principio se aplica a Android.

Plug descarado: si te gustan mis divagaciones sobre la programación en Quora, puedes disfrutar de mi programa de YouTube: Fun Fun Function

En resumen, no hay problemas técnicos que mantengan HTML5 bajo.

Como otros han dicho, no es JavaScript. Cuando se hace correctamente, la red también suele ser lo suficientemente rápida (solo transfiera datos, no elementos, etc.). Incluso DOM puede ser lo suficientemente rápido con UI y UX que está construido correctamente. Todas estas cosas son solo problemas técnicos que pueden y serán resueltos de una forma u otra. La cuestión de si usar HTML5 o nativo es puramente caso por caso: depende completamente de sus recursos, características, requisitos, plataformas de destino, etc. Algunas aplicaciones se pueden hacer en HTML5, otras no.

Sin embargo, el gran problema es que las aplicaciones basadas en HTML5 se reducen artificialmente , siendo el mejor caso Apple e iOS. Si desea hacer una aplicación híbrida de iOS (aplicación nativa para una mejor adquisición y retención de usuarios, HTML5 para un mejor control y menores costos) al incrustar el navegador en la aplicación, le espera una sorpresa. Al incrustar el navegador, obtienes una versión que es mucho más lenta e inferior a cualquier cosa que se ejecute directamente en Safari. ¿Qué lleva a la pregunta de por qué? La respuesta aburrida es la política. Al permitir que los desarrolladores obtengan todo el poder de la web para las aplicaciones de iOS, podrían eludir la App Store y sus restricciones, ganando menos dinero para Apple. Por lo tanto, lo mejor para Apple es mantener bajas las aplicaciones basadas en HTML5.

Entonces, para responder a su pregunta, qué es lo que impide que HTML se haga cargo, la respuesta es política.

¿Qué se necesitaría para que HTML5 se haga cargo? Ya sea un nuevo jugador para sacudir las cosas o un jugador existente con un modelo de negocio que funciona (también conocido como gana más dinero) con aplicaciones basadas en la web. Ambos son bastante improbables. 🙁 Salvo las opciones anteriores, nuestra única opción es esperar hasta que incluso la versión diluida sea lo suficientemente rápida.

Bien. Hay muchas razones válidas. Vayamos directamente a algunos de ellos.

Actuación
Las aplicaciones nativas puntúan en muchas cosas en este frente

1. Simplemente, las aplicaciones nativas son un código de bytes compilado procesado y ejecutado por el hardware que resulta en una ejecución mucho más rápida que la interpretación realizada por el navegador.

2. Las aplicaciones nativas pueden hacer mucho almacenamiento en caché y almacenamiento local de antemano para ejecutar aplicaciones ricas en contenido para, por ejemplo, una revista. Por otro lado, aplicaciones HTML5; aunque son compatibles con el almacenamiento local; todavía está limitado a qué y cuánto puede almacenar. Ver aquí – Almacenamiento del lado del cliente – Rocas HTML5
Por ejemplo, almacenar un archivo completo todavía es un sueño descabellado en html5.

Soporte de gráficos
Native tiene un soporte mucho mejor en términos de proporcionar API de gráficos que se pueden usar con un alto nivel de complejidad y nuevamente utilizar el hardware para ejecutar. En comparación con esto, tenemos el Canvas en html5, que nuevamente tiene su limitación tanto en términos de uso como de capacidades de procesamiento.

Incompatibilidad del navegador:
La mayor desventaja y, probablemente, lo primero que se debe alcanzar para alcanzar el nivel de las aplicaciones nativas es la incompatibilidad entre los navegadores para ejecutar la misma cosa de manera estándar. A pesar de los esfuerzos concentrados para hacer que la web siga un cierto conjunto de estándares que todo navegador debe seguir; Todavía hay algunas inconsistencias válidas que pueden dejarlo indefenso en cualquier momento.
Por ejemplo: todavía no existe una propiedad css estándar para tener un desplazamiento suave en todos los navegadores.
-webkit-overflow-scrolling ahora se introduce en el safari móvil en IOS5, pero no se admite todo el tiempo en los navegadores Chrome y Android. (Cuánta compatibilidad hay para -webkit-overflow-scrolling: touch)
Como solución alternativa, simplemente tiene que ir a bibliotecas de terceros y otros hacks para una tarea simple.

Falta de esfuerzo concentrado.
Este puede ser un punto vago para discutir; pero siempre hay una cosa que hace que el desarrollo de aplicaciones para iOS y Android sea más fácil: la disponibilidad de tantos documentos, foros, libros para el desarrollo en su plataforma y el esfuerzo para mantener su popularidad. Pero en el caso de HTML5 no existe tal esfuerzo para facilitar este trabajo y hacerlo más generalizado.

Nada lo impide como tal, es posible usar HTML5 y aún así hacer una gran aplicación. No es JavaScript que es solo la parte lenta, es JavaScript mal escrito y uso inadecuado o insuficiente de CSS.

Por lo general, las personas usan PhoneGap y jQuery, ambos son famosos, pero junto con blob de complementos basura se vuelve más lento.

CSS incorrecto.
Si observa jQuery mobile, todos los artículos están formados por dos o más span y div para dar un aspecto elegante que es totalmente innecesario. Ciertamente puede crear CSS con menos cantidad de elementos.

Botones de lujo
Puede usar múltiples fondos para crear un buen botón con un icono aplicado a elementos HTML individuales. En lugar de crear tramos anidados e imagen.

Desplegables de lujo
Puede diseñar el elemento SELECT en lugar de usar jQuery mobile que reemplaza SELECT con UL / LI.

Consejos de mejoras
1. Use HTML + CSS más que JavaScript para UI
2. Reduce el número de elementos en la pantalla
3. Utilice elementos de IU de tamaño fijo en lugar de tamaño dinámico.
4. Use consejos de optimización de JavaScript
5. Use animación CSS en lugar de JavaScript.
6. El botón no debe contener img o span, solo debe contener texto y una clase para diseñar y aplicar la imagen.
7. No cargue todos los JS o CSS a menos que realmente los necesite en la página.

A menos que esté creando juegos 3D o una aplicación de computación alta, aún puede crear una mejor aplicación receptiva con HTML5.

Razón psicológica,
Durante años, el HTML solo fue considerado como trabajo de diseñador y los programadores de nivel básico utilizaron JavaScript, y la mayoría de las personas en puestos de trabajo más altos en realidad sienten poca estima por trabajar en JavaScript. De lo contrario, el V8 de Chrome es tan rápido como el nativo porque se compila al nativo como cualquier otro idioma nativo. Por lo tanto, JavaScript puede ser más rápido y pronto se acercará a la velocidad nativa.

Tipo de pregunta confusa por intención (?).
Pídale a la gente que confirme su propio sesgo.
Nada que lo impida. Porque HTML y JavaScript ya superaron a las aplicaciones nativas.
El 33% de todas las aplicaciones son juegos.
El 47% de todos los juegos escritos con Unity (JavaScript) no son nativos.
El 15% de todos los juegos escritos con Adobe Air y no son nativos.
El 42% de los desarrolladores de juegos usan código nativo más alguna herramienta multiplataforma de terceros como la anterior. Por ejemplo: Android + Adobe Air.
Solo el 29% de los desarrolladores de juegos usan solo código nativo .
http://www.visionmobile.com/blog …

Solo el 41% de TODAS las aplicaciones son nativas (24% Android + 17% iOS).
12% de aplicaciones que ganan más de $ 10,000 / mes (¡sorprendentemente muchas!).
Entre ellos, solo el 26% de las aplicaciones son nativas (17% iOS + 9% Android).
http://www.nextbigwhat.com/app-d …

Por lo tanto, las posibilidades de un gran éxito en relación con la implementación nativa / no nativa:
iOS 17: 17 (1: 1)
Android 9:24 (~ 1: 3)
No nativo 74 x 2 * = 148: 59 (~ 2.5: 1)
* escrito una vez desplegado dos veces.
** 74 = 100-26
*** 59 = 100-41
La posibilidad de éxito para el desarrollador no nativo es 2.5 veces mayor que para iOS y 7 veces mayor que para Android uno.

No veo en algún lugar publicado qué% de no nativos son html / javascript pero aproximadamente 70-90%.

La razón del “conocimiento” común de que HTML5 es el futuro puede no ser porque todos piensan que será más rápido o mejor que las aplicaciones nativas. De hecho, eso es imposible. Las aplicaciones nativas siempre serán superiores en rendimiento e interfaz de usuario.

Sin embargo, exactamente como HTML5 ha eliminado las aplicaciones nativas en PC de escritorio en gran medida, hay algunas características muy importantes de la naturaleza de HTML5:

– Plataforma independiente
– Política independiente: nadie posee la especificación.
– Conjunto de habilidades: ya existe un conjunto de habilidades HTML5 bien establecido entre la mayoría de los programadores.
– Costo: el desarrollo de una aplicación para múltiples plataformas requiere muchos equipos separados, lo que significa administración intermedia, más dispositivos para probar, etc.

Creo firmemente que cuando la diferencia de rendimiento de la interfaz de usuario entre una aplicación nativa en comparación con una aplicación HTML5 es imperceptible, habrá una relación similar entre las aplicaciones web que usa y las aplicaciones nativas que tiene en su computadora de escritorio (juegos, ui-intensivo = nativo , todos los demás = html5).

Además, es importante comprender que es posible obtener una velocidad impresionante de una aplicación HTML5 incluso en teléfonos más antiguos: debe tener suficiente experiencia en optimización web, transiciones CSS3 y usar cuidadosamente sus recursos, especialmente el árbol DOM. Los últimos puntos en esa lista prácticamente descartan cualquier marco que pueda encontrar (como Sencha Touch, JQuery Mobile, etc.).

Compartí nuestra matriz de decisión cuando elegimos HTML5 como nuestra plataforma de desarrollo principal para la aplicación Radical.FM: ¿por qué elegir HTML5 en lugar de aplicaciones nativas?

HTML no es un lenguaje de programación. Y solo sé sobre las plataformas de Apple. Así que responderé esto como si su pregunta fuera: “¿Qué impide que las aplicaciones escritas en JavaScript tomen aplicaciones nativas escritas en Objective-C o Swift”?

Básicamente, hay dos formas de escribir aplicaciones en JavaScript hoy en día:

1. incrustado en una página HTML que abriría en un navegador web
2. incrustado en una aplicación nativa como “lógica de negocios” que tiene un marco para usar elementos de la interfaz de usuario nativos para mostrar cosas

El número 1 usa HTML y el árbol DOM para actualizar lo que ve el usuario. El número 2 usa elementos nativos de la interfaz de usuario. Ambos usan JavaScript para el flujo del programa. El representante más conocido del número 2 se llama ReactNative.

Hay más y más aplicaciones conocidas que se crearon en ReactNative y que son multiplataforma. Pero, ¿puedes decir que están “tomando” aplicaciones nativas? Yo diría: “claramente no”

No sé qué piensan otros desarrolladores sobre este tema, conozco a algunos que no conocen el idioma y no tienen problemas para cambiar de plataforma e idioma. Pero la mayoría de los desarrolladores, los de nivel superior de nosotros, somos los que decidimos qué tecnología utilizar para implementar aplicaciones para empresas y clientes, parece pensar como yo:

Odiamos JavaScript. Es un lenguaje realmente estúpido que nunca fue diseñado para manejar aplicaciones nativas. Debido a esto, carece severamente en la mayoría de las áreas que hacen que el código nativo sea hermoso, fácil de mantener y razonar.

Lo peor que le puede pasar a un chico, como yo, que vive y respira las aplicaciones Swift e iOS / Mac sería “Heredar” una aplicación ReactNative para mantenerla de un predecesor. JavaScript es tan crudo que duele.

Por el contrario, mi pan de cada día es Swift, que es el mejor de todos los lenguajes de programación existentes actualmente porque fue diseñado desde cero para ser hermoso, eficiente para escribir (aproximadamente la mitad de escribir que en Objective-C) y el compilador puede deduzca muchas cosas acerca de su código que hace que le dé advertencias y errores mientras está codificando.

Con Swift, cuando el código se compila, lo más probable es que sea correcto. Con JavaScript es mucho más prueba y error porque todas las variables pueden tener todos los tipos y usted ve los problemas con eso solo cuando el programa se ejecuta y termina con una entrada incorrecta.

La programación en JavaScript solo existe porque muchos desarrolladores web esperan volver a utilizar sus habilidades al poder crear aplicaciones nativas en lugar de aplicaciones web. Una palabra: pereza.

Mientras que los programadores sensibles, como yo, toman las decisiones arquitectónicas, las aplicaciones nativas siempre ganarán.

Por qué las aplicaciones web móviles son lentas

Lee esto. Esta publicación bien investigada (más de 100 citas) conmocionó a Hacker News cuando salió hace unos meses. El comentario: ¿Por qué las aplicaciones web móviles son lentas?

Si te sientes flojo, aquí está el resumen:

• Javascript es demasiado lento para el uso de aplicaciones móviles en 2013 (por ejemplo, para edición de fotos, etc.).

• Es más lento que el código nativo en aproximadamente 5
• Es comparable a IE8
• Es más lento que x86 C / C ++ en aproximadamente 50
• Es más lento que Java / Ruby / Python / C # del lado del servidor en un factor de aproximadamente 10 si su programa cabe en 35MB, y se degrada exponencialmente a partir de ahí

El camino más viable para que sea más rápido es empujar el hardware al rendimiento a nivel de escritorio. Esto podría ser viable a largo plazo, pero parece una espera bastante larga.

El lenguaje en sí no parece ser más rápido en estos días, y las personas que están trabajando en él dicen que con el lenguaje y las API actuales, nunca será tan rápido como el código nativo.

La recolección de basura es exponencialmente mala en un entorno con memoria limitada. Es mucho, mucho peor de lo que es en entornos de clase de escritorio o de clase de servidor.

Todos los desarrolladores móviles competentes, ya sea que usen un entorno GCed o no, pasan mucho tiempo pensando en el rendimiento de la memoria del dispositivo de destino.

JavaScript, tal como existe actualmente, se opone fundamentalmente a incluso permitir que los desarrolladores piensen en el rendimiento de la memoria del dispositivo de destino

Si cambiaron de opinión y permitieron que los desarrolladores pensaran en la memoria, la experiencia sugiere que este es un problema técnicamente difícil.

asm.js muestra cierta promesa, pero incluso si ganan, usará C / C ++ o un lenguaje similar “hacia atrás” como una interfaz, en lugar de algo dinámico como JavaScript

El problema con las aplicaciones HTML 5 es que resumen cosas, haciendo que las características realmente geniales de un sistema operativo estén parcialmente o no disponibles.

El problema principal es la interfaz de usuario. Si quieres una interfaz de usuario atractiva, quieres ser nativo. Las aplicaciones basadas en HTML rara vez usan los componentes nativos reales. La mayoría de las veces usan reproducciones HTML extrañas de estos, y se ven mal.

Las interfaces de usuario de CrossPlatform son simplemente malas y siempre inferiores. Entonces, la otra opción que tiene es ofrecer un enlace HTML completo de las interfaces de usuario de Android / iOS, y luego todavía tiene que codificar las interfaces para cada sistema operativo por separado. ¿Por qué desperdiciar tanto esfuerzo? Es interesante ver que Xamarin con su C # en iOS y Android, también se centra en un modelo de dominio compartido para ambos sistemas operativos, pero un diseño de UI codificado por separado utilizando los componentes nativos de la interfaz de usuario (aunque usando C #). Creo que ese modelo de desarrollo es mucho más viable para la codificación de plataforma cruzada, luego algo abstracto como HTML.

Se trata de la tasa de abstracción (de las capacidades del sistema operativo de bajo nivel) que se mantiene al día con la tasa de innovación (de esas capacidades). Un modelo de programación de navegador siempre será uno (o más) niveles de abstracción más adelante en la cadena.

En pocas palabras, significa que siempre puede hacer cosas mucho más potentes con API nativas y, en un mercado de aplicaciones hipercompetitivas, esto siempre será más atractivo para la mayoría de los tipos de aplicaciones. Y, en un mercado de teléfonos inteligentes hipercompetitivo, los proveedores de sistemas operativos quieren innovarse mutuamente, lo que solo acelera la tasa de innovación del sistema operativo (frente a la innovación del navegador).

Ahora, solíamos preocuparnos por la distribución de aplicaciones. La web, siendo lo que es (es decir, muy abierta) es lo suficientemente atractiva en muchos casos como para que los desarrolladores comprometan el rendimiento (nativo) versus la distribución. Sin embargo, las tiendas de aplicaciones han cambiado esa dinámica significativamente para dispositivos móviles. La distribución de aplicaciones nativas es de muy baja fricción.

Es posible imaginar y diseñar soluciones a este problema general, pero actualmente es muy difícil encontrar una dinámica comercial que lo provoque. Mozilla, junto con Telefónica, están tratando de cambiar la dinámica (al menos en los llamados mercados “en desarrollo”), pero veamos a dónde va.

Estampación

Realmente creo que el problema número uno que impide que las aplicaciones de JavaScript compitan con Native Apps son las herramientas. La visibilidad del rendimiento de una aplicación de JavaScript que se ejecuta en un entorno móvil no coincide con la nativa. Los marcos que existen a menudo son ineficientes, no escalables e hinchados. Por lo general, intentan y admiten demasiados dispositivos. Soportar dispositivos más antiguos es como tratar de soportar IE5.

En Belly, creamos una aplicación HTML5 iPad híbrida. Fue un gran éxito. Hicimos el 90% del desarrollo dentro de un navegador de escritorio, lo que nos pareció la forma más fácil y rápida de depurar ineficiencias DOM, pérdidas de memoria, etc. Aunque iOS6 introdujo una excelente forma de inspeccionar aplicaciones usando el inspector web de Safari (ver: Depuración de Web Contenido en iOS).

Mira nuestra aplicación para iPad:
http://www.davearel.com/belly/ip …

Además de las herramientas, hay una serie de otros problemas. Es un poco complicado descargar las tareas de rending en la GPU, Garbage Collection es ineficiente, el teclado nativo es inestable (creamos un teclado personalizado) y, por supuesto, fuera de una aplicación híbrida, tiene muy poco acceso a las API nativas, ninguna aplicación tienda, etc.

La creación de una aplicación HTML5 híbrida tenía sentido para nosotros. Hemos creado un cargador de arranque realmente impresionante para que podamos enviar nuevas versiones a todos nuestros iPads en cualquier momento. Pero no fue fácil y es bastante restrictivo. Para la mayoría de las aplicaciones móviles, nativo solo tiene más sentido.

“HTML5 es el futuro!” Y, sin embargo, las aplicaciones de iOS / Android de gran éxito todavía se crean principalmente como aplicaciones nativas.

Según su experiencia, ¿qué impide que las aplicaciones HTML5 / CSS / JS se conviertan en el presente, no en el futuro?

La mayoría de las bibliotecas nativas de IU son mucho más bellas y eficientes que HTML en diseño. Una CPU más rápida y más rápida es inútil en esto para HTML.

Propósito.

Creo que eso es lo que impide que las personas cambien de aplicaciones nativas a aplicaciones web en dispositivos móviles.
Claro, no podrá desarrollar aplicaciones ricas en gráficos usando HTML / JS / CSS (3), pero para otros propósitos, las aplicaciones web probablemente sean mejores [1]
Otra razón por la cual las personas aún desarrollan aplicaciones nativas (nuevamente, para algunos propósitos) es el legado de que nativo es más rápido. La tecnología ha evolucionado y se ha realizado un gran esfuerzo en los navegadores que es razonable (si no imperativo) para cuestionar si la aplicación nativa o web es más rápida de desarrollar y produce el mismo (mejor) resultado.

[1] http://www.infoworld.com/t/appli …

Para agregar a la respuesta de Matt, la coherencia de la implementación en todos los navegadores también es un problema. Esto es particularmente cierto para HTML5 y las muchas características nuevas y geniales que trae. Los diferentes navegadores en diferentes plataformas tienen muchos niveles diferentes de soporte HTML5.

Es por eso que existen sitios como http://html5test.com . Esto hace que sea difícil para los desarrolladores. Al menos, para aplicaciones nativas, si no es compatible, simplemente no funcionará. Para HTML5, si no es compatible, probablemente intente funcionar y probablemente se rompa. Sin embargo, estoy seguro de que esto se arregla a su debido tiempo.

No hay una solución única para resolver todos los problemas.
Cada herramienta, lenguaje, plataforma y tecnología está diseñada para abordar un problema específico a resolver pero, por supuesto, presentar otros.

La aplicación web funciona bien con aplicaciones de grandes empresas al simplificar el mantenimiento y la implementación requeridos. Las aplicaciones nativas están más orientadas a una sola persona.

Un desarrollador profesional con experiencia sabrá qué herramienta utilizará para resolver los problemas / deseos de los usuarios.

No es una guerra Debes preguntarte dónde está mejor la web que la nativa, a pesar de todas sus desventajas.
Dado que las aplicaciones web e híbridas tienen tantas ventajas, como la facilidad de desarrollo y mantenimiento, la multiplataforma y las actualizaciones inmediatas, se debe usar donde estas características son importantes.

Hay un momento y un lugar para todo: todo se reduce a lo que desea o necesita que sea la experiencia del usuario.

La mayoría de las veces los desarrolladores eligen HTML5 como acceso directo. Dado que HTML es familiar, ayuda a los desarrolladores web a crear “aplicaciones” mucho más rápido que aprender Java, Objective-C y C #, y luego construir una aplicación nativa separada para cada plataforma. No se equivoque, construir nativo requiere habilidad y mucho más esfuerzo para crear + mantener todo.

HTML5 es bueno en las siguientes situaciones:

1. Está creando una aplicación solo interna para su propia organización donde puede ordenar su uso.
2. Tiene un pequeño equipo de desarrollo, y es más importante que funcione en todas las plataformas que se sienta bien en todas las plataformas.
3. Necesita crear una versión móvil de algo para lo que ya tiene una solución basada en la web rápidamente. Sin embargo, esto solo debería ser una solución provisional hasta que pueda crear aplicaciones nativas.

Native es bueno en estas situaciones:

1. Está creando una aplicación orientada al consumidor, donde las calificaciones de su aplicación desempeñarán un papel importante en la adopción
2. Ya tienes un equipo de desarrolladores con los conocimientos para crear aplicaciones nativas

Con todo lo dicho, la respuesta a su pregunta es el hecho de que solo las aplicaciones nativas generalmente brindan una experiencia de usuario lo suficientemente buena como para merecer altas calificaciones en las tiendas de aplicaciones … Y los desarrolladores serios de dispositivos móviles lo saben. Es una pérdida de tiempo crear una versión HTML5 de una aplicación si su objetivo final es crear una gran aplicación.

no hay formas en que las aplicaciones basadas en HTML adopten una aplicación nativa.

Aunque HTML es un ganador en la era de Internet, no es una buena especificación / formato de visualización de interfaz de usuario.

La mayoría de las bibliotecas nativas de IU son mucho más bellas y eficientes que HTML en diseño. Una CPU más rápida y más rápida es inútil en esto para HTML.

Básicamente no hay acceso (o no confiable) a los recursos subyacentes del teléfono y su sistema operativo nativo:

p.ej. acelerómetro, GPS, cámaras, lectura de huellas dactilares, sistema de archivos local, bibliotecas de SO distintivas para el tacto, gráficos acelerados, hilos prioritarios para la generación de sonido (intente escribir una aplicación de música en el navegador), elementos GUI estándar, sistema de permisos; “intenciones”.

Si bien hay cierto progreso en todo esto, no es confiable ni completamente estándar.

Por el contrario, el escritor de la aplicación nativa. puede asumir el acceso a todos los recursos que proporciona el sistema operativo.