Componentes Web y aplicaciones híbridas: ¿presente y futuro de las apps móviles?

La tendencia en las apps móviles tiene cada vez más carácter web y menos de nativo.

You can also read this article in English.

Esta afirmación no está solo influida por mi background, mayormente web tanto en back-end como en front-end, sino por una serie de razones que explicaré a lo largo de este artículo, como la propia evolución tecnológica de software y hardware de los móviles, o el cambio de tendencia de los usuarios, que cada vez instalan menos aplicaciones.

Aquellos “maravillosos” años

Allá por el 2003, cuando los navegadores eran dispares y algunos ni siquiera seguían los estándares W3C, los desarrolladores tuvimos que convertirnos en especialistas del ‘parche’ para que una misma app web pudiera usarse y verse aceptablemente en las diferentes versiones de Internet Explorer, pero también en Netscape, Firefox, Safari, Opera, etc…

Entonces éramos conscientes de que la mayoría de los navegadores no se actualizaban de forma automática, por lo que usábamos frecuentemente ficheros CSS iefixes u otros hacks, y éramos más conservadores a la hora de innovar, ya que había que desarrollar web apps compatibles hasta con Internet Explorer 5, que era de los más utilizados y el que menos estándares seguía.

Emancipación de la web

Esto fue cambiando de forma progresiva pero imparable afortunadamente:

• Los navegadores se unieron al estándar de la W3C, incluyendo el IE.
• Su rendimiento se incrementó en un espacio de tiempo relativamente corto, impulsado por nuevos competidores como Chrome.
• Apareció HTML5 y con él un sin fin de posibilidades, permitiendo por ejemplo hacer juegos 3D, videoconferencias o chats desde el navegador y posibilitando que los navegadores móviles también pudieran disfrutar de muchas de estas características.
• Javascript se estandarizó, dejando de ser considerado un “lenguaje de juguete” para llegar a un nivel superior.
• Nacieron frameworks y aplicaciones web como GMail o Google Docs, que demostraron que se podían ejecutar vía web aplicaciones que históricamente habían sido de escritorio.

Mi trabajo diario en la parte front-end del desarrollo web pasó de ser algo tedioso y muy poco productivo a ser algo espectacular gracias a estos cambios. Se abrió un nuevo mundo de posibilidades: juegos, vídeos, streaming, tiempo real, geolocalización, toolkits CSS… Un mundo donde cada línea de código que se escribía funcionaba con un 99% de probabilidad en todos los navegadores modernos, incluyendo navegadores móviles, y con un tooling espectacular gracias a los debugger e inspectores de JS y CSS.

Hello mobile world!

No soy reacio a aprender otras tecnologías, así que en 2010 me introduje en el mundo de las apps móviles y sentí una gran decepción al darme cuenta de que era como volver al horrible pasado: Si queríamos que la app fuera usada por muchos usuarios con dispositivos móviles diferentes, teníamos que desarrollar de forma distinta para Android, IOS, Windows Phone y BlackBerry. Nunca he llegado a probar herramientas propietarias como Xamarin, por lo que desarrollar para las distintas plataformas generalmente significaba multiplicar los desarrollos de apps.

Además la depuración volvía a ser tediosa ya que algo que funcionaba en un móvil podría no funcionar en otro diferente, no sólo por el sistema operativo, sino por el simple hecho de tener una pantalla de tamaño diferente. Los emuladores iban realmente lentos por lo que el hecho de probar con el móvil real te hacía tener que comprar una serie de móviles o ir probando con aquellos que estaban a tu alcance.

Inmersión en ionic

Pasado algún tiempo los dispositivos móviles tenían CPUs suficientemente potentes y los navegadores eran lo suficientemente modernos en casi todos ellos por lo que a principios del 2016 opté por investigar aplicaciones híbridas. Probé ionic y me gustó mucho la experiencia por los siguientes motivos:

• La velocidad de desarrollo se incrementó muchísimo, en gran parte porque podía aplicar la mayoría de mis conocimientos del ámbito web. El incremento se multiplica si tienes en cuenta que prácticamente todo tu código es compatible con iOS, Android y Windows Phone.
• El 99% de lo que se programaba podía testearse desde Chrome simulando las pantallas de los dispositivos y resultó que la inmensa mayoría de veces, al probar en los móviles reales, la experiencia de usuario era igual a lo esperado. ¡Incluso cuando probabas con el móvil podías usar el inspector del navegador para cambiar estilos en tiempo real!
• El punto anterior implicaba que podíamos cambiar de iOS a Android o Windows Phone en un segundo. Esto era muy importante porque nos permitía casi asegurar que el código que acabábamos de escribir funcionaba en todas las plataformas sobre la marcha.
• La gran mayoría de animaciones, scrolls, menús que se despliegan, gestures, etc. iban fluidos. Recuerdo desarrollar un MVP de aplicación de streaming que incluía pantallas de grabación de vídeo y de streaming, con chats en tiempo real, tipo Periscope, y obtener un resultado bastante aceptable. ¡Nadie notaba que era una app híbrida!.

Sin embargo, no todo en el mundo de ionic fue positivo:

• El tiempo de carga de las apps era enormes, en torno a los 12 segundos. Esto fue mejorando a medida que se iba acercando la 2.0 de ionic y de angular, pero no bajaban de 5 segundos en un Nexus 5X.
• En dispositivos antiguos se notaba la velocidad de ejecución y el menor soporte de HTML5 de los navegadores que se embebían en el WebView. Para dar soporte a móviles con navegadores no tan modernos tuve que usar el WebView de CrossWalk. Sin embargo esto implicaba un extra de unos 12 megas en el tamaño de la app, ya que dentro se incluía el motor de renderizado de Chromium.
• Había un pequeño porcentaje de pantallas, dependiendo de la app, que tenían que acceder a partes del dispositivo para los que el estándar HTML5 no daba soporte, o los navegadores no incluían, y había que recurrir a plugins Cordova. Esta parte volvía a ser tediosa, sobre todo por el ciclo de codificar y probar.

En resumen: para el desarrollador (sobre todo de ámbito web) la productividad utilizando ionic era excelente, muy superior a la nativa, y la cuota de usuarios potenciales que se alcanzaba era altísima.

Sin embargo para el usuario final, si nos ponemos estrictos y la app es compleja, tenía un tiempo de arranque muy elevado y en alguna pantalla crítica podía requerir que usaras componentes nativos para optimizarla.

Para ser honestos, ionic ha avanzado bastante desde entonces, como se demuestra en su app Pacifica (en Google Play y Apple Store), o MarketWatch (en GooglePlay y Apple Store), pero no he podido seguirlo de cerca desde que se acabaron esos mini proyectos de prototipos en los que estaba involucrado.

Vuelta al mundo nativo con React

Tras esta experiencia, tuve la suerte de poder afrontar otro proyecto de app y decidimos hacerla esta vez en React Native, que se vende como una tecnología que permite desarrollar apps nativas en móvil, funcionando en Android y iOS.

La experiencia fue dispar: Por una parte es cierto que la app funciona en varias plataformas y que escribes Javascript (JSX concretamente), pero eché en falta la productividad que conseguía en las apps híbridas, ya que a menudo el ciclo de desarrollo era muy lento. Era necesario probar con emulador o dispositivo real por lo que a veces la pantalla se quedaba blanco. Además para mostrar el error debías activar el debugger, que hacía el ciclo de desarrollo bastante más lento, con esperas de varios segundos desde que hacías click hasta que respondía la app.

Por otra parte el inspector de estilos era muy pobre y no te permitía hacer cambios sobre la marcha ni saber el origen de los estilos que están aplicados para cambiar las fuentes. Tampoco tenías la potencia que actualmente permite CSS. Por tanto el workflow de probar en el inspector hasta encontrar el estilo apropiado para colocarlo en los ficheros de estilo aquí no tiene sentido.

Otras razones por la que sentía que React Native mermaba la productividad son:

• No permitía hacer el cambio de plataforma en un segundo, como en híbrido. Si querías comprobar en iOS lo que acababas de probar en Android, debías usar un Mac con XCode, desconectar tu Android y conectar tu iPhone, o lanzar otro emulador).
• A menudo un fallo en tu código, o guardar antes de tener terminado el cambio, hacía que la app quedara en un estado inconsistente del que no podías salir si no recompilabas todo el bundle JS, cosa que tarda entre 30 segundos y un minuto. Cuando el hot reloading funciona, generalmente la espera es de sólo 2–3 segundos.
• No era fácil la depuración de las peticiones al back-end (por ejemplo mediante REST), ni siquiera instalando react-native-debugger.
• No existían librerías de componentes tan conseguidas como ionic y la personalización de ellas era más tediosa por el pobre inspector. Yo he probado NativeBase y me pareció de las más completas.

Web components y el futuro de la tecnología móvil

Si bien es cierto que Apple está frenando el avance de las Progressive Web Apps (PWAs), entre otras cosas para controlar su App Store, es perfectamente viable hoy día realizar aplicaciones híbridas casi de cualquier tipo donde el usuario no sepa diferenciar una app nativa de una que no lo es.

Además de la ya mencionada PWA, un sin fin de tecnologías como Electron, Ionic, React, Vue, etc., así como algunos estándares que van añadiéndose al HTML5, me atrevería a afirmar que la tendencia en las apps móviles tiene cada vez más carácter web y menos de nativo.

Un estándar que puede ser clave aprovechando toda esta sinergia web es la de Web Components, donde el navegador se hace cargo de la parte común de casi todos los frameworks de presentación web respecto a renderizado de componentes, consiguiendo que la velocidad de arranque de una app móvil realizada con Web Components aumente drásticamente.

Se pueden encontrar ejemplos de las mejoras que consiguen los Web Components out-of-the-box en artículos como Simplifying Performance with Web Components de Marcus Hellberg o en conferencias como Web Components: Just in the Nick of Time , a cargo de un developer de Google Chrome en la Polymer Summit este año. También es posible probar online la experiencia nativa en la PWA llamada Cheese.

Los resultados que observó el equipo de Ionic al pasar sus componentes a web components fueron espectaculares

Al pasar a Web Components consiguieron bajar el tiempo de carga de una aplicación de 5 segundos a uno, con lo que la mayor desventaja de las aplicaciones híbridas desaparece, manteniendo todas las ventajas para el desarrollador y añadiendo un premio adicional: permitir el uso de dichos componentes en cualquier framework JS como React, Vue.js, Ember, etc.

El hecho de tener una librería de componentes agnóstica aportará, al que probablemente sea el mejor toolkit UI HTML para aplicaciones móviles, miles de desarrollos nuevos de otros frameworks.

Y otro de los temas que podían resultar inquietantes: el soporte de los Web Components en navegadores móviles parece estar superado, como se deduce de la conferencia Future, Faster: Unlock the Power of Web Components with Polymer de Google I/O ’17, donde indican que más de 1.000 millones de dispositivos móviles los soportan actualmente.

Mi experiencia con frameworks de desarrollo de hybrid apps con soporte de Web Components

Cuando me dispuse a investigar el estado actual de ionic, comprendí que aún estaban en un estado alpha, y aunque no tardarían demasiado en tener la versión final, ya existía otro framework popular que tenía todos sus componentes funcionando en web components: OnSen UI.

Dicho framework tiene bindings para React, Angular y Vue.js y varias aplicaciones en el mercado como Evento. Además dispone de una aplicación de demo para testear el toolkit. Dado que Angular tiene con diferencia el tamaño del JS mayor de todos los bindings y que mis compañeros de Commite tienen mucha experiencia en React (aunque a mí me gusta incluso más Vue.js) decidí continuar utilizando esta tecnología una aplicación de predicción meteorológica existente en una versión antigua de OnSen UI. Así la refactoricé y adapté a la última versión, añadiéndole poco a poco más funcionalidades.

Mi experiencia al desarrollar esta app móvil me llevó a las siguientes conclusiones:

• Los tiempos de espera son nulos, y no porque haya una serie de tooling como webpack que por websockets sólo compile y transmita los componentes que se van modificando en el IDE. Es prácticamente instantáneo incluso la construcción del bundle entero, así como el refresco del navegador con Control+R.
• El cambio de plataforma móvil iOS/Android es instantánea simplemente al cambiar el user-agent o el dispositivo del device toolbar en el inspector del navegador.
• El inspector del navegador funciona perfectamente: Cambio de estilos WYSWYG sobre la marcha, depuración de las peticiones REST en la pestaña Network, incluso el store de la app y las acciones usando Redux DevTools
• El código resultante es muy legible y conciso (podéis verlo aquí).

Otro aspecto a tener en cuenta es que al fin y al cabo estamos hablando de una web, por lo que se puede compartir el resultado final mediante un simple enlace: https://msaelices.github.io/react-onsenui-redux-weather/demo.html

Por último, pero no menos importante, de cara al usuario final la experiencia al usar la app me parece bastante fluida, con tiempos de carga de un sólo segundo en un Xiaomi Mi6 sin percibir en ningún momento que no es es una app nativa. De hecho fueron tan buenas las sensaciones que me decidí a repetir la misma app en el que se está convirtiendo en mi framework JS favorito, Vue.js: https://github.com/msaelices/vue-onsenui-weather. La demo online la tenéis aquí: https://msaelices.github.io/vue-onsenui-weather/

¿El resumen de esta última experiencia utilizando web components? He vuelto a disfrutar de la programación móvil.

Pienso que van a comenzar a llegar sucesos fascinantes en el mundo móvil y creo que van a ir de la mano de novedades importantes en la web como lit-html o WebAssembly.

Y vosotros: ¿Qué tecnologías usáis para desarrollar para el móvil?, ¿cuál es vuestra experiencia?