Comparativa de Frameworks Front-End con pruebas de rendimiento

Este artículo es una actualización de Comparativa de Frameworks Front-End con pruebas de rendimiento (en inglés) de diciembre de 2017.
En esta comparativa, mostraremos como diferentes implementaciones de aplicaciones casi idénticas de ejemplo para el mundo real se comparan entre sí.
La aplicación para el mundo real nos da:

  1. Aplicación para el mundo real – Algo más que una «app de tareas pendientes». Estas normalmente no transmiten una perspectiva o conocimiento suficiente para construir una aplicación real.
  2. Estandarizado – Un proyecto que cumple ciertas reglas. Proporciona una API para back-end, marcado estático, estilos y especificaciones.
  3. Escrita o revisada por un experto – Un proyecto consistente que, idealmente, un experto en esa tecnología habrá construido o revisado.

Crítica con respecto a la versión anterior (diciembre 2017)

Angular no estaba en producción. La aplicación de demostración listada en el repositorio RealWorld usaba una versión de desarrollo, pero gracias a Jonathan Faircloth tenemos una versión de producción.
Vue no estaba listada en el repositorio RealWorld y por tanto no se incluyó. Como podéis imaginar, en el mundo front-end, esto ha provocado muchos comentarios. ¿Cómo es posible que no añadieras Vue?¿Qué demonios te pasa? Esta vez Vue.js ya está incluida. Gracias Emmanuel Vilsbol.

¿Qué librerías/frameworks estamos comparando?

Como en el artículo de diciembre de 2017, hemos incluido todas las implementaciones listadas en el repositorio RealWorld. No importa si tiene mucho seguimiento o no, el único requisito es que aparezca en dicho repositorio.

Frontends de https://github.com/gothinkster/realworld (abril 2018)

¿Qué métricas observaremos?

  1. Rendimiento: ¿cuánto tarda esta aplicación en mostrar contenido y ser usable?
  2. Tamaño: ¿cuánto pesa la aplicación? Sólo compararemos el tamaño de los ficheros JavaScript compilados. El CSS es común en todas las variantes y se descarga desde un CDN (Red de entrega de contenido). El HTML también es común en todos. Todas las tecnologías compilan o transpilan a JavaScript, de modo que sólo estos ficheros.
  3. Líneas de código: ¿Cuántas líneas de código necesitó el autor para crear la aplicación basada en las especificaciones? Para ser justos, algunas aplicaciones tienen algún añadido, pero no deberían tener un impacto significativo. La única carpeta que medimos es /src de cada aplicación.

Métrica #1: Rendimiento

Echa un vistazo a la prueba de primera pintura significativa con Lighthouse que ofrece Chrome.
Cuanto antes ‘pintes’ (muestres contenido), mejor será la experiencia para el usuario de la aplicación. Lighthouse también mide la primera interacción (en inglés), pero es casi idéntica para todas las aplicaciones y aún está en fase beta.

Primera pintura significativa (ms) — cuanto más bajo, mejor


Es posible que no veamos ninguna gran diferencia con respecto al rendimiento.

Métrica 2: Tamaño

El tamaño se toma de la pestaña Red de Chrome, las cabeceras de la respuesta con GZIP más el cuerpo de la respuesta, tal y como lo entrega el servidor.
Cuanto más pequeño es el fichero, más rápida será la descarga (y menos datos a tratar).
Esto depende del tamaño del framework así como de dependencias extra que hayamos añadido, y la eficacia de la herramienta de empaquetado.

Tamaño de transferencia (KB) — más pequeño es mejor


Podemos ver que Stelve, Dojo 2, AppRun y Crizmas MVC hacen un buen trabajo. No estoy tan seguro acerca de ELM, especialmente cuando veamos la próxima tabla. Me gustaría ver una comparativa con Hyperapp, tal vez la próxima vez, ¿Jorge Bucaran?

Métrica #3: Líneas de código

Gracias a cloc podemos contar las líneas de código en la carpeta /src de cada repositorio. Las líneas en blanco y los comentarios no computan. ¿Por qué es este significativo?

Si depurar es el proceso de eliminar errores de software, entonces programar debe ser el proceso de añadirlos – Edsger Dijkstra

# líneas de código  — menor es mejor


Cuantas menos líneas de código tenemos, menores son las probabilidades de tener errores. También tenemos menos código que mantener.

En conclusión

Me gustaría agradecer a Eric Simons por crear el repositorio RealWorld Example Apps y a los contribuyentes que han escrito las diferentes implementaciones.
Actualización: Gracias a Jonathan Faircloth por proporcionarnos la versión de producción de Angular.

Si crees que este artículo es interesante, puedes seguirme en twitter y en medium

Nota: puedes encontrar el artículo original en https://medium.freecodecamp.org/a-real-world-comparison-of-front-end-frameworks-with-benchmarks-2018-update-e5760fb4a962

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *