Hoy en día casi todo proyecto de desarrollo tiene alguna interfaz web como parte del producto. Esto no es ningún desafío si tenemos un equipo el cual ya ha trabajado con este tipo de proyectos. ¿Pero que pasa si el equipo no tiene experiencia en el desarrollo de aplicaciones web?

Por ejemplo, viene del mundo enterprise, con años de experiencia en sistema de mediano y gran porte con clientes realizados con frameworks GUIs como ser Swing.

Al principio seguramente subestimemos el mundo web pensando que todo es es un juego de niños que cualquiera puede hacer y que contratando a un diseñador web nuestros problemas van a estar solucionados. Pero obviamente uno está equivocado y ni bien comienza a estudiar lo básico se encuentra con una cantidad de conceptos no menores como ser manejo de sesión, AJAX, CSS, XSS, SQL-Inyection que uno debe entender antes de poder realizar cualquier sistema.

Una vez que terminamos de estudiar estos conceptos y que nos volvemos a sentir seguros para comenzar es recién ahí que nuestro problema comienza. En ese momento es cuando la gran pregunta surge ¿Qué framework web (FW) es el que debo utilizar para mis proyectos?

Hace un par de años atrás esto no hubiera sido un problema, la respuesta probablemente hubiera sido si estamos trabajando en Java, utiliza struts. Pero hoy eso cambió debido a que solo para Java en la página http://java-source.net/open-source/web-frameworks podemos encontrar más de 40 frameworks, dentro de los cuales el que yo utilizo no está. Y ni hablar si entramos considerar FW de diferentes lenguaje de programación como ser Ruby, Python, php y .net . ¿Entonces como podemos hacer para responder semejante pregunta hoy en día?

A continuación voy a definir lo que IMHO son los factores que yo he utilizado para responder está pregunta y que pueden ser de ayuda a otros que se enfrenten a una situación similar. Partiremos de la base que tenemos un equipo de desarrollo con experiencia en un lenguaje determinado el cual debemos reconvertir al desarrollo de aplicaciones web. Algunos de los puntos que se plantearán no tienen sentido por ejemplo para un desarrollador independiente o si se está armando un equipo desde cero. Cuando se trabaja con un equipo ya formado hay factores a considerar que no dependen directamente de la tecnología y que pueden determinar que el mejor FW del mundo, no sea la mejor elección, lo cual hace que la solución del vecino no siempre sea la solución adecuada para uno. Por lo tanto debemos tener sumo cuidado con nuestros pares cuando con su mejor intención nos recomiendan “él FW” ya que probablemente ellos no conozcan el contexto donde usted lo debe utilizar. Por último hay que ser realistas y saber que probablemente al finalizar el proceso de selección haya más de un FW que pueda ser utilizado y que la definición terminará siendo un tema de preferencia con un grado de incertidumbre. La respuesta final solo la sabrá luego de estar avanzado en el primer proyecto, pudiendo equivocarse y debiendo reconsiderar su decisión. Por tal motivo es importante elegir como primer experiencia un proyecto no crítico.

Los puntos que voy a nombrar a continuación no están en un orden especial.

Puntos a tener en cuenta a la hora de elegir un FW
Conocimientos del equipo

Es de suma importancia evaluar en que se siente cómodo el equipo trabajando. Es decir si tengo todos programadores Java muy probablemente lo mejor sea buscar una FW dentro de Java de esta forma el equipo podrá aprender rápidamente el FW ya que no tiene que perder tiempo estudiando los detalles de otro lenguaje. Por otro lado FW buenos hay en casi todos los lenguajes así que no debería ser un problema fijar este punto. La excepción a esta regla sería si estamos trabajando con un lenguaje desactualizado como ser Clipper o Cobol. Pero en este caso estaremos ante una problema mayor que es una reconversión tecnológica de los sistemas.

¿Necesitamos algo que solucione solo la presentación o tenemos que trabajar en todas las capas?

Es importante determinar que grado de libertad tenemos a la hora de elegir. Es decir, estamos ante un caso en el cual tenemos un sistema ya armado al cual solo debemos darle la presentación web o estamos ante un caso en el cual podemos elegir desde la forma de presentar los datos hasta la forma de persistirlos. Dependiendo de esto nos convendrá utilizar algo que soluciones todo nuestro requerimientos o simplemente centrarnos en lo que necesitamos que es solucionar la presentación web. En base a lo anterior podemos dividir los FW dividir en dos grupos y así descartar el que no sea de nuestro interés. Los grupos serían:

Frameworks full stack

Son los que presentan una solución completa que va desde la capa de presentación hasta la capa de persistencia de la información. Los más nuevos están basados en el patrón MVC. Algunos ejemplos de estos son:

• Rails en ruby y que podríamos decir que es la estrella del momento
• Grails en Groovy
• CakePhp en php
• Spring Roo y SEAM en Java
• Django en Python

Detallar cada uno no es nuestra intención, simplemente me limitaré a comentar que la mayoría está basado en los principios de CoC (convention over configuration), DRY (don’t repeate yourself) y que su composición básica consta de un procesador de templates para el diseño de las vista (que generarán las páginas dinámicas), un despachador de HttpRequests que siguiendo determinadas convención decide a que servicio despachar el pedido. Para el manejo de los datos cuentan con un framework ORM que ofrece creación de consultas dinámicas y una cantidad de facilidades que simplifican el trabajo.

Solo de presentación:

Estos son aquellos que están orientados solo a la capa de presentación.

Ejemplos de este tipo son:

• GWT- Google Web Tookit:el cual genera una aplicación 100% JavaScript pero que es programada en Java
• JSF: Java Server Faces, es el framework de componentes oficial de Java
• ASP.NET: que es LA opción dentro de Microsoft

Soporte (comunidad, fabricante, libros, certificación, perspectiva a futuro)

Un punto importante, sobre todo en los proyectos OS, es ver la comunidad que hay al rededor del framework a utilizar. Es importante investigar si hay una empresa invirtiendo recursos en el desarrollo del producto o está movido pura y exclusivamente por la comunidad. En el último casó es cuando “el tamaño si importa” y dependiendo del tamaño de la comunidad en que se sustenta depende el soporte que podemos tener. Para esto la mejor forma es en la página del framework buscar que tantos reporte de bugs hay, que tan rápido se solucionan, cuantos desarrolladores hay corrigiendo tickets. Siguiendo en esta misma linea hay que ver cada cuanto sale una nueva versión y si hay versiones destinadas a generar una versiones estables del framework o si solo salen versiones cuando hay nuevas funcionalidades. Visto que vamos a tener que aprender a utilizar el framework hay que estudiar la calidad de la documentación de este, ver que tantos libros publicados (por ejemplo en Amazon) hay sobre el tema y si se ofrece algún tipo de certificación y/o capacitación.

Existencia de proyectos exitosos

Como nuestra intención es utilizar el FW para un producto que en algún momento deberá salir en producción seguramente no queramos ser los conejillos de indias. Si el FW es mínimamente serio entonces debe tener en su sitio web referencia a sistemas que están implementado con este. No es una mala idea de ser posible dar una mirada a estos y ver que tan bien funcionan. Sería excelente poder encontrar un blog de uno de estos proyectos en el cual se comente la experiencia durante el desarrollo del sistema.

Integración con la plataforma existente

Si el proyecto va a formar parte de un ecosistema más complejo entonces hay que tomar en cuenta las posibilidades de integración que tiene el FW y si estas son aceptables dentro de la arquitectura de nuestro producto. Por ejemplo si tenemos que interactuar con un sistema JEE es importante determinar que facilidades para invocar servicios EJB me da el FW. Claro está que siempre es posible desarrollar una capa que se encargue de la interacción, pero si el FW lo soporta nativamente no solo nos ahorramos trabajo sino que estamos reutilizando algo que está probado y utilizado por otros.

Curva de aprendizaje

Este punto hoy en día es engañoso debido a que los FW modernos tienen una curva de aprendizaje muy rápida inicialmente pero que para llegar a niveles de expertos hay que dedicarle mucho tiempo como a cualquier otro framework. Si ha esto le sumamos que la mayoría de los FW son OS con una documentación de mala calidad, que probablemente no exista soporte local y que para capacitarnos tengamos que viajar muchos kilómetros (por lo menos si están el el Sur como yo). Lo cual hace que la capacidad de aprendizaje del equipo sea un factor importante. En algunos casos para poder llegar a solucionar un problema será necesario estudiar el código fuente del FW. Si llegáramos a tener la suerte de que el presupuesto nos permitiera poder capacitar parte del equipo y/o de contratar soporte entonces no hay que dudarlo. Los dolores de cabeza y el tiempo que se puede ganar seguramente lo vale.

Probar, probar y probar

Inevitablemente para poder determinar el FW tendremos que destinar recursos y realizar algunas pruebas antes de poder llegar a una conclusión aceptable y fundamentada. No es necesario probar todos para estar tranquilo de que estamos utilizando el mejor. Cuando evaluemos recordar que estamos buscando el adecuado para el contexto donde hay que usarlo y no el mejor en general. Con un buen análisis previo probablemente no debamos probar más de dos o tres FW. Para que la prueba sea lo más comparativa posible debemos elegir un proyecto tipo y e implementarlo con con los FW que vayamos a evaluar..

¿Como comparamos los FW?

Para la comparación de los FW he utilizado una herramienta que a mi me ha ayudado a la hora de evaluar y puede ser de ayuda para ustedes también. La herramienta es una simple tabla en la que refleja la mayoría de los puntos vistos. En esta tabla calificaremos los FW dándoles un puntaje donde para cada punto tendríamos un máximo asignable y la suma de los máximos te todos los puntos suma 100. Al definir máximos diferentes por puntos estamos priorizando los puntos a evaluar de acuerdo a nuestro contexto. Por ejemplo si estamos en un caso en el cual tenemos una cantidad de sistemas existentes con los cuales debemos interactuar seguramente la capacidad de integración del FW sea uno de los puntos más importantes a evaluar mientras que si no tenemos que interactuar con otros sistemas, tenemos tiempos tiranos y un equipo ya formado con poca experiencia web entonces la curva de aprendizaje es un punto determinante en nuestra elección.

Para dejar en claro este punto vamos a ver un ejemplo:

La lectura que se pude hacer de la tabla anterior es que debemos realizar pruebas con el FW2 y el FW4 para definir cual de estos dos es el que vamos a utilizar. Gracias al estudio que realizamos redijimos por lo menos a la mitad la cantidad de FW a estudiar y tenemos una tabla que justifica nuestra elección.

Obviamente cuanta más filas le agreguemos a la tabla tendremos más información para justificar la elección.

Por las dudas aclaro que los máximos asignados son de ejemplos y ustedes deberían definir los suyos de acuerdo a sus necesidades.

En resumen…

En resumen a la hora de seleccionar un FW debemos seguir tres pasos:

1. Primero debemos evaluar los conocimientos del equipo y determinar que tipo de FW se quiere si uno que sea full-stack o solo presentación.

2. Una vez tengamos esto y sabiendo el lenguaje de preferencia podemos buscar el subconjunto de FW a evaluar. Para facilitar la evaluación confeccionamos una planilla como la vista en el punto anterior.

3. Por ultimo con los FW mejor ranqueados realizamos las pruebas las cuales se realizan con un mismo proyecto implementado en cada uno de los FW.

Luego de todo esto podremos saber cual es el FW a utilizar. Parece mucho trabajo, no? Si seguro que lo es, pero es la única forma de poder tomar una decisión minimizando el riesgo de equivocarnos… y cuando la decisiones tecnológicas de una empresa depende de nosotros es bueno tener herramientas para justificar nuestras decisiones y sobro todo para asegurarnos el éxito de nuestro trabajo.