17/03/2008
17/09/2008
11/06/2008
21/02/2008
10/03/2008
26/03/2008
Recientemente he publicado una librería open source llamada Jawr. Se trata de una herramienta que ayuda a los desarrolladores web en la creación y mantenimiento de código javascript usando un sistema modular, en lugar de meter todo dentro de uno o dos archivos enormes. También hace funciones de compresión, tanto para javascript como para CSS. Además de permitir estructurar el código en archivos separados, reduce los tiempos de carga de las páginas al minificar y comprimir los archivos hasta la séptima parte de su tamaño original.
La actual tendencia hacia aplicaciones web "ricas" lleva a un aumento en el uso de javascript y AJAX. Esto implica que el volumen y complejidad del código javascript en una aplicación promedio ha crecido considerablemente.
El programador java está acostumbrado a distribuir el código en módulos separados (clases), cada uno de los cuales reside normalmente en un archivo independiente. Sin embargo, al desarrollar en javascript hay que tener en cuenta que los clientes deben descargarse el código mediante peticiones HTTP. Los navegadores más usados hacen solo dos peticiones HTTP concurrentes contra el mismo host, de modo que cuantos más archivos haya que descargar, tanto mayor será el tiempo que tarda en cargar una página.
En consecuencia, una aplicación en la que el javascript esté altamente modularizado tendrá unos tiempos de carga de página inaceptables. Podeis leer un artículo muy interesante sobre este tema en este artículo de uno de los autores de Flickr: Serving JavaScript Fast.
¿Cómo se resuelve este problema? Las soluciones más habituales normalmente dificultan el proceso de desarrollo:
Jawr permite crear archivos .js y .css 'virtuales' que se denominan bundles (paquetes). Usando un sencillo archivo .properties, se añaden archivos individualmente o directorios enteros a los paquetes. Funciona del siguiente modo:
Jawr tiene un modo de ejecución para desarrollo en el que los paquetes no se utilizan. En lugar de esto, la tag library crea enlaces individuales para cada uno de los miembros del paquete, que se sirven sin minificar ni comprimir. Esto permite realizar un desarrollo sobre directorio WAR explotado, en el que podemos cambiar código javascript, refrescar una página y ver inmediatamente los cambios.
Para cambiar del modo de producción al de desarrollo no hay más que cambiar un flag del archivo .properties de configuración. Otras ventajas incluyen el uso de técnicas de cacheo agresivas, para forzar a que los clientes no descarguen los paquetes más de una vez, la posibilidad de declarar paquetes globales que se cargan automáticamente en cada página, mecanismos sencillos para especificar el orden en que se empaquetan los archivos, etc.
Eso sí, la documentación, aunque bastante completa, está toda en inglés... sorry! :-(
Podeis descargarlo de esta dirección. (También se puede usar el Maven).
Etiquetas: j2ee, java, javascript, css
Suena muy interesante, ¿Se te ocurre alguna opción para los hijos pródigos que no usamos JSP/JSF? ¿Hay algun "bean" o clase que se pueda llamar para convertir esos paths que no sea dentro de un taglib?
Por otro lado, si quieres que anunciemos el lanzamiento de la herramienta en el newsletter de la comunidad JavaTools, o estar enlazado desde el directorio de la comunidad, ponte en contacto conmigo ;).
muy buena idea, hasta ahora solo conocia esta tecnica de comprimir recursos en ICEfaces, tu proyecto es interesante porque puede ser usado en cualquier otro framework y se ve bastante ligero.. enhorabuena :D
Gracias por los comentarios. Por cierto, me hice un lío y acabé publicando la noticia anónimamente, sorry.
En cuanto a lo que me comentas de no usar un taglib, debería de ser fácil (porque para futuras versiones ya pensaba hacer algo al respecto). Las taglib son clases medio tontas que delegan en otras que son las que llevan el peso de la generación de enlaces, y que no dependen del API servlet/JSP.
Si realmente te interesa jugar con los fuentes, echale un vistazo al paquete net.jawr.web.resource.bundle.renderer, y también a la clase net.jawr.web.taglib.AbstractResourceBundleTag para entender cómo se invocan los BundleRenderer. ¡Las contribuciones serán bienvenidas! :-)
pregunta, hablas que comprimes los recursos mediante gzip, sin embargo en el articulo que recomiendas (por demas excelente articulo), hablan de los inconvenientes al manejar esta estrategia, tu libreria ayuda en esto de alguna forma?
Por un lado el artículo habla del problema de procesamiento excesivo que tiene el comprimir los archivos en cada petición. Jawr realiza la compresión gzip al desplegar la aplicación, y mantiene una copia comprimida y otra descomprimida (opcionalmente almacenadas en memoria) para poder servir ambas versiones. Por tanto, no hay problemas en cuanto a rendimiento.
Por otro lado, el artículo habla de ciertos navegadores que tienen problemas con contenido gzip, aunque envían la cabecera indicando que aceptan este tipo de compresión. En cuanto a Netscape 4, Jawr no aporta ninguna solución, pero el uso de este navegador es hoy día extremadamente minoritario por lo que no debería suponer un problema en un caso real de uso. A fin de cuentas, si una aplicación tiene tanto javascript como para usar Jawr, dudo mucho que sea compatible con NS4 (lo dice uno que sufrió en sus carnes el desarrollo de JS para este navegador).
Por lo que respecta a Internet Explorer, se puede establecer un flag en la configuración para no enviar contenido gzip a este navegador. Los problemas de IE con gzip alcanzan a la versión 6, aunque sólo hasta cierto service pack que Microsoft publicó mediante Windows Update hace ya cierto tiempo. Por tanto,aunque no se puede cuantificar (o se puede, pero desconozco los datos), deberían quedar pocos usuarios de IE6 con este problema.
Mediante este flag Jawr permite decidir qué hacer de acuerdo con el uso que vaya a tener la aplicación. Por ejemplo, Jawr se está usando en una aplicación de intranet en la que se sabe que el navegador es IE6 o superior, con el service pack actualizado, por lo que se envía gzip a todos los clientes. Pero si esperamos clientes con IE5, o desconocemos totalmente el tipo de clientes que van a acceder a la aplicación y queremos estar seguros de ofrecer el máximo de compatibilidad, no hay más que cambiar un parámetro de configuración. Por desgracia, nos hace perder la posibilidad de mandar gzip a clientes con IE6-7 que no tendrían problemas en manejar este contenido. Aun así, se sigue enviando javascript minificado, y seguimos contando con todas las demás ventajas de Jawr.
Ya puestos y por si te sirve, es muy facil obtener gratuitamente un hosting de Atlassian FishEye para visualizar tu repositorio del proyecto (por ser de java.net es casi automatico) de forma más agradable/funcional que con el "navegador de codigo" de CollabNet. Y ya puestos, Confluence, Jira y el profiler YourKit también tienen licencias gratuitas para este tipo de proyectos
A ver si cuando tenga un momento le echo un ojo para poder usarlo sin los taglibs.
S!
Escribe tu comentario