Más sobre Flash como herramienta de autor de HTML5

Decíamos hace un par de meses que finalmente, Flash movía ficha hacia HTML5. Pues bien: Flash CS6 está a punto de salir y la cosa ya está plenamente definida, tal y como podemos ver en el siguiente vídeo:

Primero, la mala noticia: olvídate de programar en ActionScript y que funcione en JavaScript: ambos lenguajes son primos hermanos, pero mucha de la magia que se oculta en la máquina virtual de Flash, hoy por hoy, ni existe de forma nativa en JavaScript ni tendría sentido empaquetarla en forma de bibliotecas JavaScript. Fin de la historia. Flash contará con un método para poder teclear código JavaScript desde Flash pero, así entre nosotros, es un parche bastante horroroso.

Una vez dicho esto, ¿para qué va a servir Flash en la creación de contenido HTML5? (dos aclaraciones: la primera, que entendemos por contenido HTML5, básicamente, animación, interacción y sonido en canvas; la segunda, que todo esto se basa, como comentan en el vídeo y comentábamos en nuestra anterior entrada sobre el tema, en CreateJS, una suite de bibliotecas JavaScript de código abierto y que, de hecho, pueden usarse sin tocar para nada Flash).

Repasando y resumiendo el vídeo:

  • Una de las principales gracias de Flash (la herramienta) es que una buena forma de empaquetar recursos (imágenes bitmap y vectoriales y sonido, principalmente) en un archivo de forma que luego podamos acceder a esos recursos desde un lenguaje de programación (ActionScript, en sus diferentes encarnaciones) y manipularlos de manera sencilla. Flash CS6 va a ser una buena forma de empaquetar esos mismos recursos en un archivo de forma que luego podamos acceder a ellos desde un lenguaje de programación. El cambio es que a ActionSript le va a salir un rival: JavaScript. En vez de un archivo HTML que cargue una película swf tendremos un HTML que cargue unos cuantos JavaScripts que crearán un canvas equivalente (en la medida de lo posible, que es bastante, por lo que parece) al swf.
  • Las animaciones Flash sin programación se exportarán directamente, con tweens y sonido y con carga dinámica de recursos, sin problemas. Y si usamos fragmentos muy básicos de ActionScript para, por ejemplo, poner nuestras animaciones en bucle, hacerlo en JavaScript desde dentro de Flash será bastante cutre (como ya decía antes) pero factible (de hecho, viendo cómo funciona en el vídeo, imagino que en nada habrá pequeñas bibliotecas de código que reproduzcan la mayoría de acciones básicas ActionScript y me permitiré apostar a que Flash CS7 nos traerá un soporte para JavaScript similar al actual soporte para programar en ActionScript en CS5: digno pero no espectacular). Flash hoy no acaba de ser un gran IDE para ActionScript (ese papel lo juega Flex) y, parece lógico, Flash no quiere ser un IDE JavaScript.
  • Los símbolos de nuestra película Flash serán accesibles desde JavaScript de manera sencilla. Esto permitirá (en principio y siempre según el vídeo) que ilustradores y animadores trabajen con un .fla desde Flash y irselo pasando, versión a versión, al desarrollador de turno para que este vaya haciendo su parte. Y, si desde el lado Flash no se cambian los nombres de los símbolos, debería poder substituir una versión del archivo exportado por otra más reciente sin más problemas.
  • Hay un esfuerzo importante por llegar a un equilibrio entre tamaños de archivo reducidos y código legible. Naturalmente, el HTML y JavaScript van a pesar más que el swf equivalente (pensad que hay que transmitir cada vez un montón de cosas que normalmente están en la máquina virtual de Flash, que hemos descargado una sola vez). Adobe albergará las bibliotecas JS en una CDN de manera que podamos rentabilizar cachés, pero no va a ser lo mismo. De la misma forma, el rendimiento no va a ser el mismo que un .swf, pero parece que la cosa es digna y siempre contamos con los esfuerzos de los desarrolladores de navegadores por mejorar el funcionamiento de JavaScript…

Y eso parece todo, de momento. Me atrae el pragmatismo que parece exhibir Adobe: no han intentado resolver todo el programa a costa de grandes montañas de “código spaghetti” (asumiendo las limitaciones actuales de Flash como IDE, para comenzar) y asumen que esto es una 1.0 que va a tener que mejorar deprisa si no quieren que surja un aspirante a su corona. Un muy buen (aunque tardío) primer paso, en mi opinión.

Los que estéis interesados en el tema deberías seguir por el CreateJS Developer Center que ya hay en adobe.com, que ya contiene algunos recursos y que, esperemos, crecerá notablemente en los próximos meses.

Finalmente, Flash mueve ficha hacia HTML5

O, al menos, eso parece deducirse de este sneak peek que publicó Adobe ayer:

De la necesidad imperiosa de Flash de saltar a la piscina de HTML5 antes de que el formato swf se vuelva irrelevante del todo hemos hablado en más de una ocasión en este blog. Ya en octubre de 2010 nos preguntábamos quién acabaría matando a Flash y nos olíamos que jQuery y familia podían sustituir buena parte de las ‘animaciones de botón’ (nos olvidamos de CSS3, todo sea dicho), pero que para hacer cosas potentes Canvas parecía una alternativa bastante más interesante y factible. Un poco más tarde, en marzo de 2011 nos preguntábamos a qué exportaba Flash, exactamente: Adobe anunciaba que exportaba a HTML, pero que lo generaba era jQuery por un tubo. Bien para cosas básicas, pero para nada a la altura de funcionar efectivamente con un .fla sofisticado. Toda una decepción. Y hace un poquito más de tres meses volvíamos a interesarnos por la carrera de Adobe por seguir siendo relevante en un mundo HTML. Y seguíamos sin entender. Más de lo que habíamos visto en marzo… y una alternativa a Flash: Adobe Edge (por cierto, que Edge sigue moviéndose y anda por la ‘preview 4′, que salió en enero). Pero Flash, la joya de la corona Macromedia, seguía sin salir a Canvas, limitado casi cruelmente a una sopa de divs, SVGs y animaciones del DOM. Sorprendente.

Febrero de 2012 y, finalmente, parece, Adobe tiene algo que enseñar digno de enseñarse. Enseñan poco, muy poco, pero cuentan en el vídeo que la cosa va de usar CreateJS, que se autodescribe como “una suite de bibliotecas JavaScript y herramientas diseñadas para trabajar con HTML5″, que incluye EaselJS (“una biblioteca JavaScript para trabajar con el elemento Canvas de HTML5″), TweenJS (“una biblioteca de animación y tweening para JavaScript y HTML5″, y que también sale a Canvas) y SoundJS para trabajar con sonido. Que uno diría que es una buena receta para hacer lo que hace Flash… pero sin archivos swf ni la máquina virtual de Flash. Todo ello con la firma de Grant Skinner, que, por poner un ejemplo brillante, está detrás de pirateslovedaisies.com (que sí, que es difícil de creer, pero no es un .swf…)

A Flash le queda mucho camino por avanzar si quiere salvarse de la quema, pero de golpe, la cosa parece mucho menos negra…

La carrera de Adobe por seguir siendo relevante en un mundo HTML…

…queda bastante bien ilustrada en el siguiente vídeo:

Después del anuncio de la renuncia de Adobe a continuar con el plugin Flash para los navegadores móviles, la carrera (ya en marcha: habíamos tocado el tema hace poco más de un año) por desarrollar las herramientas equivalentes a Flash para un mundo HTML se vuelve cada vez más importante.

Si bien opino que Adobe aún cuenta con bastante ventaja sobre la competencia (por ‘know how’ y, sobre todo, por presencia en el mercado), resulta un poco decepcionante comprobar que su estrategia apenas ha cambiado en doce meses. Siguen teniendo dos caballos en la carrera de las películas (por seguir usando terminología Flash) hechas con divs, CSS y jQuery (o bibliotecas JavaScript similares): un exportador para Flash (que genera HTML, CSS y JavaScript, que no HTML5; dudo bastante que hayan cambiado mucho en seis meses) y Edge, aún en beta, pero que, básicamente, parece competencia para Adobe fabricada por Adobe… Y, mientras tanto, ningún caballo en la carrera que a mí, al menos, me parece verdaderamente interesante: desarrollar algo que sea verdaderamente HTML5 (esto es, muy probablemente, tirando de canvas) y que nos ahorre los problemas de Flash, más que hacerlos perdurar en un entorno diferente… Pero, si la cosa sigue igual, comienzo a temer que Adobe pueda permitirse el lujo de patinar y aún así conservar la corona por incomparecencia de aspirantes al título. Esperemos que no sea así.

Flash exporta a… ¿qué, exactamente?

Adobe sigue blindando o intentando blindar a Flash (la herramienta de animación, más que la de desarrollo, parece) frente a los dispositivos (cada vez más, distinguidos por llevar al dorso un tatuaje de una pieza de fruta) que no reproducen Flash (el formato). Cosa que no debería sorprender a nadie. Pero sí me sigue sorpendiendo la manera en que lo están haciendo. Hoy han publicado en sus Labs Wallaby, an experimental technology that converts the artwork and animation contained in Adobe® Flash® Professional (FLA) files into HTML.

Si queréis ver un ejemplo de lo que hace, podéis ver un original en Flash y su transformación a HTML (encontrados ambos vía Andy Baio en enwire.dk). Las cosas que sorprenden:

  • Si habéis abierto la versión HTML con Firefox, Opera o IE… no habéis visto la animación. Porque ahora mismo solo funciona bajo navegadores Webkit (esto es, básicamente Safari y Chrome). Eso era razonable cuando hicieron la primera demo (a finales de octubre). Pero ya han pasado cuatro meses desde entonces…
  • Si abrís el código fuente veréis que no hay un canvas de por medio: el código muestra una colección de piezas en svg en divs anidados y animados en JavaScript usando jQuery y las herramientas de animación en JavaScript propias de WebKit.

Sus motivos deben tener, pero, por un lado, cuatro meses para lanzar algo a los Labs sin que funcione más que en navegadores (hasta ahora, al menos) minoritarios no me parece una gran idea. Uno podría sospechar que la idea es hacer algo que funcione óptimamente en la implementación de Webkit de Safari Mobile pero, entre nosotros, acabo de abrir la página en un iPhone y funcionar, funciona, pero… se arrastra. Y, por otro, si tenemos que imaginar que los desarrolladores de Webkit (y de Firefox Mobile, y de Opera Mini y Mobile) van a optimizar algo en sus motores, votaría por Canvas mucho antes que por cualquier otra cosa.

Vaya, que no dudo de la brillantez de los estrategas y desarrolladores de Adobe, pero no salgo de mi asombro…

¿Quién matará a Flash?

Parece claro: HTML5 y su combinación de Canvas y JavaScript, o alguna otra tecnología, van a acabar reemplazando a los .swf en la web

[Adobe sigue posicionando Flash como plataforma para múltiples aplicaciones. El vídeo en la web (vinculado a un ‘media server’, con ancho de banda adaptable y/o DRM) sigue siendo una propuesta de valor a considerar. También apuntan al 3D en el navegador: parece que, finalmente, el próximo Flash tendrá 3D nativo, aunque podrían llegar tarde para competir con las bibliotecas de 3D para JavaScript que llevan ya una temporada dando vueltas. Y siguen insistiendo en posicionarse como una alternativa a los entornos de desarrollo de Microsoft que sale hacia la web (donde Silverlight no parece una amenaza seria) por un lado y hacia el escritorio, dispositivos móviles y hasta televisores, por otro, de la mano de Adobe Air 2.5. Todo ello en un ecosistema con herramientas especializadas como Flash Catalyst o Flex Builder y una buena integración con la ‘estrella’ de la casa para los diseñadores, Photoshop —la integración es mejor aún con Fireworks, que parece mejor herramienta para diseñar interfaces para interactivos pero que, diría, aún no tiene la cuota de mercado que creo que merece.]

En cualquier caso, aún dando por supuesto (no parece nada descabellado) que Flash va a ceder el campo de ‘animación interactiva para la web’, seguimos necesitando una herramienta de autor comparable. Y el problema, ahora mismo, es que parece que vamos a pasar de ninguna a demasiadas opciones en un suspiro…

  • Por un lado, Microsoft, sorprendiendo a propios y extraños, sacó (sin mucha promoción) hace unas semanas Ai->Canvas, un plug-in para Illustrator (sí, de Adobe, de ahí la sorpresa) que ‘escupe’ Canvas+JavaScript de forma al menos aceptable. Y que, además, ahora mismo, es lo único que lo hace con pinta de ‘herramienta de autor’.
  • No contentos con esto, también tienen Glimmer, que sin ser un prodigio de usabilidad, ahorra mucho trabajo a la hora de usar algunos de los efectos más habituales de jQuery para manipular el DOM del navegador.
  • Por otro lado, anteayer, la propia Adobe anunció el prototipo de una herramienta nueva y especializada, Edge (vídeo de demo), que iría por la vía de jQuery. No sé si para sorpresa de propios y extraños, pero sí para la mía, que habría apostado por un exportador para Flash y me había quedado tan ancho…
  • Y cuando uno ya vivía ‘feliz’ con la promesa de una nueva herramienta, me encuentro con que Mike Chambers (el principal product manager for the Flash Platform at Adobe) tuitea que están enseñando el exportador de Flash a HTML5… Que ya era lo que yo anticipaba, efectivamente, posicionando a Adobe en los dos campos: jQuery y Canvas. [Ups: ver el segundo ‘PS’ al pie de la entrada]

Todo esto a la espera de que otros se lancen (o no) al ruedo: Microsoft también debería poderle hacer un exportador a todo lo que ahora vaya hacia Silverlight y no depender de Adobe e Illustrator, mientras que Apple podría crear sin demasiados problemas un “Flash killer” y seguir haciendo un poco la puñeta a Adobe.

Todo parece indicar que quien quiera dejar de usar Flash en la web va a tener que apuntarse a las dos opciones: para los típicos efectos ‘rollover’ y similares, jQuery o alguna de sus alternativas y, para animaciones ‘de verdad’, Canvas con sus correspondientes herramientas de autor/kits de desarrollo. Dado el nivel de mejora en el rendimiento de JavaScript de los navegadores, saltarse a Flash Player parece una buena decisión (parece que hasta Adobe vota por ello, con sus demos y anuncios), pero antes de tomarla hay que ser consciente de diversos aspectos. Hay cosas como empaquetar todos los objetos en un único .swf que parecen cómodas, y también hay que pensar en el montoncito de usuarios que siguen anclados en IE7 y 8, que no son despreciables en muchos ‘targets’ y cuyo rendimiento de JavaScript va a seguir siendo patético durante una temporada (en el caso de los “resistentes de XP”, jamás saltarán a IE9, además).

En cualquier caso, a buena parte de los desarrolladores de ActionScript les conviene ponerse las pilas y comenzar a ver cómo funcionan tanto jQuery como Canvas…

PS 20101028 Obviamente, 24 horas después de escribir el post, me encuentro con información adicional de dos que se lanzan al campo de la animación HTML5: Sencha Animator y AdVine (estos últimos dedicados en exclusiva al mundo de la publicidad, parece). Ambos, vía TechCrunch.

PS20101028 Se ha ‘filtrado’ vídeo de la demo del exportador de Flash a “HTML5″ y no se trata de Canvas+JavaScript, sino de HTML, CSS3 y JavaScript. Aún estoy más perdido…