Por qué prefiero HTML5 para WinRT Apps?

Un ensayo orientado a #Developers y #Designers, acerca de la situación actual de la industria de las #apps y su relación con WinRT

Antes que nada, déjenme decirles que soy un profundo fan de C#.

Llevo 11 años trabajando con ese lenguaje de programación y luego de haber pasado por APL, JAVA, C, C++, PHP, JavaScript, Modula 3, Ruby, Basic, Visual Basic y TypeScript, puedo decir que es el mejor lenguaje a mi modo de ver, en su relación costo beneficio.

Pero así como también me gustan los Fórmula 1, no por eso los llevaría al campo para hacer 4x4.

Como la mayoría de sus contemporáneos, C# nació en un mundo donde el backend y las aplicaciones nativas estaban en el top of mind de la mayoría de los developers, y cuando los motores de interpretación de código dinámico eran supremamente lentos y estaban relegados a ser usados en escenarios básicos que no requerían mucha capacidad de cómputo.

Pero la computación obviamente ha evolucionado y así ha de pasar con las herramientas usadas para desarrollar el nuevo software.

No quiero decir que C# no haya evolucionado. Todo lo contrario. Ha evolucionado tanto que ya tiene sus propias características dinámicas ampliamente usadas en escenarios como MVC en los ViewBag. Ha evolucionado tanto que la asincronía se maneja con un nivel de abstracción que uno casi ni se da cuenta que existe con elementos como async y await. Ha evolucionado tanto que se puede valer de un compilador expuesto como servicio para hacer todas las locuras y genialidades que se nos ocurran con Roslyn.

Sin embargo un elemento bastante disruptivo ingresó a la industria de nosotros los developers que nos hicimos desarrollando WinForms y asp.net WebSites.

Y ese elemento, no es otro más que las apps.

Su relevancia comenzó con el Web 2.0, ajax, mashups y estás cosas de principio de siglo que nos trajeron excelentes aplicaciones web que con mero JavaScript nos daban una gran experiencia de usuario en escenarios de entretenimiento, información y herramientas para consumidores finales en un ambiente relativamente multiplataforma, hasta donde los browsers lo permitían.

Estas tendencias se hicieron evidentes también en las plataformas propietarias. Más específicamente hablando, en los smartphones. Pero al ser estos propiedad de las corporaciones, cada una quiso liderar el mercado con su propio acercamiento nativo. Llámese Objective C, Java o C#, dependiendo del fabricante.

Así que en un mundo ya centrado en el consumidor, estas producciones han comenzado a mover millones de dólares y a influenciar cada actividad relacionada con el desarrollo de software. Desde sistemas operativos, pasando por herramientas de desarrollo, mercados de aplicaciones y hasta el cloud computing que ya tiene ramas completamente orientadas a las apps.

Y por apps, me refiero a conjuntos de código relativamente pequeños que corren en un dispositivo sin requerir grandes capacidades de cómputo y que se pueden conectar a servicios a través de internet.

Por qué relativamente pequeños?

Porque para que el negocio funcione, tenemos dos limitantes:

1. Que corra en todos los browsers, sin plugins o

2. Que corra en un dispositivo móvil sin agotar la batería

En ambos casos llegamos a la conclusión que el alcance de la plataforma debe estar muy bien limitado, tanto para que podamos tener un mínimo común denominador en los browsers o para que no requiramos procesadores muy complejos que consuman muchos recursos.

Tenemos dos vertientes entonces:

La de los que saben hacer apps nativas y la de los que saben hacer apps con JavaScript.

En el mundo de las apps nativas estamos nosotros los desarrolladores de la última década. En mi caso particular, los desarrolladores de C#. Y C# está muy bien plantado con los SDKs y APIs que ofrece para el mundo de las apps tanto de Windows Phone como de Windows 8. Es muy completo y tiene el poderoso respaldo de Visual Studio para lograr hacerlas.

Sin embargo el tema que tenemos: reducir el alcance de esos SDKs y APIs para que se ajusten al mundo de las apps, ha provocado que el modelo de desarrollo ya no sea aquel al que están acostumbrados los desarrolladores tradicionales que se espantan porque ya no encuentran las apis a las que estaban acostumbrados en temas tan evidentes como el manejo de archivos entre otros.

Por si fuera poco el mundo de las apps tiene una exigencia de diseño sin precedentes y una app que no guste desde el primer momento de usada, está condenada a su desinstalación inmediata. Ya no nos podemos dar el lujo de hacer apps como queramos, porque nuestros usuarios ya no son los típicos empleados que están obligados a usarlas. Las apps de verdad deben GANARSE el amor de sus usuarios y esto no solo se logra con buena programación, sino con buenos diseños y UX.

La evolución de los paradigmas de desarrollo de aplicaciones entonces ha sido dirigida a facilitar la tarea de crear interfaces de usuario de la más alta calidad gracias al trabajo de los diseñadores.

Esto básicamente requiere de un principio que he denomidado la paradoja DevDes:

1. Que los elementos de presentación estén completamente separados de la lógica

2. Que los elementos de presentación estén completamente integrados a la lógica

Por qué es esta paradoja?

Es sencillo, necesitamos que los diseñadores puedan trabajar sus diseños con sus propias herramientas sin necesidad de saber nada de desarrollo. O sea, que puedan trabajar separados de la lógica de la aplicación.

Pero cuando ya hayan acabado, necesitamos que lo que hayan hecho esté completamente integrado a la lógica de la aplicación para que no haya sufrimientos tratando de importar piezas hechas en Illustrator a un Visual Studio. De lo contrario, puede que lo que se desarrolle en realidad, quede muy distinto a lo que se había diseñado.

Además en el proceso de mejora continua, debe ser muy transparente y eficiente la comunicación y el trabajo interdisciplinario.

Entonces ahí fue cuando en Microsoft apareció WPF y el famoso XAML. Un lenguaje basado en XML que permite declarar interfaces gráficas a través de lenguaje de marcado, de tal manera que una herramienta amigable con diseñadores puede generar este texto, que luego es leído sin problema por una herramienta para desarrolladores, cumpliéndose entonces los dos puntos que declaré anteriormente.

Estas herramientas no son otras que Blend y Visual Studio.

Pero trabajar este tipo de interfaces eficientemente no es sencillo con las costumbres tradicionales de mezclar la lógica con la presentación en los event handlers del click de un botón al mejor estilo amateur cuando se aprenden a hacer aplicaciones ASP.NET o WinForms.

El afán por ordenar el caos, nos llevó a los más osados a trabajar con el modelo MVP.

Pero el nuevo esquema de XAML, requería algo mucho más sofisticado y es lo que efectivamente conocemos como MVVM.

MVVM: El monstruo que aterra a los developers tradicionales cuando ven una app que lo implementa. El que los aleja de la productividad mientras lo aprenden. Un modelo que exige un reset en la manera de pensar y programar las interfaces de usuario. Un monstruo que muchas veces frustra a los no iniciados.

He visto a decenas de desarrolladores perderse en ese mundo de modelos, vistas, vista modelos, comandos, binding, IObservable collections, INotifyPropertyChanged y dependency properties entre otros.

Y esto es, no porque sea una cosa supremamente compleja, sino porque es algo muy distinto a lo que se trató de tener anteriormente en .net: Obtener un modelo uniforme de programación. La verdad sea dicha, es utópico esto dada la inmensa variedad de escenarios de desarrollo de software que tenemos hoy en día.

Entonces, estamos perdidos los desarrolladores .net tradicionales en el mundo de las apps?

No, si nuestro deseo u obligación es hacer apps, como lo mencioné, el código y las herramientas provistas por C# y Visual Stuio/Blend son excelentes para lograrlo, pero debemos estar dispuestos a hacer el reset y tener mente abierta sobre todo para comenzar aprendiendo MVVM, antes de aventurarse al mundo de las apps.

Esto no es que aclare precisamente por qué prefiero HTML5 para las apps.

Antes de aclararlo, quiero contarles cómo veo la situación de la otra vertiente. La de los que saben hacer apps con JavaScript.

Como mencioné anteriormente, Web 2.0 evidenció lo que nosotros desarrolladores de software deberíamos ofrecer a los usuarios para poder masificar y triunfar con nuestros productos.

Esto alentó a los fabricantes de software a mejorar la velocidad de interpretación de JavaScript de sus motores, tal como sucedió con el Chakra de Microsoft o el V8 de Google. De tal manera que hoy en día con puro JavaScript interpretado se pueden lograr experiencias de usuario que poco se pueden diferenciar de una app nativa. Y con la ventaja de que si a cada plataforma nativa le ponemos su propio intérprete de un JavaScript estándar, pues tendremos aplicaciones cross platform de un desempeño óptimo.

A través de todos estos años, estas mejoras y enfoques en JavaScript han propiciado que muchos desarrolladores hayan aprendido esta tecnología que muy cierto es, por lo general es una cosa extraña para los desarrolladores .net.

Y entonces podemos hacer una comparación: Cuántos programadores web hay, vs. cuántos programadores de apps nativas hay. Obviamente la balanza se inclina hacia los desarrolladores web, dado que han existido desde hace mucho tiempo. Ergo, existen muchos más que saben JavaScript, que aquellos que saben lenguajes nativos.

Tanto así que la industria se ha preocupado por crear "traductores" en los cuales el desarrollador escribe código JavaScript y el traductor (por ejemplo PhoneGap) lo que hace es arrojar al otro lado código nativo bien sea para Windows Phone, iOS o Android. Esto por un lado le abre la puerta a un gran número de desarrolladores que no conocen las plataformas nativas y por otro minimiza la cantidad de código escrito cuando se deben hacer versiones de la app para las diversas plataformas.

Sin embargo, esto abre otra puerta a problemas que tienen que ver con que esas apps no pueden acceder a todo el poder nativo de cada uno de esos dispositivos, porque el conjunto de instrucciones soportadas por el traductor también debe obedecer a un mínimo común denominador para lograr ser multiplataforma, sin mencionar que la velocidad de ejecución se puede ver afectada de acuerdo a la calidad de la optimización del código que ejecuta el traductor.

Como ejemplo, puedo mencionar que una app para Windows Phone y iPhone creada con Phone Gap a pesar de requerir solo un esfuerzo, no explotará ciertas características únicas de cada plataforma y puede que no corra tan rápido como si esas apps fueran creadas con dos esfuerzos (uno para cada plataforma). Pero para esto Microsoft descubrió una solución llamada WinJS de la cual les hablaré un poco más adelante.

Independientemente de esto, entonces comenzamos a observar un efecto bola de nieve, en el cual entre más desarrolladores JavaScript hay, más tecnologías se ponen a su disposición. Ejemplos:

1. NodeJS , para poder escribir backend en JavaScript haciendo especial énfasis en una altísima escalabilidad lograda en un esquema de no bloqueos en el server.

2. TypeScript: un superlenguaje de JavaScript creado para poder formalizar y administrar proyectos JavaScript de mediano a gran tamaño, como si fuese todo un lenguaje orientado a objetos que al compilar se convierte en JavaScript estándar listo para ser usado en la aplicación que queramos. Es tan conveniente que dentro de Microsoft se usa por ejemplo en CodePlex y en Bing y ya muchos proyectos open source grandes lo están usando. De hecho Adobe anunció que lo usará como lenguaje principal para su Adobe Digital Publishing Suite, usada por cerca de 70% de los publishers del mundo y la cual se pondrá disponible para apps de Windows según lo anunciaron en el #bldwin de 2013.

3. LightSwitch, el RAD de Microsoft para crear aplicaciones de línea de negocio basadas en formularios de captura y consulta de datos, ahora en su última versión ofrece la posibilidad de programarse también con JavaScript para poder ejecutar sus pantallas en browsers sin necesidad de plugins (originalmente LightSwitch requería de Silverlight, lo que lo ponía fuera de alcance por ejemplo de los móviles).

4. Napa: Un entorno de desarrollo de apps para Office 365 y SharePoint en el que a través del mismísimo browser podemos escribir el código de las apps que estaremos usando. Y cuál es este código? Correcto: JavaScript.

Todo esto para mencionarles la Joya de la Corona de las implementaciones de JavaScript:

5. WinJS: La proyección de lenguaje para JavaScript que nos permite desarrollar apps para WinRT.

Y el título de Joya de la Corona es muy bien ganado, porque esta es la primera implementación en el mundo que permite acceder de manera nativa e ilimitada a los recursos de la máquina en la que se ejecuta. Así que todo el hardware y funciones especiales del sistema operativo están abiertos para ser llamados desde código JavaScript. (La historia se remonta a IE9, en donde se permitió al objeto Canvas del browser poder dibujar animaciones usando la aceleración de hardware nativa de la máquina en la que estaba corriendo, gracias al esquema integrado que tiene el browser con Windows, produciendo animaciones de hasta 60fps)

Esto es una gran ventaja frente al acercamiento tradicional de JavaScript en otros browsers, pues estos corren en un sandbox limitado que no da acceso a funciones críticas del sistema como dispositivos de almacenamiento, tarjeta de video o en Windows 8 por ejemplo, el acceso a los charms que traen los contratos de búsqueda o de share entre otros.

De hecho, esta gran práctica está comenzando a ser imitada por ejemplo por Firefox que ha centrado todo su nuevo OS en HTML5, de manera que el JavaScript usado también estará accediendo nativamente los recursos de los dispositivos sobre los cuales se estén ejecutando.

Pero volviendo al tema específico de Windows 8, si sumamos lo dicho hasta ahora al hecho de que el motor de interpretación Chakra es tan veloz, tenemos que programar una app WinRT en JavaScript no tendrá mayores diferencias en velocidad de ejecución que hacerla en C#, VB o incluso C++.

Está claro que igual el JavaScript tiene que ser interpretado y eso tarda más que el marshaling y las operaciones de boxing y unboxing de C#. Y que esto a su vez tarda más que si la app estuviera hecha en C++ crudo. Pero esas diferencias no son notorias para un usuario en el 95% de las veces; y esto en términos prácticos permite decir que el performance es el mismo, excepto en apps supremamente especiales que requieren muchos cálculos para funcionar correctamente.

Un ejemplo claro de la eficiencia de apps JavaScript en WinRT es el juego Cut the Rope (más de 100M de descargas a hoy), que primero fue nativo en iOS (15K líneas de código) y luego fue portado a JavaScript para poder ser ejecutado en IE9 y de allí pasó sin muchas modificaciones a WinRT.

La experiencia del juego es excelente sin importar el dispositivo: iPhone, IE, WinRT y hoy en día otros browsers como Chrome y Firefox también la ejecutan bien.

De hecho el código de esta app en JavaScript ocupó de nuevo solo 15K líneas de código, dado que el Canvas que manejamos con JavaScript tiene muchos comportamientos predefinidos como el pixel shader que en OpenGL (la tecnología de rendering detrás de la versión nativa) no existe y toca programar con montones de código.

Microsoft ejecutó una excelente estrategia cuando salió al mercado con su paradigma de apps para WinRT, dado que permitió a desarrolladores tradicionales seguir con su lenguaje y en cierto modo el estilo de programación acostumbrado con C# y XAML. La excelencia en la ejecución se nota porque estos desarrolladores nunca se vieron afectados ni puestos a un lado.

Pero esto no elimina el hecho de que Microsoft también notó el inmenso auge y practicidad que trae HTML5.

Lo dije: HTML5

Antes de seguir hablando déjenme mencionarle las dos connotaciones de HTML5:

1. La purista: El sucesor de HTML4, que incluye nuevos tags como video, canvas, audio, section article, header y nav.

2. La popular y más usada: La 1 + JavaScript moderno y CSS3.

Entonces por eso el título del post: HTML5 para APPS. El HTML5 para apps implica que la interfaz de usuario la manejamos con tags HTML más estilos, y la lógica con JavaScript. De hecho también es recomendable en las apps HTML5 usar paradigmas como MVVM (totalmente disponible para JavaScript) que permitan una clara separación entre la lógica y presentación.

Ahora sí continuando, les contaba que Microsoft notando la relevancia y el futuro de HTML5 (connotación 2 de ahora en adelante), lo convirtió en un ciudadano de primera clase en el mundo WinRT.

Tan de primera clase es, que muchas de las características especiales de las apps WinRT se desarrollan más fácil con JavaScript. De hecho, hay un par de cosas que no es posible hacer out of the box con VB o C# mientras que con JavaScript sí, tal como manejar el StorageDataSource: Un objeto usado en un mecanismo para mostrar imágenes en el flipview (un control contenedor cuyos elementos se pueden desplazar mediante gestos touch) sin que existan problemas de memoria cuando usamos una gran cantidad de elementos. Por ende para evitar degradación de la experiencia de usuario en C# hay que acudir a mucho código extra que en JavaScript ya viene manejado con el objeto en mención.

Adicionalmente, Blend ha sido repotenciado para no solo manejar XAML, sino también HTML. Y las bondades y facilidad de uso ofrecida agilizan enormemente el proceso de diseño de las interfaces de usuario. De hecho, la primera versión de la nueva saga de Blend solo incluía HTML para diseño.

Y así sucede con otros elementos únicos de HTML5 como el canvas, que para manejar gráficas ofrece muchas ventajas predefinidas, ahorrando cantidades de código.

Esto sin mencionar que el código que escriba sobre HTML5 va a servirme si después quiero hacer la versión web de la app o si quiero hacer la versión sobre otros dispositivos. En este caso será más fácil usar un traductor para lograrlo por ejemplo, con los inconvenientes que ya les había mencionado. Pero así como Microsoft con WinRT y Firefox acuñaron HTML5 como plataforma nativa, podría suceder que otros fabricantes como Android, iOS y por qué no, el mismo Windows Phone 8 lo hagan. En este caso, podríamos tener una gran base de código reutilizable que además va a funcionar con una velocidad y alcance muy cercano al de las apps nativas.

Si estamos conscientes de que la compatibilidad 100% no está tan cercana, entonces al menos el hecho de poder compartir una gran cantidad del código no se ve tan utópico. De hecho Microsoft (por ejemplo con la adición -ms-grid hecha al atributo display de CSS3) y Firefox (con especificaciones para manejar un calendario HTML5) han hecho propuestas al W3C para que elementos propietarios usados para aprovechar características específicas de la plataforma o para mejorar las interfaces de usuario pasen al estándar y de esta manera luego la portabilidad entre plataformas sea más posible.

Así que ya se podrán ir dando cuenta del porqué del título.

Otro ejemplo que puedo referenciar aquí, es uno que se gestó apenas hace unos días también gracias al gran evento #bldwin 2013 (Build Windows):

Efectivamente, se trata de Netflix. Uno de los principales implementadores de Silverlight en el mundo.

Sucede que el estándar de HTML5 aún no dicta cuál es el mecanismo para ofrecer medios audiovisuales con DRM: un tema supremamente importante si eres una empresa legal que hace streaming de películas. Silverlight siempre ha sido líder en la implementación de DRM y para Netflix, esta era la única opción sencilla de estar fácilmente en Windows y MACs a través de cualquier browser que soportara el plugin: IE, Chrome, Firefox y en cierta medida Opera. En Linux algo se logró con Moonlight del equipo mono.

Pero llegaron los dispositivos y con ellos cada fabricante fue muy celoso de dar soporte a plugins. Por ejemplo iPhone jamás ha soportado Flash. Y así sucedería con Silverlight. Entonces el tema del plugin no ayuda mucho a la presencia a través de todos los dispositivos. Silverlight es muy útil para desarrollar aplicaciones altamente amigables con el usuario en ambientes controlados donde la instalación de un plugin no tiene problema (Aplicaciones LOB en una intranet por ejemplo) Pero para el consumer masivo, definitivamente la historia de la industria nos llevó a otro lado.

Viendo esto, Microsoft ha estado trabajando en una propuesta de manejo de DRM dentro de HTML5 a través de IE11. Y esto se puede ver hoy en vivo, si tiene el preview de Windows 8.1 que incluye la versión 11 del browser. Así que Netflix, ha encontrado por fin una luz que alentaría la posibilidad de tener un solo desarrollo HTML5 que corra al menos en todos los browsers y sea “ fácil” volverlo nativo para los dispositivos móviles, si es que hace falta en aparatos que digan soportar el estándar.

Por ahora, la implementación que Netflix hace sobre IE11 no es estándar, pero funciona bastante bien. Aún requiere algo de trabajo para ofrecer opciones avanzadas como por ejemplo escoger idioma y subtítulos, así como opciones para compartir con el social media desde la reproducción como tal (cosas que sí tiene el cliente Silverlight).

Microsoft trabaja muy de cerca con el W3C y obviamente propondrá su implementación de DRM para convertirla en un estándar que todos los browser implementen. En otros browser como Chrome y Firefox, por ahora la experiencia Netflix sigue siendo a través de Silverlight.

Lo más interesante de todo esto, es que este IE11 que soporta DRM a través de HTML5, tiene el MISMO CORE de interpretación de HTML5 y de ejecución de JavaScript que viene con Windows 8.1. Así que al menos en lo que tiene que ver con Windows, para Netflix se hace realidad el sueño de programar una app que corra igual en el browser o en la plataforma nativa!

Y mejor aún, las innovaciones que trae IE11, ergo las apps HTML5 de Win8.1 no paran allí. Otra ejemplar inclusión es el soporte a WebGL! La famosa api de JavaScript que permite acceder directamente a la tarjeta de video para renderizar gráficos en 2D y 3D sin necesidad de plugins. Propuesta originalmente por la fundación Mozilla, hoy es ampliamente soportada por ese Firefox, Chrome e IE11. Otros como Safari y Opera dicen soportarla, pero la tienen deshabilitada por defecto. Si quieres ver si tu browser la soporta, has click en la imagen.

Entonces, todos esos excelentes desarrollos gráficos existentes en la Web hoy en día basados en WebGL están disponibles para ser renderizados nativamente en las apps HTML5 de Win8.1 directamente y con mínimos esfuerzos!!!

Pero… Wait a Minute… entonces, todo esto no va a estar disponibles para las apps XAML en WinRT?

Nada más alejado de la realidad. A partir de Windows 8.1, el WebView control de XAML ha sido optimizado enormemente y va a permitir por ejemplo que su contenido sea asignado localmente: tú le pasas el HTML/HTML5 que quieras al control y este lo renderiza usando los motores de IE y de las apps HTML5 de Windows 8. O sea, que todas las funciones van a estar completamente disponibles.

Vean; en síntesis, son estos puntos:

1. C# es mi lenguaje de backend predilecto y difícilmente habrá uno mejor.

2. El modelo de apps supone un nuevo paradigma que se ajusta mucho a implementaciones del tipo MVVM que no son usuales por ejemplo cuando trabajamos en backend.

3. JavaScript y en general HTML5 está adquiriendo un alcance global y es recomendable aprenderlo si como developer consideras que alguna vez estarás desarrollando algo de front end en tus aplicaciones.

4. El enfoque favorable que se le ha dado a HTML5 en WinRT, hace que algunas tareas se desarrollen más fácil y rápido con esta tecnología. Se hace más natural el desarrollo de apps que con XAML.

5. Hacer un desarrollo en HTML5 aumenta la probabilidad de que tenga un paso muy sencillo hacia otras plataformas.

Dado lo anterior, no cambio a mi C# para backend por nada. Pero si tuviera que cambiar de paradigma de desarrollo y aprender uno nuevo para hacer apps, por qué no mejor aprovechar y aprender también un nuevo lenguaje de programación más apropiado para estas implementaciones que además me abrirá las puertas a otros mundos como Front End en Web, NodeJS, LightSwitch, Napa y muchos más?

Además me resulta gratificante no tener que ver mermado todo el poder de .net al que estoy acostumbrado, porque las implementaciones de apps así lo exigen.

Así mi mente se sentirá más cómoda sabiendo que si estoy en backend se puede configurar en modo C#, pero si estoy haciendo una app o una interfaz web, entonces se pasa al modo JavaScript con MVVM y todo incluido.

Es por eso que prefiero HTML5 para WINRT apps.