¿Quién no ha utilizado alguna vez en su vida jQuery? La librería por excelencia de JavaScript, nacida ya hace más de 10 años, en pleno fragor de la lucha por conseguir unos estándares aceptados en la web, se ha convertido con el tiempo en un estándar de facto en el desarrollo front-end, tan ampliamente aceptado que a veces es fácil olvidar que se trata de un elemento externo al navegador y que la verdadera sintaxis de JavaScript no empieza con «$».
Según las estadísticas, en enero de 2017 era utilizado por el 68.4% de los 10.000 sitios con más tráfico o en el 74.2% del top 100.000. Unas cifras verdaderamente asombrosas ¿De dónde viene este enorme triunfo, que convierte a jQuery en uno de los proyectos más exitosos de la historia de internet?
Como decíamos antes, nació en un momento complicado (uno de tantos) en el que JavaScript empezaba a utilizarse para algo más que para mover elementos por la página, pero los navegadores iban a rebufo de las necesidades de los desarrolladores, por lo que había que llenar nuestro código de comprobaciones para conseguir que fuese cross-browser. Entonces apareció jQuery y, a través de la normalización interna que hacía, consiguió que escribiendo una sola vez pudiésemos olvidarnos del navegador que estaba utilizando el usuario y nos centrásemos en desarrollar.
Otra de sus virtudes, en un mundo en el que aparecen nuevos frameworks de JavaScript con más frecuencia que el Cercanías de Renfe, es la estabilidad. Hay muy pocos casos en los que un proyecto de este tipo se haya asentado de tal forma que una década después siga estando tan vigente. Es cierto que sus mejores días ya pasaron, pero aún goza de una buenísima salud, y uno puede añadirlo a su lista de habilidades sin ningún miedo a que en breve deje de tener de soporte o incluso desaparezca.
Todo ese tiempo que lleva funcionando, unido a una comunidad de desarrolladores enorme que no para de contribuir, ha conseguido que la librería esté tremendamente evolucionada, depurada y optimizada, con un API y una documentación ejemplares, y una cantidad de plugins disponibles tal que es difícil tener una necesidad y que alguien no la haya solucionado previamente y puesto a disposición de los demás.
Por último, su curva de aprendizaje es muy agradable y satisfactoria, de forma que lleva muy poco tiempo empezar a manipular el DOM, añadir widgets o conseguir unos resultados espectaculares en relación al esfuerzo y tiempo invetidos.
¿Acaso jQuery es como Rafa Nadal?
Pues no, Nadal sólo hay uno y jQuery tiene una buena lista de defectos que hacen desaconsejable su uso. En primer lugar conviene recordar que no es un elemento incluído por defecto en el navegador, es decir, tendremos que cargarla antes de poder utilizarla. Y hacerlo antes que ningún otro de nuestros ficheros JavaScript en los que queramos sacar provecho de ella, condicionado así las dependencias. Y aunque su tamaño esté extremadamente ajustado para todo lo que ofrece (la versión 3.1.1 se queda en 85Kb una vez minificada), no dejan de ser unas decenas de kilobytes que obligamos a descargar al usuario, y que por tanto ralentizan la disponibilidad de la página cuando el propio navegador incluye JavaScript nativo con el que posiblemente podríamos realizar las mismas funciones.
Precisamente en su propio origen reside uno de los motivos de su declive: igual que nació con la idea de normalizar y hacer más limpio el código que la Segunda guerra de los navegadores nos estaban obligando a generar, el final de la lucha o al menos la paz relativa que ha supuesto la adopción general de unos estándares tanto en CSS como en JavaScript, ha propiciado que ya no haga falta recurrir a jQuery para alcanzar esa limpieza. Una buena muestra de ello se puede encontrar en la estupenda web «You might not need jQuery«, donde se pueden encontrar, hechos con Vanilla JS, ejemplos alternativos de muchas de las funcionalidades que solemos demandarle a la librería.
Otra consecuencia negativa viene motivada por su propio éxito: su aceptación y difusión ha sido tal que muchos desarrolladores han olvidado cómo escribir simple JavaScript, o incluso, al incorporarse al mundo laboral más tarde del 2006, ni siquiera han tenido la oportunidad, necesidad, tiempo o energía de realizar ningún proyecto sin el apoyo que ofrece jQuery. Y eso, por muy fiable y sólido que sea, no deja de ser un inconveniente pues nos hace más dependientes al tener como que pasar por un puente para llegar a una de las tres áreas básicas del Front-end. Tan simple como que, si no se carga jQuery, no podemos añadir comportamiento a nuestras webs. Demasiado importante como para poner todos los huevos en una cesta si no es a cambio de unas ventajas que lo compensen.
En la lista de aspectos más puramente técnicos que conviene tener en cuenta están la mayor facilidad para realizar TDD con Vanilla JS que con jQuery, la dificultad para exportar nuestro código jQuery a frameworks de JavaScript o patrones MVC, su poca adecuación para realizar web apps al estar más orientado a la manipulación del DOM, o su incompatibilidad para realizar mobile apps usando frameworks carentes de DOM, tales como React Native o NativeScript. Para ampliar información de estos aspectos, resulta muy interesante leer este diálogo a 6 que hace unos meses tuvo un grupo de desarrolladores y que en parte han motivado este post.
Pues sigo sin saber qué hacer
Hemos repasado las ventajas y desventajas de jQuery. En la segunda parte exploraremos qué necesidades más habituales puede encontrarse un desarrollador de un estudio semejante al nuestro, si existen alternativas para afrontarlas sin necesidad de jQuery y si sale rentable abordarlas, y por último trataremos de emitir un veredicto sobre la conveniencia o no de abandonar jQuery en nuestros proyectos y que pase a formar parte de la historia junto al hack para evitar el doble margen de elementos flotados.
Sin caer en el spoiler, os adelantamos que, como casi siempre que hay una discusión, ninguno de los dos bandos va a quedar satisfecho. Os esperamos en breve 🙂
—
Carlos Espada
Técnico de deflectores
cespada@elemento115.es
