viernes, 31 de octubre de 2008

Más retornos de experiencia con Scala/Liftweb/jQuery

Basado en mis primeras experiencias positivas con Scala, Liftweb y javascript/jQuery, decidí lanzarme en mejorar mi TreeTable, un widget para Lift. Y las cosas se empezaron a complicar....

El cambio

La primera versión de mi widget usa jqTreeTable y es super simple: el código Scala genera una tabla HTML estándar y genera código Javascript que llama a jqTreeTable para que se encargue de todo. Super simple si, pero tiene limitaciones:
  • Sin soporte AJAX. No puedo buscar en el servidor el contenido de la rama a expandir.
    • Performance en el browser: con tablas medianas se empieza a notar el procesamiento inicial de jqTreeTable.
    • Performance en el servidor; generar una tabla grande con muchas ramas puede implicar muchos SQL a la base de datos (uno por cada nodo que contenga hojas).
  • jqTreeTable usa un solo id para la tabla. Eso permite un solo tree-table por pagina web.
  • la altura de las filas debe ser constante e igual a uno de los gif de jqTreeTable. Eso me impide insertar gráficos dentro de la tabla.
  • los browsers que no soportan jQuery no pueden desplegar el árbol. Si el HTML/CSS del árbol se genera en el servidor se tiene automáticamente un fallback.
Finalmente, todas las limitaciones anteriores son excusas porque la curiosidad mata el gato: a pesar que para mi proyecto me la podría haber arreglado de otra forma, tenia que hacerlo para ver que tan difícil es.


Impacto en Scala / Lifweb

Mis problemas no estuvieron en el lenguaje y el framework. Quizas sea una pena, porque no me permitio hacer progresos notables.

Puedo comentar que ya estoy usando Netbeans 6.5 y el plugin para Scala. Eso simplifica bastante en comparación de usar Netbeans, jEdit y Maven en línea de comandos. También mejora bastante la edición de Javascript.

No obstante, no es perfecto:
  • la triangulación con el repositorio local de maven hace que Netbeans desconoce las dependencias entre sus proyectos:
    • impide navegar entre los fuentes de los proyectos.
    • no hay refactoring iniciado en un proyecto Java con cambio en el código Scala.
  • seria practico poder publicar en el repositorio local de maven proyectos construidos por el build.xml de Netbeans.
  • no se como usar el debugger de javascript de Netbeans cuando es un proyecto Maven.
Todo eso no es tan grave.

Lo que si es grave, es vivir con envidia. Para los que programan en Java, Netbeans 6.5 hace el deploy automático de la aplicación web cada vez que se cambia un fuente Java, XML, JSP, etc. Es suficiente salvar el archivo, esperar 1 segundo, cambiarse al browser y hacer el refresh de la pagina. ¡Es una maravilla! En comparación, me demoro 10 segundos y aprieto bastante más veces los botones del ratón o las teclas usando maven y esperando el reload del servidor.

En resumen, me gustaria mucho que mejoren el plug-in de maven o poder bypassear este plug-in por completo.


Impacto en Javascript / jQuery / HTML / CSS

Al fin me encontre con los famosos problemas de incompatibilidad. No fue en javascript porque hasta ahora jQuery me los esconde a la perfección. Pero si en HTML y en CSS: no fui culo para solucionar el problema de la altura variable de las filas, donde IE y Firefox definitivamente no funcionan igual.

También tuve problemas serios de rendimiento en mis primeras versiones.

El resultado es que aprendí mucho de jQuery probando distintas alternativas y que mejore significativamente mis conocimientos de CSS, a pesar que eso fue insuficiente.


Impacto en la arquitectura

En mi primera versión había bastante separación entre el códígo en el browser y el servidor. Esta nueva versión tiene mucho más inter-dependencias entre Javascript y Scala.

Una consecuencia de lo anterior, es que no es fácil probar con archivos HTML planos (para no tener que esperar maven y el servidor de aplicación). Otra consecuencia, es que seria muy bueno poder usar el debugger de javascript de Netbeans junto con el debugger de Scala.


Comparación con Java

El proyecto que más tiempo me toma ahora, usa Struts y patrones J2EE 1.3 de hace 4 años atrás con capas, capas y más capas. El auto-deploy de Netbeans 6.5 es una maravilla pero no logra compensar la pesadez de este tipo de desarrollo.

Si se compara con desarrollos usando Wicket, el hecho que Lift no tenga una lista importante de componentes pre-hechos es una limitación. La ventaja es que Scala hace mucho más fácil este tipo de desarrollo.

Moraleja

Algún día tenia que vivir en carne propia la incompatibilidad entre browsers: no justifica no usar Javascript para aplicaciones RIA.

Todavía, no me arrepiento de mi incursión en Scala. Creo que permite resolver problemas que en Java son muy dificiles de atacar. Pero, eso será para otra entrada.

No hay comentarios: