Tim Sneath: «Flutter es para las aplicaciones lo que Unity es para los juegos»

Introducción

Hemos hablado con Tim Sneath, director de producto de Google para Flutter y Dart, sobre cómo el lenguaje y el marco han evolucionado en los últimos dos años, cómo se usan actualmente y hacia dónde se dirigen.

La entrevista

Evrone: Tu puesto se llama «director de producto de Flutter y Dart». ¿Qué se necesita para convertirse en director de producto, no solo para productos de consumo, sino algo relacionado con desarrolladores, como un marco y un lenguaje de programación?

Tim: Nunca he sido director de un producto de consumo, ¡solo conozco a desarrolladores! Pero, en general, para ser director de producto es necesario combinar una estrategia empresarial, comentarios de clientes, recursos de ingeniería y una cierta intuición predictiva para crear un producto que esperamos que les encante a los usuarios.

El uso de Flutter se ha incrementado enormemente en los últimos dos años, y muchos de los retos en los que he pensado están relacionados con la gestión de las desventajas asociadas a dicho crecimiento: ¿qué parte de nuestros recursos dedicamos a desarrollar nuevas características, en lugar de mejorar el área expuesta existente? ¿Cómo dividimos nuestra atención entre usuarios internos, grandes empresas y empresas emergentes? ¿Cómo damos soporte a nuevos factores de forma (como dispositivos plegables) y plataformas (como Windows y macOS) sin intentar abarcar demasiado?

Evrone: Parece que actualmente hay una especie de renacimiento para marcos que permiten desarrollar interfaces de usuario con código (por ejemplo, Flutter, Swift UI y Jetpack Compose se anunciaron o publicaron en los últimos dos años). Y la recarga activa es algo de lo que hablas mucho con Flutter. ¿Qué tendencias has observado aquí?

Tim: Creo que, desde hace varios años, la productividad de los desarrolladores se ha sacrificado en el altar de la innovación. Estaba en la universidad cuando se publicó Visual Basic 1.0 y, en muchos aspectos, representó un nuevo hito para facilitar el desarrollo de interfaces de usuario. Piensa solo por un momento… Antes de VB, para desarrollar una aplicación de Windows era necesario escribir cientos de líneas de C, usar un editor de DOS y un compilador de línea de comandos, y completar un laborioso bucle de edición, compilación y depuración para conseguir que funcionara. Visual Basic permitió a desarrolladores aficionados pintar el diseño de la interfaz de usuario directamente en la pantalla, además de ofrecer las opciones de «editar y continuar»: la capacidad de pausar una aplicación, realizar cambios y, después, continuar sin tener que volver a compilar.

Sin embargo, en las últimas dos décadas parece que cada vez resulta más difícil, en lugar de ser más fácil. Hemos añadido muchos niveles de complejidad a operaciones que antes eran sencillas, con preprocesadores y transpiladores, jerarquías de módulos con varios niveles de anidamiento y dependencias transitivas poco claras, y pilas que cambian tan rápido que tu aplicación se queda obsoleta antes de completarla.

Aún nos queda mucho camino por recorrer… Pero la recarga activa con estado es un paso adelante para recuperar esa facilidad que ofrecía la función «editar y continuar» del desarrollo de interfaces de usuario. Tengo la esperanza de que podremos seguir reduciendo la carga cognitiva de convertir una idea en una aplicación con Flutter para conseguir que los desarrolladores se centren más en lo que quieren crear y menos en cómo expresarlo mediante código.

Evrone: La guerra entre los «widgets nativos de sistema operativo» y los «widgets propios dibujados en píxeles» lleva varias décadas activa, y empezó con la primera versión de Qt. Basándote en tu experiencia con numerosas grandes empresas que crean aplicaciones móviles, ¿cuál crees que es la situación actual?

Tim: Creo que es una falsa dicotomía. Lo único que importa es la calidad: ¿puedes crear una experiencia atractiva que sea digna de un usuario exigente? La calidad tiene poco que ver con qué dato binario representa un píxel específico en la pantalla: es una combinación de rendimiento, atención en cada detalle y capacidad técnica. Algunos de los juegos más galardonados se han creado con el motor de juegos Unity, pero a nadie le importa si Monument Valley usa o no «widgets nativos del sistema operativo».

Creemos que Flutter es para las aplicaciones lo que Unity es para los juegos: ofrece rendimiento nativo y elegancia visual a las aplicaciones, independientemente de la plataforma de destino.

Evrone: ¿Cómo se relaciona Dart con el nuevo proyecto «Fuchsia» de Google? Aparece en la lista de lenguajes «recomendados», junto a C++, Rust y Python.

Tim: Fuchsia es un sistema operativo experimental de código abierto en el que hemos estado trabajando durante algún tiempo. Aunque no puedo proporcionar mucha información al respecto en la fase actual, todo el código fuente es público. Flutter permite compilar para Fuchsia, por lo que podrás ver varias referencias en el código fuente de Flutter. Y, por supuesto, Dart es el lenguaje de Flutter.

Evrone: Grandes empresas como eBay o BMW adoptan la combinación de Dart y Flutter para sus proyectos móviles. ¿Cuáles son los principales argumentos de venta para ellos?

Tim: Para muchos de ellos, es simplemente la capacidad de unificar el desarrollo de aplicaciones con una única solución de alta calidad. A pesar de ello, no tiene mucho sentido que la mayoría de las aplicaciones accesibles por clientes tengan a varios equipos trabajando para solucionar exactamente el mismo problema empresarial, con las mismas entregas y escalas temporales, todos haciendo el mismo trabajo, pero con un lenguaje y herramienta distintos, ya sea para iOS, Android o la web. Prácticamente no hay ninguna otra analogía en el desarrollo de software en la actualidad: las empresas no implementan de forma voluntaria tres nuevos sistemas de nóminas. Cuando los equipos descubren que no solo pueden crear una experiencia nativa de alta calidad para varias plataformas a la vez, sino que pueden ser más productivos de lo que serían en cualquier plataforma individual gracias a características como la recarga activa con estado, ¡resulta muy fácil convencerlos!

Los mayores desafíos no son técnicos: muchas empresas tienen una alineación organizativa en torno a la plataforma de destino, por lo que a veces hay cierta resistencia inicial por parte de los equipos que no quieren combinarse en un esfuerzo unificado. Y, por supuesto, aún somos una plataforma joven, por lo que las empresas más conservadoras tienen cierto escepticismo innato en relación con un camino poco trillado. Pero el tiempo corregirá ese problema: nuestro ecosistema de paquetes y complementos se ha quintuplicado en el último año, y hay decenas de miles de aplicaciones disponibles que demuestran que Flutter puede ofrecer calidad a gran escala.

Evrone: En tu opinión, ¿es mejor que los desarrolladores creen diseños separados para tabletas y teléfonos móviles? ¿O existen tecnologías modernas lo suficientemente potentes para crear interfaces de usuario «adaptables» que se ajusten a la perfección a distintos tamaños de pantalla?

Tim: Las complicaciones con el diseño adaptable de interfaces de usuario se encuentran tanto en el marco como en el conjunto de herramientas. La web tiene compatibilidad con consultas de medios desde hace años, pero aún resulta complicado crear una experiencia que se escale de manera uniforme en distintos factores de forma. Flutter permite esto, y Matías Duarte realizó recientemente una demostración del prototipo de una herramienta con la que estamos experimentando para Flutter.

Evrone: ¿Qué IDE prefieres actualmente? ¿Android Studio, productos de JetBrains, VS Code o algo distinto?

Tim: Estoy acostumbrado a usar VS Code, ya que llegué a Google desde el equipo de Visual Studio y es un conjunto de productos que he usado durante mucho tiempo a lo largo de los años. Y me encanta el trabajo que Danny Tuppeny ha realizado al crear las extensiones de Flutter y Dart; ha sido genial ver cómo Flutter se convertía en una experiencia fluida desde VS Code. Como equipo, no le damos importancia a las herramientas de programación que uses, ya sea Android Studio, IntelliJ, VS Code, Vim o Emacs.

Un proyecto que me resulta interesante es el esfuerzo de Language Server Protocol, que intenta salvar las diferencias entre editores y lenguajes con un protocolo común. En paralelo a un proyecto similar para adaptadores de depuración, esperamos que esto permita gradualmente a los desarrolladores elegir herramientas que se adapten a sus necesidades, sin que los autores de lenguajes tengan que duplicar su trabajo en cada una de estas herramientas.

Evrone: Dicen los rumores que se suponía que Dart iba a reemplazar a JavaScript en los navegadores web, pero ahora ha cambiado para apoyar a Flutter. ¿Es cierto? ¿Y cuál es el uso de Dart fuera del desarrollo de aplicaciones móviles?

Tim: Es cierto que la historia original de Dart empezó como una extensión del equipo de V8, que estaban realizando prototipos de nuevos métodos para el desarrollo de aplicaciones. Pero aquel Dart se parece muy poco al lenguaje actual, que renació como un lenguaje optimizado para clientes hace un par de años con el lanzamiento de Dart: 2.0. Hoy en día, Dart se centra en aspectos técnicos muy específicos: la portabilidad de la plataforma en la web, el escritorio y dispositivos móviles; la creación rápida de objetos y recolección de elementos no utilizados; y la inyección de código de máquinas virtuales durante el desarrollo con compilación nativa en tiempo de ejecución. Eso hace que se adapte a la perfección a escenarios de cliente, ya sea Flutter, una CLI o lógica empresarial.

Evrone: ¿Cuál es tu opinión personal sobre la idea de «pila completa»? Con lenguajes como Dart, que tiene un buen rendimiento tanto en el front-end como en el back-end, ¿te parece viable que los desarrolladores de hoy en día puedan crear todas las partes de una aplicación?

Tim: No sé lo que pensarán otros, pero en mi caso me resulta difícil estar al día ya solo de las tecnologías de cliente. Es genial tener un lenguaje con la flexibilidad para ejecutarse en dispositivos móviles, la web, servidores y la nube, y hemos visto varios desarrolladores que usan Dart para conseguir un excelente efecto en el servidor, a menudo para compartir una lógica empresarial existente que ya habían escrito para el cliente. Creo que los desarrolladores podrían convertirse en desarrolladores de pila completa, ya que hay mucha gente que hace exactamente eso. Pero la especialización es cada vez más necesaria a medida que las aplicaciones crecen en escala, y no creo que encuentres muchos desarrolladores auténticos de pila completa en Google fuera de los proyectos de incubación de empresas emergentes.

Evrone: Flutter para la web está en fase beta y Flutter para el escritorio está en versión alfa. ¿Qué futuro imaginas para ambos proyectos?

Tim: Ambos están aún en desarrollo, pero nos estamos acercando y pronto realizaremos varios anuncios sobre el progreso que hemos alcanzado en ambos frentes. Nunca diseñamos Flutter para que fuera solo para móvil; siempre se ha diseñado como un marco de interfaz de usuario portátil, y iOS y Android simplemente han sido los dos primeros destinos. Hay nuevos desafíos para las aplicaciones de clase de escritorio: el factor de forma y los métodos de entrada son distintos, suelen usar diferentes metáforas de interfaz de usuario y tenemos que ser capaces de cambiar el tamaño y gestionar varias ventanas. Además de eso, la web es efímera, al contrario que una aplicación móvil o de escritorio instalada.

Tanto la web como el escritorio resultan emocionantes de formas distintas como objetivos para Flutter. La web es más complicada desde un punto de vista técnico, y en especial si quieres evitar el «asombroso valle» de proyectos más antiguos, como Flash y Silverlight. Queremos que la experiencia web sea lo suficientemente fluida para que no puedas saber si una página usa Flutter o no hasta comprobar el código fuente. Hemos conseguido un buen progreso con el rendimiento: hace poco, completamos un back-end de CanvasKit para la web que ofrece enormes ganancias.

El escritorio ofrece un conjunto curioso de casos de uso: desde proporcionar a los desarrolladores una ruta completa para más de 1000 millones de equipos que ejecutan Windows, macOS y Linux, hasta reducir en gran medida la fricción para los nuevos usuarios que empiecen a usar Flutter. Uso cada vez más el escritorio como mi primer objetivo al trabajar en una aplicación de Flutter, ya que no necesitas un emulador ni un dispositivo conectado para ver los resultados.

Resulta incluso más curioso que la opción para elegir entre web y escritorio está enlazada en tiempo de ejecución con Flutter. Tenemos varios proyectos internos que aún están en mitad del desarrollo, pero no hemos decidido si se publicarán como aplicaciones de escritorio compiladas de forma nativa o como PWA. Es genial poder ofrecer ese nivel de flexibilidad.

Evrone: ¿Puedes comparar Flutter con React Native? ¿Cuáles son las ventajas para que un desarrollador de nivel medio aprenda un nuevo lenguaje de programación y deje de usar un lenguaje conocido como JavaScript?

Tim: El estilo de programación reactivo ofreció a Flutter un gran impulso en sus comienzos. Es un cambio importante en comparación con la transmisión de mensajes y estilos de modelo retenidos que han tenido prevalencia durante mucho tiempo. Pero es difícil responder a esta pregunta sin que parezca que estoy hablando mal de otro marco, lo que no es mi intención. Cada uno tiene sus puntos fuertes y sus limitaciones, y hay muchas opiniones al respecto, por lo que no hace falta que añada la mía.

Evrone: Si pudieras viajar al pasado y cambiar cualquier característica del lenguaje Dart, ¿cuál sería?

Tim: ¡Ja! Sin duda, la característica en la que he invertido más tiempo en los últimos años ha sido el modo «strong»: quería integrar un sólido sistema de tipos estáticos en el lenguaje. El concepto original de Dart era un lenguaje tipado opcional, con la capacidad de expresar tipos mediante anotaciones con fines de desarrollo, pero sin efecto semántico en tiempo de ejecución. En Dart 1.x, esto era un principio básico del lenguaje; sin embargo, con el paso del tiempo, las limitaciones de ese método han quedado patentes, ya que incluso el mundo de la web ha cambiado a la comprobación de tipos mediante TypeScript.

Realizar un cambio de esta magnitud en un lenguaje de programación activo no es una hazaña pequeña, pero el equipo de ingeniería completó este trabajo con Dart 2.0 y, en el proceso, se migraron millones de líneas del código de Dart del repositorio único de Google a un nuevo compilador de front-end común. Ahora estamos ampliando este trabajo para añadir la función de seguridad de valores nulos, que ofrece tipos que no admiten valores nulos verificables en todo el marco.

Hemos dedicado más de 50 años de ingeniería para revertir estas dos decisiones de diseño, pero el resultado final es un lenguaje sólido con seguridad de valores nulos y compiladores de eficacia demostrada para JavaScript, Intel y código máquina de ARM a partir del mismo código fuente. Creo que es algo único.

En Evrone, nos entusiasma la continua evolución de Dart y Flutter: cuanto más eficaces son, mejores soluciones de aplicaciones móviles podemos crear para nuestros clientes y socios, muchos de los cuales ya han comprobado de primera mano las ventajas del ecosistema de Dart para el desarrollo.