Skip to content
Aprende Angular de forma rápida y efectiva  Ver curso

Ionic VS React Native VS NativeScript

Si quieres leer la versión más actualizada de este artículo, sigue este enlace

Respondiendo a la pregunta de la semana, un lector que tenía dudas sobre la competencia de Ionic para apps híbridas, me comentaba…

¿En un futuro no muy lejano, Ionic seguirá encabezando la lista de frameworks de año híbridas o tendrá algún buen competidor? De ser así, ¿El competidor sería alguno actualmente conocido(native script por ejemplo)?

Evidentemente no tengo la bola del futuro 😉 pero si que te puedo dar mi opinión, fundada en años de experiencia probando nuevas tecnologías y desarrollando con ellas así como en base a las últimas tendencias que he detectado.

Native Script está bien para obtener un plus de rendimiento, pero si tengo que nombrar una alternativa potente a Ionic, aprovechando la moda de renderizar sobre nativo, lo que me viene a la cabeza es React Native.

En todo caso, mi apuesta se mantiene firme con Ionic 2, veamos por qué.

Problemas históricos de las apps híbridas

Típicamente JS funciona en un único hilo de ejecución, por lo que por mucho que tengas un dispositivo último modelo con procesador de 8 núcleos, tu aplicación híbrida sólo va a usar un núcleo del procesador para todo: el pintado de la pantalla, cálculos largos y complejos que hagas en la app, etc… Este es el principal motivo que ha dado mala fama a las apps híbridas, especialmente en el pasado cuando los smartphones eran menos potentes y eso provocaba problemas de rendimiento, como por ejemplo que al hacer scroll de un listado el desplazamiento fuera a trompicones.

El enfoque singlethread de Javascript es lo que ha dado mala fama a las apps híbridas históricamente.

Los beneficios de las híbridas/nativas

Es cierto que NativeScript se ha escuchado bastante últimamente -la propia página de Angular 2 habla de ellos- y no les falta razón. Frente a los problemas de rendimiento que se han encontrado históricamente en las apps híbridas, su propuesta se presenta como una solución para apps híbridas: la lógica de negocio, controladores, modelo etc. va en Javascript, y en lugar de pintar HTML, pintas sobre componentes nativos (con lo que el renderizado se ejecuta en otro thread, garantizando una mayor fluidez). A este tipo de solución yo la llamo híbrida/nativa.

En React Native y NativeScript, en lugar de renderizar HTML sobre un WebView, se renderizan componentes nativos Android/iOS, que se pintan en su propio thread, ganando fluidez.

La idea parece muy novedosa, pero lo cierto es que también la estaban aplicado los señores de Facebook con su alternativa: React Native, que sin duda, por el estado maduro y por la compañía que tiene detrás, es el rival más potente que veo para Ionic.

Contrapartida de las apps híbridas/nativas

Las híbridas/nativas son buenas si para ti lo prioritario es la fluidez de la app incluso en móviles de gama media/baja y tus únicos targets son Android e iOS, pero evidentemente, no todo son ventajas:

  • Curva de aprendizaje: Al no utilizar HTML sino sus propios componentes (tipo xml), tendrás que aprenderlos todos por lo que la curva de aprendizaje es más larga y además no te garantiza que lo que aprendes te vaya a servir en el futuro. Esto no es un gran inconveniente si comparamos con Ionic, ya que al final éste también aporta un montón de directivas que debes aprender.

  • Estilos: Siguiendo con la curva de aprendizaje, no solo deberías preocuparte por como mostrar datos en pantalla, sino de su diseño. React Native tiene su propio sistema para darle estilo a tu app que se suma a la curva de aprendizaje. Native Script es algo mejor en este sentido y te permite utilizar CSS, aunque no todas las propiedades habituales CSS están disponibles.

  • Plataformas: De momento, tanto React Native como NativeScript están solo disponibles para Android y iOS. No es que la cuota de mercado de smartphones Windows sea muy elevada, pero seguro que quieres que tu app esté en cuantos más smartphones mejor…

  • No funciona en web: Es importante recalcar esto. Tu aplicación React Native o NativeScript no es una web y por tanto no podrás usarla como tal. Dile adiós a tu web mobile.

React Native vs. NativeScript

No es que tenga nada contra NativeScript. De hecho, en Barcelona mantuve una charla muy animada entre cervezas con Sebastian Witalec, del equipo de Telerik y uno de los principales evangelizadores de NativeScript. Native Script está bien y tiene una integración muy buena con Angular. El problema es que la comunidad que hay detrás no me parece excesivamente grande y Telerik, su principal impulsora, no tiene la dimensión ni la repercusión de Facebook.

Cuando digo que React Native será la principal competidora de Ionic es por el mero hecho de tener a Facebook detrás: su repercusión es brutal. Es un poco como el efecto que tuvo AngularJS frente a otros frameworks de su época como EmberJS o Backbones. AngularJS se erigió de entre todos con facilidad gracias al empujón de Google. En el siguiente gráfico podemos ver como, efectivamente, React Native está teniendo mucha repercusión.

Ionic VS React Native VS NativeScript
Interés por estos frameworks en el último año

 
Personalmente, me gusta más trabajar con Angular 2 que React (aunque no sean bien bien lo mismo), pero si bien React es la librería de referencia para trabajar con React Native, el enfoque Platform Agnostic de Angular2 hace que podamos integrarlo también con React Native. El amor por Angular 2 no es, por tanto, una limitación para usar React Native.

El enfoque Platform Agnostic de Angular 2 hace que lo podamos integrar con React Native.

Ionic 2 como futuro de las híbridas

A estas alturas estarás pensando… ¿entonces… por qué dices que Ionic 2 seguirá dominando? Pues por los siguientes detalles:

  • Es web: A diferencia de las otras dos soluciones, aquí estás desarrollando con tecnología web pura y dura. Esto significa explotar Angular2, HTML5 y CSS3 en toda su magnitud. Además, significa que tu app funcionará también como web mobile.

  • Más plataformas: Además de Android y iOS, también funciona perfectamente con Windows, así que llegarás a más usuarios.

  • Eficiencia: Ionic 1 ya se movía con bastante fluidez en smartphones de gama media. Ionic 2, con Angular 2 rehecho de cero para solucionar los problemas de rendimiento de su predecesor cuando el número de bindings se disparaba, debería volar sobre la pantalla.

  • WebWorkers: Gracias a Angular 2, ahora es más fácil trabajar con Web Workers que te permiten realizar tareas en otros threads. ¡Se acabaron los scrolls a trompicones!

  • Potencia: Cada día los smartphones son más potentes y los navegadores para móviles están más trabajados, así que los problemas de rendimiento del pasado deberían quedar cada vez más enterrados.

Últimas diferencias

El lector avispado se habrá dado cuenta de un par de detalles. En primer lugar, los gráficos de búsquedas de google ponen a React Native como más popular, con diferencia, en comparación por ejemplo a Ionic 2, y por otro lado uno de los motivos por los que considero menos importante a Native Script es que no tiene una empresa detrás del tamaño de Google o Facebook, sin embargo, bien podría ser esa también la situación de Ionic.

Respondiendo a la primera cuestión hay que tener en cuenta que React Native hace tiempo que tiene Release Candidates con las que trabajar de forma estable. En cambio, Ionic 2 aún no está en versión estable (le queda poco) y sin ir más lejos la Release Candidate de Angular 2 se ha aprobado recientemente. Con esto quiero decir que lo normal es que sea en un futuro cercano cuando empecemos a ver verdadera tracción de Ionic 2.

Lo normal es que sea en un futuro cercano cuando empecemos a ver verdadera tracción de Ionic 2.

En cuanto al equipo que hay detrás, es cierto que los de Ionic tampoco tienen el tamaño de Google o Facebook, pero la tecnología (Angular 2) sí que viene empujada por Google, Ionic ha recibido en Abril 2016 una nueva ronda de financiación de 8.5M$ y a diferencia de Telerik, Ionic se dedica exclusivamente a vender herramientas para este framework.

Conclusiones

Yo siempre he defendido que la competencia ayuda al progreso y si bien mi apuesta es por Ionic 2, estoy encantado de que haya una alternativa potente como React Native, por que seguro que esa dualidad los va a hacer más fuertes y potentes a nivel individual.

Es más, si tu único objetivo es una app en Android y iOS y quieres explotar el rendimiento al 110%, te recomiendo que le des un vistazo a React Native, pero si tu objetivo con una híbrida es llegar rápido y bien a cuantos más mejor, te recomiendo Ionic 2.

En todo caso, recuerda que si lo que quieres es llegar al máximo número de plataformas posible, incluyendo web, Ionic 2 es tu elección.

¿Y tú, qué alternativa te llama más la atención?

¡Saludos!

Published inHybrid appionicIonic FrameworkJavascriptPhoneGap

9 Comments

  1. Gracias por escribir este detallado artículo. Yo soy el Gerente de Product Marketing de NativeScript.

    Primeramente, nuestra comunidad aprecia ampliamente Ionic. Es un buen producto y los desarrolladores que lo usan pueden hacer cosas excelentes. Solo comento para señalar algunas cosas que puedes no haber considerado:

    En primera instancia, es fácil ver las diferencias en rendimiento entre Ionic y NativeScript. NativeScript usa componentes nativos que por defecto vienen optimizados para el dispositivo. Intenta pones un par de mil records en una lista en aplicación hecha con Ionic e intenta navegar rápidamente.
    Puedes leer más sobre ListViews en NativeScript aquí:
    https://www.nativescript.org/blog/discover-the-list-component-in-nativescript

    Sumado a esto, las animaciones en NativeScript son objetivamente más fluidas. Intenta esta aplicación demo en tu dispositivo para que veas cómo se siente. Seguramente notarás las animaciones fluidas y las transiciones amigables.
    https://www.nativescript.org/nativescript-example-application

    Otra cosa importante para considerar, es sumamente fácil compartir código entre aplicaciones web y móviles a través de nuestra integración con Angular 2. Más información aquí: https://www.nativescript.org/blog/details/sharing-code-between-web-and-native-apps-with-angular-2-and-nativescript

    Nosotros ya hemos comenzando a trabajar en agregar la opción de generar aplicaciones HTML desde NativeScript para soportar casos de uso que sean puramente orientas a la web sin sacrificar el rendimiento nativo en dispositivos móviles. Esto está aún en etapas preliminares pero estamos confiados con que muchas cosas interesantes surgirán a partir de este trabajo.
    Estamos totalmente dispuestos a ayudarte si tienes alguna inquietud.

    • Enrique Oriol Enrique Oriol

      Hola Dan,

      Gracias por el interés. Ante todo quiero dejar claro que la intención de mi artículo no es menospreciar las cualidades de NativeScript, al contrario, creo que habéis hecho una labor excelente. La intención del artículo es la de exponer los principales rivales que veo para el panorama presente y futuro de las aplicaciones híbridas.

      Siguiendo con tu comentario, está claro que el rendimiento de NativeScript debería ser superior al de Ionic y de hecho, si has leído el artículo entero, precisamente hablo de como usáis componentes nativos en lugar de HTML. No obstante, el ejemplo de la lista con miles de elementos que pones es poco adecuado. Las listas nativas reciclan las celdas para no trabajar con más de las necesarias, pero es que justamente Ionic, que ha hecho un trabajo estupendo, proporciona la directiva collection-repeat en Ionic 1, y la directiva VirtualScroll en Ionic 2 para beneficiarse del mismo planteamiento. Si una app Ionic está bien diseñada, por mucho que una lista tenga miles o millones de elementos, funcionará igual de fluida, por que en realidad solo estará renderizando unos pocos.

      En cuanto a las animaciones, estoy seguro de que ofrecéis un plus de rendimiento, pero hoy en día, con los dispositivos actuales y unos navegadores móviles decentes, la experiencia ya es muy satisfactoria con Ionic.

      Me parecen dos aproximaciones diferentes pero igualmente válidas para solucionar un problema. Lo que yo me cuestiono es, por muy fácil que sea integrarse también con web, de momento os hace falta duplicar los templates así que… ¿vale la pena más trabajo para un resultado muy similar? Evidentemente depende de la aplicación. Si la killer feature de tu app es tener transiciones a 60fps, seguramente te conviene más NativeScript, ReactNative o directamente una app nativa.

      En otro orden de cosas, ¿cómo os veis en comparación con React Native? Mi impresión -actualmente- es que ellos avanzan a mayo ritmo y con mayor tracción, que no es difícil teniendo en cuenta el equipo que hay detrás. De ahí que los ponga por encima de vosotros como el rival más fuerte. Evidentemente es mi opinión, pero me parece interesante conocer vuestro punto de vista sobre este tema.

      En todo caso, celebro la noticia de que estéis planteando generar HTML desde NativeScript (entiendo que esto os llevaría a utilizar 1 único template para todas las plataformas, como en Ionic). No dudes en contactar conmigo para explicarme más detalles del tema, me encantará poder explicar vuestros avances en mi blog.

      Saludos,

      • Yo en lo personal prefiero Nativescript, aunque como dices aún le falta mucho por evolucionar, aún así decidí aventurarme a construir una aplicación utilizando esta tecnología y estoy avanzando bastante bien. Sin embargo tal como mencionas aún faltan muchas librerías y la comunidad al no ser tan extensa en ocasiones es difícil encontrar la solución a algunos problemas por lo que el tiempo de investigación toma mucho más tiempo que con otras tecnologías más maduras.

        Sin embargo no puedo dar un punto de vista objetivo hasta no haber utilizado las tres tecnologías, así que mi próxima aplicación será construida utilizando React para poder ampliar mi visión sobre la mejor herramienta para desarrollo ágil de aplicaciones híbridas.

        ¡Saludos desde México!

  2. Buenas, saludos desde Mar Del Plata, Argentina. Enrique, siempre me cruzo con Posts tuyos y nunca he comentado alguno así que aprovecho para agradecer tu trabajo.
    Actualmente me pidieron un app para una empresa de venta de artículos. para ver el estado de las cajas y no mucho mas. Muy lejos de pretender desarrollar un videojuego sino mas bien algo bien básico y por lo que vengo analizando en estos días me he decidido a compilar con nativescript mi webapp en angular2, basándome en la gran cantidad de opiniones que asegura esto de que nativescript es mas rápido si bien menos conocido y su golpe fuerte de trabajar con los componentes nativos de android.
    De todas formas mi impresión es la siguiente:
    Si no me convence nativescript, mas adelante podre compilar mi proyecto ANGULAR con cualquier otro híbrido del momento react, ionic2, cordova (es chiste), ext. sin mayores complicaciones que las de estudiar los pasos a seguir de cada uno.
    Por conclusión no parece tan preocupante tomar el uno o el otro, al menos para mi caso. Y si mi conclusión es correcta y, suponiendo en un futuro un proyecto de mayor magnitud, vería muy conveniente invertir en probar todos los compiladores para sacar mayor provecho al app.
    a ver que opinan.
    Saludos.

  3. Pepe Pepe

    Buenas:
    A mí me preocupa especialmente un tema que no he visto tratado en el artículo y es el comportamiento de estos frameworks respecto a funcionalidades puramente nativas del móvil que requieren acceso a hardware del dispositivo tales como NFC, Bluetooth, cámara, vídeo… cómo lo solucionan react, ionic y compañía?
    Gracias!!

    • Enrique Oriol Enrique Oriol

      Pues a través de plugins que se ejecutan en el lado nativo y con los que interactuas desde JS. Ionic tiene una sección en su documentación con todos los plugins disponibles. Es difícil encontrar algo que no esté cubierto.

      La estrategia de react native es similar

      • Pepe Pepe

        Muchas gracias por la respuesta Enrique. ¿No penaliza, a efectos de velocidad de respuesta, esa dependencia de un plug in a la hora de ejecutarlos? Gracias de nuevo.

      • Enrique Oriol Enrique Oriol

        Si el plugin está bien hecho, no debería.

  4. Pepe Pepe

    Mil gracias Enrique. Un saludo.

Deja un comentario