Recientemente EFrigerio publicaba el soporte parcial de canvas en Form4G, para los que no conozcais Form4G, es una herramienta Java con el fin de acercar Swing al web, replicando aunque no sea de forma estándar el modelo de programación web en aplicaciones de escritorio.
La publicación de Form4G e inquietudes personales previas me han hecho reflexionar si está llegando el momento en que la web y el escritorio convergen, y cuando digo convergen no me refiero a que una aplicación web pueda llegar a acercarse a la funcionalidad de una aplicación de escritorio, sino más bien a que ambos tipos de aplicaciones puedan hacerse de la misma manera.
El tema de Form4G es un tema que en su momento me interesó muchísimo, a mi también me gusta retorcer las tecnologías como decía remoh en el hilo de la noticia del lanzamiento de Form4G, la tecnología web en aplicaciones Swing habría dado un gran empuje al propio Swing, pues al acercar Swing al web el riesgo de "inversión" entre una y otra tecnología hubiera disminuido mucho.
Hace años con la llegada del primer Mozilla 1.0 estaba entusiasmado en la posibilidad de que Java, que era el lenguaje claramente emergente en esa época, pudiera integrarse con Mozilla para el desarrollo de aplicaciones de escritorio. JavaScript siempre me pareció "débil" y C++ demasiado "fuerte" y rígido, la combinación de HTML y Java con dosis de JavaScript siempre me pareció una opción de desarrollo mucho más flexible y sencilla que la tremenda complejidad (y potencia sin duda) del puro Swing (bastante malillo en aquella época).
La verdad es que nunca tuve la posibilidad real de experimentar con este enfoque, de todas formas el panorama ha sido siempre desolador, la marginación de Java por parte de la Fundación Mozilla más allá de los applets y el desinterés del mundo Java en integrar el mundo web en Swing ha sido muy muy escaso, por no hablar de la casi inexistencia de navegadores 100% Java y los que ha habido, comerciales, no parece que hayan sido muy populares.
Han existido intentos de integración del mundo web y Swing, particularmente el trabajo "hercúleo" de generar una aplicación web a partir de Swing, como es el caso de AjaxSwing (antiguo WebCream) y similares herramientas o frameworks web fuertemente basados en Swing como WingS. El objetivo es rentabilizar la inversión en aplicaciones Swing portando a web sin demasiado esfuerzo. Sin duda a muchos estas herramientas les han sido extremadamente útiles para portar sus viejas aplicaciones, sin embargo cualquiera que conozca un poco ambas técnicas de programación (Swing y web) se dará cuenta en seguida que la aplicación web generada es tremendamente forzada.
Si portar una aplicación Swing a web es relativamente "fácil" lo contrario no lo es, el paradigma de programación web basado en páginas se lleva tremendamente mal con el paradigma de una sola ventana del mundo del escritorio, por no hablar de que la forma de programar en Swing es muy diferente a la forma de programar en web.
Sin duda alguna el web es el rey absoluto sólo "amenazado" por Flex/SilverLight/JavaFX, por lo que la opción web es casi siempre la opción número uno, la intención de hacer una aplicación alternativa de escritorio "más productiva" se queda casi siempre en el papel por razones básicamente de coste (doble trabajo).
Sin embargo las cosas están cambiando, la llegada de AJAX está permitiendo el desarrollo de aplicaciones web similares al escritorio, no sólo por la riqueza visual de sus componentes sino también porque el uso intensivo de AJAX permite la creación de aplicaciones
Single Page Interface, paradigma que converge claramente con el Single Document Interface (SDI) típico del escritorio.
Pero este aspecto algunos lo podrían ver como una razón más para deshacerse del viejo Swing.
El mencionado WebCream mejoró enormemente cuando introdujo AJAX, pues anteriormente cada click suponía la regeneración de la página entera, lo cual no ha sido gran problema para un usuario web que está ya "acostumbrado" sin embargo para el usuario de la aplicación Swing que se pretende substituir el resultado dejaba bastante que desear. Pero aun así, "nadie" hoy día hace una aplicación Swing como primera opción y la porta a web después, porque todos sabemos que el usuario web tiene unas exigencias extremas sobre lo que quiere ver en la pantalla y el web permite una gran libertad de diseño con un relativo bajo coste, el mismo resultado en Swing cuesta más trabajo aunque el resultado es más correcto y no está lleno de las chapucillas propias del web (que si imágenes con las esquinas redondeadas etc).
Empezar en Swing y portar a web no es hoy día una opción (salvo excepciones), por lo tanto, la opción es llevar el web a Swing. Quizás AHORA es el momento, cuando las aplicaciones web tienden cada vez más a ser Single Page Interface lo cual encaja muy bien con el Single Document Interface del escritorio, por tanto por primera vez en la historia ambas formas de programación (web y escritorio) convergen.
En este llevar el web a Swing, Form4G es un intento. EFrigerio aprovecha el pobre soporte de HTML 3.2 de Swing con el fin de extenderlo añadiendo nuevos tags y JavaScript a través de Rhino, añadiendo además tecnologías similares al servidor tal y como una especie de servlets y JSP, digo "especie" porque el propio autor deja claro que su objetivo por ahora no es replicar exactamente el estándar servlets/JSP.
El esfuerzo es loable aunque el esfuerzo de hacer un motor web es un trabajo ingente, por lo que no veo tanto Form4G como un motor web sino una tecnología nueva "inspirada" en web.
No se cuales son claramente los objetivos personales del autor y el rumbo de Form4G, pero en ese terreno hay mucho trabajo hecho por ejemplo en Lobo Browser.
El objetivo de Lobo es construir un navegador web decente 100% Java y de código abierto, aunque siempre es posible reutilizar los componentes, extenderlos e integrarlos en aplicaciones que no sean navegadores web, es el caso del componente Cobra.
No conozco Lobo más que la superficie, pero por lo que se su objetivo es hacer web estándar. Form4G busca extender el web normal con Swing, lo cual me parece genial, estoy hablando por ejemplo del menú popup Swing que he visto en la documentación de Form4G. En mi opinión las ideas de Form4G tendrían más frutos dentro de Lobo, pero es el autor de Form4G el que tiene que decidir sus caminos y sus compañeros de viaje.
A mi me interesa mucho Lobo por dos razones, la primera como un navegador web más soportado en ItsNat, actualmente no está soportado porque todavía está muy verde, faltan demasiadas cosas ("the Javascript engine is functional, but not all APIs are complete" dice la web).
Pero Lobo me interesa mucho más por otra razón: como motor web Java con el que hacer aplicaciones de escritorio basadas en web, más bien en "la nueva web" Single Page Interface (SPI), es decir ser capaces de meter un framework web intensivo en AJAX en la aplicación de escritorio.
La idea no es nueva, todo el mundo sabe que Tomcat y Jetty desde hace mucho tiempo pueden introducirse embebidos en tu aplicación Java, sin embargo, en ambos casos, el modo de funcionamiento es el típico web, es decir el servidor se carga reservando un puerto de comunicaciones, lo cual es simplemente absurdo en una aplicación de escritorio.
Otro problema de esta técnica son los JSPs, los JSPs fueron pensados para generar páginas web lo cual tiene un valor casi nulo en aplicaciones "web de escritorio" basadas en SPI.
En el caso de ItsNat el enfoque "el servidor es el navegador" encaja bastante bien, pues básicamente ItsNat es un navegador Java W3C sin renderización web.
En mi opinión para que este enfoque de "aplicaciones web de escritorio" prospere aparte de un motor web decente (no se si todavía Lobo está a la altura), es necesario crear un falso procesador de servlets y un XMLHttpRequest que pueda funcionar en local, es decir que el envío de datos realmente se una llamada directa al falso motor de servlets.
Es más como cualquiera puede imaginar, podríamos prescindir de toda la parafernalia servlets pues cualquier evento web podría ser procesado directamente por listeners en Java y cualquier modificación del DOM podría hacerse directamente en Java, cualquiera que conozca un poco Rhino y especialmente Batik sabe de lo que estoy hablando (el tema me pilla muy de cerca porque estoy peleándome actualmente con Batik funcionando en un applet).
Aunque lo anterior es totalmente cierto no hay que olvidar que el objetivo es ser capaces de hacer aplicaciones web que funcionen tanto en remoto como en escritorio (sin crear sockets) reutilizando cerca del 100% del código, por lo que la eliminación de los servlets puede no ser viable, de todas formas hay que recordar que la tecnología servlets fue concebida como no necesariamente ligada a HTTP, por eso las clases e interfases base no incluyen dependencias HTTP, aunque en la práctica "nadie" use servlets fuera del HTTP.
Lo interesante de estas "aplicaciones web de escritorio" es que no necesitan sockets para funcionar en local y admiten extensiones Swing en la línea de los popup Swing de Form4G, por lo que la versión web de escritorio podría ser funcionalmente exacta a la remota, pero además con extensiones Swing que permitieran una mayor productividad y por supuesto con la ventaja de poder acceder al escritorio via Java (y JNI si es necesario) como cualquier aplicación de escritorio (acceso al scanner, a la cámara etc).
¿Tienen futuro estas aplicaciones web de escritorio?
lunes, diciembre 7, 2009 at 1:26AM