RIA y framework web

Son dos temas que toque antes por separado.  En el tema RIA, aposte que Javascript iba a ser la tecnología dominante en el browser (sobre Adobe Flash/Flex, MS Silverlight y Java/JavaFX).  En el tema de los framework web, observe que la guerra no esta terminada y declare mi preferencia por Lift .

Ahora, estoy seguro que los temas RIA y framework web son indivisibles, porque:

• no creo en una solución 100% browser.  Eso seria programar Javascript en el browser, llamando interfaces Web Service o RESt en el servidor que retornen XML o JSON.  Javascript es mucho más potente de lo que pensaba pero nunca tanto.

• ya no creo en una solución 100% servidor, como por ejemplo:
• un framework basado en componentes que se inicializan vía tags o programación Java y que generan mágicamente el HTML, CSS y Javascript cliente
  
• un compilador de Java a Javascript como el GWT de Google o un compilador de XML a Javascript como el OpenLaszlo .

Entonces, creo que el framework web debe permitir programar en Javascript en el browser con la opción de interactuar con el Javascript generado por el, como por ejemplo ser notificado de algún evento y procesarlo localmente (sin necesidad de ir al servidor)  Además, tiene que darme la opción de llamar código de negocio en el servidor desde Javascript mio en el browser.

Para mi, es un cambio importante, porque si había escrito sobre este tema hace 1 año, habría dicho sin vacilar que confiaría todo la generación del javascript a un framework como JSF o Wicket argumentando que "menos javascript veo mejor me porto".  Fiel a este concepto, cuando empece a trabajar con Lift, implemente un wrapper de Flot para implementar el código Javascript una sola vez y re-utilizarlo como un widget. Ahora que termine mi último proyecto, me doy cuenta que mezcle sin asco javascript en el browser con javascript generado por las API's de Lift y lo encuentro perfectamente normal.  Hasta lo encuentro elegante.

Con la luz de esta revelación, voy a revisar los framework que conozco y ver como resisten.

Lift

Si llegue a esta conclusión, es porque Lift me permitió esta mezcla y me convencí que no era una abominación. 

Una vez que entendí como funciona jQuery y el soporte AJAX de Lift es muy fácil intercambiar código javascript en el browser versus código Scala/Lift que genera javascript.  Con un poquito más de esfuerzo se puede hacer comunicar estos códigos entre si.  Cabe notar que Lift soporta Yahoo UI también y debe ser relativamente fácil (pero tedioso) soportar otras bibliotecas javascript.

Creo que David Pollak tuvo una muy buena idea usar un framework conocido: 

• ahora es fácil crear código que encapsula los widget de jQuery.  Lift puede aprovechar las mejoras en jQuery como jQuery UI.
  
• como jQuery y Yahoo UI son populares, tienen buen soporte y documentación.  El grupo de Lift puede ahorrar este esfuerzo.

Lo único que puedo criticar a Lift es que es relativamente de bajo nivel: hay que entender como funcionan las cosas por debajo para ser eficiente.  Lift esta en su versión 1.0, tiene tiempo para desarrollar algo un poco más abstracto (lo cual es posible porque el "bajo nivel" esta bien hecho).

Wicket

En comparación Wicket usa su propia API javascript.  Hasta lo que se, no hay documentación y puntos de interfaz para conectar código Javascript propio  

Es relativamente normal, ya que Wicket tiene una filosofía orientado a programación Java: los componentes se crean y asemblan vía código Java en el servidor.  Es entonces cada componente que es responsable generar el código javascript que el requiere.

JSF

Pasa lo mismo con JSF, con los agravantes:

• es bastante difícil crear componentes propios,
• algunas bibliotecas JSF que soportan AJAX intervienen el ciclo de vida del procesamiento de la pagina para retornar el código AJAX.  Eso crea incompatibilidades entre las soluciones.
• la configuración vía tags es generalmente inflexible.

Cabe notar que la idea de escribir este entrada de blog, me llego leyendo esta entrevista donde un fabricante de componentes JSF afirma que:

"A new feature in our latest edition is a JavaScript eventing model. In the past, the focus of our product was to keep the JavaScript engine under the covers, and to provide only limited access points to it. Our customers had been telling us to open that [event model] up so that they can plug in JavaScript and Ajax calls pretty much anywhere. In response to those requests, we enabled over 200 event attributes across our components."

Leyendo eso, me di cuenta que eso estaba haciendo con Lift y que era entonces un punto a su favor.  Tenia que documentarlo.

Struts

Supongo que el abuelo de los framework web hace completamente agua con AJAX.

Servlet/JSP

Podría ser una solución para código Javascript 100% cliente.  No es lo que busco.

Voy a tener que comparar Lift con RoR o Grails o Django porque parece que los framework web Java llegaron a su máxima capacidad  Nota: es un buen argumento para convencer que es tiempo de mirar otras soluciones que java. 

De desktop a Web RIA

Cuando empece mi ultimo proyecto nunca pensé que iba a terminar haciéndolo como una aplicación web.  El sistema se parece a un cajero automático: es un PC, una impresora y una pantalla touchscreen instalados en un rack cerrado.  El usuario selecciona algunos datos, la aplicación se conecta a algunos sensores e imprime una etiqueta adhesiva con códigos de barra. 

Mi primera opción fue usar Java y la API Swing para crear una aplicación desktop convencional.  Alcance a desarrollar un prototipo inicial con Matisse de Netbeans y empece a actualizar mis conocimientos de Java2D para usar la impresora.  Mi única preocupación era hacer botones y labeles grandes para que el usuario los pueda seleccionar sin problema.  

Cuando llego el primer diseño de la interfaz al usuario, empece a cambiar de opinión.  Los botones no se parecen en nada a los de Swing, de Windows o de ningún sistema operativo conocido: sus bordes se mezclan poco a poco con el fondo de la pantalla en un efecto tipo anti-aliasing.  Al disparar un botón, ejecuta una animación que se parece a un destello de luz.  Pensé que iba a tener que crear mi propio renderer de Swing y eso me sonó como complicado.  

Además, habría tenido que ubicar los distintos elementos con una precisión de pixel porque el fondo no es de un solo color, sino una trama de grises oscuros: un pixel de error y se pierde el efecto de anti-aliasing.  O sea, tenia que decir chao a los layout de Java/AWT,  Eso me sonó como mucho trabajo.

Finalmente, un nuevo requerimiento funcional hacia muy probable la necesidad de recibir un archivo vía HTTP  Tenia que integrar un servidor web dentro de la aplicación desktop.

Entonces, surgió la posibilidad de hacerlo como una aplicación web.  Por el tipo de UI, era obvia la solución: una aplicación web RIA con javascript con jQuery en el browser y el soporte AJAX de Lift en el servidor.  

Comentarios

No lamente el cambio, porque pude solicitar la entrega del diseño UI en HTML, jpeg, GIF y CSS: el diseñador se llevo la tarea de colocar todo pixel a pixel.  Incluso, logre liberarme de Java2D para la impresión: en su reemplazo use la API Java iText y una plantilla PDF que me entrego el mismo diseñador de la UI.  Con eso pude imprimir a través del plug-in Adobe Reader en el browser en lugar de controlar yo mismo la impresión.

Cada vez me gusta más jQuery.  Recomiendo a los que quieren aprender Lift, aprender a usar bien jQuery (o Yahoo UI el otro framework javascript soportado por Lift).  De esta forma, es fácil prototipear en HTML, Javascript y luego pasar a código Scala/Lift en el servidor si es necesario.

Este proyecto me permitió profundizar el soporte AJAX de Lift, el cual es muy bueno.  El código quedó modular y re-utilizable: pude crear varios componentes de negocio, como una pre-visualización HTML de la impresión y un teclado numérico touchscreen, que re-utilice tal cual entre varias paginas.  Se que hacer lo mismo con Servlet/JSP, Struts, JSF es casi imposible.  Lift es realmente una mejora significativa.

También Scala salio muy bien.  El hecho de poder llamar directamente a las API's de Java y instalarse sobre cualquier servidor de aplicación Java es realmente una ventaja enorme sobre otros lenguajes.  Por ejemplo, pude usar Apache iText (para PDF), Apache POI (para Excel) y la API Socket de Java para conectarme con los sensores.  

Buenas noticias para jQuery

No es a menudo que Microsoft anuncia su apoyo a un proyecto Open Source y eligieron usar y soportar jQuery como framework javascript, El mismo articulo menciona que Nokia también va a usar jQuery e incluso incluirlo en sus teléfonos. Me parece un éxito bien merecido.

Como nota aparte, creo que no es casualidad que MS aumenta su presencia con AJAX. La guerra de los browsers esta de vuelta y presiona a MS no abandonar soluciones estándares para los RIA tratando de seguir una linea "Silverligth only". Que tiempos más interesantes...

RIA: tiempo de apostar

He mencionado las Rich Internet Application a la pasada en algunas entradas anteriores. Hasta hace poco estaba indeciso a cual solución apostar entre Adobe, Microsoft, Sun, Google, etc. Ya me decidí.

Un poco de historia

Cada salto tecnológico es acompañado de avances notorios pero también de retrocesos.

De la época mainframe con terminales tontos a la época cliente servidor, se gano la capacidad de generar aplicaciones más interactivas basadas en ventanas graficas. Pero, el costo de despliegue de las aplicaciones aumento significativamente, porque había que desplazarse para instalar cada nueva versión en cada PC y era frecuente que diferencias pequeñas de configuración de Windows introduzcan incompatibilidades. Ese ultimo fue llamado el DLL Hell.

La época web permitio solucionar los problemas de despliegue: hay mucho menos versiones de browsers que configuraciones de Windows posibles y las aplicaciones se instalan en un servidor donde técnicas como el classloading de Java reducen significativamente el problema del DLL Hell. Lo que se perdió es la capacidad de hacer aplicaciones interactivas complejas como por ejemplo, tener un control fino de los movimientos del ratón.

La meta de las RIA es recuperar la interactivad usando el browser como método de despliegue. Se obtiene entonces los beneficios de todas las plataformas anteriores:

• de la web con HTML puro y del mainframe monolítico: un ambiente centralizado y controlado donde se hace el despliegue de las aplicaciones,
• del cliente-servidor: la capacidad de hacer aplicaciones clientes sofisticadas.
  

El termino es reciente pero hubieron varios intentos con distintos grados de éxito:

• las applets Java: aparte de lanzar el lenguaje a la fama, se usaron en algunos sitios de juegos en-linea como el de Yahoo. Cuando Microsoft abandono Java por .Net, no se actualizo más la versión de la JVM en internet explorer y las applets se estancaron. Además, los grandes sponsores de Java, Sun, IBM, Oracle se preocuparon más del lado servidor donde podían generar ingresos. A pesar de eso, Java y las API's J2SE son una buena plataforma para aplicaciones desktop: Eclipse, Netbeans, Azureus, Limewire demuestran que se pueden hacer aplicaciones de buena calidad grafica.

• ActiveX de Microsoft: no tuvo el efecto esperado pero permitio distribuir algunos plug-ins importantes como...
  

• Flash: tiene un gran éxito para generar contenido más vistoso que lo posible con HTML puro.

Técnicas en competencia

• Javascript, AJAX: Google con su servicio Gmail permitio revivir tecnologías que ya existían dentro de los browsers, pero que no habían sido usadas con toda su potencial. Se abre en varias alternativas:
• javascript puro, usando framework o API's como Dojo, jQuery, Prototype
• componentes en el servidor que generan el código Javascript (potencialmente, usando uno de los framework anterior),
• GWT de Google que permite compilar un programa Java basado en las API's de Google a código Javascript que se ejecuta en el browser
• seguramente, otros que no conozco
  

• las applet Java: están de retorno con nuevas facilidades que las hacen un poco más entretenidas, como por ejemplo:
  
• hacer drag de la applet para dejarla en el escritorio de Windows donde se ejecutará posteriormente como cualquier aplicación.
• el lenguaje JavaFX que es más amigable para diseñadores y tiene acceso a las capacidades de Java2D,
• API's graficas que se han mejorado en todos estos años, incluyendo mejoras de rendimiento con acceso directo al hardware
  

• Adobe AIR: gracias al tremendo éxito de Flash, Adobe tiene una buena recepción con los diseñadores web. Tiene que convencer ahora a los programadores.
  

• Microsoft Silverlight: se puede esperar muchos esfuerzos de parte de Microsoft para recuperar su influencia sobre los programadores de la capa cliente. Alguna vez Visual Basic reinaba el mundo y MS perdió este liderazgo con la web, Java y PHP.

Por gustos personales, siempre voy a preferir una solución basada en estándares. Antes de probar Adobe AIR y MS Silverlight, tendría que descartar completamente a Javascript y las applet java. A primera vista, las dos soluciones estandares tienen defectos:

• Javascript es la más compleja de todas las soluciones, partiendo por todas las alternativas disponibles, las incompatibilidades entre browsers y la falta de IDE que facilitan el desarrollo.
  

• las Applets sufren de su pasado y Sun ha generado mucho anti-cuerpo por haber abandonado un grupo de programadores que se fueron mayoritariamente a Flash.
  

Entonces, mi apuesta es:

• no a Adobe AIR y Microsoft Silverlight. No soy el único en el mundo a quien le gusta los estándares y se inquieta cuando depende de un solo proveedor: por algo Java tuvo mucho éxito
  

• dudo del retorno de las applets. Creo que va a depender de como Sun se maneja en el mundo de los celulares donde tiene que hacer un upgrade de su exitoso J2ME a una plataforma más sofisticada y compatible con el desktop: JavaFX es supuestamente para eso. Pero Sun esta cada vez más solo. Google, por ejemplo, decidio crear una platafarmo propia con Android.

• Apuesto al éxito de Javascript porque es mucho más fácil de usar de lo que creía.
  

Sun relanza JavaFX a JavaOne

Como previsto, Sun aprovecho JavaOne para relanzar su JavaFX como competidor de Adobe AIR, Microsoft Silverlight y AJAX, Todo estas tecnologías compiten para el desarrollo de aplicaciones tipo RIA.

Tengo que admitir que le doy poca probabilidad de éxito a Sun y apuesto mucho más a Adobe por su historia con Flash. Pero me impresionan las siguientes cifras (leer articulo completo).

Sun is hoping to tap into 2.2 billion mobile devices and the vast majority of desktop PCs that are Java-enabled. JavaFX was shown running on Google's Android mobile platform. Green noted that 85 percent of cell phones, 91 percent of desktops, and 100 percent of all Blu-ray Disc players will run JavaFX.

¡No deja de ser una base interesante!