HTML5, Flash y la madre del cordero …
Llevamos una semana muy muy movida. Despues de los ultimos anuncios oficiales por parte de Adobe, primero sobre la paralizacion de la evolucion del player mobile, y luego de la liberalizacion de Flex como proyecto open source, alucino con las reacciones de ciertas partes de la comunidad, y pienso en como Adobe puede sostener esta situación, pero lo mas chocante, es cuando analizo un poco las necesidades de los clientes y del mercado.
Antes que nada, vayamos por partes para situarnos :
Player Mobile
El día 9/11, Adobe anuncia el cese de la evolución del player mobile. Y voy a puntualizar :
- El player ( Version 11) seguirá existiendo.
- Los dispositivos Android, seguiran usandolo.
- Seguira habiendo soporte y bug-fixes para el player 11 mobile
- Tenemos una version 11 en mobile, la cual para el uso que debe tener ( mostrar contenidos ya existentes ) va sobradisima.
Lo único que han comunicado, es que no seguirían implementando nuevas funcionalidades, léase Stage 3D por ejemplo. La gran fragmentacion de dispositivos moviles, hace la labor de tener un player actualizado para todos ellos enorme, algo que ademas, tampoco es aprovechado realmente, pues no se crean contenidos flash exclusivos para el browser de moviles a dia de hoy. Los esfuerzos que estaban dedicados a este player, se redirigirán ahora hacia Air y el player desktop.
Luego te pones a leer titulares y comentarios, y es realmente alucinante como se intenta desinformar constantemente, siempre con el mismo objetivo : “Muerte a Flash”. El odio desmedido por parte de algunas partes de la comunidad, realmente no tiene sentido la verdad, pero está ahí.
Flex Open Source
El hecho de que Flex pase a desarrollarse por la comunidad como open source, suena genial a no ser por que el player, no se libera. Entonces … ¿ Como pretenden que se implementen nuevas funcionalidades u optimizaciones?. La clave es, que para evolucionar realmente, debe ir de la mano de la evolucion del player. Realmente, no se entiende … Además te lo aderezan con frases como “In the long-term, we believe HTML5 will be the best technology for enterprise application development” … Muy bien, pero ¿long-term? … osea ¿dentro de cuanto tiempo HTML5 igualará las capacidades de Flex a dia de hoy ?El absurdo
A mi lo que realmente me alucina, es como quieren vender “la moto”.Imaginate un taladro eléctrico, sí de esos que usamos para hacer boquetes. Imagina, que dicho taladro, desarrollado por la marca “Pilti”, hace boquetes más rápido que cualquier otra herramienta, y además con sus varios accesorios, facilita hacer más cosas aún, regolas, atornillar con precision, etc.
Ahora, por distintas vicisitudes de mercado, y declaraciones a go-go en todos los medios, se dice que el taladro “Pilti” consume energia, y que ademas, es algo de la marca “Pilti”, y que algo que solo una marca controle, no es bueno. Ademas, con ese taladro, se han destrozado casas, porque como es tan facil, se ha “colado” haciendo boquetes, siendo la culpla del taladro claro, no del que hacia los boquetes.
Lo mejor es un cincel y un martillo, porque realmente, son standar. Además, gastan menos energia, y cualquiera puede hacer accesorios para ellos, cinceles mas grandes, puntillas, y todo un sinfin de cosas “standar” la mar de cool. Con tu cincel y martillo, puedes hacer lo mismo que con un taladro “Pilti”, y además, si quieres construir algo en el nuevo mercado emergente de los unifamiliares, no puedes usar un “Pilti”, porque esta prohibido, dicen que como consume mas que el cincel, pues no puedes usarlo, es mejor que uses todas las herramientas que te propone la empresa de los unifamiliares, la cual además si quieres vender accesorios para sus “casas”, te ofrece una bonita tienda online donde exponerlos, eso si, ganandose ellos su buen porcentaje.
Aun asi, el tema del cincel y martillo aun no esta muy claro, cada marca hace el cincel y el martillo a su manera, y cada uno funciona algo distinto, pero son “standar” …. Ah ! , tambien puedes destrozar una casa con el cincel y el martillo, pero ahora mismo, esto no es interesante …
Los constructores, andan cabreados, porque claro, con el “Pilti”, haces boquetes en todo tipo de paredes, con la misma herramienta, y los boquetes quedan igualitos en todas ellas, usas la misma herramienta siempre, y ademas tardas 3 veces menos.
Llegan los clientes, y les piden al constructor, que quieren hacer su casa, pero con cincel y martillo claro, que es mucho mas cool, pero ¿ y el precio ? Porque claro, el constructor necesita 5 cinceles distintos, uno para cada tipo de pared, ademas, ir poniendo masilla para remendar por aqui y por alla, para dejar todo “igualado” y que quede como con el “pilti”.
El cliente, no entiende que lo mismo, cueste el triple y encima no quede igual. El constructor, tampoco entiende, que le quiten una herramienta que está 6 años por delante del cincel y el martillo, cuando además, fueron esas inconsistencias del cincel y el martillo las que provocaron la invencion del “Pilti”, pero ahora nadie se acuerda de ello. Y encima, la propia casa “Pilti” dice que estan invirtiendo a tope en cinceles y martillos ….
Bien alejémonos del ejemplo, no sin antes terminar con un sonoro WTF!!!!! ( y en negrita… )
El día a día
Mi trabajo como freelance, como el de muchos de vosotros, se centra en desarrollos flash, bien en apps para facebook, microsites, o últimamente, aplicaciones mobile. Realmente, no importa si tenemos que programar en el futuro en Javascript ( dios no lo quiera ) o en otro lenguaje, el problema realmente que veo es la capacidad de respuesta ante desarrollos que se solicitan actualmente.Algo común en todos ellos es :
- Tiempos de desarrollo cada vez más apretados.
- Presupuestos cada vez más apretados.Si un cliente solicita una tipica aplicacion facebook, un juego, un microsite complejo o similares, ¿ es viable afrontarlos actualmente con HTML+JS ? Y cuando digo viable, no me refiero a si puedo hacerlos o no, me refiero a si por timing y presupuesto puedo hacerlo.
Porque sinceramente, yo creo que seria bastante más tiempo de desarrollo y sobre todo de debug, y por tanto, no entro en timing, y además ese tiempo, provoca presupuestos mucho mas altos… ¿ Esta dispuesto el cliente a pagarlo ? Porque el mercado no está precisamente “boyante” en cuanto a pasta …
¿ Como se pretende alcanzar el nivel de flash actual con HTML+JS a dia de hoy ?
¿ No nos acordamos porque Flash tuvo tanto exito ? Fue precisamente por las inconsistencias entre browsers …
¿ Cuando HTML5 va a igualar a Flex en potencia y rapidez de desarrollo ?Conclusiones
Adobe, como compañía que es, quiere ganar dinero. Y sus inversores, quieren ver más esfuerzos en HTML5, “el futuro”. Invertir más esfuerzo, en una compañia que ha perdido un 10% en el último ejercicio, implica irremediablemente, eliminar recursos de otras secciones de la compañia.Entiendo los movimientos que han hecho, pero si van a tomar ese camino, sobre todo con Flex, que lo tomen por completo, y me refiero con esto, a que el player se haga OpenSource, y hagan lo posible por integrarlo como standar pasando por la W3C.
Pero, si el player fuera OpenSource, y cada browser implementara su propio desarrollo, ¿ no terminariamos generando las mismas inconsistencias ?
Puede que la vía del OpenSource sea una solución. Adobe se dedicaria a seguir desarrollando Software que es lo que sabe hacer, y la comunidad de desarrolladores sería externa y libre.
¿ Terminaremos viendo un <flash> … </flash> ?
Veremos que nos depara el tiempo, pero el mercado esta muy muy revuelto desde luego …
HTML5, ¿Back to reality?
Se que soy un desastre con mi blog, y lo tengo realmente abandonado, no tengo perdón de dios ciertamente. En cualquier caso, y después de tener que escribir hoy un informe detallado para pelear un proyecto ciertamente complejo, el cual el cliente quería en HTML5, aprovecho para plasmar aquí las conclusiones que saco de todo esto…
HTML5, Jobs y su iOS.
Me parece lo más sensato empezar por el origen del “fenómeno”. Fué Steve Jobs y su abierta campaña anti-Flash la que abrió la veda en toda esta vorágine. Steve, icono para muchos, emblema de la marca de la manzana, despotricó abiertamente acerca de Flash y su rendimiento, su seguridad, su estabilidad, en definitiva de todo lo que pudo y más. Automáticamente, nos dió el paradigma de la solución, HTML5.
Para empezar, todos sus iDispositivos son incapaces de reproducir flash. Los argumentos dados son la falta de potencia por parte de estos dispositivos para hacerlo, y el gran consumo de flash en cuanto a CPU con el consiguiente bajón en las baterías, argumentos que parecen no cumplirse en dispositivos Android, que misteriosamente si pueden hacerlo, bueno, incluso pueden prescindir de iTunes para hacer cualquier cosa, o conectarse simplemente por USB, pero esto probablemente ha de ser malo también…
Legiones de entusiastas de todo tipo se apuntaron a la cruzada, fanboys y detractores de Flash puros y duros, unieron sus fuerzas, y Flash era pateado en blogs, webs, y cualquier otro medio, con diferentes argumentos algunos de los cuales propuestos desde el simple desconocimiento.
Evolución del conflicto.
Después del hype inicial, aparecían ya demos del canvas, ejemplos y ejercicios de estilo sobre HTML5+Javascript, y aprovecho para hacer un apunte en el camino, y recordar que HTML5 es un leguaje de marcaje y que necesitas javascript para programar, detalle que parecen obviar muchos.
Y las cosas molaban sí, pero realmente, el rendimiento no era tan brutal como muchos esperaban. Pruebas de rendimiento similares, demostraban que HTML5 no solo no superaba a flash, sino que en ocasiones iba bastante peor en cuanto a consumo de CPU se refiere.
Primeros Proyectos
Al poco tiempo, y movidos por el efecto “cool” de los iPhone/iPads, llegaron las primeras peticiones de clientes, “lo quiero en HTML5″, y con ellas, comenzamos a ver las primeras “verdades” :
- HTML5 NO es un standar. W3C, el organismo que rige los estándares alrededor de las tecnologías, augura que será en 2014 el lanzamiento de dicho standar como tal. Ver noticia aquí.
- Javascript es un leguaje mucho mas básico y menos robusto que AS3, mucho mas complicado de debugear y mantener. Para entendernos, es como dar un salto atrás y volvernos a AS1 prácticamente.
- Los navegadores, hacen sus propias interpretaciones de HTML5, lo cual provoca lo que siempre nos ha aterrorizado a todos, se ve bien en Firefox, esto no cuadra en Safari, esto no funciona en Explorer …
- La seguridad en las aplicaciones desarrolladas con Javascript es mas débil, y hay que invertir bastante más tiempo en desarrollar métodos eficaces para evitar hacks en apps que asi lo requieran.
- Los navegadores no-modernos ( llamémosles así… ) no son capaces de mostrar HTML5, IE6 e IE7 quedan descartados, y para IE8 tenemos muchísimas limitaciones y workarounds que hacer para poder lograr que las cosas medianamente “funcionen”. Tengamos en cuenta, que IE8 e inferiores tienen a día de hoy una penetración de más de un 30% de cuota.
- Las herramientas de desarrollo actuales son bastante limitadas actualmente.
- Mantener una app potente, con miles de lineas en Javascript es algo heróico comparado con mantenerla en AS3 y POO.
Independientemente de todos estos “peros” muchos proyectos se pusieron en marcha, y en el desarrollo de ellos es donde realmente se aprende.
Back to Reality !!
Yo personalmente he estado alejado de todo ello, y simplemente he observado los toros desde la barrera, leyendo algun que otro blog y manteniendome al día en la medida de lo posible, pero ha sido a raiz de este proyecto del que tenía que preparar un informe y un presupuesto, cuando me he informado más a fondo, y he recabado feedback de desarrolladores que ya han afrontado proyectos en HTML5.
Mi principal informador ha sido mi buen amigo Javi de DrusUnlimited, el cual ya ha peleado con varios proyectos reales y me ha dado información de primera mano, habiendo desarrollado durante bastante tiempo en AS3.
Antes que nada, le comenté de que se trataba el proyecto, e iniciamos la batería de preguntas:
Yo: Javi, hablemos de timings, ¿ Que tiempo calculas que se tardaria en desarrollar esto con HTML5+Javascript en comparacion con Flash ?
Javi: ¿ El cliente quiere que se vea en todos los navegadores ?
Yo: Sí claro.
Javi: Pues calcula que puede ser facilmente casi el triple, y ya te advierto que de IE6 e IE7 te olvides, y que con IE8 has de andar con workarounds. Debugear es bastante infernal.
Yo: Ostias el triple ?
Javi: Hombre, si fuera unicamente para mostrar en iOS, seria mucho mas sencillo, pero si tiene que ser visible en todos los navegadores, la cosa se complica.
Y básicamente, era todo lo que necesitaba saber, para preparar mi informe y presupuesto para el cliente.
Estamos hablando, que a efectos prácticos, para una webapp medianamente compleja, a dia de hoy, necesitas casi triplicar esfuerzos para realizar lo mismo que con flash y AS3.
Es muy cool HTML5, pero ¿ esta dispuesto un cliente a pagar el triple por ser mas cool ? ….. En el 95% de los casos, directamente NO. ¿ Desarrollar solo HTML5 para iPad/iPhone ? Tampoco, solo suponen un 3% de cuota total.
Y un detalle más, en el iPad vale, pero en el iPhone, no me veo usando con comodidad una webapp, es simplemente incomodo ver todo tan pequeño y andar con el zoom todo el dia.
Conclusiones
Vaya por delante, que no es mi intención ni mucho menos desprestigiar a HTML5, pero a día de hoy, creo que no están los navegadores lo suficiente maduros, ni el lenguaje estandarizado, y aunque tiene un potencial buenisimo, creo que el mercado se ha adelantado demasiado, apoyándose en una tecnología a la que aún le queda un camino por recorrer antes de ser lo que debe ser.
Me parece genial que se experimente, que se use para sites personales como prueba de concepto, pero llevarla a sites de producción me parece arriesgado cuando menos, principalemente por la cantidad de workarouds, por la evolucion propia de los browsers, te puedes topar que con el nuevo navegador tal, dejan de funcionarte cosas de proyectos que ya tenias terminados, con el consiguiente curro adicional y cabreo por parte del cliente.
Lo que me impresiona, es la capacidad de Jobs para crear el revuelo que ha creado, pero el tiempo pone a todo y a todos en su sitio.
HTML5 es el futuro, en eso estamos de acuerdo, pero no el presente, y sinceramente, ni creo que HTML5 vaya a comerse a Flash, ni viceversa, cada uno tomará su sitio en el mercado, porque cada uno es mejor para ciertas cosas, no hay panacea que valga.
Soluciones
Para el proyecto en cuestión que tengo, hemos propuesto al cliente lo siguiente :
- webApp en flash
- Aplicaciones especificas para iPad/iPhone, generadas desde flash para cada uno de los dispositivos, con ello tendríamos interfaces mucho mas usables y una experiencia mucho mejor para el usuario, esta app no es un juego ni necesita rendimiento puro para moverse.
Separando la logica de la app de las vistas, tendremos muchisimo hecho de cara a las mobileApp, de modo que por bastante menos presupuesto que la version HTML5+Java le ofrecemos al cliente mejores resultados para el usuario en cualquiera de las plataformas.
Información de utilidad :
Estadísticas globales de uso, navegadores y SO.
Notification Center para AS3
Supongo que muchos ya conocereis el framework ASAP para flash. Ciertamente es un framework bastante completo, y aunque casi todos usamos los nuestros “propios”, por aquello de “yo lo hice y yo me lo entiendo”, a mi me encanta echar un vistazo a las tripas y ver que caramelitos traen dentro.
En el caso del Notification Center, era algo que ya Sergio Daroca me había comentado, y ahora que lo he visto en profundidad la verdad es que me ha parecido algo muy interesante.
Notification Center es un port a AS3 de la clase “NSNotificationCenter_Class” usada en Cocoa, utilizada en el sistema OSX, portada por Arthur Clemens. Sencillamente, es un Centro de Notificaciones, tal como el nombre indica, y que te permite generar eventos personalizados con sus parámetros.
El funcionamiento de la clase es muy sencillo :
1. Registras tu clase para recibir el tipo de eventos que desees.
2. Emites eventos desde donde necesites
3. Todas las clases suscritas reciben su evento, con los parámetros que pasaras al emitirlo.
Añadir Observer
Para añadirlo, usas :
NotificationCenter.getDefaultCenter().addObserver(this, “doSomething”, “Notification”);
Donde “doSomething” es el método que recibe el evento, y “Notification” es el tipo de evento al que te suscribes.
Ademas de por tipo de evento, puedes suscribirte por tipo de datos, cosa muy interesante :
NotificationCenter.getDefaultCenter().addObserver(this, “doSomething”, null, myTipoDatos);
De este modo, es cuchas todos los eventos, recogiendo siempre que coincida con tu tipo de datos.
Emitiendo Eventos
Haríamos :
NotificationCenter.getDefaultCenter().post(”Notification”, null, “My message”);
Con esto notificariamos a todos los escuchas del evento “Notification” pasandoles el parametro “My message”.
Y la otra opción sería :
var anIdentifier:Object = this;
NotificationCenter.getDefaultCenter().post(null, anIdentifier, “My message”);
Ahora estariamos notificando a todos los escuchas que esperan el objeto “anIdentifier”.
Recogiendo Datos :
Para recibir, en la funcion que le hubieras seteado como escucha :
private function miFuncionEscucha (inNote:Notification) : void {
var notificationName:String = inNote.name;
var notificationObject:Object = inNote.object;
var productData:Object = inNote.data;
}
Y recuperamos simplemente los argumentos pasados y propiedades del evento en sí.
Como veis, es bastante sencillo de implementar, y muy práctico. Lo mismo puede hacerse usando el modelo de eventos nativo, la verdad no lo he mirado en profundidad y no se las diferencias exactas que pueda haber, lo que puedo decir es que esta clase funciona realmente bien y es sencilla y comoda de usar.
La clase en sí esta muy bien documentada, y por cierto, hace uso de otra clase para Logs, la cual os adjunto en el “pack”, simplemente recibe eventos de Log y los emite como traces para ir controlando, es bastante sencilla y tambien esta documentada.
Tengo algunas cosas más sobre ASAP sobre las que ire posteando, es un framework con muchos “caramelitos” dentro desde luego…
Espero os sea de utilidad !!
Descarga :
