Html5: Html para aplicaciones web
Desde hace mucho tiempo, oímos culpar de los problemas intrínsicos de las aplicaciones web, a la naturaleza “document-oriented” de la web. La web fue pensada originalmente como una red para compartir documentos “hipervinculados”, y no como plataforma de aplicaciones distribuídas. De hecho fue éste el argumento expuesto por Google en forma de historieta para lanzar Chrome.
Para subsanar esta brecha surgieron una gran variedad de tecnologías, como javascript, Java Applets, Ajax, Flash, y más recientemente Google Gears, Java FX y Silverlight con la intención de crear en los browsers lo que se conoce como Rich Clients, clientes que permitan una experiencia de usuario similar a la de una aplicación de escritorio, con todas la ventajas de la web.
Sin embargo en todo este tiempo, el “poder legislativo” de la web, la W3C, no se quedó de brazos cruzados, y como es de esperar, respondieron con un estándar, tomándose su tiempo. La respuesta de la W3C fue: HTML5
HTML5 traerá muchas novedades, pero lo importante, la idea que está detrás de la mayoría de ellas, es la creación de aplicaciones web “ricas” en nuestros browsers. Para muestra basta un botón:
- Graficos vectoriales, animaciones y efectos visuales más avanzados
- Almacenamiento local en el browser, no sólo como diccionarios, también en forma de bases de datos SQL, y otras facilidades para aplicaciones “offline/online”
- WebWorkers, tareas asincrónicas, y un sistema de mensajería entre ellas.
- Navegación Ajax
- Streaming de audio y video
- DOM Events, los elementos de un documento html, expondrán una serie eventos (ej: div.resize)
- Drag & Drop
- Tags semánticos asociados a aplicaciones como: <progress>, <meter>, <command>, <datalist>, <output>, y nuevos tipos de campos para formularios (<input>) como “datetime”, “range”, “search”, etc.
- varios etc.
A esta altura, resulta evidente que tener soporte para todo esto, de forma nativa en HTML, se ve como una amenaza para todos los que proveen estos features actualmente mediante plugins, como Flash, Java FX, Silverlight y otros.
HTML5 todavía está en pañales, y se acerca lentamente, sin embargo la mayoría de los browsers ya soportan varios features de HTML5.
IE9, Podría Microsoft estar suicidando Silverlight?
Con la salida de IE8, Microsoft empezó a soportar algunos features de HTML5, sin embargo este era muy limitado, y con la ausencia del elemento <canvas> que permite la inclusión de gráficos vectoriales, se especuló sobre una estratégica defensa de Silverlight.
Sin embargo, con la llegada de IE9 están anunciando un soporte para HTML5 mucho más completo, tanto que publicaron una pagina para probar entre otras cosas el soporte HTML5 de IE9 (incluyendo animaciones y gráficos vectoriales con aceleración por hardware).
Y a esto se suma un nuevo engine Javascript, que pretende ponerse a tiro con el resto con benchmarkings prometedores. Esto me recuerda un comentario sobre el futuro de Javascript de Martín Salías.
Para los que trabajamos con .Net surgen ahora dudas existenciales sobre como afectará esto el futuro de Silverlight.
Sin duda la familiaridad del framework .Net, C#, y la integración con VisualStudio son la panacea para los desarrolladores que ya trabajamos con .Net, sin embargo, ¿Qué features realmente distintivos tendrá Silverlight para los usuarios?
Gráficos 3D, Out-of-browser y Smooth Streaming?
Quizás todavía sea solo futurología, pero la llegada de IE9 nos acerca bastante a la pregunta:
¿Cuál será el lugar que ocupará Silverlight (y otras RIU) con la llegada de HTML5?.
Profecía autocumplida: Google + Apple + Microsoft
Ya no hace falta decirlo, a esta altura, HTML5 será un caso evidente de profecía autocumplida, no sólo por tratarse de un estándar de la W3C, sino por contar con el apoyo de Google (además de incluir soporte en Chrome, decidió abandonar Google Gears, por considerarlo un subset de lo que HTML5 proveerá y creo una versión HTML5 de YouTube), Apple (soporte en Safari, que incluirá IPhones que actualmente no soportan Flash), y finalmente Microsoft con la llegada IE9.
Falta aún saber cuanto falta para que sea soportado completamente por los browsers más populares, y para que nuestras IDEs nos permitan aprovecharlo.
