Planteadas en nuestro artículo anterior las ventajas e inconvenientes de utilizar jQuery, llega la hora de decidir qué hacemos con él. Y para ello el primer paso es responderse a una pregunta:
¿Qué necesidades de JavaScript tengo como desarrollador?
Es difícil encontrar una respuesta que no requiera una explicación de miles de píxeles de longitud, así que vamos a tomar el caso de un estudio como Elemento115, y pensar en los proyectos más recientes que tengamos. Eso nos permitirá limitar los casos de estudio.
Para empezar debemos distinguir entre proyectos de webs puramente comerciales, como microsites o páginas clásicas de empresa tipo «quiénes somos-productos-servicios-contacto«, y web apps, que son algo más complejas, en funcionalidad, evolución y tecnología. La definición del tipo de proyectos que encontramos en internet es bastante más poliédrica que está simple categorización, pero como primer acercamiento nos puede servir.
Pueden servir como ejemplo, en nuestro caso, Titanio Estudio y Zio Rød Brand Consultants.
En el primer caso nos encontramos con unas necesidades de JavaScript muy básicas: mostrar/ocultar elementos, plegar/desplegar secciones, añadir algún efecto visual, validar formularios… en general acciones que tienen mucho que ver con el filtrado y manipulación de elementos del DOM, y la aplicación de animaciones sobre ellos.
En el segundo, a lo anterior se le unen peticiones AJAX, preparación, envío, recepción y procesado de datos (que pueden llegar a ser bastante grandes y complejos), almacenamiento local de información, gestión dinámica del contenido, exportación del código a Mobile App… en definitiva, un conjunto de funcionalidades que requieren de una buena estructura del código que permita que sea robusto, escalable y testeable.
Definidas las necesidades, hay que pensar cuál es la mejor opción para satisfacerlas.
¿Es jQuery la alternativa que más me conviene?
Esta es la pregunta del millón, y el motivo de estos dos artículos. Y la respuesta es… depende.
Para proyectos muy sencillos, las ventajas de jQuery se ven potenciadas pues nos permiten alcanzar resultados muy óptimos en muy poco tiempo, y por la propia naturaleza del proyecto será raro que nos encontremos algunos de sus inconvenientes, o al menos no de forma que nos afecte demasiado. Por estos mismos motivos podemos llegar a plantearnos usarlo si es que seguimos una metodología en la existe una entrega rápida de prototipos funcionales de forma recurrente.
En el caso de web apps, podemos empezar a dudar, y con motivo. Si bien es cierto que muchos de ellos serían abordables y correctamente resolubles con una buena arquitectura basada en jQuery, puede que no sea lo más óptimo, pues nos obligará a hacer un trabajo extra para llevar la librería a los límites que queremos al no estar diseñada para ello, cuando usando Vanilla JS podríamos obtener los mismos resultados de forma más natural y con un código más fácil de testear y exportar.
Si a esto se le unen otros factores como el equipo de desarrollo con el que cuentes, el tiempo del que dispongas, los navegadores a los que tengas que dar soporte, la deuda técnica que seas capaz de asumir… hay tantos factores con tantas posibles alternativas que resulta imposible elaborar una respuesta absoluta. Para cada caso habrá que tener en cuenta las conclusiones anteriores y analizar, según los factores externos, qué es lo mejor.
¿Entonces?
Como hemos visto, el escenario que se nos presenta no es sencillo: multitud de situaciones iniciales distintas, y variedad de ventajas e inconvenientes de cada decisión, lo que nos lleva a la imposibilidad de encontrar una respuesta clara a la pregunta que nos hacíamos al inicio: ¿qué hacemos con jQuery?
Existiendo alternativas a muchas de las cosas para las que veníamos usándolo, quizá la mejor opción sea la de casi siempre: no tomar ninguna decisión radical, empezar a probar desde ya mismo a hacer proyectos sin jQuery y evaluar el proceso. Y poco a poco, sin abandonarlo del todo, ir añadiendo a nuestro repertorio técnico el Vanilla JS de la misma forma que en su momento hemos hecho con otras tecnologías, hasta llegar al punto de disponer de un elemento más con el que decidir cómo abordamos los proyectos.
Porque, que no se nos olvide en medio de esta vorágine tecnófila, lo importante en nuestra profesión es resolver problemas de la mejor forma posible. La herramienta que utilicemos para ello no importa.
