Saltar al contenido

Un artículo más sobre html5: expectativas, novedades, cambios, etc. Nada interesante para los que sigan la evolución de html5, excepto que explica porqué se han integrado dos tipos de cambios en la nueva versión de html. Por un lado tenemos al W3C que ha incorporado cambios relacionados con la estructura documental y semántica de html con nuevas etiquetas (header, footer, dialog, aside, etc) y por otro el WHATWG que ha incluido aspectos más relacionados con el desarrollo de aplicaciones (etiquetas canvas, video, audio y nuevos apis web workers y local storage). Creo que esta parte es la que tendrá más peso en el futuro, convirtiendo a la web en una plataforma de desarrollo.

En lo que no estoy de acuerdo es en el ámbito temporal. Aunque microsoft tiene mucho peso, el soporte en navegadores no-microsoft es muy amplio y generalizado y no debería quedarse atrás. Aunque el W3C espera que hasta 2022 no haya una versión estandarizada, probablemente haya un estándar de facto implementado (incluyendo a microsoft) antes de 2-3 años (con la excepción del vídeo, dónde los codecs son un problema importante, que no tiene solución a corto plazo).

PD: he añadido la etiqueta web2.0, aunque ya suena anticuado y pasado de moda. Aún así han quedado los cambios más "estructurales" de la web2.0: la web cómo plataforma social, los interfaces ajax, etc.

Primero, debido a una metedura de pata configurando feedburner (con el que publico a través de twitterfeed) había dejado de funcionar la publicación en twitter. Debería estar resuelto, espero que este post sirva de prueba.

Segundo que la metedura de pata vino porque he cambiado la fuente rss para que llegue a través de feedburner y me sorprende que haya alrededor de 50 suscriptores por RSS! Ya sé que es una misería, pero es mucho más de lo que me esperaba, gracias por seguir leyendo.

Y tercero, voy a hacer un breve comentario de mi escasa experiencia con twitter. Al principio, me parecía que twitter era cómo un histórico del estado de messenger: al igual que mucha gente va actualizando su estado en messenger, twitter era cómo un log de este tipo de mensajes de estado: "Estoy en casa", "Leyendo choque de reyes", "Viendo el partido del Real Madrid", etc. Personalmente, no le veía mucha utilidad a escribir públicamente este tipo de mensajes.

Pero creo que esa función inicial se ha visto sustituida por una función nueva: el retweet. Un retweet sirve para reenviar un tweet publicado por otra persona. Algo sencillo, pero que cambia la filosofía de twitter. La gente publica sus artículos, noticias, etc. en twitter y si son buenas son "retweeteadas", con lo que twitter se ha convertido en un medio de difusión social. Al contrario que los filtros sociales cómo digg o meneame, en los que la finalidad es que los artículos aparezcan en una portada común, twitter no tiene más objetivo que comunicar los artículos publicados de contacto en contacto, con lo que cumple mejor la función de difusión social.

Me imagino un grafo social, en el que en un punto se publica un artículo y por medio de retweets, el artículo se difunde a través del grafo. Si es bueno, llega a muchos nodos y si no, apenas se difunde. Es sólo la impresión de un novato en twitter que quería compartir con todos, podéis comentar, retweetear o lo que queráis.

Para los que trabajen con arduino, sabrán que es un proyecto basado en Processing, un lenguaje y entorno de programación para aplicaciones multimedia e instalaciones interactivas. Lo que quizá no sepan es que processing se ha portado a javascript utilizando la nueva etiqueta canvas de html5: processing.js. En el estado actual, soporta muchas de las instrucciones de processing, excepto las instrucciones 3D, que esperan poder implementarlas cuando se desarrolle una etiqueta canvas 3D (para firefox ya hay un intento de implementación). Además processing.js fue portado por John Resig, creador entre otros proyectos de la librería jquery. Igualmente sorprendente para mí es que muchos de los ejemplos de chrome experiments están hechos con processing.js.

Una ventaja de processing.js sobre processing es que además de ejecutarse en navegadores recientes y aceptables sin ningún plugin (explorer no entra en esta categoría todavía) se integra fácilmente con el entorno web y se pueden agregar otras librerías javascript (jquery, por ejemplo) para realizar experimentos muy visuales.

El lado negativo está en el rendimiento, que no es nada bueno. En mi ordenador con 4 cores, se me quedaba bloqueado porque sólo tiraba de una cpu. Si alguien diseña un proyecto complejo, debería implementar parte de la lógica con web workers.

Un estudio concluye que el futuro de las aplicaciones móviles está en las aplicaciones móviles web adaptadas a los interfaces táctiles. El estudio viene de una empresa que se dedica a las búsquedas en la web para terminales táctiles, así que no es extraño que hayan llegado a esa conclusión.

Sin embargo el estudio apoya con cifras la idea de que los juegos y las aplicaciones de entretenimiento se distribuyen más como aplicaciones nativas mientras que las apliaciones sociales y las aplicaciones para compras y servicios se distribuyen más como aplicaciones web.

En cualquier caso existe la duda técnica de si las aplicaciones basadas en web serán tan rápidas como las aplicaciones de escritorio. Muchas aplicaciones son lo suficientemente buenas, pero probablemente los juegos más exigentes no sean adaptables a la web.

Un ejemplo que me he encontrtado es el de freeciv un juego de escritorio para el que han desarrollado un frontend en html5 y por ahora la experiencia no me ha parecido demasiado buena. Se puede jugar, pero no tiene una interfaz demasiado buena comparado con el juego de escritorio.

Por otro lado está la duda económica. Las aplicaciones web generan ingresos principalmente por medio de la publicidad y las suscripciones. Las aplicaciones nativas lo hacen mayoritariamente a través del cobro por descarga. Aunque técnicamente sea viable desarrollar juegos completamente html5, es posible que generen más ingresos con el modelo de cobro por descarga, por lo que quizá no sea rentable desarrollar juegos html5.

2

Google acaba de introducir google voice para el iphone como aplicación web basada en html5 en lugar de cómo aplicación nativa, saltándose el proceso de la app store de apple. Voice es una aplicación interesante en sí misma porque virtualiza nuestra línea telefónica, pero lo llamativo en este caso es que una aplicación nativa ha sido sustituida por una aplicación web abriendo el debate sobre qué modelo es más adecuado para desarrollar aplicaciones móviles.

Lo cierto es que no todas las aplicaciones son iguales. Por ejemplo la mayoría de juegos necesitan acceso directo al hardware para funcionar rápido. Sin embargo para una aplicación que no sea muy exigente técnicamente, puede ser suficiente con html5, beneficiandose de la disponibilidad y facilidad de instalación de las aplicaciones web y de la visibilidad en los buscadores web como google.

La verdadera clave será la capacidad para generar ingresos, ya sea por publicidad, por descarga o por suscripción. Y en este sentido, actualmente lleva cierta ventaja la app store, pero es probable de que la irrupción de aplicaciones web potentes puede cambiar el escenario.

Muchos sitios web están añadiendo versiones móviles de sus portales que incluyen soporte para html5. Leyendo un artículo sobre las mejores prácticas para desarrollo de sitios móviles, me he encontrado con la versión móvil de flickr, que utiliza el api de geolocalización de html5 (que se puede probar con firefox 3.5). La nota curiosa es que la geolocalización de flickr, una empresa yahoo, utiliza google maps. Es probable que yahoo maps no funcione bien en dispositivos móviles mientras que la versión 3 del api de google maps está optimizado para dispositivos móviles, lo que nos da una idea de la importancia que le da google a las aplicaciones móviles.