¿Qué significan Windows 8 y su nuevo WinRT? (+videos)

Esta semana arrancó la conferencia //build/ (nuevo nombre del tradicional PDC de Microsoft) y el foco principal fue el lanzamiento (en versión preliminar para desarrolladores) de Windows 8 y su nuevo modelo de programación. Para quienes no las vieron, dejo debajo los videos de las charlas de apertura del día 1 (mayor foco en Windows 8) y el día 2 (mayor foco en desarrollo).

Uno de los anuncios más polémicos o complejos fue el nuevo modelo para desarrollar aplicaciones Windows que puedan ser distribuidas a través del próximo Market, siguiendo el modelo popularizado por Apple y al que ya se ha sumado toda la industria, incluyendo Windows Phone.

El siguiente es el diagrama más visto en los últimos días mostrando cómo queda el stack de Windows, y debe tenerse en cuenta que es un diagrama aproximado, porque obviamente simplifica muchas cosas para servir como modelo introductorio:

Básicamente, la mayor novedad está en la sección verde del diagrama (aplicaciones estilo Metro). Este tipo de aplicaciones serán las que puedan distribuirse a través del Market, y su particularidad es que no pueden acceder al API completa de Win32, sino que dialogan contra el API de WinRT, la nueva estrella del mundo Microsoft.

En principio, WinRT es una buena idea. Lo que hace es proveer un contexto de ejecución seguro (similar al de un navegador) para aplicaciones Metro (insisto en que el modelo anterior existe, pero NO se puede distribuir por el Market). Lo que se logra con esto es que todas esas aplicaciones tienen acceso mediado y controlado a los recursos físicos del sistema, y son muchísimo más seguras, aun cuando pueden escribirse básicamente bajo tres paradigmas:

• En .NET (utilizando el mismo CLR pero con un perfil especial que restringe el API disponible, similar a lo que sucede al escribir aplicaciones en Silverlight), utilizando XAML para el diseño de las interfaces.
• En código nativo (C/C++) utilizando XAML también, pero sin acceso a Win32, sino a WinRT.
• En JavaScript, utilizando HTML/CSS para el diseño de interfaces.

Otra característica importante de WinRT es que todas sus API tienen interfaces asincrónicas, salvo las que tienen tiempo de respuesta asegurado inferior a 50 milisegundos. El objetivo de esa decisión es mejorar la respuesta de Windows sobre todo en la interacción con el usuario. Todos sabemos que es normal en Windows tener demoras en el explorador o dentro de las aplicaciones, y mirar por unos segundos la famosa ruedita girando. Con el advenimiento de las interfaces táctiles (uno de los temas más fuertes en Windows 8) esos tiempos de respuesta no son viables. Por eso es importante volver a un modelo más similar al de programación en la web (con JavaScript) basado en operaciones que devuelven callbacks, que liberan el hilo de ejecución hasta que la operación termina.

La contra de este modelo en general es que el nivel de complejidad para manejar callbacks anidados y el control de errores se eleva considerablemente. No es casualidad entonces que tanto en .NET 4.5 como en JavaScript veamos crecer el uso de patrones asincrónicos (en C# 5 a través de las nuevas cláusulas await y async, heredadas de F#) y en JS con la creciente adopción de promesas (utilizando las abstracciones .then() y .when() ) en bibliotecas como jQuery, Dojo y otras derivadas de CommonJS.

Entre otros temores surgidos a partir de las presentaciones del nuevo modelo, está la confusión sobre si .NET ha perdido importancia. Personalmente creo que no, pero Microsoft ha vuelto a las fuentes en algunos sentidos, volviendo a poner énfasis en el código nativo para aplicaciones de alto rendimiento. Los lenguajes manejados dan mayor productividad en general, pero sólo en C/C++ se pueden crear aplicaciones de muy alto rendimiento en velocidad, consumo de recursos e incluso consumo de energía. Estos tres factores no eran tan importantes hasta hace un par de años porque pensábamos nuestra aplicaciones para correr en computadoras de escritorio o servidores, pero el desarrollo de los dispositivos móviles (teléfonos, tabletas, y otros) ponen de nuevo foco en ellos. Y en el otro extremo, aplicaciones del lado del servidor que ahora tenemos que pensar para miles de usuarios concurrentes hacen que tengamos que el ahorro de recursos en alta escala financie con creces el tiempo extra de desarrollo.

En fin, quedan muchos temas disparados que espero seguir tratando más adelante. Cualquier comentario o pregunta son bienvenidos. Les dejo los videos para que se diviertan.

Apertura del día 1 - Windows 8

Apertura del día 2 - Desarrollo y Operaciones