Y vuelvo con una entrada sobre los cambios que se están realizando en Firefox, en concreto para la futura versión 4 (la actual es la rama 3.6).

“Firefox es lento y usa mucha RAM”

Por eso dentro de Mozilla se están haciendo cambios para mejorar ambas cosas. Firefox 4 se abre mucho más rápido (y cuando digo mucho, es del orden de segundos en ordenadores no demasiado nuevos) y se cierra muchísimo más rápido (un cambio sobre la gestión de cookies permitió mejorar el tiempo de cerrado en más del 90%), y esto es debido tanto a los cambios con las cookies, como al uso de nuevas versiones de diferentes códigos que usaba Mozilla (como SQLite).

Aceleración por hardware

¿Lo qué? (ojo, comparación no muy buena) Pues eso, imagínate que tienes un coche, cuya aceleración es de llegar a 100km/h en 10 segundos. Tu motor no da más de sí, es un cuello de botella. Pero… ¿y si usamos algo para acelerarlo? Por ejemplo, ¿óxido nitroso? Ocurriría que igual en vez de en 10 segundos, tardas 5 y encima gastas menos gasolina.

Pues es lo que ocurre con esto, la aceleración de hardware usa las tarjetas gráficas (sí, esas que hace años todos queríamos la última para jugar a los juegos a más resolución, más antialising y más sombras y explosiones detalladas) para renderizar la página. Como las tarjetas gráficas son muy buenas en “crear” imágenes, ¿por qué no usarlas en el navegador? Libera carga al procesador principal y encima lo hace más rápido. Todo beneficios.

Esto está implementado ya en Firefox para Windows, usando Direct2D (una tecnología de DirectX, sí, la de los juegos), y se va a implementar vía OpenGL en Linux y Mac.

JavaScript: Tracemonkey, JaegerMonkey, SpiderMonkey

No, no va de miles de monos escribiendo a la vez alguno de ellos puede escribir en algún momento el Quijote… o sí.

JavaScript, nuestro querido JavaScript. El que hace que algunas páginas tengan unos menúes desplegables increíbles, el que hace que Gmail sea tan rápido y bonito. El que hace que Facebook tenga tanto dinamismo… Las páginas están usando cada vez más y más JavaScript, y de una forma muy muy intensa, lo que hace que cada vez queramos motores de JavaScript más rápidos.

En Firefox 3.6 el motor de JavaScript era TraceMonkey, pero, hay que admitirlo, fue barrido por la “competencia” (V8 de Google Chrome y Nitro de Safari). Ahora se está realizando otro motor, complementario a TraceMonkey y que unido puede mejorar muy sustancialmente el desempeño de Firefox en JavaScript. Es un tema muy técnico y tenéis referencias aquí.

Otras cosas…

Por ejemplo, se han separado los procesos de UI y de renderizado de páginas web, lo que hará que ahora el navegador no se quede congelado si una página falla.

Conclusión: más ligero y rápido.

“Firefox es feo”

Aquí te lo has ganado Firefox 4 va a cambiar su aspecto completamente. Sí, y digo completamente, atento:

¿qué te parece? Ese es el tema pensado para Windows Vista y Windows 7, pero también están para Mac y Linux.

¡Ey! ¿Has notado más cambios?

Pestañas en la parte superior (tabs-on-top)

Sí, se lo hemos copiado a Google Chrome. ¿Acaso es malo copiar cuando algo es bueno? Las pestañas ahora por defecto estarán situadas por encima de la barra de direcciones, pero se puede cambiar fácilmente haciendo clic derecho en cualquier parte de la barra de herramientas y seleccionando la opción “Pestañas en la parte superior”.

App-tabs

Sí, se lo hemos copiado a Chrome. ¿Tengo que repetirlo? Es una fantástica idea para la web de estos días: tener abierta todo el rato una serie de páginas (que son como nuestras aplicaciones en la web) que más usamos: GMail, Twitter, Facebook… sólo mostrando el icono y sin el texto de la pestaña, porque nuestra memoria visual es mejor que la memoria que recuerda escritos y sabemos qué páginas son.

Menú Firefox

Ey, cómo te lo sabes. Con la misma idea de Ópera, o el menú de Chrome 6. Esto no es lo que está implementado ni se sabe qué es lo que se va a implementar completamente, pero es un acercamiento a qué es lo que será el botón.

Gestor de complementos

Además, también hay cambios en el gestor de complementos (el que se abría vía el menú Herramientas > Complementos/Agregados), para que en vez de que salga en una nueva ventana, se abra en una nueva pestaña, por ejemplo…

Conclusión: más moderno.

“Firefox no es 64-bit”

¿Quién ha dicho eso? ¡Que levante ambas manos! Realmente… ¿Firefox necesitaría ser de 64 bits? ¿Necesitaría tanta memoria RAM que no cabe direccionamiento en 32 bits? Para la mayoría de las cosas no, pero por ejemplo para el vídeo (¿he oído instrucciones específicas de 64 bits para decodificar?) o JavaScript sí es necesario (de hecho, el nuevo motor hablado más arriba requiere instrucciones específicas x64 para funcionar a pleno rendimiento).

Así que Firefox 4 va a ser 32 y 64 bits, en todas las plataformas. Exceptuando que 64bit para Mac sólo funcionará a partir de Leopard (10.5).

Conclusión: más rapidez.

“Firefox no funciona con HTML5 en Youtube”

YouTube en su día usó (y sigue usando) el “estándar” (lo entrecomillo porque no es libre ni abierto, pero sí usado por mucha gente) H264. Y Firefox no lo implementó (ya se discutió sobre esto, pero básicamente porque su implementación no era libre y gratuita y requería pagar licencias anuales de unos 6 millones de dólares). Finalmente, Google (propietario de YouTube) liberó un nuevo formato de vídeo, con una calidad similar a la del cerrado H264 pero totalmente abierto, por lo que Firefox lo va a implementar en esta nueva versión (como ya lo hace Chrome 6, u Opera 10.6).

Así que a partir de ahora, si ves que en cualquier video de YouTube te sale esto en el reproductor

(nota el HTML5 – WEBM) es que estás usando vídeo en formato WebM en HTML5 en Firefox Sin necesidad de plugins extras como Flash.

Conclusión: no Flash

“Safari tiene unos demos increíbles que Firefox no es capaz de mostrar”

Es probable que hayas visto por ahí demos de HTML5 + CSS3 que funcionan maravillosamente bien en Safari y ni se ven en Firefox. Esto es debido a que CSS3 no está finalizado aún, y todos los navegadores implementan estas características de forma similar pero con nombre diferente. Pongo un ejemplo:

Imagínate que eres un robot, y que tus instrucciones son: “Si encuentras una caja azul, la coges, la abres, ves lo que hay y lo haces”.

Por otro lado, a otro robot le dicen: “Si encuentras una caja naranja, la coges, la abres, ves lo que hay y lo haces”. Exactamente lo del primero pero cogiendo una caja de distinto color.

Pero las cajas son idénticas en contenido, se abren igual… pero tienen distinto color.

El primer robot no cogerá la caja naranja pero sí la caja azul y lo contrario sucederá con el segundo: cogerá la caja naranja y no la caja azul. Pero… ¿qué pasa cuándo deliberadamente sólo se deja una caja azul y no se deja una naranja? Pues que el primer robot abrirá la caja y “parseará” su contenido (realizando la acción que ponga en su interior), mientras que el segundo se quedará de brazos cruzados esperando a “su” caja naranja.

Es lo que ocurre en algunas demos: -moz-muévete sería la propiedad en Firefox y -webkit-muévete sería la propiedad en Safari y Chrome. Si se ponen las dos propiedades en una página, perfecto, ambos navegadores se moverán, pero si sólo se pone -webkit-muévete sólo Safari y Chrome se moverán, mientras que Firefox no.

Obviamente, esta es una limitación temporal, en cuanto el estándar esté completo y terminado, los navegadores tienen que quitar sus sufijos (“-moz” o “-webkit”) para que la web sea estándar

Por cierto, una vez finalizado y con nuestro ejemplo, habría una “caja” sin más, que todos los navegadores cogerían y la usarían, sin diferenciar por color (racista, que los navegadores son unos racistas).

Otro por cierto, mira este vídeo sobre tecnologías web a ver qué opinas:

“Firefox copia a Chrome”

Y Chrome copió el código de los marcadores de Firefox, y Firefox el de los plugins fuera de proceso a Chrome, y Firefox copió de Ópera las pestañas, e Internet Explorer copia la idea de motor de JavaScript, y Safari usa WebKit que fue una copia (fork) de KHTML de KDE… Por suerte las patentes de software no funcionan en todo el mundo, ni todo está patentado

Conclusión: libertad creativa.

“Chrome mola, Firefox sucks”

Para gustos, los colores o navegadores Sólo te pediría que probaras Firefox 4 y que cualquier cosa que no te guste la pongas en los comentarios o en el botón “Opinión” en la parte superior derecha de las betas de Firefox, intentaré responder en la medida de lo posible

Conclusión: abre tu mente y critica de forma constructiva.

Final

Como podéis ver, Firefox 4 va a ser un cambio muy radical en cuanto a lo que estábamos acostumbrados a ver. Nueva interfaz, mayor velocidad, mejor gestión de complementos, más seguro respecto a plugins y muchísimas más cosas que me he dejado en el tintero que intentaré escribir en otro post… si no se me olvida.

• Google Chrome soporta H264 y Theora
• Safari soporta sólo H264
• IE9 (futuro) soportará H264
• Opera soporta sólo Theora
• Firefox sólo Theora

Como vemos, los principales navegadores usan H264, al menos los que dan más del 75% de cuota total (si incluimos al futuro IE9, claro). La cuestión es que tenemos:

• Theora: Opera y Firefox (y Google Chrome junto a H264)
• H264: Safari, Chrome e Internet Explorer 9

Potencia económica por estándares:

• Theora: Mozilla y Opera (junto a comunidad libre y Wikimedia principalmente)
• H264: Patentado y usado por Apple, Google y Microsoft

Este es el primer argumento: potencial económico (y de imagen) de los navegadores que utilizan H264 frente a la “marginalidad” económica de los que no lo quieren utilizar, porque… no se puede negar que el poder de sólo uno de los contendientes del H264 es infinitamente mayor que cualquiera de los que pujan por Theora.

Y es que Theora es actualmente inferior técnicamente a bajos bitrates de codificación de video que H264, por lo que para muchos sitios es inusable, al contrario que H264. Además, a pesar de que H264 tiene patentes, la mayoría del contenido en vídeo que hay en la web (YouTube) está ya en H264 (servido en este formato para el iPhone y todos los terminales Android) y muchos de los servicios Flash codifican el vídeo que sirven en este formato.

Luego, podemos decir que Mozilla no se va a bajar del carro con el H264, por simple ética, sería traicionar a su idea de web abierta. Y me parece muy lógico. El problema vendrá cuando veamos IE9 usado mayoritariamente, Chrome con alta cuota y Safari (y Mac) con un número alto (y significante) de usuarios.

En ese caso los únicos perjudicados serán los usuarios de Mozilla que no podrán usar el “estándar” que se ha ido formando con H264 impuesto por los diferentes vendedores de navegadores.

Y sólo nos quedaría esperar a que haya un estándar de vídeo libre que mejore o equipare a H264, pero para entonces, ya será tarde…

Y que comience la enésima discusión…

Bueno, sabemos que el nuevo Firefox 3.6 (si no lo tienes ya estás tardando en descargarlo) tiene una opción interna para hacer una limpieza de sus bases de datos de forma periódica (esto mejora el tiempo de arranque y de respuesta de la barra de direcciones, así como el espacio ocupado en disco), pero realmente sólo lo hace al archivo places.sqlite (el que tiene todas las direcciones de páginas visitadas… y muchas cosas más), pero realmente los perfiles en Firefox tienen muchos más archivos de bases de datos .sqlite, como por ejemplo:

webappsstore
urlcassifier3
signons
search
permissions
formhistory
downloads
cookies
content-prefs

y el ya mencionado places.sqlite.

Todos ocupan su respectivo espacio en el disco, normalmente los que más son places.sqlite (explicado anteriormente) y urlclassifier3.sqlite (contiene páginas de malware y atacantes, que se bloquean para no poder navegar por ellas).

Así que si queréis que se limpie cuando vosotros queráis, sólo tenéis que hacer lo siguiente en MACOS X (explico Linux más abajo)

1. Abre una consola (Terminal). Escribe nano bin/limpiarFx.sh
2. En lo que se abre, escribe:

   cd ~/Library/Application\ Support/Firefox/Profiles

   for i in */*.sqlite; do echo "VACUUM;" | time sqlite3 $i ; done


   (elimina el posible salto de línea, sólo puede haber dos líneas, una que empieza en cd… y otra que empieza en el for…

3. Cierra el archivo con Control-x y guárdalo (con la S o con la Y).
4. Ahora escribe: nano .profile y en el archivo que se abre, baja hasta el final del mismo (con las teclas de dirección) y añade…

   export PATH=~/bin:$PATH

   Y ciérralo como anteriormente con un Control-x y guardando los cambios con S o Y.

5. Ahora escribe chmod +x ~/bin/limpiarFx.sh

Ahora cada vez que quieras limpiar Firefox tienes que tenerlo cerrado (si no, no se podrá limpiar correctamente), abrir una consola de comandos y escribir:

limpiarFx.sh

Paso 1- Siéntete Microsoft. Ten una magnífica idea, y como es tan magnífica y nadie podría copiarla, la patentas. Algo así como: “reordenar las pestañas mediante arrastrar y soltar las miniaturas de esta interfaz”. Eso se refiere a una “pestaña” que abre IE7 y 8 para mostrar las pestañas que tienes abiertas, en modo miniaturas, y que se puedan “reordenar”. Pedazo de idea.

Paso 2- Una vez que lo tienes patentado… y que hay geeks que se dedican a buscar patentes de software, espera a que lo saque algún blog (yo lo leí en Genbeta, por cierto, enhorabuena por este notición).

Paso 3- Espera los comentarios de la gente

Paso 4- Comprueba como tu competencia, Mozilla, hace lo mismo, en 19 líneas de código y lo sube a su repositorio, sin patentes, sin noticias, sin nada, esperando a que sea el usuario final lo encuentre útil.

Paso 5- Disfruta de un mejor navegador, probándolo hoy mismo.

Postdata: Lo mejor, el comentario del desarrollador de esta “patente innovadora” en Mozilla:

This was surprisingly trivial, thanks to the solid drag and drop API and due to the fact that browser-tabPreviews.js handled the TabMove event already.

Así que nada, a espera a que Microsoft lo implemente… en el software, no en papel.

1. Se me olvidaba
2. Son fiestas
3. Estudio

Así que sin más dilación, voy a poner las 5 cosas que me gustaría que se mejoraran/ocurrieran en este 2010 en la comunidad Hispana:

• Mayor coordinación sobre la escritura de documentación: SUMO, Mozilla Hispano… sí, sabemos que escribir documentación es una lata, pero al final, alguien lo tiene que hacer.
• Continuar el Podcast. Ey, sí, ¡tenemos un podcast! Quizás con que haya menos de 1 año de diferencia entre el anterior número y el actual me conformaría por el momento.
• Miembros, miembras, colaboradores, y colaboradoras (palabra que no está en la RAE pero que aceptaría si aparecen colaboradores de sexo femenino) para la comunidad. Da igual en qué, lo importante es participar: noticias, foros, documentación, desarrollo, organización… todo vale.
• Organización de un evento de software libre con otras comunidades, como ya se está planteando, pero que necesita un impulso y la organización final (me lo apunto como tema personal también)
• Con los traductores, más quedadas en persona. Nunca viene mal quedar para tomarnos unas cañas (o unas cocacolas ) pero me gustaría quedar alguna vez para mejorar las traducciones de forma conjunta, haciendo todo mucho más homogéneo, y quién sabe, si con las comunidades hispanohablantes.

Aquí mi Meme, no sé si falta alguien, pero si no, dejo la pelota en el aire para que caiga en la casa de cualquier persona que quiera participar.

Hubo cierta categoría sobre blogs de tecnología. En dicha categoría hubo un blog nominado, llamado Alt1040, el cual al final se llevó el premio, siendo abucheado por el público al ritmo de ¡tongo! ¡tongo!.

Llegamos al día de hoy, menos de dos semanas después de recibir el premio al mejor blog sobre tecnología, cuando nos encontramos con un artículo bastante desafortunado:

Firefox consume demasiados recursos y Mozilla lo sabe (¿la solución para cuándo?)

Bueno, por el post se comenta que hay un sitio de Soporte de Mozilla (SUMO) en el cual hay un artículo diciendo: Firefox consumes a lot of CPU resourcers (sic), vamos que “Firefox consume muchos recursos de la CPU” (o procesador).

En ese artículo no se dice en ningún momento la palabra “RAM”, pero el autor de Alt1040 lo toma como arma de ataque en su post, simplemente escribiendo el nombre del artículo (ni siquiera enlazándolo).

Simplemente, haciendo una pequeña prueba de mis 48 pestañas actuales que tengo abiertas en Firefox 3.6b4pre (o sea, una compilación de la futura versión de Firefox) y deshabilitando Flash en Safari y en Firefox (sí, no quiero que me pete el ordenador), me arroja estos números:

¿Quién gasta menos RAM?

Es más, ¿quién gasta menos procesador?

Vale, pues metamos a Google Chrome, ese grandísimo navegador que es más rápido, más liviano, más bonito y más todo que ha hecho Google. Como es multiproceso (un proceso diferente por pestaña, parece ser), pues la CPU podría verse si hay muchos procesos comiendo todo…

Pues qué cosas, ahí mismo ya come más CPU que Firefox… pero bueno, vayamos a la RAM:

1651	 Chromium Helper	willyaranda	1,6	3	41,4 MB	Intel
1650	 Chromium Helper	willyaranda	0,0	3	27,0 MB	Intel
1652	 Chromium Helper	willyaranda	1,0	3	28,3 MB	Intel
1649	 Chromium Helper	willyaranda	0,0	3	38,5 MB	Intel
1648	 Chromium Helper	willyaranda	0,0	3	28,1 MB	Intel
1647	 Chromium Helper	willyaranda	0,0	3	28,8 MB	Intel
1646	 Chromium Helper	willyaranda	0,0	3	34,8 MB	Intel
1645	 Chromium Helper	willyaranda	4,9	3	47,6 MB	Intel
1644	 Chromium Helper	willyaranda	0,1	3	43,7 MB	Intel
1643	 Chromium Helper	willyaranda	0,3	3	22,4 MB	Intel
1642	 Chromium Helper	willyaranda	3,4	3	96,7 MB	Intel
1641	 Chromium Helper	willyaranda	5,2	3	33,0 MB	Intel
1640	 Chromium Helper	willyaranda	0,9	74	93,1 MB	Intel
1639	 Chromium Helper	willyaranda	0,0	3	16,9 MB	Intel
1638	 Chromium Helper	willyaranda	0,0	3	19,9 MB	Intel
1637	 Chromium Helper	willyaranda	4,7	3	42,9 MB	Intel
1636	 Chromium Helper	willyaranda	0,3	3	40,7 MB	Intel
1635	 Chromium Helper	willyaranda	0,0	3	35,2 MB	Intel
1634	 Chromium Helper	willyaranda	0,1	3	29,6 MB	Intel
1633	 Chromium Helper	willyaranda	0,6	3	39,0 MB	Intel
1632	 Chromium Helper	willyaranda	5,7	3	41,0 MB	Intel
1631	 Chromium Helper	willyaranda	0,0	3	26,3 MB	Intel
1602	 Chromium	willyaranda	0,4	17	45,1 MB	Intel

Lo que nos da un total de 900MB de memoria RAM! ¿No está mal, verdad?

Pongámoslo en un gráfico, de esos que gustan tanto a las páginas:

PD: Y sí, hay que reconocer que tanto Safari como Chrome se abren muchísimo más rápido que Firefox, pero ¿acaso el editor de ese artículo menciona que una de las áreas donde más esfuerzo ha puesto Mozilla para la nueva versión de Firefox es la carga inicial del navegador? Ya lo veréis en Firefox 3.6…

Actualización: Estas imágenes que vienen ahora corresponden a los tres navegadores habiendo hecho un

sync && purge

antes de cada prueba, como digo en mi tweet. Lo dicho, imágenes del antes y del después de cargar las pestañas que tenía guardadas. (Si alguien quiere las páginas, que me lo pida):

Firefox

Webkit (Safari)

Chromium (Chrome)

Opera (10.10)

Como me piden en los comentarios, con Ópera. Lo mismo que anteriormente, con

sync && purge

y me arroja estos datos (notar que también desactivé flash en esta prueba, para que fuera igual en todos. También notar que Opera se colgó en un momento determinado como se puede ver, lo reinicié, sync && purge y listo:

Pero en este caso no quiero asustar, si no hacer una pequeña reflexión. Como algunos sabréis, estoy en un curso organizado por la Universidad Rey Juan Carlos de Madrid (aunque estoy en Fuenlabrada) junto a Mozilla Europe, donde varios de los desarrolladores de Firefox o tecnoevangelistas, como Paul, o un becario como Vivien que trabaja para Fennec, nos están enseñando a hacer extensiones, comprender mejor el mundo de Mozilla y esas cosas.

Bueno, pues estaba esta mañana revisando mi correo, mis feeds y me encuentro con esto:

Mozilla Firefox 3.5 Remote Buffer Overflow Exploit (untested crash)

El primer exploit disponible públicamente para Firefox 3.5. Yo pensando: ¡vaya! la que nos va a caer encima…

Y cae, pero porque la gente no se informa lo suficiente parece ser…

Y es que vayamos con la evolución en el tiempo de este problema:

1. Se abre un bug en Bugzilla (el 503286) en el que se reporta un problema en una página rusa que hace que el navegador se cierre de forma inesperada y con posible corrupción de memoria.
2. Los desarrolladores van haciendo testcases, osea, pruebas cada vez más minimizadas para intentar acotar dónde está el fallo. No es lo mismo tener una página con 100 líneas o una con 10 exactamente con el problema y nada más.
3. Se arregla un bug con un parche el día 9 de Julio (hace 5 días), pero sólo para la versión posterior a Firefox 3.5, esto es la 3.6 o la Firefox.next
4. Hoy se encuentra en Milw0rm un exploit público basado en los testcases creados por los desarrolladores para minimizar el problema
5. ——- Comment #30 From WD 2009-07-13 21:01:22 PDT (-) [reply] ——-

   From the duped bug 504001 ,
   This bug has reliable exploit code on milw0rm that results in code execution.

   http://milw0rm.com/exploits/9137

6. Se crea el parche para la versión estable 3.5 (derivado de la de Firefox.next) y se sube al repositorio.

Pero aquí la cuestión que subyace es que Mozilla encuentra un fallo grave de seguridad y lo publica abiertamente en Bugzilla, donde todo el mundo puede contribuir y aportar comentarios. Alguien de fuera de Mozilla y con ganas de fastidiar a los usuarios crea un exploit basado en las pruebas que estaban haciendo los desarrolladores para arreglarlo. ¿Es ético? Si se sabe que un fallo está documentado y arreglado o en proceso de serlo ¿está bien sacar un exploit para desprestigiar?

Lo peor de todo que no es que haya salido en Milw0rm (donde miles de hackers se dan cita diariamente para subir sus exploits) si no que por ejemplo ha salido en la lista de seguridad más importante de España, en Una-al-dia de Hispasec, con una gran penetración en el sector diciendo encima que no hay parche, cuando sí lo hay y ya hay compilaciones diarias que lo traen arreglado.

Y no hay peor ciego que el que no quiere ver…

Mozilla/5.0 (SymbianOS/9.2; U; Series60/3.1 NokiaE71-1/210.21.006; Profile/MIDP-2.0 Configuration/CLDC-1.1 ) AppleWebKit/413 (KHTML, like Gecko) Safari/413

¡Joder! No le podrían haber pusto más extensiones, que si es un Mozilla 5.0, que si es un Symbian 9.2, un Series 60 versión 3 con el Feature Pack 1, el modelo del teléfono con su firmware, un perfil, algo más, la revisión de Webkit que lleva (un poco viejuna ehh), que es KHTML como Gecko y que está basado en Safari.

Vamos, que sólo les ha faltado poner que ¡Internezz Ezplorer 6 Rulzzz!

Y uno de los mejores artículos para explicarlo: http://webaim.org/blog/user-agent-string-history/

Acabo de leer un artículo muy interesante que trata precisamente de esto mismo: los códecs, pero en un contexto mucho más grande: la web. Como sabéis, el futuro estándar HTML5 posee una nueva etiqueta <video /> que permitirá añadir vídeos fácilmente a las webs como lo hacemos ahora mismo con la etiqueta <img /> por ejemplo.

¿Qué podría permitir esto? Que Youtube no use Flash en sus reproductores o que DailyMotion haga lo mismo. ¿Habéis visitado las páginas? ¿No? Hacedlo. Visitad la primera con Firefox y la segunda con Safari (con Quicktime instalado). Ahora haced lo contrario. La primera con Safari y la segunda con Firefox.

¿Ya? Vale, ¿habéis visto lo que pasa? ¿Que Youtube sólo funciona con Safari + Quicktime pero no con Firefox y que DailyMotion sólo con Firefox y no con Safari?. Pues eso mismo es lo que os pasaba en los ordenadores de los demás: CÓDECS.

Analicemos la situación. Esta versión de prueba de Youtube que sólo utiliza etiquetas válidas de HTML5 hace uso de la etiqueta <video />, pero el pequeño problema es que HTML5 quitó qué códecs usar por defecto. Empezaron con OGG/Theora, pero se desechó esa opción (cualquier compañía grande ha creado su estándar cerrado y con patentes de vídeo: Microsoft WMV, Apple con h.264…). Así que cada uno puede elegir qué códec utilizar, y claro, ahí ya dependes de plugins exteriores para cargar el vídeo o bien de internos… pero un navegador no puede ser un VLC en potencia. Lo mismo que pasa ahora con los objetos flash, que dependemos del Plugin Flash (instalado casi de facto en todos los ordenadores).

Bien, así que Youtube usa un formato que DailyMotion no, porque Firefox no funciona en Youtube pero sí en este último.

Esta versión de prueba de Youtube usa vídeos en MP4, un formato con licencias, no libre, por el que hay que pagar patentes o canon para poder crear un reproductor o para utilizar las librerías para codificar/decodificar… (es más, cuando eliges un vídeo en Youtube en alta definición realmente estás eligiendo el vídeo en MP4 aunque sea Flash realmente el reproductor/decodificador). DailyMotion de hecho ha firmado un acuerdo con Mozilla para pasar sus vídeos al formato libre OGG/Theora (que hoy por hoy da menos calidad que el MP4, todo hay que decirlo) para que se use un formato de vídeo libre, estándar y sin patentes, por eso se puede ver sin ningún tipo de códec externo y todo de forma transparente al usuario.

Si os habéis fijado, el HTML5 está de moda, el <video /> está de moda… wait… ¿de qué navegadores estamos hablando? Safari y Firefox. Un 30% de cuota de mercado. ¿Quién sigue teniendo el 70% restante? ¿Alguien se cree que en un periodo razonable de tiempo (¿1 año?) Microsoft va a ser capaz de adaptar su navegador a los nuevos estándares propuestos por el grupo que desarrolla HTML5? Es más, ¿creéis que va a aceptar que se use un formato abierto cuando ellos tienen un formato propietario, licencias de por medio, con DRM llamado Windows Media Video?

Como acaba rezando el artículo <video /> es un gran avance, pero estarán durante mucho, mucho, mucho tiempo los reproductores Flash de por medio, comiéndonos los recursos de la CPU hasta que por lo menos Adobe decida optimizarlo o bien Microsoft se decida a usar <video />

Lo bueno es que Chrome ha decidido unirse a los navegadores (Firefox sólo por ahora) para soportar el formato OGG/Theora en su próxima versión, la 3.0. Ojalá dejemos de depender de formatos propietarios y lentos…

Actualización: Se me olvidaba comentar que hubo un excelente debate en Slashdot acerca de si HTML5 sustituirá a Flash como reproductor de vídeo. No os lo perdáis.

Actualización2: Me comenta Julen, que Opera también soporta la etiqueta <video /> desde ¡Noviembre de 2007! Incluso en sus últimas versiones estables. Además vía OGG/Theora como Firefox y en un futuro Google Chrome. Muy interesante

Pues bien, ayer mismo salía a la luz una nueva versión de Prism (no definitiva, pero de ahí la podéis descargar), el cliente de la Fundación Mozilla que en un principio había descartado porque usaba una versión vieja del motor Gecko y era más lenta que Fluid.

Y esta nueva versión está basada en la rama 1.9, por lo que está equiparada con Firefox 3, pero esto sigue haciéndola menos compatible con los estándares que Safari 4 y, por extensión, Fluid. El motor Javascript también es más lento en teoría, ya que en la rama 1.9 de Gecko no está implementado Tracemonkey, algo que sí va a estar en la versión 1.9.1, sobre la que funcionará Firefox 3.5.

Pero, ¿vale la pena esta nueva versión de Prism? Y mi respuesta es un tajante y rotundo SÍ.

En primer lugar como aplicación autónoma, ya que es compatible con todos los sistemas y plataformas donde Firefox 3.0 funciona, ya que ambos están basados en Gecko. Fluid es sólo para MacOS X (donde todos sabemos que las aplicaciones están muy pulidas y optimizadas para los 4 procesadores, 4 tarjetas gráficas que utiliza Apple y punto).

Pero es que Prism me ha impresionado, no sólo porque su velocidad en MacOS X es más rápida que el propio Fluid, si no que además al ser multiplataforma puedo compartir mis aplicaciones web-escritorio con todo el mundo sin necesidad de hacer ni un solo cambio, por lo que los usuarios de Windows y de Linux también se benefician de estas mejoras.

Pero es que Prism, como aplicación independiente, está basado en Firefox 3.0, pero no es lo único que tenemos, si no que hay una extensión para Firefox 3.0 y 3.5 que utiliza el propio navegador como motor de renderizado. Y es increíble.

Si ya de por sí Prism como aplicación estándar tarda casi un segundo menos que Fluid en cargar GMail (Prism 3 segundos, Fluid unos 4), Refractor, la extensión para Firefox es increíble. Obviamente depende en qué versión de navegador lo instales, si es en un Firefox 3.0 tendrás la misma velocidad que Firefox 3.0 (o sea, igual que Prism), pero si lo instalas en Firefox 3.5 beta 4… lo gozas. Casi un segundo más rápido que Firefox 3.0 en cargar, debido, sobre todo, a Tracemonkey, ese gran, grandísimo motor Javascript escrito por la fundación Mozilla y los colaboradores. Clic en el enlace directo de Gmail, ventana, cargando…, ya tienes tu correo. En dos segundos desde que pincho en el icono, tengo todo mi correo web. Y usando sólamente 45 megas de memoria (no puedo comparar con Mail.app o con Thunderbird 3 beta porque tienen más cosas).

Como digo, estas aplicaciones son perfectas para personas que utilicen mucho páginas recargadas de Javascript, quieran tener perfectamente en forma su navegador y no quieran ver cómo tienen que poner otro giga de RAM sólo para navegar por internet.

Las dos principales desventajas de Prism es que (en MacOS X) no permite el uso de archivos de iconos .icns por lo que o bien usamos una imagen PNG para los enlaces directos o bien el favicon de la página, que suele tener tan poca resolución que es mejor ni ponerlo (he abierto un bug en Bugzilla acerca del uso de archivos icns en Mac, ya que si se edita internamente la aplicación se pueden usar sin problemas). El otro problema es que no tiene reconocimiento de páginas web muy populares. Así como en Fluid yo tenía abierto mi GMail y me mostraba en el icono los correos que tenía sin leer, Prism no. Igual es porque es mucho más genérico que Fluid, pero estaría bastante bien que la API permitiera hacer cositas de estas: modificar iconos al vuelo, tener patrones para hacer acciones…

Lo dicho, si queréis echarle un vistazo y probarla, en esta página tenéis las descargas de Fluid para los 3 grandes sistemas y la extensión para Firefox para Mac y Windows (para Linux aún no disponible debido al bug 436998).

Además intentaré hacer algunas webapps para alguna de las páginas más usadas en España, o por lo menos las que yo creo que se usan más.