aNieto2K Desarrollo web, Wordpress, y alguna cosilla más

En SixRevisions han realizado una comparativa entre las últimas versiones de los navegadores más usados del momento:

• Mozilla Firefox 3.5
• Google Chrome 3.0
• Microsoft Internet Explorer 8.0
• Opera 10.0
• Apple Safari 4.0

En las pruebas realizadas, han optado por pasar una serie de tests con el fin evaluar los diferentes navegadores:

• SunSpider JavaScript Benchmark
• SlickSpeed (jQuery values reported)
• Numion stopwatch
• CSS Rendering Benchmark
• Resource Monitor

Resultados

(Ver Imagen)

Los resultados son lo que ya sabíamos, pero más bonitos… 😀

Desde que conozco Firefox siempre me he quejado del excesivo consumo de memoria que el navegador produce en mi máquina. Es cierto que versión, tras versión, esto se ha ido corrigiendo aunque sigue siendo excesivo y preocupante en alguno casos.

(Ver Imagen)

Según esta gráfica, que descubro en dotnetperls.com, parece ser que en una comparativa entre Google Chrome 3.0 Dev, Firefox 3.5 RC, Safari 4.0 for Windows y Opera 10b podemos ver el cambio. En la gráfica vemos como Google Chrome llega a necesitar hasta 1,2GB de RAM para abrir las 150 primeras páginas del Top de Alexa, frente a los 327 MB de Firefox y los 554 y 517MB de Operay Safari respectivamente. Y es que un navegador es algo más que ejecutar Javascript muy rápido 😀

Desde que tengo Firefox 3.5RC1 (ha salido la RC2) es cierto que he notado una disminución en consumo de recursos, pero aún es pronto para segurar que esta versión será la que estabamos esperando (en cuanto a consumo de memoria).

Hoy se ha presentado por fín, entre otras cosas, la versión definitiva de Safari 4. Hasta el momento podíamos usar la Beta que personalmente opino que era bastante estable. Cuando lo he descargado y me he puesto a hacer pruebas me he llevado una grata sorpresa al ver que era más rápido que Google Chrome en el test específico para V8 (el motor que renderiza Javascript de Google Chrome).

(Ver Imagen *Muy Grande*)

Partiendo de que ambos usan el mismo motor de renderizado HTML, WebKit (aunque creo que diferentes versiones del mismo) el motor javascript es diferente en ambos. Aún quedan muchas pruebas por hacer, pero parece que SquirrelFish es el motor javascript de hoy, mañana ya veremos 😀

ACTUALIZACIÓN

Me he dejado llevar por la emoción y el cansancio. Por desgracia para los amantes de Safari4, Google Chrome es aún mucho más rápido en este test, el resultado está expresado en iteraciones por lo que mientras el número sea mayor el resultado será más óptimo. Así que en la imagen de arriba, vemos como Safari4 es más lento en el test V8 que Google Chrome. Siento las molestias.

ACTUALIZACIÓN 2

Después de hacer un par de pruebas más, podemos decir con el 100% del convencimiento que Google Chrome es hoy por hoy, el navegador más rápido (ejecutando javascript) del lejano oeste. Incluso en el test que WebKit usa para compararse contra los otros navegadores, SunSpider, sale mal parado, aunque eso sí, mucho mejor que la versión anterior.

Aclaraciones

Hay que ser conscientes de dos cosas:

1) La velocidad de ejecución de javascript es importante

El javascript que tenemos que ejecutar en las páginas webs cada vez está siendo más complejo y este requiere mayores recursos, sin contar que en breve estos recursos pueden verse multiplicados frente a demandas tan exigentes como las que nos presentó Google con Google Wave (por ejemplo). Esto no hace que este punto sea importante, pero debemos darle más importancia de que tiene actualmente.

2) Un navegador no solo ejecuta javascript

También debemos ser conscientes de que un navegador hace más cosas que reproducir javascript, ha de ser rápido, amigable y sobretodo cubrir las necesidades de cada usuario, ni más ni menos. Si un navegador tiene muchas novedades pero no acaba de cumplir ciertas necesidades o las cumple parcialmente, no estará consiguiendo su cometido. Así que hemos de dejar claro que se trata de un cúmulo de cosas que ayudan a decidir cual es mejor o peor, pero siempre para cada uno, nunca para un conjunto de individuos.

Hace unos días comentabamos que encontramos unos problemas a la hora de usar nuestro WordPress 2.7 en Safari 4. Más concretamente al insertar Links o imagenes. Bueno pues ya tenemos una solución.

Despues de leer que el problema estaba en todas las adaptaciones de TinyMCE y que disponian de una versión devel funcional para este navegador he probado a integrarla en WordPress y así poder trabajar con Safari 4 sin problemas con nuestros WordPress.

Solución

1. Descargas este fichero
2. Haz una copia de la carpeta wp-includes/js/tinymce/ a wp-incldes/js/tinymceOLD/
3. Sin borrar la original (wp-incldes/js/tinymce/) sobreescribe los ficheros con el contenido del fichero descargado.
4. Ya puedes probarlo en tu panel de administración.

Hazlo tu mismo

1. Descargar la última versión «devel» de tinyMCE.
2. Haz una copia de la carpeta wp-incldes/js/tinymce/
3. Saca el contenido del fichero que acabas descargar, lo que necesitas está en la ruta (tinymce\jscripts\tiny_mce)

Estos son los ficheros que necesitas, copialos sobre la carpeta original en wp-incldes/js/tinymce/. Y listo! 😀

Pues he de decir que Safari4 me ha encantado. Aúna lo que me gusta de Google Chrome (Webkit) y lo que me gusta de Firefox (Firebug). No creo que pueda decir nada nuevo que no se haya dicho yá sobre este navegador. Pero ya me he encontrado con el primer problema a la hora de trabajar con WordPress 2.7 y Safari4 sobre Mac.

Como podemos ver la caja en la que pondremos la URL y los datos relacionados a ella, aparece debajo del layer oscuro que oscurece el resto de la página. Esto es debido a que esta caja no tiene z-index. Con esto debería solventarse:

.clearlooks2 {
z-index:300000;
}

Pero ahí no acaba, al intentar cerrar la caja, obtenemos un error de tiny_mce que no he podido mirar aún:

TypeError: Result of expression 'na' [undefined] is not an object.

Si alguien descubre algo, que avise.

Actualización

El problema lo produce TinyMCE y ocurre con todas las versiones de este WYSIWYG sobre este navegador, al parecer en la versión de desarrollo del SVN ya lo tienen funcionando y esperan liberarlo con la próxima versión en breve. Así que los usuarios de WordPress tendremos que esperar a una actualización de las tantas que nos tienen acostumbrados 😀

Inspector es el Firebug de WebKit/Safari y hace ya tiempo que vamos viendo su evolución y la adquisición de nuevas mejoras que completaban esta herramienta del navegador. 

Alvaro Videla ha extendido las posibilidades añadiendole un juego que ha portado de uno hecho en ActionScript del concurso de 25lines.com. 

El resultado, poco útil, permite ver las posibilidades y la facilidad de extender esta herramienta para ofrecernos ayudas y mejoras propias con el fin de personalizar y facilitar nuestra tarea.

Via

Con esta versión para Safari, tenemos ya Google Gears para:

• Internet Explorer 6+ y Firefox 1.5+ sobre Windows
• Firefox 1.5+ sobre Linux
• Firefox 1.5+ sobre MacOs X
• Internet Explorer 4.01+ sobre Windows Mobile.
• Opera Mobile 9.50
• Opera 9.5*

La lista va creciendo y eso nos acerca a una propuesta realmente interesante para suplantar el almacenamiento DOM hasta que este esté más y mejor implantado en los navegadores futuros.

* Recordaba que la versión 9.50 estaba preparada para trabajar con Google gears, pero buscando información solo he encontrado para la versión Mobile, así que por el momento lo dejo como interrogante. Actualizaré en cuanto tenga más info.

A ver si alguien puede decirme, que hay de diferente entre estas imagenes:

Imagen A

Imagen B

Imagen C

Imagen D

Es dificil, ¿verdad? Es normal que sea complicado ya que la gente de Firebug ha conseguido algo realmente sorprendente. Si nos fijamos bien, la imagen A es Firebug 1.2 desde Firefox 3 en MacOs, las demás son Firebug Lite 1.2 sobre Internet Explorer 7 (B), Opera (C), Safari (D).

El resultado es soprendente y es que esta nueva versión de Firebug Lite ha revolucionado el concepto de debug de aplicaciones web. Da igual en que navegador estes desarrollando o teniendo problemas, con Firebug Lite creerás que estás en Firefox, con la confianza y seguridad que eso conlleva.

Recordemos como instalarlo en nuestra aplicación:

• Añadimos entre nuestros tags <head></head> el siguiente código.

    <script type='text/javascript'
        src='http://getfirebug.com/releases/lite/1.2/firebug-lite-compressed.js'></script>

o podemos tener un acceso directo en nuestro navegador para poder añadir la funcionalidad a cualquier página.

Firebug Lite 1.2