¿Es React Native la mejor solución para tu próximo gran proyecto?

Airbnb ha dejado de ser un ejemplo de startup que utiliza React Native (RN) y esto podría ser un indicador de que no siempre las expectativas que tenemos con un stack de desarrollo son las correctas. La decisión de Airbnb fue duramente meditada, plasmada en una serie de posts en su blog explicando las principales razones. A fin de aprendizaje, sirve leer los posts ya que es la muestra de cómo un equipo técnico de grandes dimensiones y expectativas enormes asumen nuevas tecnologías, para luego descartarlas.

No sólo ha sido Airbnb que ha desistido de utilizar RN, Udacity también anunció su despedida con este framework, explicando muchos de los problemas con los que los desarrolladores nos topamos al momento de integrar alguna funcionalidad en específico en una aplicación existente. 

Algunos de los factores más comunes para adoptar este framework suelen ser:

• Avanzar rápido: un desarrollo rápido que apoye a las startups a llegar a sus metas y producir ganancias de una manera más rápida y con reducciones de costo, como en recurso humano.
• Write once, run everywhere: escribir el mismo código y replicarlo en cada plataforma.
• Mejorar la experiencia de desarrollo, que algunos IDEs como Android Studio o Xcode dificultan con sus amplios tiempos de compilación.
• Desarrolladores web: poder contar con que tu mismo equipo de desarrollo web, será tu equipo de desarrollo móvil, que aplica las mismas técnicas y tecnologías basadas en Javascript.
• Historias de éxito: con muchas empresas que utilizan el framework.

El punto más hablado por Airbnb (y Udacity) es que no es tan fácil el tema de escribir código una sola vez y luego replicarlo en plataformas distintas. El punto clave es que ambos contaban ya con una gran cantidad de funcionalidades en nativo y que además el core de sus apps debían ser nativas y comunicarse con RN, demandando esfuerzos para nada triviales. Algunas de las piedras de tropiezo de Airbnb son:

• Problemas con TypeScript: por temas de compatibilidad, que siempre lograron resolver sin embargo.
• El tamaño extra que RN añade a los builds: para las aplicaciones que ya tienen código nativo, RN añade alrededor de 8-12 MB más.
• Es imposible crear builds de Android 64-bit.
• Tiempos de inicialización y renderización.
• Evitaron utilizar gestos complejos en pantallas creadas con RN.
• Actualizaciones de RN, debido a las actualizaciones mismas de React 16.
• Airbnb modificó muchas cosas de RN en su propio fork.
• Mantener el código con relación a temas de UI o compatibilidad forzaron a la compañía a integrar equipos de Android y IOS y trabajar en branch distintos.

Algo a tomar en cuenta y, muy en cuenta, es el aspecto del equipo, que debería influir en cualquier decisión técnica que se tenga que tomar. No es algo tan simple como un lenguaje, librería o framework. Existen decisiones que pueden afectar la forma de trabajo del equipo de desarrollo, incluyendo todos los aspectos desde el diseño hasta el producto.

Y es que no sólo tras los relatos de Airbnb, sino que por experiencias con mi equipo de desarrollo, es factible decir que RN está polarizado: existe una clara brecha entre IOS y Android, aunque la filosofía de RN sea "write once, run everywhere". RN no funciona de la misma forma en cada plataforma, y por mucho, los errores y contratiempos son distintos. Sin embargo, no para todas las aplicaciones sucede este fenómeno. No todas las aplicaciones son igual de complejas, ni presentan los mismos retos.

El punto clave, a mi parecer, es el siguiente: todo depende si la aplicación empieza desde cero con RN o si ya tiene un desarrollo nativo propiamente en Android o IOS. Claramente no es lo mismo desarrollar desde cero a integrar código. Si lo tuyo es construir una aplicación desde cero con RN, mi opinión es que, adelante, ve a crear aplicaciones increíbles. No necesitas un equipo con programadores Android y IOS, para nada. Solo basta comprender el ecosistema de RN y saberse todos los trucos de los que dispone.

Si ya tienes una aplicación algo compleja en Swift/Objective-C o Java/Kotlin, estarás realizando una integración de código y no un desarrollo puro en RN. Tu aplicación sufrirá muchos cambios. Tendrás numerosos problemas de compatibilidades, gestiones de repositorios por aparte, migración de funcionalidades y más.

RN depende del tipo de aplicación que construyas. Por experiencia, vale con todo, pero desde cero. RN es sumamente poderoso, e increíble. Pero con un stack ya definido nativamente, la integración del framework pierde su poder, y pasa a crear problemas en vez de solucionarlos. RN es tu mejor opción para startups que necesitas que sucedan ayer.

- Brolius