Flutter, el nuevo integrante de nuestro stack. Una decisión basada en cifras
Flutter es una cross-platform y queremos mostrarte el porqué.
Artículo hecho en colaboración con Santiago García Gil.
Lo único constante es el cambio. Día a día el mundo se transforma; con él, la tecnología. Flutter es ejemplo de ello. Las tecnologías que hace unos años brillaron, quizás ya no sean la mejor opción para solucionar las
necesidades de hoy.
Hacerle frente al cambio requiere de decisiones fundamentadas, es ahí donde entró Flutter en escena. Incluir esta tecnología en nuestro stack Bancolombia fue una decisión basada en diversos casos de éxitos, artículos científicos y de realizar varias pruebas de concepto a nivel de la organización.
Flutter es popular; la dinámica de la comunidad de desarrolladores y encuestas famosas como Stack Overflow Survey dan fe de ello. No obstante, estamos convencidos de que es más que “un chico cool de la clase”; por ello, hoy exploraremos sus ventajas. ¿Lo elegimos por moda?, no ¿Por cifras y evidencia científica? Por supuesto que sí.
Lo que vamos a contarles no será una opinión sobre Flutter, sino una divulgación basada en datos; obtenidos del benchmark hecho en Bancolombia. Pondremos algunas cifras sobre la mesa, las cuales creemos les parecerán, cuanto menos, interesantes. Veamos.
Flutter, el primer cross-platform de gran performance
Flutter es un framework cross-platform que permite la creación de aplicaciones multiplataforma. Se destaca por su gran rendimiento, muy cercano a las opciones nativas de Android e IOS. Esto se logró gracias a dos cosas: SKIA engine, su motor de renderizado; y a que es compilado, a diferencia de los otros framewoks en su categoría. Ser compilado le dió una enorme ventaja debido a que el artefacto generado en tiempo de compilación es código nativo, que no debe pasar por un intérprete; a este se le conoce como bridge.
El mejor rendimiento, sin duda, se obtiene en un desarrollo nativo; sin embargo, Flutter nos permite obtener un desempeño más que sobresaliente. Siempre que tengamos buenas prácticas de desarrollo y una buena arquitectura, podremos obtener un rendimiento similar a una aplicación nativa.
Flutter es compilado tanto para arquitecturas x86–64 como ARM. Así logramos una compilación nativa, lo que no podríamos lograr con otro stack Cross-platform como React Native. Este último usa el Javascript Bridge, un intérprete que realiza la comunicación entre los componentes nativos y el código intermedio. De esta manera, se logra que el código Javascript sea entendido y asimilado por los componentes nativos. Tal hecho penaliza su rendimiento en comparación con Flutter; ya que, al estar a más bajo nivel, no requiere las técnicas de bridges; lo cual favorece su desempeño. A continuación, mostramos las gráficas que nos sirvieron de inspiración para cuestionarnos sobre cuál plataforma nos convendría más:
Para ejecutar la prueba comparativa de rendimiento, codificamos 4 aplicaciones con el propósito de ejecutar una transacción simple y revisar cómo se comportaban; evaluamos cuatro criterios: tiempo de respuesta de la solicitud en milisegundos (algoritmos de Gauss y Borwein), consumo de memoria RAM, porcentaje de uso de la CPU, tamaño del APK y cantidad de almacenamiento requerido en el dispositivo anfitrión. Probamos cuatro stacks de desarrollo: Flutter, Kotlin, React Native y Low Code. Los dispositivos usados fueron: Xiaomi Redmi Note 8, Huawei P20 Lite, Iphone 11 y Samsung Galaxy A50. El resultado mostró cifras concluyentes, dándole ventaja a Flutter con respecto a React Native, donde el rendimiento de Flutter es más cercano al de las aplicaciones nativas.
En el apartado de APK y almacenamiento vimos que Flutter es superado por su competidor directo, React Native, y por las otras opciones. Sin embargo, estos dos criterios no son lineales en la medida que crece la aplicación. Los resultados; 30MB aproximadamente para un APK productivo y en promedio 150 MB en uso de memoria, una cifra de consumo razonable; teniendo en cuenta que la tecnología disponible tiene buena capacidad para soportar números como estos.
Complemento de las aplicaciones Nativas, no el reemplazo
Los críticos de Flutter dicen cosas como: “no es conveniente…”, “…es una tecnología de nicho” o “solo moda…”. La idea detrás de las tecnologías Cross-platform no es reemplazar al desarrollo nativo, sino, cubrir la mayoría de las funcionalidades comunes que puede tener una aplicación móvil y reducir el TTM (Time to Market), sin sacrificar mucho el rendimiento. Es ahí donde vuelve a jugar un papel importante SKIA. Flutter con SKIA engine es competente en sus labores de renderizado. Cubre de manera apropiada la mayoría de los casos de uso estándar, a nivel de UX, para el desarrollo de aplicaciones móviles: navigation bars, list, banners, forms, animations. Algunos dicen que solo es una imitación de los elementos nativos, lo cual, puede ser cierto hasta cierto punto. A pesar de esto último, el hecho de que imite los elementos nativos no quiere decir que su look & feel sea malo, ni mucho menos su rendimiento, solo no es nativo y en consecuencia su apariencia cambia un poco.
No intentes usar Flutter para reemplazar el desarrollo nativo
Si crees que Flutter puede reemplazar al desarrollo en Kotlin y Swift, estás equivocado. Flutter es excelente para crear aplicaciones que no requieran uso de funcionalidades especializadas, UX exclusivos y difíciles de emular por tecnologías no nativas, o sea, para casos de uso que, por lo mismo, requieren sí o sí del uso de lenguajes nativos. De lo contrario, estarás comprometiendo la mantenibilidad de la aplicación; ya que, para mantener a flote la aplicación lanzada, se deberá mantener tanto el código en Dart como el de Swift y Kotlin. Básicamente, estarías rompiendo con la arquitectura Cross-platform de Flutter y la filosofía “Write once, and deploy everywhere”. Esto constituye un antipatrón.
A pesar de lo mencionado, el hecho es que, en algunos escenarios (ej: configurar permisos y capacidades) requerimos cierto desarrollo nativo para complementar lo ya hecho con Dart. Escenarios como los mencionados no rompen la arquitectura sino que buscan extender, con mesura (aquí es crucial un buen criterio sobre arquitectura aplicativa), las capacidades de Flutter. Esto lo hace muy compatible con SDKs nativos.
Flutter y Dart al servicio de la Mantenibilidad y Eficiencia
El rendimiento no es el único criterio. Para nadie es un secreto que hay una alta rotación en las compañías tecnológicas por la alta demanda de profesionales, lo cual lleva a una competencia sin cuartel por el talento humano. Por ello, buscamos que los desarrolladores se sientan cómodos y disfruten trabajar con un lenguaje o una tecnología, donde vean que su tiempo de aprendizaje se reduce y su productividad aumenta.
Sin complicaciones, podemos tomar a las Cross-platform como lo siguiente: un único código de aplicación que mantener. Esa es una premisa muy atractiva para los equipos de alto rendimiento o que buscan serlo. Tener un solo código fuente que cubra iOS y Android con alto desempeño y la posibilidad, cada vez más viable, de hacerlo para Web, Desktop y CLI. Es un claro factor que favorece la mantenibilidad y eficiencia. Hace a los equipos de TI más productivos y a la organización más rentable; permite enfocarse en habilitar soluciones fluidas y efectivas a nivel móvil que cumplan con las expectativas de servicio del negocio, a la vez que se logra un código más fácil de arreglar y evolucionar, ya que no requiere tanta inversión de tiempo y dinero para mejorarlo o soportarlo.
Dart es el lenguaje de desarrollo en Flutter
Aquí se vale hacer varias preguntas: ¿es Dart una buena opción para desarrollar? ¿Eso hace a Flutter más débil con respecto a la competencia? Hay fans y detractores. Estos últimos argumentan que Dart constituye un reto o impedimento más para sumar a la curva de aprendizaje de Flutter, ya que es otro lenguaje por aprender; inclusive se llega a decir que no es Javascript, que es difícil, que es mejor Kotlin y Swift… Ahora, se puede lanzar en contraposición otra pregunta: ¿Por qué ha de ser una debilidad aprender un nuevo lenguaje? Uno que se parece bastante al paradigma bajo el que se fundamentan otros como C++, Java, Javascript y C#. Con estos podemos estar cubriendo, por lo menos, la tercera parte de los lenguajes más usados en el mundo. Por lo tanto, remontar la curva de aprendizaje será más fácil.
Es estadísticamente factible, de acuerdo con lo anteriormente dicho, que alguien ya tenga nociones; bases adquiridas con otros lenguajes, para rápidamente desarrollar con Dart. Si en la vida te has topado con alguno de los lenguajes mencionados, bastará con echar una mirada rápida para comprender la dinámica de programación en Dart y darte cuenta de que es fácil de implementar y comprensible, principalmente por los siguientes aspectos:
- Es fuertemente tipado, según la documentación oficial. Aunque, en realidad es de tipado medio pues da flexibilidad para usar tipos como any, var y dynamic. Además, desde la versión 2.0 puede ser null safety, impidiendo que por defecto puedan existir variables nulas. Esto sirve para prevenir posibles bloqueos en el funcionamiento de una aplicación móvil, evitando pasar más tiempo del necesario depurando el código.
- Es declarativo lo que facilita crear código legible y comprensible. Permite sacar provecho de la programación funcional, con los widgets de una forma declarativa, preocupándonos más en el “qué queremos lograr”, en vez del “cómo”, propio del mundo imperativo.
- Orientado a objetos, siendo familiar para la gran mayoría de desarrolladores.
Las cifras, de nuevo, respaldan lo anteriormente dicho. En nuestro benchmark encontramos que la proporción aprendizaje vs codificación es más equilibrada en Flutter que, en este caso, Xamarin. La siguiente gráfica representa la productividad promedio de un desarrollador que comienza a aprender y a codificar en Flutter vs. realizar lo mismo con Xamarin. Los resultados fueron:
Basado en lo anterior, se puede concluir que; puede ser más productivo desarrollar con Flutter, la inversión de tiempo entre aprendizaje y codificación es equilibrada. Esto puede ser un factor a nivel motivacional, al momento de abordar o continuar el aprendizaje de una herramienta. El resultado nos mostró que la inversión de tiempo de aprendizaje en Flutter es 3 veces menor que en Xamarin. En cuanto a codificación, luego de haber aprendido del framework respectivo, se concluyó que en Flutter se pueden desarrollar 9 transacciones en 36 horas de trabajo, en Xamarin solo se podría hacer una.
Todo indica que habrá Dart para rato
Vale la pena destacar el hecho de que AWS haya dado su respaldo a Dart como lenguaje confiable y fácil de implementar, brindó soporte para Dart en AWS Lambda y Dart para AWS Amplify. El primero, hasta hace poco, solo permitía el uso de Python o Node.js para la creación de las funciones y el segundo; que es el servicio de AWS para crear y lanzar aplicaciones móviles, ya permite a Dart como opción de desarrollo. Con esto se puede ver que la hipotética obsolescencia temprana, que algunos auguraban al lenguaje, queda en entredicho.
Hay opiniones acerca de la irrelevancia de Flutter en comparación con React Native o Xamarin, afirmando que la industria no lo quiere y si lo usan es para proyectos pequeños y PoC. ¡Falso! Hay grandes actores de la industria, incluso fintechs de peso, que adoptaron Flutter como su framework para desarrollo móvil. Nubank, la startup brasileña de banca digital optó por esta opción de Google después de contrastarla con otras, especialmente contra React Native. Otros actores relevantes que decidieron apostar por Flutter fueron el Grupo Toyota, BMW, Capital One, entre otros.
¿Qué tal el soporte?
Cada vez que buscamos hacer a una tecnología parte de nuestro stack, buscamos que cuente con una comunidad robusta y de crecimiento sostenido. Con Flutter hallamos lo que queríamos.
Pudimos concluir que el nivel de soporte por la comunidad es bastante bueno. A pesar de que al comienzo hubo reparos por parte de entusiastas acerca de cómo manejaban los issues, a qué tan compatibles eran con plataformas nativas o cuán actualizadas se mantenían sus librerías. Flutter demostró que cuenta con una comunidad muy dinámica de contribuidores, hecho respaldado por las cifras en GitHub, en donde, con menos de 5 años en el mercado, tiene más estrellas que React Native y Xamarin, superando a este último también en forks; mostrando en todo lo anterior un crecimiento vertiginoso.
Si bien, tiene mayor cantidad de issues que las anteriormente mencionadas, puede deberse a que aún está en proceso de maduración; dado su tiempo en el mercado y por la gran dinámica que tiene la comunidad, la cual está muy activa en mejorar el framework. Esto también se evidencia en una cantidad de pull request, superior a sus competidores.
También se encontró una comunidad muy activa en Stack Overflow, preguntando cada vez más por tópicos relacionados a Flutter.
¿Es Flutter una tecnología encasillada en un nicho?
A hoy, ¿qué tecnología no es de nicho? ¿Acaso eso está mal? Es una consecuencia natural del advenimiento de la era de la información, con sus demandas crecientes en especialización o focalización de esfuerzos.
No hay muchos esfuerzos encaminados en hacer un backend con Swift, ¿o sí? Puede ser, puesto que uno puede lograr lo que se proponga a costa de romper la arquitectura. Pero, ¿es lo correcto? Las tecnología de hoy están hechas, generalmente, para propósitos específicos. A manera de ejemplo, uno podría sacar clavos con un alicate en vez de un martillo, pero… ¡Ese no es su propósito! Tener un propósito, un lugar, una razón de ser, está bien. Esto para la tecnología no es la excepción.
La conclusión es que, ser una tecnología de un nicho de mercado en específico no está nada mal. Si su nicho es el de crear aplicaciones Cross-platform, está bien; para eso fue creada, no para ser “bala de plata”. Si ya sabemos que tecnologías como Flutter tienen el propósito fundamental de emular la mayoría de las interacciones de las aplicaciones móviles, sin pretender el reemplazo de las implementaciones nativas; mejores para ciertos casos de uso; pues, está bien encasillada. Las cifras la respaldan. Hacer aplicaciones geniales de código único es su especialidad, su lugar en el mercado.
Retos a resolver por parte de Flutter y la comunidad
Flutter trabaja arduamente para estabilizar y agregar nuevas características a pasos agigantados. Ojalá esto sirva para afrontar los próximos retos. Básicamente dos:
Seguir fortaleciendo el soporte para aplicaciones híbridas o Web apps: Aunque ya está estable para desarrollo de Web apps, es aun reciente y está en proceso de maduración. A inicios de marzo del 2021, Flutter anunció su versión 2.0, en donde algunos componentes difieren de su implementación en comparación a la primera versión. Sin embargo, los cambios no generan una alta dificultad de migración, puesto que no es una alteración drástica como la sucedida entre Angular.js y Angular framework, sino que es sutil y no genera fricción en quienes ya desarrollaron con Flutter 1.x.x. En esta nueva versión es palpable la evolución que han ido ofreciendo para el mundo web y la implementación por default de la capacidad null safety.
Ciclo de vida dado por Google: parte de la comunidad de desarrollo dice que puede haber riesgo de que Flutter o Dart puedan ser uno de los proyectos abandonados por Google. Es prematuro pensarlo dadas sus dinámicas, reveladas por las cifras en GitHub, y su popularidad; así el gigante de Mountain View tenga fama de dejar desamparadas en medio del camino a sus propias creaciones, con casos memorables como el de Inbox, Google plus, Google Talk, Google Nexus, Google Code… En fin. Incluso, si se quisiera ver a Dart como su talón de Aquiles, no es el caso; puesto que vemos con gusto, como lo dijimos líneas atrás, que AWS ya da soporte para Dart en sus servicios de AWS Lambda y Amplify. Hay futuro para Flutter.
Conclusiones
- No es una regla de oro usar Flutter, se debe analizar el caso de uso que se deba aplicar para todas las soluciones. No hay tecnología que sea perfecta para todo.
- Aunque Flutter posee un gran rendimiento, no está hecho para reemplazar al desarrollo nativo, sino para complementarlo.
- Aprender Flutter y Dart es mucho más fácil, en comparación a otras herramientas como React Native y Xamarin.
- Usar bien Flutter ayuda indudablemente a la mantenibilidad y eficiencia, al mantener un código base único para múltiples plataformas.
- Flutter posee suficientes dinámicas a nivel de los usuarios como para dar un parte de tranquilidad a quienes duden si desarrollar con el framework por falta de soporte de comunidad. Basta con revisar su GitHub.
- A partir de la versión dos, se potencializa la creación de aplicaciones híbridas, gracias al soporte para Web apps. Habrá que darle tiempo a la misma para que demuestre sus bondades.
¿Ustedes qué opinan al respecto? Seguro hay más cosas por considerar, como el debugging. ¿Creen que es mejor el sistema Mono debug de Javascript Bridge? ¿Alguna opinión que se escape del objeto de nuestro estudio? Déjenos saberlo, nos encantará conocer más.
