es-robot.com

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.

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.