Conocéis a DHH. DHH es el creador de un montón de cositas, entre ellas Rubion Rails.
Fue polémico hace poco porque estuvieron quitando TypeScript, ¿vale? De 37 Signals.
Y eso hizo mucha polémica. Es una persona que le gusta el salseo y está cada dos por tres.
El otro día dijo una cosa bastante polémica que yo no estoy de acuerdo.
No estoy de acuerdo. Le entiendo, pero no estoy de acuerdo, ¿vale?
¿Qué es lo que dijo y qué es lo que ha pasado?
En una charla estaban comentando esto.
El estado del arte ya no consiste en encontrar formas más sofisticadas de construir JavaScript o CSS.
No se trata de construir en absoluto. O sea, construir por build, ¿vale? De hacer builds.
Ya no se trata de hacer builds.
Apóyate en HTTP2 y el ahora soporte universal para importar mapas para evitar la agrupación.
Y entonces puso esto, ¿no? Que estos son como los tiempos en los que tardas en construir una aplicación.
Van, fíjate, es infinito X, es build, infinito X, no build. ¿Qué significa no build?
Que en lugar de tener que empaquetar tu aplicación, dejar de empaquetar tu aplicación y enviar directamente el JavaScript sin empaquetarlo.
Y importar todo lo que tengas que importar y ya está. Todos los JavaScript y tal.
Para que nos hagamos una idea a qué se refiere. Aquí, si nos vamos aquí en dependencias y pongo el confetis Canva este, ¿vale?
¿Veis? Esto sería no build. Porque yo aquí lo que estoy haciendo es simplemente importar la dependencia y ejecutarla.
Y aquí no se está haciendo ningún proceso de empaquetador. Nada, ¿sabes?
Esto es simplemente lo que está haciendo y lo podemos ver aquí en la preview.
Si abrimos las herramientas y miras en Nickwork, vais a ver que aquí lo que hace es cargar la biblioteca y una vez que carga la biblioteca, la ejecuta.
Lo bueno de esto es que el tiempo que hemos tenido que tardar en el paso de construcción de nuestra aplicación es cero.
Buenísimo. Eso está bien.
¿Qué ha pasado con esto? Pues él continúa.
Dice, hey, que si no sabéis, hey es un email que hay aquí, que es de 37 signals.
Está ejecutándose con JavaScript para la aplicación principal sin un paso de construcción.
Mira en contraste, compara las puntuaciones de Lighthouse, de las cargas de la bandeja de entrada, de la bandeja de entrada con Gmail y con hey.
Creo que lo estamos haciendo bastante bien con no build, importar mapas y unos 100 archivos de JavaScript individuales.
Enviamos medio mega de JavaScript sin comprimir frente a los 10 megas de Gmail.
Y aquí tenemos su cara de felicidad.
Y entonces compara, compara hey con Gmail.
Es una comparativa que es un poquito...
No tiene ningún sentido comparar, aunque sean dos productos que son lo mismo, que son dos gestores de correo,
pero realmente tienen las mismas funcionalidades, realmente presentan igual la información, están haciendo exactamente lo mismo.
O sea, es una comparación muy tramposa porque no sabemos si es exactamente lo mismo.
Por ti mismo, registrándote hey, toda la fuente de JavaScript se envía sin minificación.
O sea, podemos ir a hey, que yo no sé si tengo una cuenta de hey, no sé si podremos ver a mejor aquí.
Pero dice que están enviando el código...
No, aquí lo veo minificado.
O sea, dicen que lo están enviando sin minificar.
A mí me parece muy mala idea, sinceramente.
No tiene ningún tipo de sentido hacerlo sin minificación.
Legible allí mismo en el navegador.
Es una excelente manera de construir, una excelente manera de aprender.
No es necesario compilar JavaScript para aplicaciones modernas.
Mira, aquí lo tenemos, ¿no?
Dice que no...
Dice...
¿Veis?
Que no lo tiene minificado.
Me parece un poco...
Me parece un poco raro, la verdad.
No me parece que tenga mucho sentido.
O que no le veo ninguna desventaja a minificarlo.
Pero aquí viene Guillermo a comentar una cosa.
Que me parece muy interesante lo que dice, ¿no?
Mi conclusión.
Hostia, Guillermo, aquí le mete...
Le mete...
Le mete una colleja.
Gran respeto y felicidades al equipo de Gmail.
Gmail tiene 1.500 millones de usuarios activos.
Ágiles interacciones del lado del cliente.
Extrema madurez y estabilidad del producto.
Y una puntuación de rendimiento.
O sea, un coste.
Un coste de rendimiento.
Un delta de solo 10 puntos respecto a una nueva aplicación.
Dios.
O sea...
¡Zasca!
Vaya colleja le acaba de dar, tío.
El delta sería la diferencia.
Un delta sería una diferencia de 10 puntos, ¿no?
El coste de oportunidad.
Digamos que tú empiezas...
Cuando tú empiezas una página web y la tienes vacía, tu rendimiento es 100.
Tiene que ser 100.
Pues no estás cargando nada, ¿no?
Entonces, el delta sería ese coste de oportunidad.
¿Cuál es el coste que quieres asumir para entregarle lo que le quieras entregar al usuario?
Y esto es muy importante porque muchas veces la gente se enfoca mucho en el rendimiento.
Y yo soy una de esas personas.
Pero es normal que al final haya un delta.
Porque todo tiene un coste de oportunidad.
Por ejemplo, si quieres cargar algo interactivo, tienes que cargar JavaScript.
Y a lo mejor eso, pues tiene un coste.
Entonces, a lo mejor lo máximo que puede llegar al rendimiento es un 98.
Y está bien.
Además, es probable que esté limitado a ejecutarse en versiones de navegador muy antiguas para lograr compatibilidad global.
Y dice 100%.
¿De acuerdo?
Amplia gama de navegadores y dispositivos compatibilidad con Google Workspace.
Sistema de extensión, temas, indicadores, funciones, experimentos, telemetría, instrumentación muy avanzadas.
Es una maravilla la ingeniería que hizo avanzar la web durante décadas.
Joder, tío.
La verdad es que vaya padreada la meta.
La metido.
Bueno, aquí hay un montón de gente que está de acuerdo.
Obviamente, no le ha contestado ni le ha dicho absolutamente nada el bueno de HH.
Ahí no ha contestado.
Prefiero ese 10% con ese montón de usuarios.
Claro, ¿no?
Hay veces que hay que sacrificar rendimiento para entregar el producto.
Eso tiene sentido.
Y es verdad que yo creo que ahí no tiene mucho sentido el hecho de hacer este tipo de comparaciones cuando Gmail es un producto mucho más antiguo y que estás intentando poner el foco donde no es.
Él está intentando defender que la diferencia de 10 puntos viene por su estrategia de cómo sirve el JavaScript.
Que no está mal.
O sea, a mí me parece muy interesante lo que hacen y seguro que tiene un montón de ventajas.
Pero creo que no le ayuda a hacer esta comparación.
O sea, a mí no me parece una comparación aquí.
Aquí dice, ni siquiera estoy tratando de convencerte de nada.
Si te encanta tu forma de compilar JavaScript actual y todas las herramientas, frameworks y dependencias, oye, genial.
Disfruta.
Haz cosas geniales.
Pero si no lo haces, aquí tienes una alternativa que igual te puede gustar.
¿Vale?
Bueno.
Y ojo porque encima Sam aquí le mete y dice, oye, me encanta tu contenido y tu perspectiva.
Pero sinceramente, una de las principales razones por las que mi video baja de hate fue que no funcionaba.
O sea, de que no tenía buen rendimiento.
Que no era performante.
La interfaz de usuario.
No puedo mirar el código, así que no tengo ni idea de dónde estaba el cuello de botella.
Pero si es el modelo de esto, no estoy seguro de quién lo compra.
Y es que es verdad.
El hecho de no minificar el código y no empaquetarlo, a mí me parece un error horrible.
Y no lo digo con maldad.
Lo digo como que creo que podrían mejorarlo.
Porque es una herramienta que tenemos tan cerca y que podemos...
Lo bueno de empaquetar es justamente el evitar que tengas que hacer muchas peticiones HTTP,
que sabemos que justamente son muy costosas.
Pese a HTTP2.
Que HTTP2, oye, está genial.
HTTP2 nos ha ayudado un montón al hecho de hacer multiplexing, de hacer más de una petición,
de poder reutilizarlas.
HTTP3, que es lo que utiliza Google y un montón de páginas nuevas, es incluso mejor todavía.
Pero aún así, de que como son mejores, ya lo podamos hacer.
Se trata de que lo que estamos haciendo, optimicemos al máximo y además saquemos el rendimiento de esto.
Y entonces hagamos un win-win de las dos cosas, ¿sabes?
Porque si no, no tiene mucho sentido.
No estamos sacando el 100% de lo que podemos conseguir.
Perdón por no saber, pero que es minimizar.
Tú, lo que haces normalmente, lo que hacemos aquí, imagínate que tú tienes este JavaScript.
Este JavaScript está bien porque es legible, mantenible, cualquier persona lo puede leer y tal.
Es WC, es un compilador de JavaScript y aquí, por ejemplo, puedes ver cómo se minifica el código.
Pero si esto tú lo envías al navegador, si hacemos un byte counter, podemos ver que esto ocupa 1,8K, ¿vale?
¿Por qué? Porque un carácter, cada carácter es un byte.
Entonces, si tienes 1,891 carácteres, más o menos, porque hay algunos carácteres especiales, saltos de línea y tal.
Entonces, más o menos, 1,9K, 1,9K.
Si tú minificas el código, le damos este input, ¿vale?
Lo que vamos a hacer, no vamos a hacer ninguna transformación.
Lo único que vamos a hacer es darle a este minify, ¿vale?
Minify. Vamos a poner que se quede el código igual.
Solo dándole al minify, lo que vamos a ver es que está minificando el código, obviamente.
Lo primero que hace es cargarse todo lo que serían los saltos de línea.
¿Por qué? Porque el salto de línea es más costoso que un punto y coma.
Luego, lo que podemos encontrar, a lo mejor en algunas cosas, es que algunas variables lo que hacen es, pues, hacerlas más cortas, quitarle el nombre, yo que sé.
Este puerto, bueno, veo que este puerto, ¿ves que lo ha dejado exactamente igual?
Pero bueno, que si miramos esto, lo ponemos aquí, 300 bytes menos.
¿Veis? Aquí lo tendríamos.
Lo que estamos haciendo aquí es minimizar, es 300 bytes menos.
Así que lo que estamos haciendo es conseguir enviar menos bytes.
Luego, lo que hacemos con esto es comprimirlo.
Y para eso podemos utilizar broadly, broadly online o getzip.
Getzip es más antiguo y no tiene tanto sentido.
Pero a ver, input, a ver si encontramos un broadly para que lo veamos.
Text to broadly, broadly, mira este por ejemplo.
Y esto lo que hace es comprimirlo a un formato que se llama broadly, que lo tendríamos aquí.
Y aquí tendríamos el texto comprimido.
Fíjate, esto sería 466 bytes según esto.
Bueno, porque aquí no sé por qué no me lo ha copiado todo.
Pero fíjate que nosotros tenemos 466 bytes y luego lo que enviamos serían 328.
O sea, sería cuestión de que estamos ahí primero minificar y luego comprimir.
La ofuscación no ayuda, Carlos.
La ofuscación no ayuda.
La ofuscación todo lo contrario.
La ofuscación, aparte de que es bastante polémica, de que realmente sirva.
La ofuscación, una buena ofuscación, ya te digo que no ayuda.
La ofuscación lo que hace es que ocupe más tu código JavaScript.
Porque lo que se hacen son técnicas justamente para ofuscar el código, no para minificarlo.
Y lo que va a ocurrir con la ofuscación, y lo podéis ver de cualquier forma.
¿Veis este código?
Si vosotros lo ofuscáis, ¿vale?
Le ponemos ofuscade.
¿Qué es lo que va a pasar?
Que este código va a ser mucho más complejo de ejecutar.
Porque fijaos que hay parseInt, no sé qué.
O sea, este código va a ser mucho más difícil de que lo entienda el navegador, de que lo ejecute.
Y además, a la hora de enviarlo, también va a ser más difícil y más complejo.
O sea, no sirve para rendimiento, sino que sirve realmente para que no se entienda el código.
Pero hay tantas herramientas de ofuscación que ya os digo yo que no tiene mucho sentido.
¿Vale?
Entonces, esto es lo que hablaba de HH.
Ya no tiene más sentido, pero es más seguro.
Polémico.
Yo, la verdad, no recomiendo para nada que ofusquéis el código.
Si os digo yo algo, es que no ofusquéis el código porque no tiene ningún tipo de sentido.
Ofuscar, hoy en día se puede deofuscar muy fácil.
Estáis, por desgracia, haciendo que le vaya peor la página al usuario.
Y además, incluso le puede saltar hasta el antivirus.
Porque muchos ataques se hacen con deofuscación.
Y si queréis algo seguro, no pongáis en el front.
No tiene sentido.
Alguien me preguntaba el otro día, ¿puedo ofuscar mi código para meter las keys?
No, ¿sabes?
No.
No hagáis eso directamente.
Ofuscar se intentaba antiguamente como para que nadie pudiese ver tu código.
Pero es que a día de hoy hay tantas herramientas que lo deofuscan que ya no tiene sentido.
¿Pero qué importa la experiencia del usuario?
Claro, ¿pero qué importa?
Pues es que importa es lo que más importa.
Básicamente es lo que más importa.