Listado y cla­si­fi­ca­ción de los fra­me­wo­r­ks web

Las apli­ca­cio­nes de es­cri­to­rio están cada vez más presentes en Internet y los usuarios pueden acceder a ellas en los na­ve­ga­do­res en forma de apli­ca­cio­nes web. Un ejemplo clásico son los we­b­mai­le­rs y los bro­w­se­r­ga­mes o juegos de navegador. Asimismo, en el entorno em­pre­sa­rial se ha es­ta­ble­ci­do el “software como servicio” (conocido en inglés como Software as a Service o SaaS) como modelo de licencias. Hoy en día hay apli­ca­cio­nes web para la gestión de las re­la­cio­nes con los clientes (CRM), la gestión de me­r­ca­n­cías, ne­w­s­le­t­te­rs, la pla­ni­fi­ca­ción de proyectos, el registro de los horarios de los tra­ba­ja­do­res y la co­n­ta­bi­li­dad fi­na­n­cie­ra. Las pequeñas empresas, en especial, se be­ne­fi­cian de modelos de fa­c­tu­ra­ción variables en función de las ne­ce­si­da­des y de sistemas ce­n­tra­li­za­dos en Internet, lo que reduce los costes derivados del ma­n­te­ni­mie­n­to y la ad­mi­ni­s­tra­ción y garantiza la máxima fle­xi­bi­li­dad in­de­pe­n­die­n­te­me­n­te de la pla­ta­fo­r­ma o del di­s­po­si­ti­vo. 

En lo relativo al de­sa­rro­llo de apli­ca­cio­nes web, los pro­gra­ma­do­res recurren, por regla general, a los llamados web fra­me­wo­r­ks, pero ¿qué es un framework? Y, ¿en qué se di­fe­re­n­cian los fra­me­wo­r­ks es­pe­cí­fi­cos para apli­ca­cio­nes web?

Como fra­me­wo­r­ks (en español, in­frae­s­tru­c­tu­ras) se conoce a las es­tru­c­tu­ras de pro­gra­ma­ción que se utilizan como base para el de­sa­rro­llo de software, de manera que los de­sa­rro­lla­do­res evitan tener que empezar a escribir desde cero cada vez que programan un nuevo software, lo que re­su­l­ta­ría en una gran in­e­fi­ca­cia. Existen pro­pue­s­tas ya probadas en forma de códigos de programas para un gran número de funciones estándar en el ámbito del de­sa­rro­llo de software. Ge­ne­ra­l­me­n­te, en el marco de la pro­gra­ma­ció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 re­pre­se­n­ta una colección de di­fe­re­n­tes clases que cooperan entre sí y que determina, así, la es­tru­c­tu­ra básica de cada software que va a ser de­sa­rro­lla­do tomando a este framework como base. Cuando un framework sirve como marco esencial para apli­ca­cio­nes web, se puede hablar en este caso de fra­me­wo­r­ks para apli­ca­cio­nes web, cuya forma abreviada es framework web.

Como base para el de­sa­rro­llo de software, los web fra­me­wo­r­ks deben ofrecer es­tru­c­tu­ras sencillas y claras que faciliten su ma­n­te­ni­mie­n­to y que hagan posible que los de­sa­rro­lla­do­res puedan crear apli­ca­cio­nes web en un corto período de tiempo. Para cumplir con estas exi­ge­n­cias, muchos web fra­me­wo­r­ks remiten a tres pri­n­ci­pios básicos de diseño:

• Don’t repeat yourself (DRY): el principio de no repetirse tiene que ver con evitar la re­du­n­da­n­cia. La in­fo­r­ma­ción re­du­n­da­n­te como, por ejemplo, los códigos du­pli­ca­dos, que pueden evitarse, tienen un efecto negativo en el ma­n­te­ni­mie­n­to del software, ya que, en caso de tener que adaptar los fra­g­me­n­tos de código, los cambios deben llevarse a cabo en di­fe­re­n­tes 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 pa­r­si­mo­nia o de economía: si se encuentra más de una solución para una de­te­r­mi­na­da situación, se debería escoger aquella que requiera el menor número de hipótesis y variables. Para utilizar un framework o para so­lu­cio­nar un problema es­pe­cí­fi­co debería uti­li­zar­se la menor cantidad de código posible.

• Co­n­ve­n­tion over co­n­fi­gu­ra­tion: a mayor co­n­fi­gu­ra­ción mayor es el esfuerzo necesario para su manejo. Por el contrario, las co­n­ve­n­cio­nes ofrecen la po­si­bi­li­dad de reducir la co­m­ple­ji­dad. Por ello, los fra­me­wo­r­ks web deberían fijar pro­ce­di­mie­n­tos acre­di­ta­dos en forma de co­n­fi­gu­ra­ción pre­de­te­r­mi­na­da y ofrecer, op­cio­na­l­me­n­te, otras po­si­bi­li­da­des de co­n­fi­gu­ra­ción.

Si se tienen en cuenta estos pri­n­ci­pios de diseño, la apli­ca­ción de los web fra­me­wo­r­ks en el de­sa­rro­llo de software ofrece numerosas ventajas. Sin embargo, las ventajas de los fra­me­wo­r­ks también conllevan ciertos límites para los de­sa­rro­lla­do­res, quienes co­n­si­de­ran algunas re­s­tri­c­cio­nes es­tru­c­tu­ra­les como de­s­ve­n­ta­jas.

La uti­li­za­ción de web fra­me­wo­r­ks en el ámbito del de­sa­rro­llo de software está motivada por una reducción tanto del tiempo como de los costes. La idea fu­n­da­me­n­tal es, a este respecto, la re­uti­li­za­ción de los códigos. Esto está, sobre todo, re­la­cio­na­do con funciones básicas como las co­ne­xio­nes de la base de datos, las pla­n­ti­llas para crear páginas web, el al­ma­ce­na­mie­n­to en caché o las funciones relativas a la seguridad, que los fra­me­wo­r­ks ponen a di­s­po­si­ción en forma de módulos de código. Con ello, los esfuerzos derivados del de­sa­rro­llo de software se limitan al código de programa es­pe­cí­fi­co de la apli­ca­ción nueva. Debido a que la mayoría de web fra­me­wo­r­ks se plantean como software libre y gratuito, por lo general no generan gastos de ad­qui­si­ción.

Además, los fra­me­wo­r­ks fomentan la ge­ne­ra­ción de códigos fuente más limpios, ya que para las funciones estándar los de­sa­rro­lla­do­res pueden recurrir a co­m­po­ne­n­tes ya probados. Los fra­g­me­n­tos de código puestos a di­s­po­si­ción en los fra­me­wo­r­ks ex­pe­ri­me­n­tan, en su mayoría, numerosos ciclos de de­sa­rro­llo y se optimizan co­n­ti­nua­me­n­te gracias a una comunidad que actúa como testadora y colabora en las tareas de de­sa­rro­llo, lo que permite descubrir y eliminar las brechas de seguridad de los co­m­po­ne­n­tes nuevos con rapidez en el caso de proyectos de gran en­ve­r­ga­du­ra. En los foros de los proyectos, moderados en parte por equipos de soporte, tiene lugar, además, un in­te­r­ca­m­bio entre usuarios y de­sa­rro­lla­do­res.

En Internet hay una cantidad in­aba­r­ca­ble de fra­me­wo­r­ks para el de­sa­rro­llo web que se di­fe­re­n­cian entre sí tanto en lo co­rre­s­po­n­die­n­te al principio de es­tru­c­tu­ra­ción como al espectro de funciones, de forma que los proyectos de software pueden incluso requerir la apli­ca­ción de di­fe­re­n­tes web fra­me­wo­r­ks. En este sentido, los de­sa­rro­lla­do­res se en­cue­n­tran con el problema de tener que elegir la es­tru­c­tu­ra más adecuada para su proyecto. Con fre­cue­n­cia se opta por arreglos para adaptar los límites del framework al proyecto en cuestión. Debido a que los fra­me­wo­r­ks están co­n­ce­bi­dos como so­lu­cio­nes uni­ve­r­sa­les, los de­sa­rro­lla­do­res rara vez utilizan todas las funciones de la es­tru­c­tu­ra fijada. En función del volumen del framework, las apli­ca­cio­nes 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 de­s­ve­n­ta­jas es el hecho de que los de­sa­rro­lla­do­res tienden a depender de un fa­bri­ca­n­te de­te­r­mi­na­do o de una comunidad de de­sa­rro­lla­do­res y, en casos es­pe­cia­les, la uti­li­za­ción de fra­me­wo­r­ks está ligada a de­te­r­mi­na­das co­n­di­cio­nes de licencia. Además, pueden surgir problemas cuando se suspende el de­sa­rro­llo de los fra­me­wo­r­ks. Debido a que los de­sa­rro­lla­do­res tienen que fa­mi­lia­ri­zar­se con la creación de la es­tru­c­tu­ra del programa co­rre­s­po­n­die­n­te y con las po­si­bi­li­da­des de uso, se necesita cierto período de ada­p­ta­ción, aunque este se re­la­ti­vi­za por el ahorro de tiempo que conllevan las funciones y los  co­m­po­ne­n­tes de código pre­de­fi­ni­dos. En este sentido, los críticos hacen re­fe­re­n­cia al riesgo de que se pierdan los co­no­ci­mie­n­tos básicos, ya que los usuarios que programan basándose en los fu­n­da­me­n­tos de los fra­me­wo­r­ks ya no se ocupan tanto de los lenguajes de pro­gra­ma­ción que se usan.

Debido a que se puede acceder li­bre­me­n­te al código fuente de la mayoría de fra­me­wo­r­ks web, en principio todo el mundo puede fa­mi­lia­ri­zar­se con él. Las apli­ca­cio­nes para el uso em­pre­sa­rial que se de­sa­rro­llan sobre la base de co­m­po­ne­n­tes de código de acceso público suelen ser, a ojos de los hackers, más tra­n­s­pa­re­n­tes que las propias apps, que no tienen un código abierto.

De la misma forma que en el caso de los fra­me­wo­r­ks en general, los fra­me­wo­r­ks para apli­ca­cio­nes web también se di­fe­re­n­cian de las bi­blio­te­cas de programas (libraries) y de las he­rra­mie­n­tas de de­sa­rro­llo web. Mientras que las bi­blio­te­cas solo ofrecen funciones in­di­vi­dua­les, se puede co­n­si­de­rar a los fra­me­wo­r­ks como es­tru­c­tu­ras de pro­gra­ma­ción in­ter­ac­ti­vas para procesos estándar, es decir, apli­ca­cio­nes que no están del todo completas.

Los co­m­po­ne­n­tes básicos más im­po­r­ta­n­tes de un framework de software re­pre­se­n­tan clases que cooperan con los métodos asignados. A este respecto, se trata de bloques de código que describen las ca­ra­c­te­rí­s­ti­cas de los objetos de código y sus co­m­po­r­ta­mie­n­tos. Algunos de estos co­m­po­ne­n­tes son estáticos y, por lo tanto, in­va­ria­bles, pero hay otros que pueden ser adaptados por los usuarios, por ejemplo, so­bre­s­cri­bie­n­do métodos, lo que brinda la po­si­bi­li­dad de adaptar la es­tru­c­tu­ra del programa a una tarea es­pe­cí­fi­ca. Para los co­m­po­ne­n­tes flexibles de los fra­me­wo­r­ks se ha es­ta­ble­ci­do el nombre de “hot spots”, mientras que los estáticos reciben la no­me­n­cla­tu­ra de “frozen spots”.

Los fra­me­wo­r­ks web se guían, por lo general, por el concepto de inversión de control (en inglés, Inversion of Control (IoC). Este puede de­s­cri­bi­r­se como la apli­ca­ción del llamado principio de Hollywood en la pro­gra­ma­ción orientada a objetos: “Don’t call us, we call you!” (¡No nos llames, nosotros te llamamos!).

De manera si­m­pli­fi­ca­da, IoC significa que la re­s­po­n­sa­bi­li­dad para la ejecución de los programas no recae en los co­m­po­ne­n­tes que se de­sa­rro­llan 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 co­m­po­ne­n­tes que el usuario puede im­ple­me­n­tar y registrar en el framework y de los cuales puede disponer cuando los necesite, algo que se puede ilustrar con el principio de fu­n­cio­na­mie­n­to de los castings de Hollywood, es decir, “ahora que te conocemos, nos pondremos en contacto contigo cuando te ne­ce­si­te­mos.”

Para poder ejecutar esta función central de control, los fra­me­wo­r­ks de­te­r­mi­nan una interfaz especial que tiene que ser im­ple­me­n­ta­da por todos los co­m­po­ne­n­tes. Por medio de este principio de diseño, el framework siempre está en situación de poner en marcha los co­m­po­ne­n­tes que se crean y de im­ple­me­n­tar métodos de re­tro­lla­ma­da (callback). Estos permiten que el framework transmita datos a los co­m­po­ne­n­tes o provoque un co­m­po­r­ta­mie­n­to de­te­r­mi­na­do por medio de las llamadas a métodos. Mientras en el de­sa­rro­llo de software clásico las clases y sus de­pe­n­de­n­cias ya se fijan durante la co­m­pi­la­ción, la inversión de control de un software permite generar objetos de manera dinámica durante el tiempo de ejecución.   

En el de­sa­rro­llo 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 De­pe­n­de­n­cy Injection (DI) o De­pe­n­de­n­cy Lookup.

La mayoría de fra­me­wo­r­ks para apli­ca­cio­nes web se basa en un patrón de ar­qui­te­c­tu­ra de­no­mi­na­do Model-View-Co­n­tro­ller (MVC) o Modelo-Vista-Co­n­tro­la­dor en español. Este hace re­fe­re­n­cia a la se­pa­ra­ción estricta entre lógica de apli­ca­ción y capa de pre­se­n­ta­ción y, a la hora de de­sa­rro­llar software, lo divide en los sectores modelo (modelo de datos), vista (pre­se­n­ta­ción) y co­n­tro­la­dor (control de programa).

• Modelo de datos: el modelo es la parte de los fra­me­wo­r­ks que contiene tanto los datos que se presentan como la lógica de la apli­ca­ción y las normas. La vi­sua­li­za­ción de los datos y las pro­pue­s­tas de cambio se llevarán a cabo a través de los métodos provistos para estos casos.

• Pre­se­n­ta­ción: la tarea básica de la vista es la re­pre­se­n­ta­ció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 (pu­l­sa­cio­nes de teclas, clics) y tra­n­s­mi­ti­r­las al co­n­tro­la­dor.

• Control de programa: el co­n­tro­la­dor 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, tra­n­s­mi­tie­n­do los datos al modelo u ordenando cambios en la vista.

El objetivo del patrón de ar­qui­te­c­tu­ra MVC es un proyecto de programa ca­ra­c­te­ri­za­do por la fle­xi­bi­li­dad. La se­pa­ra­ción entre lógica de apli­ca­ción y capa de pre­se­n­ta­ción debe facilitar la rea­li­za­ción posterior de cambios y ex­te­n­sio­nes así como la re­uti­li­za­ción de cada uno de los co­m­po­ne­n­tes. De esta manera se reducen, por ejemplo, los esfuerzos de pro­gra­ma­ción para adaptar el software a las di­fe­re­n­tes pla­ta­fo­r­mas (Windows, Mac, Linux) o para uti­li­zar­lo como apli­ca­ción web, ya que, en co­n­se­cue­n­cia, solo se tienen que adaptar el co­n­tro­la­dor 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 fra­me­wo­r­ks basados en Java. En este modelo, la página JSP, el servlet y el Java Bean co­rre­s­po­n­den a la vista, al co­n­tro­la­dor y al modelo re­s­pe­c­ti­va­me­n­te.

El mercado de las apli­ca­cio­nes web es muy variado. Las apps di­s­po­ni­bles en el navegador se di­fe­re­n­cian entre sí, en función del ámbito de apli­ca­ción y del espectro de funciones, no solo en cuanto a tamaño y apa­rie­n­cia, sino también en lo referente al diseño del software. El motivo para ello es la di­ve­r­si­dad de los fra­me­wo­r­ks web di­s­po­ni­bles, basados en di­fe­re­n­tes te­c­no­lo­gías y que siguen di­fe­re­n­tes pla­n­tea­mie­n­tos en el diseño de software. En co­n­tra­po­si­ción, también funcionan los enfoques de una única página, múltiple, del lado del servidor y del cliente, así como los fra­me­wo­r­ks web basados en acciones y en co­m­po­ne­n­tes.

Las apli­ca­cio­nes de página múltiple están formadas por varias páginas HTML que, por regla general, se abren al in­tro­du­cir la co­rre­s­po­n­die­n­te dirección URL en el navegador y que están co­ne­c­ta­das entre sí mediante hi­pe­r­ví­ncu­los. La interfaz de usuario de una apli­ca­ció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 es­tru­c­tu­rar­se a través de paneles, pestañas o tarjetas de registro, pero la dirección URL de una apli­ca­ción de página única no se modifica durante la na­ve­ga­ción.

El modelo de pro­gra­ma­ción de una apli­ca­ción web clásica se co­rre­s­po­n­de con el de la World Wide Web, cuya ar­qui­te­c­tu­ra está marcada por el Hypertext Transfer Protocol (HTTP). Cuando un usuario accede a una apli­ca­ción web, en ello pa­r­ti­ci­pan tanto uno o varios se­r­vi­do­res como un programa cliente, por lo general, un navegador web. En función de cómo esté diseñada la co­mu­ni­ca­ción entre el servidor y el cliente se puede hablar de apli­ca­cio­nes centradas en el servidor (server-centric) o en el cliente (client-centric):

• Client-centric: si, al iniciar una apli­ca­ción, la interfaz de usuario HTML, incluida la lógica de la apli­ca­ción, se carga en su totalidad en el cliente, se puede hablar de apli­ca­cio­nes centradas en el cliente. Los cambios en la interfaz a causa de las entradas del usuario son rea­li­za­dos por medio de lenguajes de pro­gra­ma­ción del lado del cliente, como por ejemplo Ja­va­S­cri­pt. Un enfoque de diseño como tal es el que se re­co­mie­n­da para apli­ca­cio­nes en las que los usuarios trabajan durante un espacio de tiempo pro­lo­n­ga­do en la misma vista, ya que el servidor vuelve a cargar los datos de la interfaz. El enfoque o pla­n­tea­mie­n­to del lado del cliente se utiliza para de­sa­rro­llar apli­ca­cio­nes de página única y es seguido por fra­me­wo­r­ks de Ja­va­S­cri­pt como AngularJS o EmberJS.

• Server-centric: en el caso de las apli­ca­cio­nes centradas en el servidor, la lógica de la apli­ca­ción permanece en el servidor, que crea la interfaz de usuario y la entrega a los clientes para su pre­se­n­ta­ción. Para llevar a cabo cambios en dicha interfaz, se puede recurrir a lenguajes de pro­gra­ma­ción del lado del servidor y, en gran parte, dichos cambios se llevan a cabo con in­de­pe­n­de­n­cia de las in­se­gu­ri­da­des del lado del cliente. Este pla­n­tea­mie­n­to se aplica, en general, en las apli­ca­cio­nes de página múltiple, en las que se puede acceder a las diversas vistas de página en función de las ne­ce­si­da­des del servidor. Un diseño de software de tales ca­ra­c­te­rí­s­ti­cas está ligado a tiempos de carga más pro­lo­n­ga­dos, aunque reduce los re­que­ri­mie­n­tos en el di­s­po­si­ti­vo 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 rea­li­za­ción de este pla­n­tea­mie­n­to del lado del servidor es el que se da, por ejemplo, en fra­me­wo­r­ks como Django, Zend y Ruby on Rails.

Un enfoque centrado en el servidor está presente, sobre todo, en fra­me­wo­r­ks de­sa­rro­lla­dos para crear apli­ca­cio­nes web clásicas con una es­tru­c­tu­ra de página múltiple e in­te­r­fa­ces HTML clásicas. En estas apli­ca­cio­nes solo se muestra la interfaz, que, por regla general, utiliza el navegador, lo que hace que pueden eje­cu­tar­se in­de­pe­n­die­n­te­me­n­te del sistema operativo o navegador web que se use. El servidor se encarga de la lógica de control siguiendo el esquema de co­mu­ni­ca­ción de solicitud-respuesta de HTTP. Las apli­ca­cio­nes web centradas en el cliente también reciben el nombre de Rich Clients o Rich Internet Ap­pli­ca­tio­ns (RIA). Este tipo de apli­ca­cio­nes im­ple­me­n­tan la interfaz de usuario y la lógica de apli­ca­ción en el cliente, la cual se cargará co­m­ple­ta­me­n­te cuando dichas apli­ca­cio­nes se inicien. Al contrario de lo que ocurre con las apli­ca­cio­nes 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 ac­ce­si­bi­li­dad en línea y el acceso al disco duro, usuales en las apli­ca­cio­nes de es­cri­to­rio.

En el plano del control de las apli­ca­cio­nes, los web fra­me­wo­r­ks pueden dividirse en dos clases. Mientras que los fra­me­wo­r­ks web basados en acciones (action-based) re­pro­du­cen el modelo de solicitud/respuesta (request/response) en el que se basa HTTP, los web fra­me­wo­r­ks basados en co­m­po­ne­n­tes (component-based) pre­s­ci­n­den de él. Fra­me­wo­r­ks web basados en acciones: en los entornos de trabajo web basados en acciones, el co­n­tro­la­dor co­n­s­ti­tu­ye una instancia central que se hace cargo de las so­li­ci­tu­des de los clientes, las valida y pone en marcha una acción. Para cada posible acción, los de­sa­rro­lla­do­res de apps tienen que crear pre­via­me­n­te un objeto de software que contenga la co­rre­s­po­n­die­n­te lógica de la apli­ca­ción y dicho objeto puede, por lo general, deducirse de clases ab­s­tra­c­tas. Una vez fi­na­li­za­da la acción, el co­n­tro­la­dor actualiza el modelo de datos y transmite el resultado a la vista, que genera la respuesta y la manda de vuelta al cliente. Los fra­me­wo­r­ks web basados en acciones se apoyan en el patrón MVC y reciben la no­me­n­cla­tu­ra de “request-based” debido a la estricta apli­ca­ción del esquema request/response. Sus re­pre­se­n­ta­n­tes clásicos son:

• Django

• Ruby on Rails

• Symfony

• Spring MVC

• Co­deI­g­ni­ter

Debido a que los de­sa­rro­lla­do­res de apli­ca­cio­nes son los en­ca­r­ga­dos de definir en detalle las posibles acciones de los fra­me­wo­r­ks web basados en acciones, se habla de enfoque white box. Este po­si­bi­li­ta que los de­sa­rro­lla­do­res tengan más margen de acción, aunque requiere una mejor co­m­pre­n­sión de los web fra­me­wo­r­ks co­rre­s­po­n­die­n­tes, ya que los de­sa­rro­lla­do­res son los re­s­po­n­sa­bles de la creación de HTML, CSS y Ja­va­S­cri­pt. Fra­me­wo­r­ks web basados en co­m­po­ne­n­tes: en co­n­tra­po­si­ción al enfoque co­n­tro­la­do por acciones, los web fra­me­wo­r­ks co­n­tro­la­dos por co­m­po­ne­n­tes pre­s­ci­n­den del patrón solicitud/respuesta (request/response) en el que se basa HTTP y en el que la interfaz de usuario de una apli­ca­ción web es co­n­te­m­pla­da como una re­co­pi­la­ción de co­m­po­ne­n­tes. Para cada uno de estos co­m­po­ne­n­tes, que están unidos del lado del servidor con objetos de software, se definen de­te­r­mi­na­das reac­cio­nes durante el de­sa­rro­llo de la apli­ca­ción web. Estas dan lugar a ciertos eventos que se resuelven por medio de una in­ter­ac­ción del usuario con los co­m­po­ne­n­tes. En este caso también se puede hablar de fra­me­wo­r­ks web co­n­tro­la­dos por eventos. Sus re­pre­se­n­ta­n­tes clásicos son:

• Lift

• Apache Tapestry

• Ja­va­Se­r­ver Faces

• Apache Wicket

La idea básica que se esconde tras el enfoque basado en co­m­po­ne­n­tes es la de agrupar acciones similares. El co­m­po­ne­n­te Ac­cou­n­t­Co­n­tro­ller re­pre­se­n­ta, por ejemplo, acciones como login, logout o ge­tA­c­cou­nt. Un objeto de software puede ser re­s­po­n­sa­ble de más de una acción y, a este respecto, los web fra­me­wo­r­ks basados en co­m­po­ne­n­tes ofrecen, por lo general, una gran selección de co­m­po­ne­n­tes re­uti­li­za­bles que ocultan los detalles del esquema request/response a los de­sa­rro­lla­do­res de apps. En este contexto se puede hablar de black box. Este tipo de fra­me­wo­r­ks web son apro­pia­dos para los de­sa­rro­lla­do­res que quieren basarse, en primer lugar, en co­m­po­ne­n­tes pre­de­fi­ni­dos. Quien quiera tener mayores li­be­r­ta­des con respecto a HTTP, HTML, CSS y Ja­va­S­cri­pt, es más co­n­ve­nie­n­te que opte por los web fra­me­wo­r­ks basados en acciones.

Debido a la gran in­flue­n­cia de los fra­me­wo­r­ks en las funciones y po­si­bi­li­da­des de diseño de las apli­ca­cio­nes web y en el flujo de trabajo durante el de­sa­rro­llo 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 co­no­ci­mie­n­tos previos ad­qui­ri­dos.

Las cue­s­tio­nes fu­n­da­me­n­ta­les a este respecto están re­la­cio­na­das con el tipo de apli­ca­ción y con la ar­qui­te­c­tu­ra deseada (centrada en el servidor o en el cliente), ambos aspectos con co­n­se­cue­n­cias directas sobre el control y la facilidad de manejo de las web apps.  

Los co­no­ci­mie­n­tos li­n­güí­s­ti­cos y la di­s­po­ni­bi­li­dad de la in­frae­s­tru­c­tu­ra necesaria también co­n­s­ti­tu­yen un punto de partida para la búsqueda del framework web adecuado. Es­pe­cia­l­me­n­te en el caso de los lenguajes de pro­gra­ma­ción más ha­bi­tua­les como PHP (p.ej., Zend, Symfony, CakePHP o Co­deI­g­ni­ter), Java (p.ej., Ja­va­Se­r­ver Faces o Apache Wicket) o Python (p.ej., Django), se puede recurrir a una gran selección de web fra­me­wo­r­ks bien do­cu­me­n­ta­dos. La po­pu­la­ri­dad de Ruby en el marco del de­sa­rro­llo web tiene que ver, sobre todo, con el famoso web framework Ruby on Rails. Los web fra­me­wo­r­ks centrados en el cliente se suelen apoyar en el lenguaje de scripts Ja­va­S­cri­pt.

Los de­sa­rro­lla­do­res que en el pasado se dedicaban bá­si­ca­me­n­te a programar apli­ca­cio­nes de es­cri­to­rio se en­cue­n­tran menos cómodos cuando utilizan el modelo de pro­gra­ma­ción del esquema request/response de aquellos entornos de trabajo basados en acciones que los de­sa­rro­lla­do­res web clásicos. En este caso puede ser un buen punto de partida usar los fra­me­wo­r­ks web basados en co­m­po­ne­n­tes.