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.

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

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

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

Internet Explorer

Para detectar si usa Internet Explorer sin tener en cuenta la versión:

var ie=(document.all)? true:false;
if (ie) alert('Su navegador es Internet Explorer');

Internet Explorer 6

Muchos sabemos que IE6 es un caso especial. El siguiente script nos ayudará a detectar este caso y controlarlo:

var is_ie6 = (window.external && typeof window.XMLHttpRequest == "undefined");
if (is_ie6 ) alert('Su navegador es Internet Explorer 6');

Safari

Para detectar el navegador de Apple:

var is_safari = navigator.userAgent.toLowerCase().indexOf('safari/') > -1;
if (is_safari ) alert('Su navegador es Safari');

Google Chrome

Aunque es un navegador que cumple bastante fielmente los estándares, sigue comportándose en determinados casos de forma especial. Controlaremos este caso así:

var is_chrome= navigator.userAgent.toLowerCase().indexOf('chrome/') > -1;
if (is_chrome) alert('Su navegador es Google Chrome');

No incluyo ningún script para detectar si el navegador es Firefox ya que es un navegador que cumple al 100% los estándares, el cual nos permite tratarlo como el caso por defecto.

El objeto Navigator

En los últimos 2 casos vemos que usamos el objeto navigator que contiene la info que buscamos. De hecho podríamos usar este objeto navigator para detectar cualquier navegador, ya que navigator.userAgent.toLowerCase() nos indica el tipo de navegador que usa, la versión y más información que nos puede servir para controlar cada caso.

Haz clic aquí para ver un ejemplo del objeto Navigator.

Al hacer clic te debe de salir la siguiente información:

Propiedades

Las propiedades de Navigator que podremos consultar son:

• appCodeName. Cadena que contiene el nombre del código del cliente.
• appName. Cadena que contiene el nombre del cliente.
• appVersion. Cadena que contiene información sobre la versión del cliente.
• language. Cadena de dos caracteres que contiene información sobre el idioma de la versión del cliente.
• mimeTypes. Array que contiene todos los tipos MIME soportados por el cliente. A partir de NS 3.
• platform. Cadena con la plataforma sobre la que se está ejecutando el programa cliente.
• plugins. Array que contiene todos los plug-ins soportados por el cliente. A partir de NS 3.
• userAgent. Cadena que contiene la cabecera completa del agente enviada en una petición HTTP. Contiene la información de las propiedades appCodeName y appVersion.

Métodos

• javaEnabled(). Devuelve true si el cliente permite la utilización de Java, en caso contrario, devuelve false.

Prototype vs jQuery

De todos estos frameworks, sin duda hay 2 que están por encima de los demás, almenos a lo que a popularidad se refiere, y son el jQuery y el Prototype. En este artículo me voy a ahorrar la explicación de los pros y contras de cada uno, o cual es el mejor de los 2, porque este debate ya se abrió hace mucho en Internet, hay mucha información allí fuera.

Me voy a limitar a mí propia experiencia. Y yo me quedo con Prototype. Con esto estoy llendo en contracorriente porque parece que en la actualidad, jQuery le está ganando terreno a Prototype en cuanto a popularidad. Pero la gente creo que se equivoca cuando argumentan que jQuery es más potente que Prototype.  Una cosa es que al tener más respaldo popular, se hayan creado  más plug-ins y más documentación para usar el framework, pero eso no implica que su core sea mejor que Prototype.

Llevo ya varios años usando Prototype, en conjunción con Scriptaculous, y nunca he tenido motivos para cambiarme de framework. La gente me dice, “eso es porque no has probado jQuery…” No es cierto, sí que lo he usado, y no veo una gran diferencia. Son bastante similares. Muchos me comentan que la posibilidad de concatenar varios métodos seguidos que permite jQuery es una pasada, pero no sé si saben que desde Prototype 1.6, también permite contatenar métodos.

Scripty2: El próximo salto de Prototype + Scriptaculous

La combinación de Prototype con Scriptaculous – una librería de efectos – se complementa a la perfección con Prototype, y este dúo te permite realizar prácticamente cualquier cosa que se te ocurra en la web frontal y jugar con los elementos DOM. La grandísima noticia que leí en el blog de uno de los autores directos de Scriptaculous, Thomas Fuchs, es que está de camino una nueva versión del Scriptaculous, rebautizado como Scripty2. Todavía es una versión alpha pero hay una demo online que nos da una ligera idea de las nuevas capacidades de la librería y… ¡¡madre mía!! ¡Tiene una pinta increíble!

Se ha mejorado en todos los aspectos la librería, separándolo en Core, UI y FX. Código más compacto pero más potente. La cosa promete, estaré observando con detalle la evolución de este proyecto. Cuando esté la versión final, me gustará escuchar la comunidad de desarrolladores web y Front-End’s, y en especial a los ultra defensores del jQuery

Web oficial de Scripty2: http://scripty2.com

Fuente: Mir.aculo.us

Cito algunas de las librerías que he utilizado personalmente y que corrigen la incompatibilidad de Internet Explorer 6 (IE6). Todos ellos son válidos y funcionan a la perfección, por tanto elegir un script es más una elección por gusto que por otra cosa:

PNG fix

Correcto script que habilita las transparencias de PNG en IE6.

http://homepage.ntlworld.com/bobosola/

Unit PNG fix

Otro script que soluciona el problema, esta vez todo en menos de 1kb!
http://labs.unitinteractive.com/unitpngfix.php

SuperSleight

Esta vez un script salido de uno de los sitios web de referencia para todo Front-End o diseñador web.

http://24ways.org/2007/supersleight-transparent-png-in-ie6

IE7-js

Alojado en code.google.com, un script completo que además de corregir el problema de la transparencia, corrige otros problemas con IE6 y versiones anteriores.

http://code.google.com/p/ie7-js/

He probado todas estas librerías y todos hacen más o menos lo mismo:

Le aplica un “filter”  a la imagen (progid:DXImageTransform.Microsoft.AlphaImageLoader(...)). Es un filtro que solo admite IE6 y lo que hace es habilitar las transparencias de la propia imagen.

Cada librería lo aplica a su manera, y su aplicación también varía ligeramente. En mi trabajo actual empecé usando Unit PNG fix pero he acabado usando IE7-js ya que me interesaba el resto del paquete.