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. 

Framework web en el mundo Java

Para los framework ORM, la guerra ya terminó y JPA ganó. Hay que recordar que no hace tanto, habían muchas soluciones para la capa de persistencia entre los cuales estaban los EJB Entity Beans, Hibernate, JDO y JDBC directo. Ahora todos están de acuerdo que JPA cumple 90% de las necesidades.

En el caso de los framework web, la guerra sigue vigente y es entretenido seguir el avance de las batallas y tratar de pronosticar el vencedor. Además, me permitirá explicar porque, a pesar de mi entusiasmo por soluciones estándares, estoy involucrado con Liftweb y Scala.

Voy a hacer primero un recorrido por las soluciones que conozco. Nota: no pretendo conocerlas todas.


Servlet y JSP

Eso es el equivalente de usar JDBC Directo en un ORM. Su gran gracia es su simplicidad, la cual es equivalente a la de usar PHP. Por esta razón, lo elijo si tengo que hacer una aplicación para un contenedor Java antiguo y si el cliente no obliga usar un framework X.

Su principal problema es que no obliga que la aplicación sea de tipo MVC y hay que ser disciplinado para no caer en código inmantenible. Para proyectos grandes, con muchos programadores de distinto nivel de conocimiento, no es una buena solución.


Struts

Struts corrige el problema anterior forzando ordenar el código. Yo encuentro que el costo es demasiado alto, muchos conceptos, muchos XML y archivos de propiedades: un "hello world" no puede ser tan complicado. Por eso considero Struts como uno de los responsables de la sensación de pesadez del mundo Java: en particular cuando la critica viene de un programador PHP.

Struts sigue bastante popular y Struts2 esta en la pelea: espero que no gane.


JSF

Los que critican el proceso de estandarización de Java tienen en JSF una víctima clara a la cual lanzar sus dardos. Las principales criticas que me hacen sentido son:

• sobre ingeniería: JSF tiene muchos puntos de extensión, que agregan mucha complejidad como por ejemplo los renderer.
• orientarse a los fabricantes de IDE y de componentes: "no importa si hay que tocar muchos XML porque el IDE se encargará". Desgraciadamente, eso se cumple a media.
  
• mantener compatibilidad con JSP. Eso creo un caos inicial donde había un EL para JSF muy similar pero distinto al de JSP y pasaba cosas raras cuando se mezclaban tags JSTL con los de JSF.

La gran gracia de JSF es su modelo de componente. Si se busca la eficiencia de desarrollo al estilo de Visual Basic/PowerBuilder de la epoca cliente-servidor hay buenas opciones de bibliotecas soportadas en IDE. Por ejemplo, Woodstock de Sun permite un desarrollo Wysiwig con Netbeans.

Ojo, que una vez que se elije una de estas soluciones, esta trabajando con un JSF "con apellido":

• el runtime de estas bibliotecas no soportan siempre las implementaciones de JSF (principalmente la de Sun y la de Apache). Eso implica que puede haber también problemas con el contenedor, si este viene con una de estas dos implementaciones.
  
• dependen de un solo IDE o de un plug-in para un IDE,
• suelen ser incompatibles con otras bibliotecas para JSF. Este ultimo problema se da mucho con las que soportan AJAX.
• la mayoría usan tags y dejan fuera la posibilidad de usar facelets en lugar de JSP.
  

Entonces, antes de casarse con una biblioteca y su IDE respectivo, hay que hacer una buena evaluación. Como no hay estandarización de esta capa, la gracia de tener un estándar para JSF se diluye: eso implica que puedo mirar por el lado a pesar de mi aprecio a soluciones estandarizadas.

Como hay varios proveedores interesados en mejorar JSF, no creo que este muerto. SI logran más simplificación y compatibilizar sus bibliotecas, seria un salto importante para crear el mercado tipo Visual Basic tan anunciado y esperado.


Wicket

Wicket.es distinto. Al abandonar JSP y sus taglibs, lograron separar por completo los artefactos HTML, CSS del código Java. Por otra parte, dice adiós a archivos de configuración en XML Son razones más que suficientes para atraer la atención.

Además, tiene una biblioteca de componentes importantes con soporte AJAX out-of-the-box y es relativamente fácil crear componentes propios (lo cual es ahora difícil en JSF 1.x). De hecho, JSF 2.0 reconoció estas ventajas y anuncia soporte oficial para facelets (¡al fin!) y métodos para crear componentes propios.

Yo recomiendo usar Wicket para proyectos web en Java.


Seam

No se puede comparar Seam, con los frameworks anteriores. De hecho incorpora JSF y ahora soporta a Wicket como opción.

Lo menciono aquí porque:

• logran la integración de las distintas capas de la aplicación.
  
• están aportando a los estándares de Java con la especificación WebBeans (nota aparte: ¡SpringSource aprenda de jBoss si quieres ser un vendedor ético!)
• marca una tendencia en los frameworks: una solución más integral con AJAX, REST, generación de PDF, page workflow, etc.
  

Si tuviera que usar JSF, porque un cliente me lo pide, trataría de usar o por lo menos ser compatible con Seam. Además, gracias al nuevo soporte de Wicket, vamos a poder incorporarlo en nuestros desarrollos Java.


Soluciones RIA en lugar de framework web

Se puede usar un cliente RIA y conectarse al servidor via REST o Web Service. En este caso, desaparece el framework web casi por completo.

Es una posibilidad pero la encuentro improbable: un framework web con una buena biblioteca de componentes AJAX es más simple.


Soluciones no Java

Con el soporte de muchos lenguajes sobre la JVM y los servidores de aplicación, es perfectamente posible usar otro lenguaje con su respectivo framework, para la capa de presentación llamando la lógica de negocio en Java. Por ejemplo, Netbeans permite desarrollar con Groovy/Grails, Ruby/Ruby On Rails y PHP haciendo el deploy sobre servidores de aplicación JEE. Para no mencionar solamente productos de Sun, se puede hablar de:

• el Project Zero de IBM (a pesar que no me queda claro si puede invocar código Java)
• el soporte PHP de Resin con Quercus. Drupal es 4 veces más rapido sobre Resin que sobre Apache. Sun Glassfish y Oracle Weblogic usan Quercus en modo interpretado para soportar PHP

Creo que esta tendencia va a seguir y es el camino que yo escogí al probar Scala y Liftweb. Y veo el futuro cada vez mejor:

• los programadores top de Liftweb están trabajando para mejorar el soporte JPA,
• los plug-in para Netbeans y Eclipse esta mejorando.
• me da la oportunidad de crear componentes y hacer un tipo de desarrollo que no hacia desde mi época en lenguaje C sobre MS-DOS: me hace sentir bastante más joven.

Conclusión

No creo que la guerra este cerca de terminar. El impacto de AJAX y RIA son factores importantes. Por el momento, voy por el camino Wicket (incorporando pronto Seam) cuando estaré ligado a Java y Scala/Liftweb cuando tendré más libertad.


Update 10 de Noviembre 2008: cambios menores de redacción

Update 12 de Noviembre 2008: otro cambio de redacción y mencionar que SpringSource apuesta fuertemente a Groovy/Grails.

Update 22 de Noviembre 2008: solamente mencionar esta conversación extensa en TSS sobre el mismo tema.