Lo mejor de la semana
En nuestro grupo SoloJava cada dia es mas frecuente la participacion en debates sobre el uso de tal o cual Tecnología. Un ejemplo de esto nos lo da Martin en lo que he titulado "Lo mejor de la semana", no se si sera una seccion fija en este espacio pero, al menos por ahora, Martin se ha ganado la posbilidad de ser el primero en participar en ella. A continuacion su opinion:
Son reflexiones interesantes, y se hacen mas frecuentes mientras mas
grandes y complejos son los sistemas, y mas se usa y abusa de las
"facilidades" de JSP/EL/TagLibs.
Yo tengo una opinion muy particular del desarrollo de aplicaciones Web con
JSP y tecnologias relacionadas, que probablemente la mayoria no comparte.
No me gusta JSP, me parece un accidente en la historia del Java, que
respondia mas a las presiones competitivas frente a ASP y PHP, que a la
necesidad tecnica, no en vano surgieron rapidamente otros enfoques
alternativos, basados en Template Engines.
Para comenzar esta el problema de crear practicamente otro lenguaje dentro
de tu platilla o pagina, sobre el que no puedes hacer comodamente debug
con Eclipse, por ejemplo, porque no es codigo fuente real, es un
artificio.
Luego tienes el problema de la libertad que tienes para hacer las cosas
con JSP, entremezclando logica y presentacion. Paradojicamente, se vende
JSP como una tecnlogia que favorece la separacion de presentacion y
logica, pero la mayoria de las aplicaciones JSP que he visto, con el
tiempo terminan parchando las paginas con todo tipo de cosas, desde acceso
directo a base de datos hasta algortimos de calculo. Claro que hay maneras
de mejorar las cosas con JSP, de ser mas disciplinado, de usar una capa de
TagLibs para tener un enfoque mas declarativo, pero el problema es que el
uso de JSP PERMITE que un modelo disciplinado sea desvirtuado, y esto a
menudo sucede cuando los proyectos se hacen mas complejos, aumentan las
presiones de entrega, y se hace presente la tendencia al caos en el
proyecto. Por otro lado, el uso de TagLibs, ya no es Java, como tu bien
dices, estas usando un "meta-lenguage", construido con Java, pero que ya
no es Java, o sea, incorporaste mas complejidad en la ya variada gama de
herramientas y tecnologia que usas para desarrollo Web.
Para mi, el estandar de Servlets (2.3) ya es suficientemente robusto y
bien pensado como para necesitar las JSP, soy de la opinion que un
TemplateEngine permite lograr un mejor modelo MVC, al tiempo que usas un
solo lenguaje: Java, con todas las facilidades que eso implica (todo el
poder que te da Eclipse cuando programas en Java puro). Dependiendo del
TemplateEngine, se reducen las posibilidades de violentar un modelo
establecido de programacion y separacion de UI y logica. Hay un paper muy
interesante en este sentido:
Enforcing Strict Model-View Separation in Template Engines:
http://www.cs.usfca.edu/~parrt/papers/mvc.templates.pdf
Luego esta el tema de la productividad. No rechazaria un esquema
simplemnte porque no es "java puro", pienso que debe existir un equilibrio
entre una arquitectura solida, cuya integridad conceptual se mantiene
hasta el fin del proyecto, y un enfoque productivo de programacion. No
compro el argumento de que, algo robusto necesariamente tiene que ser
dificil o enredado, argumento con el que mas de una vez he visto
justificado el uso de Struts, cuyo principal merito (en mi opinion) es
haber sido el primero y mas publicitado, dificilmente el mejor.
Ahora empujan JSF, inundando los pricipales portales de Java con articulos
introductorios, que se esfuerzan por hacer ver que JSF si puede ser facil
de usar, si asi fuera, no necesitarian de tanta evangelizacion con el
tema. Nuevamente tratan de crear una ilusion, la de un GUI orientado a
eventos, como con .Net, sobre unas tecnologias estandar como HTTP y HTML
que no necesitan nada de eso.
Al final pienso que muchos equipos de desarrollo terminan atrapados en la
sopa de acronimos que es J2EE: JSF, JSP, JSTL, EJB, etc... y piensan que
tienen que usar todas esas cosas para hacer aplicaciones J2EE
"respetables", con el resultado lamentable de que atrasan sus proyectos, e
imponen requerimientos poco realistas de formacion profesional a sus
integrantes.
Bueno, me termine yendo por la tangente, pero es que tu reflexion daba
para eso y mas.
Saludos,
Martin
Son reflexiones interesantes, y se hacen mas frecuentes mientras mas
grandes y complejos son los sistemas, y mas se usa y abusa de las
"facilidades" de JSP/EL/TagLibs.
Yo tengo una opinion muy particular del desarrollo de aplicaciones Web con
JSP y tecnologias relacionadas, que probablemente la mayoria no comparte.
No me gusta JSP, me parece un accidente en la historia del Java, que
respondia mas a las presiones competitivas frente a ASP y PHP, que a la
necesidad tecnica, no en vano surgieron rapidamente otros enfoques
alternativos, basados en Template Engines.
Para comenzar esta el problema de crear practicamente otro lenguaje dentro
de tu platilla o pagina, sobre el que no puedes hacer comodamente debug
con Eclipse, por ejemplo, porque no es codigo fuente real, es un
artificio.
Luego tienes el problema de la libertad que tienes para hacer las cosas
con JSP, entremezclando logica y presentacion. Paradojicamente, se vende
JSP como una tecnlogia que favorece la separacion de presentacion y
logica, pero la mayoria de las aplicaciones JSP que he visto, con el
tiempo terminan parchando las paginas con todo tipo de cosas, desde acceso
directo a base de datos hasta algortimos de calculo. Claro que hay maneras
de mejorar las cosas con JSP, de ser mas disciplinado, de usar una capa de
TagLibs para tener un enfoque mas declarativo, pero el problema es que el
uso de JSP PERMITE que un modelo disciplinado sea desvirtuado, y esto a
menudo sucede cuando los proyectos se hacen mas complejos, aumentan las
presiones de entrega, y se hace presente la tendencia al caos en el
proyecto. Por otro lado, el uso de TagLibs, ya no es Java, como tu bien
dices, estas usando un "meta-lenguage", construido con Java, pero que ya
no es Java, o sea, incorporaste mas complejidad en la ya variada gama de
herramientas y tecnologia que usas para desarrollo Web.
Para mi, el estandar de Servlets (2.3) ya es suficientemente robusto y
bien pensado como para necesitar las JSP, soy de la opinion que un
TemplateEngine permite lograr un mejor modelo MVC, al tiempo que usas un
solo lenguaje: Java, con todas las facilidades que eso implica (todo el
poder que te da Eclipse cuando programas en Java puro). Dependiendo del
TemplateEngine, se reducen las posibilidades de violentar un modelo
establecido de programacion y separacion de UI y logica. Hay un paper muy
interesante en este sentido:
Enforcing Strict Model-View Separation in Template Engines:
http://www.cs.usfca.edu/~parrt/papers/mvc.templates.pdf
Luego esta el tema de la productividad. No rechazaria un esquema
simplemnte porque no es "java puro", pienso que debe existir un equilibrio
entre una arquitectura solida, cuya integridad conceptual se mantiene
hasta el fin del proyecto, y un enfoque productivo de programacion. No
compro el argumento de que, algo robusto necesariamente tiene que ser
dificil o enredado, argumento con el que mas de una vez he visto
justificado el uso de Struts, cuyo principal merito (en mi opinion) es
haber sido el primero y mas publicitado, dificilmente el mejor.
Ahora empujan JSF, inundando los pricipales portales de Java con articulos
introductorios, que se esfuerzan por hacer ver que JSF si puede ser facil
de usar, si asi fuera, no necesitarian de tanta evangelizacion con el
tema. Nuevamente tratan de crear una ilusion, la de un GUI orientado a
eventos, como con .Net, sobre unas tecnologias estandar como HTTP y HTML
que no necesitan nada de eso.
Al final pienso que muchos equipos de desarrollo terminan atrapados en la
sopa de acronimos que es J2EE: JSF, JSP, JSTL, EJB, etc... y piensan que
tienen que usar todas esas cosas para hacer aplicaciones J2EE
"respetables", con el resultado lamentable de que atrasan sus proyectos, e
imponen requerimientos poco realistas de formacion profesional a sus
integrantes.
Bueno, me termine yendo por la tangente, pero es que tu reflexion daba
para eso y mas.
Saludos,
Martin
» Publicar un comentario