Frameworks Javascript: jQuery, Prototype, Yui…

La lista es interminable, cada vez hay más y más frameworks Javascripts. Como desarrollador web debemos convivir con ellos a diario pero cuando se comienza un proyecto siempre nos ataca la misma pregunta. ¿Cual se adecua mejor a las necesidades?

Lamentablemente no hay respuesta fácil a este pregunta existencial ya que en ella influyen varios factores como que tecnología estamos usando, cuanta es nuestra experiencia en cada uno de ellos, cuanto tendremos que codificar por nuestra cuenta y cuanto podremos hacer reutilizando plugins.

Para quienes no saben, un framework Javascript es una librería cuyo objetivo es hacernos más fácil la tarea de programar con JavaScript. Son necesarias porque es muy frecuente encontrarse patrones y necesidades comunes durante un proyecto y en lugar de reinventar la rueda en cada proyecto estas librerías nos ayudan a poder reutilizar los patrones que ya implementan, o algún cliente implementó. También debido al variable soporte de JavaScript de todos los exploradores, escribir código que funcione bien en todos ellos es casi una misión imposible. Estas librerías intentan aislarnos de todas esas incompatibilidades tan nefastas entre Internet Explorer, Firefox, Safari, Opera, y demás y permitirnos centrarnos en agregarle valor a nuestro desarrollo en lugar de pasar días peleando contra los exploradores.

Como dije anteriormente existen infinidad de frameworks JavaScript, y cada día hay más, lo cual hace la decisión de cual elegir más difícil, sin embargo lo que más pondero yo a la hora de elegir es que tan bien conozco el Framework. Y este me parece es el punto clave.

Si uno busca en internet comparaciones entre los diferentes frameworks, todos dicen lo mismo: este es mas rápido que tal otro, este funciona mejor en el explorador casiDesconocido tal y demás, pero se pierde el foco de cual es el motivo por el cual existe, o sea, simplificar la vida del programador.

En lo personal cuando estoy desarrollando primero intento hacer que funcione correctamente, luego me preocupo por la velocidad y de ser necesario lo optimizo. Por lo tanto si un framework es 10 milisegundos más rápido que otro en recuperarme un elemento, pero ya sea por incomodidad o desconocimiento me lleva una semana de desarrollo extra lograr el mismo resultado.. ¿que me importa? !!! Tal vez a la larga esos 10 milisegundos no sean ni apreciables, o incluso puede darse el caso que el código resulte mas largo o complejo por otro lado y termine siendo peor. Es como la discusión por que voy a usar un lenguaje de programación de alto nivel si assembler es más rápido, y todos concordamos que la respuesta es.. ¡ porque sería inhumano e innecesario hacerlo de otra manera !

Dicho esto, el elegir un framework es mucho más fácil. Uso lo que conozco, lo que me resulta cómodo, lo que me ayudará a programar más rápidamente y mejor.

Pero luego cuando ya nos decidimos por un framework, nos ponemos a codificar el backend con alguna tecnología de servidor (cuya elección no es una respuesta muy diferente a esta, aunque hay más para debatir)  usando algún framework para dicha tecnología y nos damos cuenta que ese framework ya trae un framework Javascript por defecto. Si este es el mismo que yo tengo costumbre, entones no hay problema, sigo feliz de la vida. Pero si este es diferente ¿que hago?

Y aquí entra el siguiente tema… ¿Por qué conformarse con un único framework? Por suerte en este caso se pueden usar varios simultáneamente. Pero siempre hay un coste. La cantidad de archivos y tamaño a descargar y la incompatibilidad entre ellos.

La primera pregunta, de la cantidad de archivos, en lo personal no me parece un factor. Es verdad que el usuario lo sentirá al comienzo, pero los exploradores actuales tienen un muy buen cache que disminuyen los tiempos de carga considerablemente. Además, si la gente tolera páginas Flash, puede tolerar con más razón algunos archivitos JavaScript… y si efectivamente se demora mucho más, ahí si es un caso especial y hay que analizarlo más detenidamente, pero ya pasará a ser un problema porque molesta, no un posible problema que estoy inventando.

Pero el problema de la incompatibilidad entre los diferentes framework si es algo importante.

Creo que no lo dije aún, pero mi Framework favorito es Prototype, porque fue el primero que conocí, el que más fácil me resultó entender, porque es con el que soy más productivo. Sin embargo he trabajado también con jQuery y con YUI que son de los tres que hablaré. Otros framework los he usado muy poquito como para emitir una opinión.

El caso es que lamento decirlo, pero Prototype es el framework más incompatible de todos. El se apodera de todo el javascript y todo el DOM y redefine el lenguaje para que se parezca más a Ruby. Lo cual me parece excelente !. Según tengo entendido Prototype nació como la librería javascript de preferencia para Ruby on Rails, entonces es normal que nosotros, los desarrolladores de punta a punta, que tenemos que lidiar con el lado del servidor y el cliente deseáramos un poco de homogeneidad en todo el proceso en lugar de tener que aprender lenguajes y formas de pensar diferentes. Nuevamente, la productividad primero.

Esta filosofía hace que al cargarse Prototype, se modifiquen los objetos propios del core de JavaScript y DOM como Arrays, String, Event, HTMLElement. A todos se les inyectan nuevos métodos con la idea de facilitar el desarrollo. Pero eso puede romper otros frameworks que esperan que el javascript se comporte de una determinada manera.

En el otro extremos tenemos a YUI, un proyecto de Yahoo que sigue la filosofía de, javascript es javascript, ¿para que cambiarlo? acostumbrate!. Tampoco me parece mal, pero tal vez sea por costumbre, o tal vez sea por que soy viejo, pero no me acostumbro. En YUI todo se encuentra contenido en un namespace llamado YAHOO, y no extiende el DOM ni nada. Entonces es prácticamente inocuo y he podido usarlo exitosamente con Prototype a la vez. Decidiendo en cada tarea con que framework me resultaría más fácil hacer cada tarea. En lo personal, considero a YUI como YUI como una colección de Widgets en lugar de un Framework integral,  no estoy seguro si no es exactamente ese el enfoque que se la ha querido dar.

En el medio lo tengo a jQuery, que fue inspirado definitivamente por Prototype, pero intentando hacerlo más simple para el implementador. Lamentablemente utilizan algunas funciones en común con Prototype, pero a diferencia de Prototype, la gente de jQuery sabe que es probable que haya otra librería en conflicto y permite cambiarle el nombre a la función muy fácilmente, o directamente hacerla desaparecer. Actualmente puedo decir que jQuery y Prototype se pueden utilizar simultáneamente, pero no puedo decir que los plugins de estos sigan la misma filosofía y es ahí cuando comienzan a fallar las cosas.

Veamos un caso real, estoy trabajando con un equipo de personas en el desarrollo de un sitio web, este sitio web se esta realizando con Grails, (lo cual explica algunos de los post que últimamente estamos haciendo). Este Groovy Framework permite elegir varias librerías javascript entre ellas Prototype y YUI. Además de nuestro equipo de programadores, trabajamos con otro equipo de diseñadores.

En un mundo ideal, los diseñadores se encargarían de toda la vista, y nosotros ni nos enteraríamos que existe JavaScript, pero no vivimos en un mundo ideal. Entonces todos tenemos que saber todo.

Cual es nuestro estado entonces, los diseñadores hicieron el trabajo usando jQuery como Framework, nosotros comenzamos usando Prototype y porque algunas cosas eran más fácil de hacer con YUI agregamos esta librería al proyecto. Por ahora están coexistiendo pacíficamente, pero mi temor es que esto se encamine a ser una pesadilla.

Entiendo todas las partes jQuery es, a mi parecer, el más fácil de usar, y tiene una cantidad de Plugins de muy buena calidad asombrosa. Para proyectos simples muy visuales jQuery es mi primera opción

Prototype fue agregado por mi. Además como Grails se basa en Groovy, y este a su vez en Ruby, y prototype intenta asemejar JavaScript a Ruby, encaja bastante bien en el proyecto. Además la forma de programar en Prototype pareciera ser más orientada a objetos que el de los demás framework. Pero algunos de los efectos que se querían lograr y estaban planteados con jQuery no tenían un fácil equivalente con Prototype (hay también miles de plugins para Prototype, pero me parece que no tan buenos como jQuery, o al menos jQuery tiene una referencia mejor)

Finalmente como YUI tiene un plugin para Grails, y soportaba la creación de tablas populadas por ajax muy flexibles fue agregado YUI al proyecto también. Otros miembros del equipo, casi sin experiencia previa con Frameworks JavaScript tomaron se acostumbraron más rápidamente a UI que a los demás, y este comenzaron a utilizar para otras cosas.

Fuimos madurando como pudimos las diferentes funcionalidades y en este momento algunos efectos están con jQuery porque los diseñadores lo habían hecho así. Parte que requería programación especializada esta con Prototype. Y otra parte se encuentra con YUI. A veces todos en la misma página.

Mi opinión particular es que YUI tiende a necesitar mucho más código. Sentencias mas largas y no por eso mas claras. Ofrece mucha flexibilidad, pero a costa de una complejidad enorme. Y el plugin de Grails que debería haber simplificado el trabajo carece de algunas funcionalidades que terminan haciéndolo inútil  y terminamos escribiendo el código a mano. Y tareas que deberían tardar 3 horas terminaron tardando3 días, en parte por desconocimiento de la herramienta y en otra parte, porque a mi parecer la herramienta tampoco lo hacía muy fácil.

Algo a favor de YUI, es que la documentación oficial es abundante (hasta diría tan abundante que molesta) y que promueve algunos patrones muy interesante, pero a menos que el core de la aplicación sea Javascript me parece que todas las tareas que realiza son más fácilmente realizable con los otros frameworks.

Prototype es mi favorito, tengo cierta parcialidad para este framework. Es fácil de implementar, tiene varios plugins destacables pero esta pensando para codificar mucho, hay pocas cosas pre-hechas. Pero las que ya están hechas son increíblemente útiles y fáciles. Un punto en contra es que su documentación es demasiado concisa. O sea, solo sirve de referencia, si no sabes usarlo bien la documentación no ayuda y si lo dominas no la necesitas.

jQuery tiene una muy buena documentación también, y muchos más plugins prehechos o al menos de una calidad aceptable, pero pareciera más orientado a hacer las cosas rápidamente en lugar de estructuradamente.

Finalizando, esas son mis opiniones. Al final de cuentas hay un flamewar entre frameworks, solo espero que sea para el bien de la comunidad. Mi único consejo es que cada uno use el que se sienta más cómodo y evitar mezclar librerías si es posible.

Tal vez este post no le resulte muy util a nadie, pero la verdad, solo quería quitarme del pecho mis pensamientos sobre estas librerías en general.


3 Responses to “Frameworks Javascript: jQuery, Prototype, Yui…”

  1. Excelente informe!!
    Estoy aprendiendo JavaScript, soy digamos un “diseñador web jr.” jeje estoy tratando de aprender lo mas posible.
    Con HTML, CSS y hasta PHP me llevo bastante bien, pero con JavaScript no llego a entenderlo todavia…
    Por eso me interese mucho por tu informe sobre Frameworks, que tal vez me ayudan en mi tarea.
    Lei la mitad del articulo y por falta de tiempo terminare de leerlo mas tarde
    Pero por lo que acabo de ver, es excelente tu explicacion, muy clara.

    Muchas gracias y saludos!

  2. Acabo de leer todo el articulo completo, y aunque como te habia comentado antes se poco y nada de JavaScript, me parece excelente la explicacion que hiciste sobre estos frameworks.
    Voy a agregar tu blog a mis favoritos y revisar mas articulos porque me parece que tenes una redaccion excelente.
    Muy claras las explicaciones y respecto a tu ultimo comentario:
    A mi me sirvio tu articulo, al menos para entrar en el tema
    Saludos!

  3. Estoy buscando urgentemente alguien que me desarrolle un demo interactivo de un sistema desarrollado cliente servidor. Pense inicialmente en YUI pero puede ser en cualquier framework.
    Si alguien esta interesado porfavor contacteme via email lbernal@grupoverytel.com

Discussion Area - Leave a Comment