AirBnB React Native

Artículo

Airbnb ¿por qué abandonó React Native?

Inicio histórico

En los inicios de la compañía, Airbnb era solo una web con su principal fuente de visitas desde dispositivos móviles. Allá por 2012 su equipo de ingenieros pensó que, para atender la fuerte demanda de su base de usuarios desde dispositivos móviles, debía invertir en aplicaciones para dichos terminales. Durante 4 años desarrollaron las aplicaciones de iOS y Android utilizando lenguaje nativo puro.

Sin embargo, en 2016, el panorama se había volcado tanto hacia los dispositivos móviles que su equipo de desarrollo no era capaz de atender semejante demanda en dos proyectos tan diferenciados, con lo que comenzaron a buscas soluciones cross-platform que cubrieran ambas a la vez.

Al estar su web desarrollada con React, y aprovechando el lanzamiento en 2016 por parte de Facebook de React Native tras desarrollar sus propias aplicaciones nativas, Airbnb se lanzó a desarrollar un piloto que acabó siendo lanzado al mercado finalmente como su primera aplicación nativa usando componentes React.

El uso de React Native incrementó rápidamente la velocidad del ciclo de desarrollo de sus aplicaciones, así como su inversion en el desarrollo, soporte e infraestructura del framework.

Abandono

Como hemos visto, Airbnb adoptó React Native hace aproximadamente dos años cuando, relativamente, era una tecnología que acababa de empezar su andadura y apenas estaba probada, pero les produjo un buen resultado.

Sin embargo, el pasado 19 de junio de 2018 sorprendieron a propios y extraños con la noticia de que dejaban de utilizarla para el desarrollo de sus aplicaciones móviles, y cambiaban a desarrollo puro nativo de nuevo.

Ante la sorpresa generalizada, la propia compañía compartió con la comunidad algunas de las razones por las que tomaban esta decisión. Revisemos a continuación, detenidamente, los motivos que la compañía de alquileres turísticos ha esgrimido al respecto:

  • Falta de madurez: debido a que es un framework relativamente nuevo, y a su constante desarrollo Airbnb ha tenido que invertir en el mismo framework para el desarrollo de sus aplicaciones, llegando hasta el punto en el que, por momentos, han tenido que mantener su propio fork del framework de cara a realizar contribuciones y evitar cambios que impactaran sobre su desarrollo.
  • Dinámicamente tipado: JavaScript no es un lenguaje tipado la hora de desarrollar, como ya sabemos, el tipado se realiza en tiempo de ejecución, dinámicamente, lo cual ha sido para ellos la cusa de innumerables problemas a la hora de, por ejemplo, realizar refactorizaciones. Y posibles soluciones de tipado estático en desarrollo como puede ser TypeScript tienen sus propios problemas, en este caso debido al coste de la migración.
  • Inconsistencias entre iOS y Android: a pesar de que este es uno de los puntos fuertes del framework, como decíamos en el pasado artículo de presentación de Raact Native, no es oro todo lo que reluce, y hay pequeños detalles que aún no está pulidos. Como ejemplos mencionan pequeños extractos de código en JavaScript o librerías de terceros, que no son soportados igual de bien en ambos entornos, teniendo de nuevo la compañía que responsabilizarse de ese desarrollo adicional, con lo que ello conlleva.
  • Mantenimiento de tres entornos: los desarrolladores e ingenieros de la compañía se ven obligados a mantener tres entornos diferentes (a saber: React.js, Android, and iOS) dónde deben realizar labores de desarrollo y debug.

Análisis del impacto

Dicho esto, y en cuanto al soporte, recordemos que React Native sigue contando con el apoyo incondicional de Facebook y su otra compañía, Instagram. Decir que carece de apoyo teniendo esos dos gigantes detrás sería faltar a la verdad. Si bien es cierto que el propio Facebook ha tenido que salir públicamente a dar el apoyo necesario a la tecnología, deja muy bien a las claras que la noticia acerca del cambio de parecer de Airbnb ha impactado, pero no supone un golpe mortal al framework, sino sólo un contratiempo, la magnitud del mismo sólo la podremos valorar con el paso del tiempo.

A raíz de este suceso, las grandes preguntas son: ¿significa esto que React Native está acabado? No, definitivamente no, ni mucho menos. Pero, ¿entonces debo dejar de tenerlo en cuenta para mis desarrollos nativos? Tampoco. Me explico.

Ya han pasado meses desde esta noticia, y podemos comprobar que React Native sigue existiendo en el ecosistema de soluciones posibles de cara al desarrollo de aplicaciones nativas, es decir, a corto plazo el impacto ha sido, digamos, moderado a la popularidad del framework, a medio o largo plazo es algo difícil de predecir con la cantidad de tecnologías que surgen nuevas día a día, pero por el momento, a día de hoy, sigue siendo un alternativa viable y muy válida.

Sobre si elegir React Native para el desarrollo nativo de un proyecto, la decisión es muy particular de cada compañía y depende en gran medida del proyecto y sus requerimientos (cómo siembre ¿no?), y lamentablemente no hay una matriz de decisión que dé una respuesta fiable al cien por cien.

¿React Native o nativo puro?

Al final la decisión de si confiar en React Native o en el desarrollo diferenciado nativo puro en cada uno de los lenguajes de iOS o Android, es la eterna cuestión, una vez hemos tomado la decisión de ir a nativo frente a la alternativa híbrida. Salvando las distancias, esta decisión tiene muchas similitudes con los argumentos que se han planteado en favor del desarrollo híbrido o nativo. Sin ánimo de parecer simplista, realmente todos los factores su puede reducir muy drásticamente a dos: económico y funcional.

  • Económico porque con la solución nativa hay que desarrollar cada funcionalidad dos veces, con React Native, la teoría dice que no, esto impacta en muchos factores, pero al final todos ellos convergen al mismo: la cantidad de dinero que has de invertir en el desarrollo.
  • Funcional porque si tu aplicación necesita tener funcionalidades muy particulares y poco convencionales, al final en ambos casos el desarrollo se va a tener que hacer customizado, con lo cual es mejor ir hacia un desarrollo nativo puro. Si por el contrario son funcionalidades más convencionales la decisión sería ir más hacia React Native.

A modo de conclusión del artículo, y tras el análisis a alto nivel realizado, tanto del framework (en el anterior artículo) como de sus compañías soporte, y las noticias al respecto, el titular sería que quizá React Native no sea una herramienta perfecta, pero sí merece, al menos, ser tenida en cuenta a la hora de valorar un desarrollo nativo. Quizá no sea lo que buscas, quizá no te convenza en absoluto una vez hayas analizado los pros y contras respecto a tu proyecto, pero desde luego es una alternativa real, válida y solvente, no la descartes sin más por lo que hayas oído, dale una oportunidad.

José Antonio Blanes

José Antonio es Jefe de Equipo en DxD de Deloitte, formando parte del área de movilidad dentro de la competencia Java. Profesional con más de siete años de experiencia, todos ellos en la firma, como desarrollador web, primero de aplicaciones basadas en el paradigma J2EE, y en la actualidad más centrado en el desarrollo web frontend basado en Angular, así como en la implementación de aplicaciones híbridas para dispositivos móviles, con más de dos años de experiencia en este tipo de desarrollos. Actualmente combina sus labores como desarrollador con la gestión de equipos y tareas dentro de la metodologías ágiles, formando parte del Development Team.

Did you find this useful?