Frameworks

Con la aparición de los smartphones como los conocemos actualmente surgieron dos sistemas operativos utilizados en prácticamente todos los dispositivos a nivel mundial: iOS y Android. Para el desarrollo tradicional en dichos sistemas utilizamos los lenguajes nativos que estos incorporan, a saber, Objective-C y más recientemente Swift para los dispositivos del sistema proporcionado por Apple y Java en el caso del que nos proporciona Google.

Sin embargo, con la aparición de HTML5 y las características que introdujo CSS3, especialmente las media-queries, se demostró que era posible crear aplicaciones web con una visualización cambiante según el dispositivo, reduciendo la necesidad de crear aplicaciones orientadas únicamente a dispositivos móviles en muchos casos. Esta potencia y las características que este desarrollo proporcionaba, junto con la aparición de los modernos frameworks de JavaScript, llevó a los desarrolladores a preguntarse ¿Y si fuera posible ir más allá y reusar el código de nuestra web para crear nuestras aplicaciones móviles dedicadas a medida?.

El desarrollo híbrido hasta la actualidad

Basándose en las ideas previamente comentadas, a partir del 2010 comienzan a aparecer de forma comercial ciertos frameworks que suponen el germen del estado actual del desarrollo híbrido. Uno de los primeros es Titanium, de Appcelerator, que proporciona una API para desarrollar aplicaciones móviles usando JavaScript puro, sin embargo, este producto igual que otros similares de esta época inicial presentan aún ciertas incomodidades:

• El desarrollo en esta plataforma carece de scope por fichero, lo que significa que cualquier cambio de variable o cualquier variable no aislada en cualquier lugar de cualquier fichero puede interaccionar de forma no deseada con cualquier otra en cualquier otro fichero.

• No es un framework como tal y por tanto no hay ninguna orientación típica como MVC o MVP, lo que dificulta la coordinación del trabajo con un equipo a menos que se siga un flujo de trabajo muy estricto y completamente personalizado por proyecto.

• Es necesario, muy frecuentemente, realizar cambios condicionales dependiendo de si el dispositivo es iOS o Android, y en muchas ocasiones la visualización no es homogénea entre ambos sistemas operativos pese a que los dispositivos tengan pantallas similares.

Para solucionar esto, una vez aparece el famoso framework Angular.js, también aparecen nuevas soluciones como el, aún ampliamente usado, framework Ionic, que combina el poder de Apache Cordova (Un generador de aplicaciones híbridas de la Apache Foundation) con la potencia del framework de Google, permitiendo así por primera vez generar aplicaciones híbridas basadas en JavaScript con un flujo de trabajo y una API prácticamente equivalentes entre un proyecto web y un proyecto mobile.

Sin embargo, las soluciones hasta este momento, aunque cada vez más numerosas y con mayor soporte de conexión con las funciones de sistema de los dispositivos, siguen siendo mucho más lentas que las aplicaciones nativas debido a varios factores:

• Las aplicaciones híbridas, a diferencia de las nativas, no utilizan un sistema de renderización nativo, es decir, por ejemplo, en el caso de Android no producen vistas procesables por el sistema en formato XML, sino que los sistemas operativos ofrecen un componente para el sistema llamado WebView, que como su nombre indica está orientado a renderizar una web o en su defecto cualquier árbol DOM como si de un navegador se tratase. Por tanto, el rendimiento de la aplicación está limitado al rendimiento de la implementación de dicho componente, y aunque ahora está realmente optimizado, en las primeras versiones de estos sistemas móviles este componente tenía un rendimiento realmente deficiente y no admitía todas las características completas de HTML5 y CSS.

• En el caso de Android, y antiguamente en el de iOS, el sistema no proporciona una implementación integrada del intérprete de JavaScript, lo que significa que, además de que cada aplicación deba de incorporar su intérprete, el rendimiento no es por supuesto ni cercanamente parecido en ambos casos.

Por este motivo, pocos años después de la aparición de los frameworks puramente híbridos, comienzan a aparecer los (mal) llamados “frameworks nativos”, cuyo secreto es ofrecer el mismo ecosistema existente (Utilización de un framework JavaScript popular y de APIs de acceso a las funcionalidades) pero que internamente use un conjunto de componentes para la renderización que se “compilen” a vistas nativas del sistema de forma que la aplicación no necesite vivir como parte de un WebView y pueda ser tratado en gran parte por el desarrollador como una aplicación nativa del sistema.

Los frameworks híbridos más populares

A fecha actual, ya podemos encontrar un gran número de soluciones para desarrollo de aplicaciones híbridas que tienen diversas orientaciones y soluciones perfectamente adaptadas a según el tipo de producto que se desee desarrollar. Por ello mismo, y por sintetizar, en este artículo mostraremos tres de los frameworks más interesantes y populares del mercado que tienen la particularidad de cubrir distintos tipos de necesidades a la hora de generar nuestras aplicaciones móviles:

Ionic Framework

Ionic es quizás uno de los frameworks híbridos que más popularidad han alcanzado con el tiempo, popularidad que inicialmente aumentó debido a la adición de Angular como framework JavaScript para el desarrollo, lo cual facilitaba mucho portar proyectos ya existentes o desarrollarlos desde cero.

Internamente, y a la hora de generar nuestra aplicación móvil, Ionic utiliza Capacitor (Inicialmente llamado Apache Cordova) como librería para transpilar la aplicación y lograr un compilado en Android o iOS que permita renderizar nuestra aplicación en la implementación nativa de WebView de nuestros dispositivos. Además, el ecosistema de Ionic es muy rico, lo que nos permitirá, ya sea desde las propias funciones del framework o a través de paquetes externos, acceder a las APIs nativas del dispositivo como si de una aplicación nativa se tratase.

Sin embargo, y como comentábamos al inicio de esta sección, la solución propuesta por Ionic está orientada a unas necesidades concretas de desarrollo, y esto se debe a que tampoco está carente de inconvenientes:

• Renderizar en un WebView siempre será más lento que renderizar de manera nativa, ya que será necesario pintar y actualizar un árbol DOM sobre este componente, y a instancias finales el rendimiento de la aplicación dependerá directamente de la implementación de WebView del dispositivo en el que se ejecute. Esto en muchos casos no será un impedimento, pero podría ser poco acertado para ciertos proyectos que llevemos a cabo que puedan ser intensivos en recursos.
• Por el mismo hecho de no usar componentes nativos, cualquier aplicación que queramos desarrollar que deba de hacer un uso intensivo o necesario de los recursos del sistema operativo puede llegar a ser una tarea titánica (Véase por ejemplo cualquier juego). También en algunos casos ciertos conectores para ciertas APIs muy novedosas podrán no encontrarse disponibles, y crearlos implicará conocimientos avanzados tanto de iOS como de Android (Contradiciendo prácticamente el uso que buscamos con el framework).

React Native

En el otro lado de la baraja respecto a Ionic nos encontramos a React Native; Un framework de desarrollo híbrido cuya novedad radica en renderizar de forma nativa en cada sistema.

El acercamiento de React Native difiere de Ionic de una manera realmente sencilla. En vez de permitir generar una aplicación utilizando HTML, CSS y JavaScript, este framework limita el desarrollo al uso de React con una renderización en su lenguaje de renderizado habitual, JSX, y basado en componentes propios que soportan CSS inline. De esta manera, React Native puede, a la hora de renderizar, transpilar este código en vistas nativas de cada uno de los sistemas operativos móviles correspondientes, creando aplicaciones de visualización 100% nativa que sin embargo ejecutarán su lógica a través de un intérprete de JavaScript integrado.

La ventaja más obvia de este acercamiento es que las aplicaciones creadas con React Native tienen un rendimiento cercano a cualquier aplicación nativa de Android o iOS, pero sin embargo también sacrifica ciertas características por el camino:

• Al renderizar de manera nativa, habrá que tener en cuenta las diferencias entre las transpilaciones a unas y otras vistas o componentes de cada sistema, es decir, la visualización podrá ser en general irregular y en muchas ocasiones será necesario hacer implementaciones separadas para cada sistema operativo, aumentando así el tiempo de desarrollo.

• Al no renderizar en HTML ni CSS, reaprovechar una aplicación web para reconvertirla en aplicación móvil será mucho más dificultoso que con Ionic, aunque la lógica pueda permanecer intacta será necesario adaptar tanto el HTML y el CSS a la estructura de componentes proporcionada por el framework y tener en cuenta sus posibles limitaciones.

• A pesar de tener un rendimiento cercano a una aplicación nativa, es necesario entender que la ejecución debe de pasar por un intérprete de JavaScript, y por tanto siempre será menor a una implementación similar en nativo. Además, en el caso de Android, cada aplicación tendrá un peso elevado ya que es necesario incluir un intérprete externo en el empaquetado final.

NativeScript

Nativescript, al igual que React Native, es un producto basado en la creación de aplicaciones híbridas de renderizado nativo que pueden ejecutar aplicaciones JavaScript con acceso a las APIs nativas del dispositivo móvil.

La diferencia principal con React Native radica en que los componentes de renderización son independientes del framework (o no framework) de JavaScript que deseemos utilizar, lo que nos permite realizar, por ejemplo, una aplicación utilizando Angular (Como en el caso de Ionic) pero con una renderización optimizada que se aprovecha del motor nativo de nuestro dispositivo. Además, NativeScript permite usar otros frameworks populares como Vue.js o Meteor, o incluso JavaScript puro si así lo necesitáramos.

Sin embargo, y al basarse en una tecnología similar a React Native, los problemas que presentan son bien parecidos:

• Las aplicaciones también sufren de un bundle aumentado debido a la necesidad de introducir un intérprete y unos paquetes añadidos que permitan acceder a las funcionalidades del dispositivo.
• La capacidad para depurar las aplicaciones está muy poco trabajado en el caso de este framework. Es generalmente difícil de configurar y muchos errores son oscuros o se encuentran escasamente documentados.

Xamarin

Xamarin es una plataforma creada por los desarrolladores del famoso proyecto Mono, una plataforma de desarrollo basada en el framework .NET, pero que a diferencia de Mono fue creado con propósito comercial por Microsoft para ser incluido en su ecosistema de desarrollo.

La principal ventaja de Xamarin es la abstracción casi absoluta de la capa de aplicación, permitiendo crear una app desarrollada en C# que se compila de manera nativa tanto a iOS, Android y Windows (Y dependiendo de la versión, incluso al difunto Windows Phone).

Aunque el rendimiento es muy considerable ya que desde C# se crea un compilable para las aplicaciones y no es necesario un intérprete (Lo que también reduce el peso del bundle), Xamarin también tiene sus pequeños inconvenientes para depende qué proyectos:

• Al no utilizar HTML ni CSS no puede reaprovecharse nada del código de antiguos proyectos web para portarlos a dispositivos, a diferencia de Ionic, NativeScript, o React Native con la lógica JavaScript.

• La plataforma, al ser propietaria de Microsoft, tiene ciertas opiniones que tienden a beneficiar al resto de productos y herramientas de Microsoft por encima de otras opciones Open Source.

El futuro del desarrollo híbrido

El futuro del desarrollo híbrido es aún incierto, muchas voces suenan clamando que el futuro será del muy anunciado (y esperado) Flutter de Google, un framework basado en el joven lenguaje Dart que ya es capaz de crear aplicaciones compiladas tanto móviles (para Android e iOs), web y de escritorio usando únicamente un único código altamente generalizable.

Sin embargo, actualmente, y pese al gran avance del lenguaje en el que se basa (llamado Dart), actualmente las librerías de soporte como las de gestión del estado o inyección de dependencias brillan prácticamente por su ausencia, lo cual fue en parte lo que dificultó la introducción de React Native en proyectos a gran escala en el pasado.

Sin embargo, y sin lugar a dudas, el futuro tiende a abstraerse de las plataformas de despliegue, esto es debido a que las diferentes APIs entre las mismas funcionalidades, así como los diferentes sistemas para compilar, dificultan el acceso a nuestras aplicaciones. Y aunque esto se soluciona en cierta manera por la existencia de las web apps, estas no proporcionan el soporte completo y necesario para todas las características que necesitemos (Por ejemplo, el acceso a disco).

Pero por ahora, y en el más crudo presente, te ofrecemos la oportunidad para formarte en las tecnologías que más lo están rompiendo con nuestros cursos de React Native para principiantes y de Xamarin para principiantes ¡Échales un ojo y no te arrepentirás!