Las expectativas fallidas con React Native que te harán plantearte si usarlo o descartarlo para tu app

Que Airbnb haya dejado de ser un ejemplo de startup utilizando React Native nos hace preguntarnos si las expectativas que depositamos sobre esta tecnología son correctas. Como reflexión podemos revisar la decisión de Airbnb, duramente meditada. Prueba de ello es la serie de blog posts que acompañaron el anuncio, explicando las razones desde lo más técnico a cultural.

Es un excelente aprendizaje de cómo un equipo técnico con unas dimensiones y unas ciertas expectativas asume una nueva tecnologías y, posteriormente, se ve obligado a descartarla. Con las consecuencias que eso conlleva. Recordemos que React Native no es una simple librería o framework sino que tiene otras implicaciones que pueden modificar la forma de trabajar o hasta la cultura de un equipo de desarrollo.

Airbnb no ha sido la única compañía que ha anunciado el abandono de React Native, a los pocos días lo hizo Udacity, publicando un riguroso post con sus razones también. Mencionando muchos de los quebraderos de cabeza con los que nos hemos encontrado algunos de nosotros intentando introducir React Native en una aplicación ya existente. En este caso, era un equipo reducido de 4 desarrolladores el que tomaba la decisión, en contraposición a los casi 100 ingenieros de Airbnb.

Ni Facebook se libró del rumor que incluso ellos estaban abandonando parte del desarrollo React Native a favor del nativo en Android e iOS, al poco tiempo lo desmintieron rotundamente. En su keynote de F8 mostraron como lo usan en diversas partes de la app como blood donations, crisis responses, los atajos de gestión privacidad o wellness checks.

Los factores para adoptar React Native suelen ser algunos de estos:

• Poder avanzar rápido. Las necesidades de una startup en pleno crecimiento y evolución demandan poder desarrollar rápido. Y más si es en mobile. La carencia de desarrolladores y la “duplicidad” en cierta forma de desarrollos en Android e iOs.
• Escribir el mismo código sólo una vez, en lugar de replicarlo en cada plataforma casi prácticamente. Aquí hay que distinguir entre empezar de cero una feature/app en React Native o tener que convivir con código de Java/Kotlin y Objective-C/Swift de por medio.
• Mejorar la experiencia de desarrollo. En el desarrollo mobile los tiempos de compilación, incluso algunos IDE como Xcode no dan una experiencia buena. Por eso, React Native promete mejorar la calidad de vida de los desarrolladores o al menos los tiempo de compilación
• Experiencia en javascript y desarrollo web. Disponer de un equipo con experiencia en frontend y no disponer de suficientes desarrolladores móviles es un razón de peso, más si ya en la web se está usando React.
• Atraer desarrolladores interesados en una nueva tecnología. Aunque Android e iOS sigan siendo tecnologías punteras, muchas empresas ven React Native como una forma de atraer gente interesada en nuevas formas de trabajar y con una tecnología, ojo, que viene de Facebook. Probablemente no sea uno de los mejores reclamos ni tampoco fácil para los recruiters, pero no sería la primera vez que veamos adoptar una nueva tecnología guiados por el marketing.
• Las historias de éxito de algunas compañías que lo están usando: Airbnb era una de ellas, pero tranquilo quedan muchas más.

Quebraderos de cabeza con React Native

El mayor quebradero de cabeza sufrido por Udacity y Airbnb es que no es tan fácil el atribuido lema de “write once, run everywhere”. Sobre todo porque ellos ya disponían de una gran cantidad de funcionalidades desarrolladas en nativo. Pero lo más importante de eso es que la parte más core de la aplicación debía ser nativa y comunicarse con React Native. Algo nada trivial que no funciona del mismo modo según la plataforma y requiere un esfuerzo extra y nada trivial.

Airbnb dispone de un gran número de ingenieros para poder crear la infraestructura necesaria. Lo que podría parecer a simple vista que React Native simplificaría, no fue así. Tampoco que debido a la inmadurez de React Native durante el tiempo que lo ha usado Airbnb haya tenido que parchear ciertas cosas. Llevandoles a mantener un fork con más de 50 commit por delante. Cada actualización de versión se hacía más compleja, además de amplio esfuerzo en construir librerías para adaptar sus necesidades a React Native.

Por el camino como detallan en el tercer post de la serie van otras piedras en el camino:

• Los problemas del tipado de JavaScript. Suplidos con TypeScript a duras penas por temas de compatibilidad, aunque posteriormente resueltos. Facebook siempre impulsó Flow.
• El tamaño extra que añade React Native a las aplicaciones que ya tienen código nativo. Entorno a 8-12 MB algo que para algunos mercados es un gran problema.
• La imposibilidad de crear builds de Android 64-bit. Un problema para usar ciertas librerías también ya metidas en el proyecto. La issue sigue abierta.
• Los tiempos de inicialización y renderización de entre 280 ms (iOs) y 440 ms(Android). O los problemas entre transiciones en Android lo que llevó a meter un delay de 50 ms para evitar problemas
• Tuvieron que evitar usar gestos complejos en pantallas creadas con React Native. Lo que llevó a trabajar en la unificar API de ambas plataformas en react-native-gesture-handler.
• Actualizar React Native ha sido problemático durante estos dos años. Sobre todo de Native 0.43 a 0.49, ya que usaba React 16 en beta.
• Airbnb debe cumplir con la suficiente accesibilidad en todas sus funcionalidades lo que les llevó a modificar ciertas cosas de React Native en su propio fork.
• Tal como comentaba Udacity, incorporar React Native requiere actualizar algunos procesos en CI que lo hacen más complejo y pesado. Incrementando el peso de las build de media un 20%, además de introducir más paso y dependencias.
• La fragmentación de dispositivos (sobre todo en Android) provoca que haya que hacer modificaciones en ciertos componentes React Native, hasta al punto de tener que crear custom component como relata Udacity, además de un mayor esfuerzo en el testing. Nada nuevo en el ecosistema de Android pero que React Native ni soluciona ni minimiza, en ocasiones todo lo contrario.
• El mantenimiento del código resolviendo problemas de UI o de compatibilidad llevó a los equipos de Android e iOS a trabajar en branch distintos. Lo que llevó a un divergencia más que la esperada uniformidad de ambas plataformas.

Construyendo un equipo cross-platform

Uno de los aprendizajes que más provecho se puede extraer del relato de Airbnb sobre React Native es la parte del equipo. Y es algo que podemos aplicar a cualquier decisión técnica que tengamos que tomar en el seno de un equipo. No es simplemente un lenguaje, una librería o un framework. Hay ciertas decisiones, como en este caso de React Native, que puede afectar a la forma de trabajar al equipo de desarrollo, incluyendo al producto y diseño, por supuesto.

React Native está polarizado, se nota hablando con desarrolladores de Android e iOs. La causa principal es que esa “bala de plata” no funciona de la misma forma en cada plataforma ni los retos ni errores a superar son los mismos. Dependiendo de la experiencia tenida, puedes llevarte una opinión u otra. Claro que no todos construimos las mismas aplicaciones ni son igual de complejas ni tienen los mismos retos tecnológicos.

Una de las primeras realidades que puedes encontrarte construyendo ese ansiado equipo cross-platform es que vas a seguir necesitando expertos en las tres plataformas. Tanto en el hecho de mejorar la experiencia con algunos elementos custom.

No sólo porque el diseño sea distinto por plataforma, sino que React Native tiene algunos comportamiento por defect en algunas situaciones como la renderización de textos, el uso del teclado o las propias Activities que tendrás que cambiar. Y sin hablar de la parte del debugging cuando entras en las profundidades de JavaScript-React y su relación del entorno nativo. No todos los desarrolladores están los suficientemente preparados para eso.

Un hecho curioso que remarca Airbnb fue como les afectó en la contratación de ingenieros. Muchos desarrolladores Android o iOS dudaban de entrar a formar parte de una empresa que apostaba tan fuerte con React Native.

La división de equipos también fue compleja. Cada codebase estaba dividido entre nativo (Android e iOS) y React Native. Compartir lógica de negocio, modelos, estados, etc… era cada vez más complicado y muy poca gente era capaz de entender el flujo completo de todo. Compartir código entre la web y móvil era el objetivo pero dejo de ser el beneficio real, ya que debía ser usado y mantenido de forma independiente.

Todo depende si tu aplicación empieza de cero en React Native o es híbrida (Android/iOS)

No es lo mismo desarrollar una aplicación cross-plataform desde cero a integrar código React Native. Dicho esto y teniendo en la cabeza los problemas que tuvieron Airbnb y Udacity: esos son tus riesgos. Ahora bien, todo depende de ti y el tipo de aplicación quieras construir.

1. Si quieres construir una app desde cero en React Native, dónde la mayor parte del código Javascript

Adelante, quizás esta sea la situación ideal. Muchas startup a día de hoy en sus primeros meses ya no necesitan contar con un programador Android y otro iOS. Con una app 100% React puedes construir un buen MVP que funcione en ambas plataforma Para ello debes conocer todo el ecosistema de React Native, aqui un buen roadmpa para ello. Siempre y cuando tu desarollo no se salga de lo convencional.

Siempre me guardaría bien las espaldas con un equipo de frontend que maneje ampliamente JavaScript. Con eso puede ser suficiente para tener una gran experiencia con React Native, sin ni siquiera tocar XCode o Android Studio.

2. Tienes ya un aplicación relativamente compleja en Swift/Objective-C o Java/Kotlin

Este es un claro campo minado donde una aplicación existente tenga que sufrir numerosos cambios para dar el primer paso con React Native: problemas de compatibilidades con librerías, gestionar repositorios aparte, migrar funcionalidad o intercomunicar la capa de negocio o dominio. Todo el tipo de problemas con los que Airbnb y Udacity se han enfretado.

Tu equipo actual tendrá que aprender una nueva tecnología, o quizás el conocimiento de algunas funcionalidades deban dividirse entre expertos en JavaScript y Java/Kotlin, por ejemplo. Además de tender a separar el código de la app de 3 repositorios como mínimo. Además de tener que abordar problemas similares a los anteriormente relatados para mantener la coherencia de la app con partes 100% nativas y otras React Native. Estas serías navegaciones, layout, comunicación de partes dominio y vista, etc..

En definitiva, React Native depende mucho de tu tipo de aplicación y tus aspiraciones. Con las experiencias de Udacity o Airbnb podemos ver reflejada la realidad no tan perfecta de una tecnologías prometedora pero no perfecta para todos.