Listado y clasificación de los frameworks web

Las aplicaciones de escritorio están cada vez más presentes en Internet y los usuarios pueden acceder a ellas en los navegadores en forma de aplicaciones web. Un ejemplo clásico son los webmailers y los browsergames o juegos de navegador. Asimismo, en el entorno empresarial se ha establecido el “software como servicio” (conocido en inglés como Software as a Service o SaaS) como modelo de licencias. Hoy en día hay aplicaciones web para la gestión de las relaciones con los clientes (CRM), la gestión de mercancías, newsletters, la planificación de proyectos, el registro de los horarios de los trabajadores y la contabilidad financiera. Las pequeñas empresas, en especial, se benefician de modelos de facturación variables en función de las necesidades y de sistemas centralizados en Internet, lo que reduce los costes derivados del mantenimiento y la administración y garantiza la máxima flexibilidad independientemente de la plataforma o del dispositivo. 

En lo relativo al desarrollo de aplicaciones web, los programadores recurren, por regla general, a los llamados web frameworks, pero ¿qué es un framework? Y, ¿en qué se diferencian los frameworks específicos para aplicaciones web?

Como frameworks (en español, infraestructuras) se conoce a las estructuras de programación que se utilizan como base para el desarrollo de software, de manera que los desarrolladores evitan tener que empezar a escribir desde cero cada vez que programan un nuevo software, lo que resultaría en una gran ineficacia. Existen propuestas ya probadas en forma de códigos de programas para un gran número de funciones estándar en el ámbito del desarrollo de software. Generalmente, en el marco de la programación orientada a objetos entran en acción clases a las que se recurre en calidad de proyectos de ejecución de objetos de software. En general, un framework representa una colección de diferentes clases que cooperan entre sí y que determina, así, la estructura básica de cada software que va a ser desarrollado tomando a este framework como base. Cuando un framework sirve como marco esencial para aplicaciones web, se puede hablar en este caso de frameworks para aplicaciones web, cuya forma abreviada es framework web.

Como base para el desarrollo de software, los web frameworks deben ofrecer estructuras sencillas y claras que faciliten su mantenimiento y que hagan posible que los desarrolladores puedan crear aplicaciones web en un corto período de tiempo. Para cumplir con estas exigencias, muchos web frameworks remiten a tres principios básicos de diseño:

• Don’t repeat yourself (DRY): el principio de no repetirse tiene que ver con evitar la redundancia. La información redundante como, por ejemplo, los códigos duplicados, que pueden evitarse, tienen un efecto negativo en el mantenimiento del software, ya que, en caso de tener que adaptar los fragmentos de código, los cambios deben llevarse a cabo en diferentes partes del código del programa.

• Keep it short and simple (KISS): a un problema, una solución. Este es el principio básico del paradigma KISS, que está orientado al principio de parsimonia o de economía: si se encuentra más de una solución para una determinada situación, se debería escoger aquella que requiera el menor número de hipótesis y variables. Para utilizar un framework o para solucionar un problema específico debería utilizarse la menor cantidad de código posible.

• Convention over configuration: a mayor configuración mayor es el esfuerzo necesario para su manejo. Por el contrario, las convenciones ofrecen la posibilidad de reducir la complejidad. Por ello, los frameworks web deberían fijar procedimientos acreditados en forma de configuración predeterminada y ofrecer, opcionalmente, otras posibilidades de configuración.

Si se tienen en cuenta estos principios de diseño, la aplicación de los web frameworks en el desarrollo de software ofrece numerosas ventajas. Sin embargo, las ventajas de los frameworks también conllevan ciertos límites para los desarrolladores, quienes consideran algunas restricciones estructurales como desventajas.

La utilización de web frameworks en el ámbito del desarrollo de software está motivada por una reducción tanto del tiempo como de los costes. La idea fundamental es, a este respecto, la reutilización de los códigos. Esto está, sobre todo, relacionado con funciones básicas como las conexiones de la base de datos, las plantillas para crear páginas web, el almacenamiento en caché o las funciones relativas a la seguridad, que los frameworks ponen a disposición en forma de módulos de código. Con ello, los esfuerzos derivados del desarrollo de software se limitan al código de programa específico de la aplicación nueva. Debido a que la mayoría de web frameworks se plantean como software libre y gratuito, por lo general no generan gastos de adquisición.

Además, los frameworks fomentan la generación de códigos fuente más limpios, ya que para las funciones estándar los desarrolladores pueden recurrir a componentes ya probados. Los fragmentos de código puestos a disposición en los frameworks experimentan, en su mayoría, numerosos ciclos de desarrollo y se optimizan continuamente gracias a una comunidad que actúa como testadora y colabora en las tareas de desarrollo, lo que permite descubrir y eliminar las brechas de seguridad de los componentes nuevos con rapidez en el caso de proyectos de gran envergadura. En los foros de los proyectos, moderados en parte por equipos de soporte, tiene lugar, además, un intercambio entre usuarios y desarrolladores.

En Internet hay una cantidad inabarcable de frameworks para el desarrollo web que se diferencian entre sí tanto en lo correspondiente al principio de estructuración como al espectro de funciones, de forma que los proyectos de software pueden incluso requerir la aplicación de diferentes web frameworks. En este sentido, los desarrolladores se encuentran con el problema de tener que elegir la estructura más adecuada para su proyecto. Con frecuencia se opta por arreglos para adaptar los límites del framework al proyecto en cuestión. Debido a que los frameworks están concebidos como soluciones universales, los desarrolladores rara vez utilizan todas las funciones de la estructura fijada. En función del volumen del framework, las aplicaciones pueden contener más código del necesario, por lo que se puede hablar en este caso de sobrecarga de código.

Otra de las desventajas es el hecho de que los desarrolladores tienden a depender de un fabricante determinado o de una comunidad de desarrolladores y, en casos especiales, la utilización de frameworks está ligada a determinadas condiciones de licencia. Además, pueden surgir problemas cuando se suspende el desarrollo de los frameworks. Debido a que los desarrolladores tienen que familiarizarse con la creación de la estructura del programa correspondiente y con las posibilidades de uso, se necesita cierto período de adaptación, aunque este se relativiza por el ahorro de tiempo que conllevan las funciones y los  componentes de código predefinidos. En este sentido, los críticos hacen referencia al riesgo de que se pierdan los conocimientos básicos, ya que los usuarios que programan basándose en los fundamentos de los frameworks ya no se ocupan tanto de los lenguajes de programación que se usan.

Debido a que se puede acceder libremente al código fuente de la mayoría de frameworks web, en principio todo el mundo puede familiarizarse con él. Las aplicaciones para el uso empresarial que se desarrollan sobre la base de componentes de código de acceso público suelen ser, a ojos de los hackers, más transparentes que las propias apps, que no tienen un código abierto.

De la misma forma que en el caso de los frameworks en general, los frameworks para aplicaciones web también se diferencian de las bibliotecas de programas (libraries) y de las herramientas de desarrollo web. Mientras que las bibliotecas solo ofrecen funciones individuales, se puede considerar a los frameworks como estructuras de programación interactivas para procesos estándar, es decir, aplicaciones que no están del todo completas.

Los componentes básicos más importantes de un framework de software representan clases que cooperan con los métodos asignados. A este respecto, se trata de bloques de código que describen las características de los objetos de código y sus comportamientos. Algunos de estos componentes son estáticos y, por lo tanto, invariables, pero hay otros que pueden ser adaptados por los usuarios, por ejemplo, sobrescribiendo métodos, lo que brinda la posibilidad de adaptar la estructura del programa a una tarea específica. Para los componentes flexibles de los frameworks se ha establecido el nombre de “hot spots”, mientras que los estáticos reciben la nomenclatura de “frozen spots”.

Los frameworks web se guían, por lo general, por el concepto de inversión de control (en inglés, Inversion of Control (IoC). Este puede describirse como la aplicación del llamado principio de Hollywood en la programación orientada a objetos: “Don’t call us, we call you!” (¡No nos llames, nosotros te llamamos!).

De manera simplificada, IoC significa que la responsabilidad para la ejecución de los programas no recae en los componentes que se desarrollan y se ejecutan basándose en el framework, sino en el propio framework, el cual adopta la función de programa principal que coordina el flujo de control. También hay otros componentes que el usuario puede implementar y registrar en el framework y de los cuales puede disponer cuando los necesite, algo que se puede ilustrar con el principio de funcionamiento de los castings de Hollywood, es decir, “ahora que te conocemos, nos pondremos en contacto contigo cuando te necesitemos.”

Para poder ejecutar esta función central de control, los frameworks determinan una interfaz especial que tiene que ser implementada por todos los componentes. Por medio de este principio de diseño, el framework siempre está en situación de poner en marcha los componentes que se crean y de implementar métodos de retrollamada (callback). Estos permiten que el framework transmita datos a los componentes o provoque un comportamiento determinado por medio de las llamadas a métodos. Mientras en el desarrollo de software clásico las clases y sus dependencias ya se fijan durante la compilación, la inversión de control de un software permite generar objetos de manera dinámica durante el tiempo de ejecución.   

En el desarrollo web, IoC tiene el estatus de un concepto de diseño general. A la hora de aplicarse entran en juego patrones de diseño como Dependency Injection (DI) o Dependency Lookup.

La mayoría de frameworks para aplicaciones web se basa en un patrón de arquitectura denominado Model-View-Controller (MVC) o Modelo-Vista-Controlador en español. Este hace referencia a la separación estricta entre lógica de aplicación y capa de presentación y, a la hora de desarrollar software, lo divide en los sectores modelo (modelo de datos), vista (presentación) y controlador (control de programa).

• Modelo de datos: el modelo es la parte de los frameworks que contiene tanto los datos que se presentan como la lógica de la aplicación y las normas. La visualización de los datos y las propuestas de cambio se llevarán a cabo a través de los métodos provistos para estos casos.

• Presentación: la tarea básica de la vista es la representación de los datos que facilita el modelo. Para ello, hace uso de métodos para preguntar por el estado del modelo, que será el que le informe sobre los cambios. Otra de las tareas de la vista es hacerse cargo de las entradas del usuario (pulsaciones de teclas, clics) y transmitirlas al controlador.

• Control de programa: el controlador funciona como interfaz entre el modelo y la vista. Para ello gestiona una o varias vistas, analiza las entradas del usuario y reacciona conforme a ello, por ejemplo, transmitiendo los datos al modelo u ordenando cambios en la vista.

El objetivo del patrón de arquitectura MVC es un proyecto de programa caracterizado por la flexibilidad. La separación entre lógica de aplicación y capa de presentación debe facilitar la realización posterior de cambios y extensiones así como la reutilización de cada uno de los componentes. De esta manera se reducen, por ejemplo, los esfuerzos de programación para adaptar el software a las diferentes plataformas (Windows, Mac, Linux) o para utilizarlo como aplicación web, ya que, en consecuencia, solo se tienen que adaptar el controlador y la vista.

A este respecto y en forma de JSP (Java Server Pages) Model 2 entra en acción un patrón de diseño que se apoya en MVC también en el caso de los web frameworks basados en Java. En este modelo, la página JSP, el servlet y el Java Bean corresponden a la vista, al controlador y al modelo respectivamente.

El mercado de las aplicaciones web es muy variado. Las apps disponibles en el navegador se diferencian entre sí, en función del ámbito de aplicación y del espectro de funciones, no solo en cuanto a tamaño y apariencia, sino también en lo referente al diseño del software. El motivo para ello es la diversidad de los frameworks web disponibles, basados en diferentes tecnologías y que siguen diferentes planteamientos en el diseño de software. En contraposición, también funcionan los enfoques de una única página, múltiple, del lado del servidor y del cliente, así como los frameworks web basados en acciones y en componentes.

Las aplicaciones de página múltiple están formadas por varias páginas HTML que, por regla general, se abren al introducir la correspondiente dirección URL en el navegador y que están conectadas entre sí mediante hipervínculos. La interfaz de usuario de una aplicación de página única, por su parte, consta de una página HTML en la que convergen todas las entradas del usuario. Esta puede estructurarse a través de paneles, pestañas o tarjetas de registro, pero la dirección URL de una aplicación de página única no se modifica durante la navegación.

El modelo de programación de una aplicación web clásica se corresponde con el de la World Wide Web, cuya arquitectura está marcada por el Hypertext Transfer Protocol (HTTP). Cuando un usuario accede a una aplicación web, en ello participan tanto uno o varios servidores como un programa cliente, por lo general, un navegador web. En función de cómo esté diseñada la comunicación entre el servidor y el cliente se puede hablar de aplicaciones centradas en el servidor (server-centric) o en el cliente (client-centric):

• Client-centric: si, al iniciar una aplicación, la interfaz de usuario HTML, incluida la lógica de la aplicación, se carga en su totalidad en el cliente, se puede hablar de aplicaciones centradas en el cliente. Los cambios en la interfaz a causa de las entradas del usuario son realizados por medio de lenguajes de programación del lado del cliente, como por ejemplo JavaScript. Un enfoque de diseño como tal es el que se recomienda para aplicaciones en las que los usuarios trabajan durante un espacio de tiempo prolongado en la misma vista, ya que el servidor vuelve a cargar los datos de la interfaz. El enfoque o planteamiento del lado del cliente se utiliza para desarrollar aplicaciones de página única y es seguido por frameworks de JavaScript como AngularJS o EmberJS.

• Server-centric: en el caso de las aplicaciones centradas en el servidor, la lógica de la aplicación permanece en el servidor, que crea la interfaz de usuario y la entrega a los clientes para su presentación. Para llevar a cabo cambios en dicha interfaz, se puede recurrir a lenguajes de programación del lado del servidor y, en gran parte, dichos cambios se llevan a cabo con independencia de las inseguridades del lado del cliente. Este planteamiento se aplica, en general, en las aplicaciones de página múltiple, en las que se puede acceder a las diversas vistas de página en función de las necesidades del servidor. Un diseño de software de tales características está ligado a tiempos de carga más prolongados, aunque reduce los requerimientos en el dispositivo del cliente. En algunas apps también se puede evitar, en este sentido, la permuta de la lógica de control por motivos de seguridad. La realización de este planteamiento del lado del servidor es el que se da, por ejemplo, en frameworks como Django, Zend y Ruby on Rails.

Un enfoque centrado en el servidor está presente, sobre todo, en frameworks desarrollados para crear aplicaciones web clásicas con una estructura de página múltiple e interfaces HTML clásicas. En estas aplicaciones solo se muestra la interfaz, que, por regla general, utiliza el navegador, lo que hace que pueden ejecutarse independientemente del sistema operativo o navegador web que se use. El servidor se encarga de la lógica de control siguiendo el esquema de comunicación de solicitud-respuesta de HTTP.

Las aplicaciones web centradas en el cliente también reciben el nombre de Rich Clients o Rich Internet Applications (RIA). Este tipo de aplicaciones implementan la interfaz de usuario y la lógica de aplicación en el cliente, la cual se cargará completamente cuando dichas aplicaciones se inicien. Al contrario de lo que ocurre con las aplicaciones web clásicas, al optar por el enfoque del lado del cliente se pueden llevar a la práctica otro tipo de funciones, como el control por drag and drop, la accesibilidad en línea y el acceso al disco duro, usuales en las aplicaciones de escritorio.

En el plano del control de las aplicaciones, los web frameworks pueden dividirse en dos clases. Mientras que los frameworks web basados en acciones (action-based) reproducen el modelo de solicitud/respuesta (request/response) en el que se basa HTTP, los web frameworks basados en componentes (component-based) prescinden de él.

Frameworks web basados en acciones: en los entornos de trabajo web basados en acciones, el controlador constituye una instancia central que se hace cargo de las solicitudes de los clientes, las valida y pone en marcha una acción. Para cada posible acción, los desarrolladores de apps tienen que crear previamente un objeto de software que contenga la correspondiente lógica de la aplicación y dicho objeto puede, por lo general, deducirse de clases abstractas.

Una vez finalizada la acción, el controlador actualiza el modelo de datos y transmite el resultado a la vista, que genera la respuesta y la manda de vuelta al cliente.

Los frameworks web basados en acciones se apoyan en el patrón MVC y reciben la nomenclatura de “request-based” debido a la estricta aplicación del esquema request/response. Sus representantes clásicos son:

• Django

• Ruby on Rails

• Symfony

• Spring MVC

• CodeIgniter

Debido a que los desarrolladores de aplicaciones son los encargados de definir en detalle las posibles acciones de los frameworks web basados en acciones, se habla de enfoque white box. Este posibilita que los desarrolladores tengan más margen de acción, aunque requiere una mejor comprensión de los web frameworks correspondientes, ya que los desarrolladores son los responsables de la creación de HTML, CSS y JavaScript.

Frameworks web basados en componentes: en contraposición al enfoque controlado por acciones, los web frameworks controlados por componentes prescinden del patrón solicitud/respuesta (request/response) en el que se basa HTTP y en el que la interfaz de usuario de una aplicación web es contemplada como una recopilación de componentes. Para cada uno de estos componentes, que están unidos del lado del servidor con objetos de software, se definen determinadas reacciones durante el desarrollo de la aplicación web. Estas dan lugar a ciertos eventos que se resuelven por medio de una interacción del usuario con los componentes. En este caso también se puede hablar de frameworks web controlados por eventos. Sus representantes clásicos son:

• Lift

• Apache Tapestry

• JavaServer Faces

• Apache Wicket

La idea básica que se esconde tras el enfoque basado en componentes es la de agrupar acciones similares. El componente AccountController representa, por ejemplo, acciones como login, logout o getAccount. Un objeto de software puede ser responsable de más de una acción y, a este respecto, los web frameworks basados en componentes ofrecen, por lo general, una gran selección de componentes reutilizables que ocultan los detalles del esquema request/response a los desarrolladores de apps. En este contexto se puede hablar de black box. Este tipo de frameworks web son apropiados para los desarrolladores que quieren basarse, en primer lugar, en componentes predefinidos. Quien quiera tener mayores libertades con respecto a HTTP, HTML, CSS y JavaScript, es más conveniente que opte por los web frameworks basados en acciones.

Debido a la gran influencia de los frameworks en las funciones y posibilidades de diseño de las aplicaciones web y en el flujo de trabajo durante el desarrollo de las mismas, el proceso de trabajo comienza, por regla general, con la selección del marco de programa adecuado. En ello, se tienen que tener en cuenta el proyecto de software y los conocimientos previos adquiridos.

Las cuestiones fundamentales a este respecto están relacionadas con el tipo de aplicación y con la arquitectura deseada (centrada en el servidor o en el cliente), ambos aspectos con consecuencias directas sobre el control y la facilidad de manejo de las web apps.  

Los conocimientos lingüísticos y la disponibilidad de la infraestructura necesaria también constituyen un punto de partida para la búsqueda del framework web adecuado. Especialmente en el caso de los lenguajes de programación más habituales como PHP (p.ej., Zend, Symfony, CakePHP o CodeIgniter), Java (p.ej., JavaServer Faces o Apache Wicket) o Python (p.ej., Django), se puede recurrir a una gran selección de web frameworks bien documentados. La popularidad de Ruby en el marco del desarrollo web tiene que ver, sobre todo, con el famoso web framework Ruby on Rails. Los web frameworks centrados en el cliente se suelen apoyar en el lenguaje de scripts JavaScript.

Los desarrolladores que en el pasado se dedicaban básicamente a programar aplicaciones de escritorio se encuentran menos cómodos cuando utilizan el modelo de programación del esquema request/response de aquellos entornos de trabajo basados en acciones que los desarrolladores web clásicos. En este caso puede ser un buen punto de partida usar los frameworks web basados en componentes.