septiembre 22, 2005

Java Server Faces

Me he dado cuenta que no había comentado mi opinión sobre JSF en la bitácora, y lo he hecho varias veces en algún post de The Server Side.
Me recuerda JSF mucho al estilo de programación con un "viejo" servidor de aplicaciones llamado NetDynamics (¿alguien se acuerda?). Era como programar por eventos en la web. Es como esconder que realmente estás en un entorno en el que en medio existe un protocolo llamado HTTP, y que a veces para ser efectivo y programar eficientemente necesitas conocerlo a fondo.
Por eso no me gusta tampoco JSF. El hecho de que generes unos códigos que ya desde el principio se decía que es que habría IDEs para generarlos, te hace pensar que pueden ser mucho más engorrosos para exprimirlos al máximo.
Y me he acordado de esto, por que ahora hay un artículo interesante sobre la que todo el mundo habla casi como una nueva manera de programación para la WEB, con AJAX: Does JSF + AJAX really make sense?.

I wonder if it would not be better to either use AJAX very sparingly so it doesn't interfere with existing request processing patterns, or move the controller entirely to the client and forget server-side web frameworks as we know them today.
Estoy bastante de acuerdo con él, aunque no creo que haya que ser tan drástico, puesto que, para ello, los navegadores aún deben evolucionar bastante (para soportar un controlador complejo sería mejor algo más que el rudimentario JavaScript). Y también ya se ven numerosas páginas que hacen un uso impactante de AJAX, por ejemplo: netvibes.com.

9 comentarios:

  1. Francamente sorprendente la referencia que das a netvibes, lo primero que se me ha ocurrido es que ofrece unas posibilidades realmente potentes para las aplicaciones de intranets basadas en portlets, yahoo, peoplesoft, oracle y compañía.

    Respecto a la realización de aplicaciones con ajax, al igual que tú, considero que aún queda tiempo para que sea asumible realizar aplicaciones complejas sin incurrir en costes desorbitados, aunque etoy seguro de que ese es el futuro. Creo, y espero, que en un par de años las posibilidades de las aplicaciones de escritorio y las basadas en web serán similares, pero para ello hace falta que se simplifique el desarrollo de estas últimas. Esta simplifación debería venir dado por la definición de un estándar que permita la generación de interfaces, mediante CSS, XUL, XAML o similares, y que permita también la comunicación con el servidor mediante algún lenguaje o tecnología estándar. A este último respecto se me hace difícil pensar que el lenguaje no sea otro que JavaScript, aunque no es precisamente santo de mi devoción, sin embargo es seguro que surgirá algún framework que ofrezca un método simplificado de comunicación con el servidor, posiblemente basado en SOAP sobre XMLHttpRequest, o quizás se acabe adoptando la recomendación XForms del W3C, quién sabe.

    En lo que respecta al lado servidor quizás la cosa sea más complicada, y cada tecnología adopte su propia filosofía, que esperemos afecte lo menos posible a la parte cliente, aunque por ahora parece todo lo contrario. Ejemplos como Sajax en PHP o Atlas en ASP.NET 2, pueden parecer la panacea en este momento, pero creo que pueden acabar convirtiendo el desarrollo de aplicaciones web en una auténtica torre de bábel.

    Por lo que a mi respecta, creo que lo mejor es seguir muy de cerca cómo evolucionan todas estas tecnologías, e ir aplicándolas paulatínamente, conforme vayan instaurándose.

    ResponderEliminar
  2. Yo soy de la opinión de que AJAX de momento debemos verlo como una posibilidad más de interacción con el usuario, desde la interfaz. No creo que sea una revolución excepto en la interfaz. Creo que es demasiado aventurado meterse en establecer controladores en cliente, o cambios de filosofía en el servidor.
    Eso tendrá que venir una remodelación más profunda de los navegadores o de la web, creo.

    ResponderEliminar
  3. Creo que tienes mucha razón en que hace falta algo más que javascript para mover el controlador al cliente.

    En mi caso hemos creado una gran RIA con Flash y J2EE (principalmente EJBs), que va de miedo gracias a que el runtime de Flash es bastante potente y permite la orientación a objetos que tenemos en Java.

    Por eso no soy partidario de Javascript, puesto que creedme que un proyecto con AJAX se tiene que convertir a la fuerza en un infierno cuando empieza a crecer y el equipo de desarrollo es medio-alto.

    Para pequeñas cosas creo que AJAX no está mal, pero para proyectos complejos me quedo con Flash...si no puedo meter una licencia de Flex ;)

    ResponderEliminar
  4. si quieres empezar a aprender a programar en Java, tienes que bajarte el J2SE, éste incluye la máquina virtual de Java, el compilador, el depurador y unas cuantas herramientas más.

    tienes que entrar a la página de sun y bajarte el J2sdk, que es el kit de desarrollo de Java que te acabo de comentar.

    puedes usar un entorno integrado desarrollo (ide), como Visual Age, Jdeveloper, Eclipse, NetBeans, etc... pero si hasta ahora estás empezando te recomiendo que no uses ninguno de ellos, porque tu objetivo ahora es aprender a programar en Java y no luchar con todas las idiosincrasias que tienen esos entornos.

    personalmente yo instalo primero el JDK y luego instalo un editor de texto llamado TextPad que te permite escribir el código fuente de los programas en Java, y para compilar [CTRL] + 1; y para ejecutar el programa [CTRL] + 2; eso sí para que que funcione tienes que haber instalado Java primero.

    J2EE, es un conjunto de librerías para hacer desarrollo empresarial en Java, así que por ahora no las necesitas, primero debes aprender a programar en Java y luego si puedes usar esas librerías.

    Adrian Acosta

    ResponderEliminar
  5. Hola, Java presenta desventajas tales como:

    * La de poseer la tecnología de la máquina virtual, si se hace referencia a la velocidad. Pero no a la portabilidad.

    * Es considerablemente lento respecto de lenguajes como C o C++.

    Excluyendo estas desventajas, ¿Qué otras contras tendría este lenguaje?

    Adrian Acosta

    ResponderEliminar
  6. Nuevamente quisiera agregar otros puntos importantes que debemos tomar en cuenta los siguientes puntos
    Ventajas:
    - Al compilarlo, se genera código objeto, nativo de cada máquina. Resultado: C++ es más rápido que Java. Y bastante más rápido, diría yo. Digamos que a la hora de elegir un lenguaje, la necesidad de velocidad de nuestra aplicación inclinaría la balanza hacia C++. Pero aún nos quedan muchos "pesos" que añadir a los platillos.
    - Es una extensión de C. Por eso, muchas programadores encontrarán muy sencilla la transición, ya que podrán seguir haciendo cosas a la antigua usanza.
    - Permite un control de la memoria y una capacidad de programación de bajo nivel impensable en Java. Otro platillo para C++.
    Desventajas:
    - No es multiplataforma. Para lograr aplicaciones que se ejecuten en varios SO, se requiere de cierto esfuerzo. Platillo para Java.
    - No presenta una arquitectura estándar de desarrollo orientado a Internet. Digamos que Java es algo más que un lenguaje, es toda una plataforma, y apoyada por muchas empresas, lo que le otorda un grado de calidad del que carece C++.
    - Es una extensión de C. ¿Pero no era una ventaja?. Bueno, pues también es un inconveniente, pq bastantes dogmas de la POO se sacrifican para hacer hueco al C. Java corrige esos problemas.
    - No presenta un toolkit tan rico como el de Java. Java soporta el desarrollo rápido de aplicaciones, y muchas de las tareas de un programador están resueltas en su toolkit. Aunque hay muchas librerías en la red para C++, no son estándar del lenguaje, y algunas son de pago.

    ResponderEliminar
  7. ¿Y que hay con JSF?
    JSF (Java Server Faces) es un framework de desarrollo basado en el patrón MVC (Modelo Vista Controlador).

    Al igual que Struts, JSF pretende normalizar y estandarizar el desarrollo de aplicaciones web. Hay que tener en cuenta JSF es posterior a Struts, y por lo tanto se a nutrido de la experiencia de este, mejorando algunas sus deficiencias.

    ResponderEliminar
  8. Hay que diferenciar JSF y Struts.

    ¿Cuál usar?
    En una arquitectura típica de tres capas tenemos varias opciones para la capa de presentación: jsf, webwork, tapestry, struts, spring mvc...

    La opción más extendida a día de hoy es Struts, aunque JSF cada vez está cogiendo más fuerza. Hoy he mantenido una conversación interesante en el canal #jsf de freenode con Ken Paulsen creador del framework JSFTemplating, quien me comentó las siguientes ventajas de JSF:

    El soporte de JSF en IDEs como Eclipse, Netbeans, etc. es mucho mejor

    Constantemente se crean nuevos componentes JSF
    Gran soporte de JSF en la industria
    JSF es parte de Java EE (Struts no)
    Todos los servidores de aplicaciones, por tanto, incluyen JSF

    ResponderEliminar
  9. Los sistemas MVC (Modelo-Vista-Controlador) permiten una separación clara entre presentación y lógica de negocio. Uno de los frameworks MVC más usados para la construcción de aplicaciones Web ha sido Apache Struts. En la actualidad Struts está siendo superado por la nueva propuesta estándar de Java para implementar este modelo, Java Server Faces (JSF). Una de las ventajas de JSF es que es independiente del tipo de aplicación a desarrollar, existiendo implementaciones tanto para aplicaciones Web como para aplicaciones clientes standalone o incluso para aplicaciones en dispósitivos móviles.

    ResponderEliminar