Cómo mejorar el rendimiento de apps front-end con Web Workers y TDD

Testear aplicaciones web es una tarea difícil. De hecho, apuesto a que has notado que incluso el entorno de código puede ser hostil para las pruebas, con ventanas, documentos, escuchadores de eventos, callbacks y, para complicar aún más las cosas, cada browser implementa especificaciones a su manera. Afortunadamente, el ecosistema front-end ha evolucionado hacia un mejor estado que permite probar incluso aquellos códigos que dependen en gran medida de la plataforma para funcionar.

En una reciente edición especial de nuestros Coding Dojo's presenciales, estudiamos el ecosistema frontend centrándonos en el rendimiento de la aplicación. El dojo fue diseñado para desarrolladores familiarizados con JavaScript y Test-Driven Development (TDD).

Para esta sesión, decidimos adoptar el enfoque de randori, que es nuestra forma habitual de llevar a cabo coding dojos después de experimentar con dividir a las personas en parejas.

La sesión comenzó con una breve introducción a la agenda del día. La idea era dividir el coding dojo en dos partes: en la primera parte, en la cual exploraríamos el problema que queríamos resolver/codificar y una introducción a los web workers; en la segunda parte, aplicaríamos Test-Driven Development (TDD).

En las siguientes dos secciones describo el coding dojo con más detalle y al final del artículo comparto algunas conclusiones para que pruebes por ti mismo.

Parte 1: Introducción a Web Workers

La primera parte de la sesión estuvo dedicada a introducir los web workers. Esta es una API bien respaldada para el navegador, pero no es tan popular entre los desarrolladores como podría serlo.

Los web workers ofrecen varias ventajas, incluido un rendimiento mejorado para las aplicaciones frontend. Sin embargo, también pueden agregar complejidad al mantenimiento e implementación del código.

Para explorar las limitaciones de JavaScript en el navegador, comenzamos con un problema simple: mostrar y ocultar un indicador de carga para simular que se está realizando una computación.

Con ese ejemplo, observamos:

• La limitación que JavaScript tiene con respecto a la ejecución multinúcleo.
• Cómo la parte de renderizado del navegador web sufre a causa de ello, resultando en una experiencia de usuario deficiente.

Una vez que completamos esto, comenzamos a implementar web workers para mejorar la experiencia del usuario.

En esta parte, aprendimos sobre los web workers y los trade offs que ofrece al implementar una solución más compleja. Una vez finalizado, estuvimos listos para abordar la segunda parte del dojo.

Parte 2: Test-Driven Development

La segunda parte de la sesión se centró en aplicar lo que aprendimos sobre web workers en la primera parte, utilizando Desarrollo Guiado por Pruebas (TDD).

Comenzamos centrándonos en la regla comercial que queríamos implementar con web workers. Decidimos implementarla primero sin workers y luego refactorizarla para usar workers.

En el proceso, nos encontramos con una de las dificultades al realizar pruebas de código con web workers:

• La librería Jest para probar web workers requiere que implementes el worker sobre la marcha, en lugar de utilizar un archivo JavaScript.
• Dado que ahora tienes un worker, debes ser especialmente cuidadoso al tratar con recursos.

Logramos seguir el flujo de TDD sin mayores restricciones. Al final, discutimos cómo los web workers son, en última instancia, un detalle de implementación, y que podríamos mantener la misma lógica comercial con o sin ellos.

Principales conclusiones

Pudimos aprender como grupo y conocer mejor los web workers. Comenzamos con una introducción a la tecnología y elegimos un problema simple para codificar. Luego, pasamos a un enfoque más complejo y aplicamos Test-Driven Development (TDD) a nuestro flujo de trabajo.

Las principales conclusiones de la sesión son que:

• Obtuvimos una mejor comprensión de los web workers. Uno de los asistentes incluso compartió que pensaba que los web workers eran más difíciles de lo que resultaron ser.
• Los web workers pueden agregar complejidad a las aplicaciones web.
• Es posible realizar pruebas de código con web workers y refactorizar para utilizar web workers en código que aún no los está utilizando.

El feedback al final de la sesión fue positiva; los asistentes querían ver más interacciones de ese tipo con nuevas APIs disponibles en el navegador para usar en su trabajo diario. Dado tal entusiasmo, estamos evaluando nuevas características web que podemos incluir en futuras ediciones de nuestros coding dojos.

¿A quién no le gustaría aprender una nueva API que pueda brindar una mejor experiencia para nuestros usuarios al interactuar con nuestras aplicaciones?

Si deseas obtener más información y descubrir qué nuevas temáticas exploraremos en nuestros próximos Coding Dojos, dale un vistazo a nuestra página de eventos y apúntate al próximo dojo!