Con la línea siguiente:

Event.observe(window, 'load', function() {});

Podremos ejecutar algo una vez la página esté completamente cargada. Muy útil si queremos asegurar por ejemplo que un div al que queremos interactuar está ya cargada en la página, o si queremos realizar cualquier acción tras la carga completa de la página. Esto es que están todos los elementos del DOM renderizados y todo el resto de elementos web cargados también: js, css e imágenes incluidos. Las peticiones AJAX no entrarían en este saco ya que son peticiones asíncronas y no se carga secuencialmente en el waterfall de la carga de la página.

Hasta aquí todo perfecto. Pero también tenemos otra condición que se usa mucho que es:

document.observe('dom:loaded', function(){});

Esta línea es muy similar a la anterior pero no son exactamente iguales. ¿En qué se diferencian?

Similares pero no iguales

¿Cuál es la diferencia? Pues en el caso del ‘dom:loaded’, éste avisa de cuándo están todos los elementos DOM cargados, independientemente de si están todas las imágenes descargadas.

Conocer la diferencia de estas dos técnicas de control de carga permitirá dominar con más precisión cómo y cuándo queremos ejecutar nuestros scripts, y podremos mejorar la velocidad de carga de la página, y prevenir posibles bugs.

Con jQuery es lo mismo

Antes he mencionado de los métodos que se usan en Prototype, pero con jQuery ocurre exactamente lo mismo. La sintaxis varía ligeramente, eso sí. La relación sería la siguiente:

// Carga del window.onload
// En Prototype
Event.observe(window, 'load', function() {});
// En jQuery
$(window).load(function(){});

// Carga del dom
// En Prototype
document.observe('dom:loaded', function(){});
// En jQuery
$(document).ready(function(){});

Los listeners son una herramienta muy potente, y no solo sirven para observar la carga de la página sino que se le puede dar muchos más usos.

Entre las novedades que explica Sitepoint, me ha parecido interesantísimo:

console.timeStamp

Han añadido un nuevo comando API console.timeStamp(), que permite marcar una linea de tiempo en la gráfica de tiempo-carga que hay en el panel Red. Esto me parece buenísimo ya que permitirá depurar más y mejor, se podrá trabajar mucho mejor temas de optimización y velocidad de carga de la web, etc.

Solo por esta característica ya me lo estoy bajando.

Preview del color

Otra característica chula es que ahora Firebug muestra los colores en los formatos hex, rgb, rgba, hsl y hsla; y además te muestra en una tooltip pequeñita una previsualización del color.

También se destacan otras características como formato de dimensiones de cajas CSS3, Opciones del panel DOM, dirección IP en el panel Red, preview HTML en el panel Red (útil para ver respuestas JSON que devuelven html) y opciones adicionales para editores externos.

Puedes encontrar un resumen más completo en el artículo de Sitepoint o en el sitio oficial de Firebug.

Descargar Firefox 5

Descargar Firebug 1.8

Los pasos para instalar el plugin son*:

1. Ir a “Help -> Install New Software -> Add”
2. Introducir datos
   1. Name: “Rockstar Optimizer”
   2. Url: “http://update.rockstarapps.com”
3. En la lista que se carga debajo, checkear los componentes que quieres instalar (yo puse todos)
4. Ir dando al botón NEXT hasta finalizar la instalación.
5. Te pedirá que resetees el Eclipse. “Yes”.

* La versión Eclipse que he usado para instalar el plugin es “Eclipse IDE for JavaScript Web Developers. Version: Helios Service Release 1. Build id: 20100917-0705″

Cómo usar Rockstar Optimizer

Una vez instalado el plugin, es muy fácil de usar. Tan solo has de seleccionar el archivo JS (o los archivos JS) que quieres comprimir y/o minimizar y darle al botón derecho. Aparecerá una opción nueva denominada “Rockstarapps”. Dentro de esta opción aparecerán las diferentes acciones que puedes aplicar como:

• Comprimir Javascript
• Validar JsLint
• Concatenar Javascripts (si seleccionaste varios)

La primera acción de comprimir es la que más me interesa y está bastante bien porque la acción es altamente personalizable. Te da a elegir diferentes modos de compresión como el YUI Compressor, o el Closure Complier de Google. Después hay una serie de opciones para configurar el nivel de compresión y validación que se quiere aplicar.

La ventajas de añadir un paso “Build” en la fase de desarrollo

Optimizar los ficheros JS y reducir el número de peticiones está en el orden del día. En la actualidad hay una gran variedad de opciones y alternativas para realizar un “Build”. Se pueden crear procesos Ant en el Eclipse o Netbeans, se puede incluso automatizar este proceso para que lo haga el propio servidor, existen herramientas online que te minimiza y comprime cualquier script o fichero JS, etc.

Lo que me ha gustado de este plugin Rockstar Optimizer es su facilidad de uso y que está integrado en el editor que uso a diario para programar.

¿Lo has usado? ¿Cuál es tu impresión?

Fuente: rockstarapps

El uso de fuentes de letra chulas en nuestras webs siempre había sido mucho más complicado de lo que debería. Suerte que hoy en día tenemos a disposición distintas técnicas y scripts como el Cufon que nos ayudan renderizar las páginas con la tipografía que mejor le sienta al diseño.

Google (como no) nos trae una alternativa más, y ha sacado una nueva versión 2 de su Google Web Fonts. ¡La pinta no puede ser mejor!

Usar fuentes en la web nunca fue tan fácil

Google Web Fronts es una herramienta online con una colección generosa de fuentes a elegir, y el uso es algo tan sencillo como introducir una línea en el HEAD como:

<link href='http://fonts.googleapis.com/css?family=Redressed&v2' rel='stylesheet' type='text/css'>

font-family: 'Redressed', cursive;

Para dicha reunión recopilé un par de frases que encontré por Internet y que me resultaron conceptos muy interesantes. Dicen así:

HTML que tenga sentido sin JS no debería ser creado por JS.

HTML que únicamente tenga sentido con JS debería ser generado por JS.

Es un concepto sencillo de entender pero no tan sencillo de aplicar. Entender el concepto permitirá al programador tomar decisiones más acertadas de cuándo o dónde han de generar el código HTML: directamente en la plantilla o desde JS. Incluir este concepto en la metodología de trabajo de todos evitará que de forma totalmente arbitraria nos encontremos con casos mezclados y sin coherencia.

Por lo demás, usamos – al igual que muchos – las convenciones de codificación que recomienda Crockford en su página:

http://javascript.crockford.com/code.html

Si una persona te dice que es realmente fácil hacer cosas increíbles, entonces, o te está mintiendo, o tiene pocos conocimientos de estándares.

Los que trabajamos profesionalmente en este sector sabemos muy bien de qué habla. Cuántas veces habremos oído aquello de ‘Pero si esto se hace en 10 minutos’ o ‘Si HTML lo sé hacer hasta yo’ o ‘No entiendo como puede ser tan complejo esto, si eso lo tienen todas las webs’.

En fin, sin comentarios a estas frases…

Pues yo respaldo este comentario de Thomas Fuchs. No porque haya criticado a jQuery en concreto, sino más bien la fuerte dependencia que tienen muchos desarrollador de los frameworks, pero sobretodo de los plugins.

Conocimientos: Javascript, jQuery, etc.

Mi puesto en mi trabajo me ha permitido ver a lo largo de los años un buen puñado de CV’s de front-end developers (fronteros), y algo que me hace gracia es ver cómo muchos muchísimos escriben que tienen conocimientos sólidos en Javascript, y en especial jQuery. ¡Como si fuera más importante saber jQuery que Javascript! Pues voy a ser muy directo para este tipo de personas: Que hayas instalado y personalizado un par de plugins en un blog o una web como el lightbox y otra pijadita más, no te da derecho a indicar que ya sabes programar en Javascript, oh! Que domines jQuery no te convierte en un gurú del Javascript.

A veces, nos flipamos mucho en los CV’s, y eso puede acabar jugando en contra de tus intereses. A veces conviene ser más humilde y sincero, que ser un gurú.

En un artículo anterior de la página oficial ya hemos podido ver un avance de todo este paquete de mejoras y bugfixes que incluía las release candidates de esta versión 1.7 de Prototype. De dichas mejoras se destacan:

• Migración al motor de selectores CSS llamado Sizzle (el que usa jQuery).
• Nuevos métodos como Element#on, que permite simplificar la gestión de los eventos (handlers); o Element#Layout, perfecto para llevar un control preciso de cada pixel de nuestros elementos del DOM.

Sin duda esta release de Prototype 1.7 es una gran noticia para los que usamos esta gran librería, y parece que el Core Team están haciendo muy bien las cosas, ya que han atacado los puntos débiles que siempre había tenido esta librería como el rendimiento con el uso de selectores CSS para controlar elementos DOM respecto a otras librerías como jQuery.

Y lo siguiente será la llegada del Scriptaculous 2!! Scripty 2 + Prototype 1.7 será explosivo!

¿Ya has actualizado tu versión de Prototype a 1.7 en tu proyecto? ¿Has notado alguna mejora?

Scripteka es un directorio de extensiones y componentes JS para Prototype bastante completo y muy útil. En ella puedes encontrar una diversidad de extensiones desarrolladas por programadores de todo el mundo. Desde diferentes extensiones para crear galerías de imágenes que sigue el estilo del popular Lightbox, extensiones para optimizar la carga de los elementos de la página (LazierLoad), para validar formularios (JSValidate) y un largo etcétera.

Lo mejor de Scripteka es que no tienes que andar buscando por buscadores algún componente o script, sino que está todo recopilado y centralizado, y de forma progresiva hay más extensiones dadas de alta.

Yo llevo bastante tiempo usando esta página como referencia para mis proyectos y sin ir más lejos, para Cine25 uso diferentes componentes obtenidos de Scripteka como por ejemplo:

• Prototube: Crea una capa para poder insertar videos de Youtube de forma fácil o mostrar capturas  (thumbnails) de los videos de forma automática. Lo uso para los tráilers.
• Livepipe: Extensión que dota a Prototype de más funcionalidades como abrir modales, crear tabs (pestañas) de forma ágil entre otras cosas.
• Protoload: Controlar visualmente que se está cargando la página o una parte de ella, con los típicos iconos que va rotando o cargando.

En Cine25 evidentemente tengo desarrollos JS propios en el proyecto, porque muchas funcionalidades son muy específicas de la Red Social, pero no todo está hecha a manija. Si ya hay un módulo o componente que ha creado otro publicado por Internet  y va fenomenal, porque no aprovecharnos y ganar tiempo para implementar otras cosas!

Resultados del test

Según los resultados que me han salido a mí, el framework que mejor y más rápido trabaja con el uso de selectores css es  la última versión de YUI 3.1.0 (39*), y le pisa los talones jQuery (40) y DOMAssistant 2.8 (41). Si lo comparo con Prototype 1.6, que es el framework que más he usado (y uso), ha obtenido un tiempo de 58, que es claramente más alto que estos primeros, y vemos que Prototype rinde menos. No obstante, hay buenas noticias al respecto ya que la última versión  de Prototype, 1.7, que ya está ultimando su salida oficial (ya van por la Release Candidate 3), viene integrado Sizzle, el motor que usa jQuery para los selectores. Aquí explican esta integración, entre otras cosas.

Comparando la nueva versión Prototype 1.7 RC2, ésta obtiene un tiempo de 42, que le recorta prácticamente toda la distancia que tenía jQuery de Prototype, igualándole pues en rendimiento del uso de selectores. Gran noticias para usuarios del Prototype, y mejor para empezar un lunes de trabajo como hoy

Como dato a destacar, el que realmente va más rápido y desbanca a cualquier es hacer uso de javascript nativo (29). Aunque bueno, creo que no es comparable con los frameworks, aunque en el test lo han incluido. Sus motivos tendrán.

* menor es mejor