¿Cuál es la diferencia entre HTML5, Native y una aplicación híbrida? ¿Cual es mejor?

Veo muchas ideas falsas en las respuestas aquí.

Primero, las definiciones:

• HTML5 es una tecnología que se utiliza para especificar (parte de) el aspecto visual de una página web. HTML5 puede servirse desde un sitio web y representarse como una “aplicación web” en el teléfono. También se usa en aplicaciones híbridas para diseñar las partes visuales (controles, etc.).
• Cualquier aplicación que pueda publicar en la tienda es, en algún nivel , una aplicación nativa. Cuando las personas dicen “aplicación nativa” a menudo significan “no híbrido”, pero existe una falsa dicotomía implícita entre “nativo” y todo lo demás, cuando en realidad hay muchas opciones
• Una aplicación híbrida usa específicamente un WebView para representar la mayoría de los controles / elementos visuales. Encontrarás HTML5 y JavaScript manejando la mayoría de las aplicaciones híbridas.

Supongo que realmente está comparando “aplicación web”, “aplicación escrita en Java para Android y Objective C o Swift para iOS” y “aplicación escrita en Cordova / PhoneGap”. Sin embargo, estas no son las únicas tres opciones, por lo que quiero agregar algunas opciones más para comparar. Para obtener un resumen rápido de las opciones que estoy considerando, consulte esta tabla:

Como puede ver, “nativo” e “híbrido” no son las únicas opciones. Cordova / Ionic son tecnologías híbridas: el renderizado se realiza en un WebView, aunque puede usar funciones nativas del dispositivo que no están disponibles en un sitio web (cámara, notificaciones, etc.).

Puede crear aplicaciones multiplataforma que tengan un rendimiento nativo. La mayoría de los juegos han estado utilizando técnicas de desarrollo multiplataforma durante años, y los juegos son más sensibles al rendimiento que la mayoría de las aplicaciones.

Existen Unity3d, Cocos2d-x y muchos otros entornos de desarrollo multiplataforma que le brindarán un rendimiento completo para su juego (en algunos casos mejor que “nativo”), y solo necesita escribirlo una vez.

Pero los motores de juego no son ideales para aplicaciones generales, entonces, ¿qué opciones tenemos allí?

El desarrollo “híbrido” ha sufrido muchas dificultades en los últimos años. Zuckerberg afirmó que el híbrido simplemente “no es lo suficientemente bueno”. Pero luego Sencha Mobile creó un clon de Facebook basado en WebView que demostró que en realidad puedes hacerlo lo suficientemente rápido. Lea sobre esto en The Making of Fastbook: An HTML5 Love Story.

Por lo tanto, puede usar híbrido, y Cordova / PhoneGap es probablemente la plataforma más madura para construir. Sin embargo, hay opciones además de eso: Ionic Framework se basa en Cordova y le brinda controles adicionales específicos de la plataforma para que su aplicación se vea más Android o iOS en su plataforma respectiva. Meteor le brinda una forma de crear aplicaciones de pila completa que comparten código, y le permite apuntar a iOS, Android, aplicación web y código de servidor con la misma base de código.

Pero he enumerado más opciones que Cordova en la tabla anterior. A veces quieres controles nativos, y varias de las opciones anteriores te dan la posibilidad de crear controles nativos desde tu aplicación multiplataforma.

React Native y Xamarin le permiten crear controles nativos al crear diferentes rutas de código para cada plataforma: para un control particular, definirá cómo se ve en Android y cómo se ve en iOS.

NativeScript y Tabris.js abstraen los controles comunes, por lo que puede definir su diseño una vez y hacer que funcione en ambas plataformas. Hay una nueva función de Xamarin que también te permite trabajar de esta manera, aunque no he escuchado qué tan bien funciona.

Kivy no usa controles nativos, sino que es un motor de juego que simplemente proporciona las herramientas que normalmente necesita para escribir una aplicación. Entonces, en lugar de parecerse a una aplicación de Android o iOS, es más probable que cree algo que se vea como una aplicación completamente personalizada. El rendimiento no debería ser un cuello de botella, pero puede que te guste o no el estilo.

Otras Consideraciones:

• Una característica clave que ofrecen algunas de las soluciones basadas en JavaScript es Live Update: la capacidad de enviar una nueva versión de una aplicación a los usuarios sin tener que esperar a que se actualicen en la tienda o que la tienda apruebe una actualización. Dado que la aprobación en la tienda de Apple puede variar de días a semanas, la capacidad de enviar un parche a los usuarios casi de inmediato es poderosa. También significa que no necesitará admitir versiones antiguas de su API, si tiene una, ya que puede garantizar que la aplicación utilizará el último cliente API.
• En Native, obtienes acceso a las herramientas de desarrollo de la plataforma, que suelen ser buenas. En el desarrollo híbrido, tiene acceso a la increíblemente buena pila de herramientas de depuración disponibles en Chrome, y las herramientas de Safari, para depurar su aplicación en tiempo real. Los otros enfoques de JavaScript generalmente también tienen una forma de conectar Chrome, y React Native en particular admite la recarga en vivo: cambie un aspecto de la página que está viendo y lo volverá a procesar como si acabara de ejecutar todo el código para ese punto de nuevo. Es como una característica instantánea de “volver a ejecutar la aplicación y tomar las mismas decisiones”.
• Los SDK nativos suelen ser detallados y molestos de usar para hacer algunas cosas comunes. Tener un ecosistema de complementos disponible significa que agregar algo como pagos en la aplicación puede pasar de ser una molestia a agregar un complemento y la interfaz de usuario. Lo mismo para el inicio de sesión en Facebook, notificaciones, etc. El ecosistema de complementos de Cordova es uno de los mejores, pero NativeScript se ve impresionante.
• NativeScript tiene una característica interesante: envuelve todas las API del sistema operativo con JavaScript, por lo que tan pronto como se publique una nueva API, puede llamarla directamente. De JavaScript Sin plug-in nativo.
• Si tiene requisitos serios de procesamiento de datos, probablemente querrá un código nativo “real”, con lo que me refiero a C / C ++ / Go / Rust o similar. La mayoría de las aplicaciones no necesitan esto, pero si lo necesita, casi todos los entornos anteriores tienen una forma de conectar su código nativo a la aplicación, pero es posible que deba conectarse por plataforma. Esto no se tiene en cuenta en la figura de “ahorro” anterior, porque no se aplica a la mayoría de las aplicaciones.
• Las estimaciones en la tabla anterior son realmente solo estimaciones. Muchos son tomados de (mi memoria de) lo que el equipo que desarrolla la tecnología respectiva ha afirmado, pero muchos son solo conjeturas educadas. Su experiencia puede ser diferente.
• Si necesita utilizar un complemento de terceros para su aplicación, seguramente estará disponible en nativo para iOS / Android, pero no necesariamente para cualquier otra cosa. Muchos complementos están disponibles para Cordova, pero si el que desea usar no lo está, debe agregar el costo adicional de crear un complemento Cordova (u otro) para esa tecnología. También se suma al costo.
• Si necesita partes sustanciales de su código para convertirse en un complemento, para ser utilizado por otras compañías, hay suficientes personas que desarrollan código nativo que probablemente esté atrapado desarrollando nativo.

En conclusión: hay muy pocas razones para desarrollar usando la plataforma SDK nativa directamente más, y cuesta casi el doble hacerlo. Excepto si va a proporcionar su código como complementos para otros, le recomiendo encontrar una solución multiplataforma y usarla.

EDITADO para agregar información sobre Live Update (“parches en caliente”) como lo menciona Shai Alon en los comentarios.