Mozilla Prism, «site specific browsers» ad hoc

La disyuntiva es de las que está marcando 2008: ¿aplicaciones web como hasta ahora o aplicaciones de escritorio (o para el móvil) conectadas? Parece claro, al menos de momento, que las modas actuales indican que la aplicación de escritorio «de toda la vida» ha muerto. Igual resucita con el próximo cambio de paradigma, pero parece que eso es algo que no va suceder a corto o medio plazo. Los datos viven «in the cloud» y una parte de la potencia de cálculo también.

Las ventajas de las aplicaciones web son bien sabidas: siempre corremos la versión más actualizada del software, no hay instalación (si la velocidad de nuestra conexión a internet es suficiente, que si no es como si instalásemos cada vez) y no importa en qué sistema operativo estemos: todos tienen un navegador lo suficientemente sofisticado como para actuar de máquina virtual. Ese último punto, además, es una bendición para el desarrollador, que programa una sola vez para todas las plataformas, gracias a las bibliotecas y frameworks que corren por ahí.

Las aplicaciones conectadas, por su parte permiten una riqueza en la ‘user experience’ y en la interacción con el sistema operativo que la capa del navegador limita muy seriamente. A cambio, cuanta más ‘lógica de programación’ viva en el cliente más nos tenemos que preocupar de múltiples versiones y de mantener una API que hable con todas ellas y, si queremos correr sobre múltiples sistemas operativos no nos queda (o no nos quedaba, mejor) más opción que, en el mejor de los casos, compilar múltiples veces…

El año pasado comenzamos a ver dos intentos de solución al problema. Por un lado, Adobe anunciaba Air, que permitía aprovechar las habilidades adquiridas en el desarrollo de aplicaciones AJAX/Flash/Flex y añadía unas cuantas APIs para hablar con el escritorio y un proceso de empaquetado que, vía máquina virtual, nos permitía hacernos un hueco en el escritorio (de momento Windows y MacOS, en breve Linux).

Por el otro, la Mozilla Foundation lanzaba a través de Mozilla Labs Prism, que toma un camino similar: quitemos al navegador todo lo que sobra para correr aplicaciones (barras de menú y navegación, para comenzar) y añadámosle las cosas que le faltan si es necesario (un motor de base de datos, por ejemplo) y obtendremos el mismo resultado. Más detalles aquí.

El viernes se anunciaba nueva versión de Prism (vía), con una novedad interesante: extensión para Firefox (solo funciona con la beta 3 de Firefox 3 y versiones posteriores) que permite a cualquier usuario empaquetar cualquier aplicación web para ejecutarla en el escritorio. Así, por ejemplo, podemos empaquetar el correo de GMail o el calendario de Airset:

Captura de pantalla de la aplicación Prism GMail

No vamos a conseguir funcionalidades que no estuviesen en la aplicación web original (que podrían añadirse, eso sí, mediante scripting y, como apuntan en Ars Technicacomo apuntan en Ars Technica, con los mismos privilegios que una extensión y pudiendo, por tanto, acceder directamente al sistema de archivos y otras actividades normalmente no disponibles desde una aplicación web), pero a veces va bien sacar determinadas aplicaciones del navegador.

El administrador de tareas muestra dos instancias de Firefox. La segunda, que consume 120 megas, es el navegador. La primera, que se queda en cincuenta y tantos, es la aplicación de GMail

De momento faltaría que las aplicaciones se identificasen mejor, al menos en Windows, que eso de tener dos procesos corriendo con el mismo nombre no es exactamente la mejor política…

Cómo «desromper la web»

Botón ?emular IE7″ en IE8

Pues va a ser que «no romper la web» no era tan difícil. En vez de obligar a los «buenos desarrolladores» a introducir un tag más en sus cabeceras para disfrutar del respeto a los estándares del próximo navegador de Microsoft, se le añade un botoncito a IE8 para activar el modo IE7. Sigue sin ser una buena solución (que no existe: va a haber que contentarse con la menos mala), pero parece bastante más razonable esta que la anunciada hace unas semanas y desestimada hace unos días…

La home que carga IE8 al lanzarlo por primera vez apunta claramente al botón

Eso sí, muy discretos para marcar dónde está el botón no han sido :-P.

Por lo demás, Explorer 8 Beta 1 me está haciendo alguna que otra cosa rara con algún div AJAX y con las cajas de texto de los formularios, pero no parece mal navegador, para una beta 1. Y «mola» hacerle importar la configuración de Firefox :-P.

PS Eso sí, el destrozo que le hace el nuevo Explorer a Google Reader es de los que hacen época…

IE8 ?destroza? Google Reader

WebSlices. Un poquito de «web semántica» en Explorer 8

Mientras me bajo la beta 1 de Internet Explorer 8 nevego un poco por el Internet Explorer 8 Readiness Toolkit. Una vez solucionado el problema de los estándares, creo que pocos van a discutir que IE8, con su renovado respeto por la interoperabilidad, puede ahorrar muchos dolores de cabeza a los desarrolladores web (aunque, la verdad, de momento no creo que abandone Firefox)…

De las novedades que trae el invento me quedo con las Webslices (literalmente, «lonchas de web»). ¿De qué se trata? De marcar trozos de una página web de forma que IE8 (pongan en marcha los cronómetros para ver cuándo se lanza la extensión equivalente para Firefox) los reconozca y se suscriba a ellos, presentándolos al usuario de forma independiente al resto de la página. ¿Y eso para qué? Pues para hacer un «pseudo-push» de contenidos sin hacer uso de RSS. Un uso muy rudimentario sería marcar la primera entrada de la «home» de un blog y obtendríamos una funcionalidad muy similar a la del RSS. Para encontrar usos más interesantes tendremos que pensar en contenido de páginas web que se genere automáticamente pero que no tenga RSS. ¿Pero eso no consumirá mucho ancho de banda? Pues depende. El navegador tendrá que descargar todo el HTML de la página. Pero podrá ahorrarse, por ejemplo, todas las imágenes u otros objetos que no estén dentro de la «webslice»… ¿Las gracias, más allá de lo obvio? Al menos tres:

  • Para el funcionamiento (explicado aquí), tiran de microformatos y de un nombre de clase. Y los microformatos «molan» :-).
  • Las ‘webslices’ son absolutamente transparentes para los navegadores que no las soporten.
  • Se trata de una novedad que tanto Opera como Safari (y demás navegadores Webkit) o Firefox (y otros ‘Mozillas’) pueden implementar vía plugin en cuestión de horas y, si la cosa funciona, incorporar a su base de código sin apenas esfuerzo.

Vale, los dos últimos puntos son de cajón, pero… ¡estamos hablando de Microsoft! :-P

Si además es cierto que soportan de verdad CSS 2.1 (y que están con CSS3) y las mejoras del DOM y para AJAX anunciadas son significativas (habrá que leerlo con más detenimiento), IE8 puede contribuir a hacernos creer que el equipo de desarrollo de Explorer «se lo curra», a que desarrollar para la web sea un poco menos doloroso y a facilitar un goteo de pequeñas innovaciones en los navegadores que fluyan con facilidad de una familia a otra…

IE8 y los estándares

Curioso viaje el de Internet Explorer 8. Y eso que aún son bien pocos los que han podido tocar su beta…

A finales de enero de este año A List Apart se descolgaba con dos artículos – globo sonda, Web Standards, Forward Compatibility, and IE8 y From Switches to Targets: A Standardista’s Journey (este últimado firmado nada más y nada menos que por Eric Meyer, que se dice pronto) anunciando que, si bien Internet Explorer 8 iba a tener un exquisito respeto por los estándares web, este no iba a venir activado por defecto: si el desarrollador de turno no incluía una línea de código en la cabecera de la página (<meta http-equiv="X-UA-Compatible" content="IE=8" />), Explorer 8 reproduciría la página exactamente igual que IE7, a pesar de poderlo hacer mucho mejor (donde «mejor» debe leerse como «de acuerdo con los estándares»). Impresionante.

El motivo aducido por Microsoft para ello (motivo, hay que añadir, que el que suscribe consideró en su momento, y considera todavía, bastante razonable, aunque no sea de mi agrado) era «no romper la web». Con el paso de IE6 a IE7 el equipo de Microsoft Explorer rompió muchas páginas web que se habían desarrollado alrededor de la infinidad de particularidades de Explorer 6. Ningún «estandardista» sufrió esas consecuencias, naturalmente, porque, de hecho, el lanzamiento de IE7 tenía como objetivo agradar a esa comunidad (además de respetar algo más los estándares, que ya tocaba). Las víctimas fueron los «malos desarrolladores». Esos que no se toman la molestia de comprobar que sus aplicaciones funcionen más allá del navegador por defecto (esto es, IE6, en aquel momento, IE6 y IE7, ahora mismo) ni saben qué es un estándar web y continúan pensando que maquetar con tablas es la cosa más natural del mundo. ¿El problema? Una buena cantidad de esos desarrolladores se dedica a programar las intranets y aplicaciones web de las empresas del «Fortune 500» (y puede permitirse, por tanto, el «lujo» de ignorar absolutamente la existencia de Firefox). Y esas empresas son esenciales para la cuenta de explotación de Microsoft. Provocarles una crisis es un más que posible mal trago para las arcas del gigante del software (y un dolor de cabeza añadido a la migración de XP a Vista…), pero dos representaban un riesgo por el que, debieron pensar, bien valía la pena jugársela y arriesgarse a irritar a la comunidad de desarrolladores web respetuosos con los estándares…

Dicha comunidad, como no podía ser de otra forma, se alzó en armas y llevaba mes y pico de campaña de acoso y derribo contra la decisión de Microsoft. Hasta hoy. Parece que es verdad que corre sangre nueva por Redmond y desde el IEBlog se anuncia un paso atrás de proporciones épicas: IE8 funcionará siempre que pueda respetando los estándares (como bien explican en la entrada, todos los navegadores se miran las páginas antes de representarlas; solo si «se atreven» aplican el modo «respetuoso con los estándares» que, en caso de fallar, puede hacer un auténtico destrozo con una página web que no esté a la altura).

La conclusión con la que me quedo (además de aplaudir la valentía del equipo de IE) es que Microsoft está haciendo todo lo que puede (y dada su enorme masa, cualquier pequeño movimiento es harto complicado) para adaptarse a los nuevos tiempos, prestar atención a la comunidad y respetar los estándares y la interoperabilidad. Cualquier día de estos se congela el infierno…