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 caso de start-up usando React Native nos hace preguntarnos si las esperanzas que depositamos sobre esta tecnología son adecuadas. Como reflexión podemos repasar la resolución de Airbnb, fuertemente meditada. Prueba de ello es la serie de weblog posts que acompañaron el anuncio, explicando las razones desde lo más técnico a cultural.

Es un genial aprendizaje de de qué manera un equipo técnico con unas dimensiones y unas ciertas esperanzas acepta una nueva tecnologías y, más tarde, se ve forzado a descartarla. Con las consecuencias que eso acarrea. Recordemos que React Native no es una simple librería o bien framework sino tiene otras implicaciones que pueden alterar la manera de trabajar o bien 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 poquitos días lo hizo Udacity, publicando un estricto blog post con sus razones asimismo. Mentando muchos de los quebraderos de cabeza con los que nos hemos encontrado ciertos de nosotros procurando introducir React Native en una aplicación ya existente. En un caso así, era un equipo reducido de cuatro desarrolladores el que tomaba la resolución, en contraposición a los prácticamente cien ingenieros de Airbnb.

Ni Fb se libró del rumor que aun estaban abandonando una parte del desarrollo React Native en favor del nativo en Android y también iOS, al poco tiempo lo desmintieron tajantemente. En su keynote de F8 mostraron como lo utilizan en distintas unas partes de la aplicación como blood donations, crisis responsees, los grupúsculos de administración privacidad o bien wellness checks.

Los factores para adoptar React Native acostumbran a ser ciertos de estos:

Poder avanzar veloz. Las necesidades de una start-up en pleno desarrollo y evolución demandan poder desarrollar veloz. Y más si es en mobile. La falta de desarrolladores y la “duplicidad” en cierta manera de desarrollos en Android y también iOs.
Redactar exactamente el mismo código solo una vez, en vez de contestarlo en todos y cada plataforma casi. Acá hay que distinguir entre iniciar de cero una feature/app en React Native o bien tener que convivir con código de Java/Kotlin y Objective-C/Swift por el medio.
Progresar la experiencia de desarrollo. En el desarrollo mobile los tiempos de colección, aun ciertos IDE como Xcode no dan una experiencia buena. De ahí que, React Native promete progresar la calidad de vida de los desarrolladores o bien por lo menos los tiempo de colección
Experiencia en javascript y desarrollo web. Contar con de un equipo con experiencia en frontend y no contar con de suficientes desarrolladores móviles es un razón de peso, más si ya en la página web se está utilizando React.
Atraer desarrolladores interesados en una nueva tecnología. Si bien Android y también iOS prosigan siendo tecnologías de vanguardia, 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 Fb. Seguramente no sea de los mejores reclamos ni tampoco simple para los recruiters, mas no sería la primera vez que veamos adoptar una nueva tecnología guiados por la mercadotecnia.
Las historias de éxito de ciertas compañías que lo están usando: Airbnb era una de ellas, mas sosegado quedan considerablemente más.
React fue creada por Jordan Walke, un ingeniero de software en Fb en 2013.Es utilizado intensivamente por Fb y también Instagram

Quebraderos de cabeza con React Native

El mayor quebradero de cabeza sufrido por Udacity y Airbnb es que no es tan simple el atribuido leimotiv de “write once, run everywhere”. Sobre todo pues ya disponían de un sinnúmero de funcionalidades desarrolladas en nativo. Mas lo más esencial de eso es que la parte más core de la aplicación había de ser nativa y comunicarse con React Native. Algo nada trivial que no marcha de exactamente la misma manera conforme la plataforma y requiere un sacrificio extra y nada trivial.

Airbnb dispone de un elevado número de ingenieros para poder crear la infraestructura precisa. Lo que podría parecer a simple vista que React Native facilitaría, no fue de este modo. Tampoco que debido a la inmadurez de React Native a lo largo del tiempo que lo ha utilizado Airbnb haya debido parchear ciertas cosas. Llevandoles a sostener un fork con más de cincuenta commit por delante. Cada actualización de versión se hacía más compleja, aparte de extenso sacrificio en edificar librerías para amoldar sus necesidades a React Native.

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

Los inconvenientes del tipado de JavaScript. Reemplazados con TypeScript difícilmente por temas de compatibilidad, si bien más tarde resueltos. Fb siempre y en todo momento impulsó Flow.
El tamaño extra que agrega React Native a las aplicaciones que tienen código nativo. Ambiente a ocho-doce MB algo que para ciertos mercados es un enorme inconveniente.
La imposibilidad de crear builds de Android sesenta y cuatro-bit. Un inconveniente para emplear ciertas librerías asimismo ya metidas en el proyecto. La issue prosigue abierta.
Los tiempos de inicialización y renderización de entre doscientos ochenta ms (iOs) y cuatrocientos cuarenta ms(Android). O bien los inconvenientes entre transiciones en Android lo que llevó a meter un delay de cincuenta ms para eludir inconvenientes
Debieron eludir utilizar ademanes complejos en pantallas creadas con React Native. Lo que llevó a trabajar en la aunar API de las dos plataformas en react-native-gesture-handler.
Actualizar React Native ha sido conflictivo a lo largo de estos un par de años. Sobre todo de Native 0.43 a 0.49, en tanto que empleaba React dieciseis en beta.
Airbnb debe cumplir con la suficiente accesibilidad en sus funcionalidades lo que les llevó a alterar ciertas cosas de React Native en su fork.
Tal y como comentaba Udacity, agregar React Native requiere actualizar ciertos procesos en CI que lo hacen más complejo y pesado. Acrecentando el peso de las build de media un veinte por ciento , aparte de introducir más paso y dependencias.
La fragmentación de dispositivos (sobre todo en Android) hace que haya que hacer modificaciones en determinados componentes React Native, hasta al punto de tener que crear custom component como narra Udacity, aparte de un mayor sacrificio en el testing. Nada nuevo en el ecosistema de Android mas que React Native ni solventa ni minimiza, a veces todo lo opuesto.
El mantenimiento del código resolviendo inconvenientes de UI o bien de compatibilidad llevó a los equipos de Android y también iOS a trabajar en branch diferentes. Lo que llevó a un divergencia más que la aguardada uniformidad de las dos plataformas.
React Native es más que una librería o bien framework, afecta a la cultura de desarrollo de tu equipo

Prosigue habiendo grandes empresas confiando en React Native, mas Airbnb ha debido descartarlo tras un par de años de intenso desarrollo

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 una parte del equipo. Y es una cosa que podemos aplicar a cualquier resolución técnica que debamos tomar dentro de un equipo. No es sencillamente un lenguaje, una librería o bien un framework. Hay ciertas resoluciones, como en un caso así de React Native, que puede afectar a la manera de trabajar al equipo de desarrollo, incluyendo al producto y diseño, como es natural.

React Native está polarizado, se aprecia hablando con desarrolladores de Android y también iOs. La causa primordial es que esa “bala de plata” no marcha de igual modo en todos y cada plataforma ni los desafíos ni fallos a superar son exactamente los mismos. En dependencia de la experiencia tenida, puedes llevarte una opinión o bien otra. Claro que no todos edificamos exactamente las mismas aplicaciones ni son igualmente complejas ni tienen exactamente los mismos desafíos tecnológicos.

Una de las primeras realidades que puedes localizarte edificando ese ansiado equipo cross-platform es que vas a continuar necesitando especialistas en las 3 plataformas. Tanto en el hecho de progresar la experiencia con ciertos elementos custom.

No solo por el hecho de que el diseño sea diferente por plataforma, sino React Native tiene ciertos comportamiento por defect en ciertas situaciones como la renderización de textos, el empleo del teclado o bien las propias Activities que deberás mudar. Y sin charlar de la una parte del debugging cuando entras en las profundidades de JavaScript-React y su relación del ambiente nativo. No todos y cada uno de los desarrolladores están los suficientemente listos para eso.

Un hecho curioso que remarca Airbnb fue como les afectó en la contratación de ingenieros. Muchos desarrolladores Android o bien iOS vacilaban de entrar a ser parte de una compañía que apostaba tan fuerte con React Native.

La división de equipos asimismo fue compleja. Cada codebase estaba dividido entre nativo (Android y también iOS) y React Native. Compartir lógica de negocio, modelos, estados, etcétera era cada vez más difícil y poquísima gente era capaz de comprender el flujo completo de todo. Compartir código entre la página web y móvil era la meta mas dejo de ser el beneficio real, en tanto que había de ser utilizado y mantenido de forma independiente.

The ability for RN product code to be shared across platforms at Airbnb *in my opinion* was an overwhelming success. Features in RN were often done with zero lines of platform-specific code. In this regard, it WORKED.— Leland Richardson (@intelligibabble) veinticuatro de junio de dos mil dieciocho

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

No es exactamente lo mismo desarrollar una aplicación cross-plataform desde cero a integrar código React Native. Dicho esto y teniendo en la cabeza los inconvenientes que tuvieron Airbnb y Udacity: esos son tus peligros. Ahora bien, todo depende de ti y el género de aplicación desees edificar.

1. Si deseas edificar una aplicación desde cero en React Native, dónde la mayoría del código Javascript

Adelante, tal vez esta sea la situación ideal. Muchas start-up hoy en sus primeros meses ya no precisan contar con un programador Android y otro iOS. Con una aplicación cien por ciento React puedes edificar un buen MVP que funcione en las dos plataforma Para esto debes conocer todo el ecosistema de React Native, aquí un buen roadmpa para esto. Siempre que tu desarollo no se salga de lo usual.

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

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

Este es un claro campo minado donde una aplicación existente deba padecer abundantes cambios para dar el paso inicial con React Native: inconvenientes de compatibilidades con librerías, administrar repositorios aparte, migrar funcionalidad o bien intercomunicar la capa de negocio o bien dominio. Todo el género de inconvenientes con los que Airbnb y Udacity se han enfretado.

Tu equipo actual deberá aprender una nueva tecnología, o bien quizá el conocimiento de ciertas funcionalidades deban dividirse entre especialistas en JavaScript y Java/Kotlin, por poner un ejemplo. Aparte de tender a separar el código de la aplicación de tres repositorios por lo menos. Aparte de tener que abordar inconvenientes afines a los previamente contados para sostener la congruencia de la aplicación con partes cien por ciento nativas y otras React Native. Estas serías navegaciones, layout, comunicación de partes dominio y vista, etcétera.

En suma, React Native depende mucho de tu género de aplicación y tus aspiraciones. Con las experiencias de Udacity o bien Airbnb podemos ver reflejada la realidad no tan perfecta de una tecnologías prometedora mas no idónea para todos.