Gerason Vines decía, usar jQuery ha resultado un 53% menos de JavaScript y un archivo un 36% más pequeño que la versión con Inmascript 6.
He añadido incluso unos rendimientos entre jQuery y tal.
Aunque parece aparentemente que la sabiduría común es que jQuery está muerto, una tecnología muerta porque ha sido reemplazada por Inmascript 6,
todavía no encuentro los hechos que soporten este argumento.
Es verdad que ha mejorado, que ha cerrado un poco el gap, pero que la introducción de Query Selector ha sido fantástico y tal,
pero el valor de jQuery nunca ha sido ese, sino que ha sido mucho más, ha ido más allá y tal.
Y aquí sigue hablando de que todavía es más fácil utilizar jQuery que utilizar Inmascript tal cual, JavaScript, vanilla.
Y esto es importante porque tú que soy líder de vuestro campo están viendo vuestras recomendaciones
y entonces te vas a equivocar si le dices que jQuery puede hacer esto y lo otro.
Y lo único que quiere es que tengas evidencia y que balancees tu opinión para que encontres la persuasión, la evidencia para persuadir.
No digas vanilla, porque no digo vanilla, pero sí se utiliza un montón.
Vanilla JavaScript, vanilla JavaScript, vanilla JavaScript.
Bueno, total, que esto es lo que dice, ¿no?
Yo la verdad es que siempre alucino con estas cosas.
No sé la gente por qué se enfada tanto.
Es una cosa muy loca.
Yo de verdad a veces me lo he estado mirando.
Digo, esto, o sea, lo dice de verdad, pero tiene un repo.
Tiene un repo versus JavaScript.
A ver, vamos a ver, porque aquí tenemos esto.
Tiene unas cosas.
A ver, total lock, JavaScript lock, file size, total download size.
Fijaos en esto.
Igual yo soy idiota o algo, pero puede ser que esto de aquí sea más de un 200% más que lo de abajo.
O sea, es que igual soy yo que lo estoy viendo mal.
Pero puede ser que esto de aquí...
Ay, perdón.
Porque igual soy yo que lo estoy...
Pero este, este de aquí, puede ser que sea un 200% más que el de abajo.
No lo sé.
Igual me lo estoy imaginando yo.
Porque dice tecnologías, findings, o sea, cosas que ha encontrado.
Dice jQuery, 67 líneas, JavaScript lock, 45, file size, download size.
Vale, es que claro, si tú te estás descargando 70k a 2000, perdón, 2000, ni un 200, un 2000, perdón, perdón, madre mía.
200 veces más, es 200 veces más.
Es que el tema es, o sea, si tú te descargas 70k para ahorrarte menos de 20 líneas, ¿te compensa?
Esa es la pregunta que muchas veces te tienes que hacer.
O sea, si te ahorras 20 líneas de código, ¿vale la pena que te descargues 70.000 bytes?
Esa es la pregunta del millón que te tendrías que hacer.
Esa es una primera pregunta.
Que puede ser que sí.
O sea, que puede ser que sí.
Pero vamos a ver.
También vamos a ver el código.
Porque, ajá, vamos a ver la versión de jQuery.
Bueno, aquí tenemos el jQuery, ¿vale?
70k, vale, perfecto.
Aquí tenemos el código.
Vale, aquí vemos que page content, si es un objeto vacío, this.data, this.data.
Si la operación es page, ¿vale?
Haces esto, devuelve esto, devuelve esto.
Render, el pager, una función.
Devuelve aquí todo esto, añade la clase.
La verdad es que la API jQuery me ha gustado siempre, las cosas como son.
Vale, aquí un for each.
Si cuando está ready, tal, tal.
Bueno, o sea, que entiendo que el código de jQuery es este, ¿no?
Más o menos.
Vamos a ver en más script.
Vamos a ver qué ha hecho.
¡Vaya!
Ha creado una clase.
Vamos a ver esto, porque es que esto es para verlo, ¿eh?
Vale, ha creado una clase.
Vale, ¿por qué ha creado una clase?
¿Por qué tiene que poner las llaves en la siguiente línea?
¿Por qué tiene que poner las clases en la siguiente línea?
O sea, las funciones sí que se pueden poner en la misma línea.
Ah, no, aquí la pone en la siguiente.
Esto es un poco raro, pero bueno.
Vamos a ver.
Vale, o sea, tiene que crear clases.
Vale, dos clases que son pager.
Un poco forzado también, todo el tema de espacios y tal.
Vale, aquí sí, select, no sé qué.
Tampoco me parece.
O sea, vamos a poner que está en la comparación.
Que la verdad es que me parece un poco forzado tener que hacerlo en clases.
Que si él lo ve un poco más claro, pues tampoco me parece mal.
O sea, está bien.
También me parece un poco forzado el hecho de tener que ponerlo claro.
Como lo hace con clases y lo hace con propiedades, el hacer un salto para cada llave, pues obviamente ya le salen unas pocas líneas más.
Ya le salen unas cuantas líneas más.
Pero el ahorro de código, que al final son casi todo líneas.
O sea, no me parece tan grave el código que tiene que escribir.
No sé cuál era su punto.
Pero yo creo que aquí, aparte de una cosa que debería tener en cuenta, es el hecho de, te puede gustar más jQuery.
No pasa absolutamente nada.
Y jQuery es una biblioteca maravillosa.
Si es que no hay ningún problema.
Ahora bien, todo tiene un coste de oportunidad.
Y hay que entender que, por ejemplo, esta persona puede ser que él sepa jQuery.
Y es tremendo.
A lo mejor él es mucho más rápido y productivo utilizando jQuery.
Y puede tener sentido.
Pero una persona que, por ejemplo, ahora, de repente, tenga que aprender desde cero,
a lo mejor le cuesta más tener que aprender jQuery que hacerlo con Vanilla.
O sea, a lo mejor puede ser.
O al revés, puede ser.
No, yo ya sé jQuery, pues a lo mejor le tiene sentido y ya está.
Luego, por otro lado, yo creo que el punto no tiene sentido.
Por 20 líneas de código, el cómo vas a justificar meter una biblioteca de 70k por ahorrarte 20 líneas de código.
Yo creo que no tiene mucho sentido.
Y luego, tampoco es que, porque hablar de eficiencia o eficacia o todo esto,
el tema es, ¿y hay una alternativa mejor que jQuery que no ocupe 70k que lo pudieras hacer más rápido?
O sea, por ejemplo, pienso en Priak y hacerlo encima declarativo.
Priak ocupa, ¿qué ocupa?
¿7k o una cosa así?
Van del fobia.
O sea, el problema de decir, ah, es que con jQuery lo hago más rápido y no sé qué,
pues es que a lo mejor utilizas Priak, mira, que son 4k.
O utilizas, mira, la alternativa Umbrella JS.
Umbrella JS es una alternativa a jQuery, que es mucho más pequeña.
Y a ver, Umbrella, claro, es que dicho esto, ¿cuánto ocupa?
2k.
Entonces, el punto este de, no, es que con jQuery no sé qué, pues tío, pues utiliza Umbrella JS.
O es que tienes algo amoroso por jQuery, ¿sabes?
Porque es un poco raro.
Porque, bueno, pues utiliza Umbrella, son 2k, no son 70 como jQuery y ya está.
Y utilizas la API que te dé la gana.
El tema es que, no sé, no entiendo muy bien a veces este tipo de comparaciones.
Dice, este proyecto intenta comparar jQuery contra Más Cris 6 para analizar si hay algún mérito o argumento a favor o en contra de jQuery.
Utilizad lo que os dé la gana.
Todo tiene un coste de oportunidad, amigos.
Tampoco pasa nada.
Si utilicéis muchas veces jQuery, puede tener sentido utilizar jQuery.
No hay que demonizarlo.
Pero creo que tampoco, yo creo que es interesante conocer la plataforma porque obviamente el coste que tiene es cero.
El código es muy parecido.
Además, se puede llegar a hacer un custom element web components y tal que al final no vas a tener ningún problema.
Dice que se ahorra un 36% en bundle size usando jQuery.
Eso no tiene ningún tipo de sentido.
Eso es mentira totalmente porque es imposible.
O sea, es imposible que en bundle size te puedas ahorrar.
Yo creo que él se refiere sin contar la dependencia, ¿sabes?
O sea, él cuenta sin contar la dependencia.
Ese es el tema.
Claro, alguien le ha hecho una PR, ya dice con una pull request más, claro, en lugar de utilizar todas estas clases,
pues utiliza directamente con las funciones.
Que claro, tiene mucho más sentido.
Y seguramente con esto será, si no igual, incluso puede ser que menos líneas o las mismas líneas que jQuery.
Seguramente, seguramente no será tan bonita porque la API de jQuery está muy bien, pero son 70k, tío.
Es que las cosas como son.
El chat se cabreó por Clean Code y Meadu por la comparación.
Nah, hombre, no me cabreo, pero me parece muy infantil hacer estas comparaciones, la verdad.
Y mira que me gusta mucho el tema de jQuery, pero no sé.
O sea, yo no tengo nada en contra de jQuery, pero creo que es muy infantil hacer estas comparaciones.
Gracias.