Framework – In­tro­du­zio­ne e clas­si­fi­ca­zio­ne

In rete si trovano sempre più ap­pli­ca­zio­ni, che vengono messe a di­spo­si­zio­ne degli utenti sotto forma di ap­pli­ca­zio­ni web da aprire dal browser. Rientrano tra gli esempi classici di questo tipo i web mailer o i giochi per il browser. Anche nel contesto aziendale si è affermato il modello di licenza Software as a Service: ci sono ap­pli­ca­zio­ni web per i processi CRM (Customer Re­la­tion­ship Ma­na­ge­ment), per il sistema di gestione della merce, per new­slet­ter, per la pia­ni­fi­ca­zio­ne dei progetti, per la re­gi­stra­zio­ne del tempo di lavoro dei di­pen­den­ti o per la con­ta­bi­li­tà. Proprio le piccole aziende traggono maggior vantaggio da modelli economici orientati alle proprie esigenze e da una di­spo­ni­bi­li­tà centrale su Internet. Così i costi per la gestione e l’am­mi­ni­stra­zio­ne sono ridotti, e si gode anche della massima fles­si­bi­li­tà, visto che non si è legati ad una specifica piat­ta­for­ma o ad un di­spo­si­ti­vo in par­ti­co­la­re.

Per svi­lup­pa­re le ap­pli­ca­zio­ni web, i pro­gram­ma­to­ri ricorrono ge­ne­ral­men­te ai framework. Ma di che cosa si tratta? E che cosa rende un framework così speciale per le ap­pli­ca­zio­ni web?

Con framework (in italiano: struttura o in­te­la­ia­tu­ra) si intende la struttura di un programma che viene uti­liz­za­ta come base nello sviluppo software. Se uno svi­lup­pa­to­re volesse scrivere un nuovo programma, sarebbe inef­fi­cien­te dover ri­co­min­cia­re ogni volta da zero. Per numerose funzioni standard nello sviluppo software esistono soluzioni già pronte sotto forma di codice. Nella pro­gram­ma­zio­ne orientata agli oggetti vengono uti­liz­za­te so­prat­tut­to classi, che vengono integrate come progetto per lo sviluppo degli oggetti. Un framework rap­pre­sen­ta spesso una col­le­zio­ne di diverse classi collegate tra di loro e sta­bi­li­sce così la struttura di base del design di ogni software, che viene svi­lup­pa­ta a partire dal framework. Se un framework serve come struttura di base delle ap­pli­ca­zio­ni web, si parla di framework per ap­pli­ca­zio­ni web (in inglese: web ap­pli­ca­tion framework).

Come base per lo sviluppo software, i framework do­vreb­be­ro mettere a di­spo­si­zio­ne strutture chiare, gestibili fa­cil­men­te e che con­sen­to­no agli svi­lup­pa­to­ri di creare in poco tempo ap­pli­ca­zio­ni web fun­zio­nan­ti. Per sod­di­sfa­re questo requisito, molti framework si basano su tre principi di base del design:

• Don’t repeat yourself (DRY): il principio Don’t repeat yourself mira ad evitare la ri­pe­ti­zio­ne nell’ambito dello sviluppo software. Le in­for­ma­zio­ni ri­don­dan­ti, quali ad esempio duplicati di codici, sono ten­den­zial­men­te evitabili e si ri­flet­to­no ne­ga­ti­va­men­te sulla gestione del software. Se devono essere adattate stringhe di codice ri­don­dan­ti, le modifiche devono essere apportate in diversi punti del codice del programma.

• Keep it short and simple (KISS): ad ogni problema cor­ri­spon­de una soluzione. È questo il principio base del paradigma KISS, che si orienta sulla regola della par­si­mo­nia. Se per una questione si trovano più soluzioni, si deve scegliere quella che abbia il numero minore di ipotesi e variabili, quindi si dovrebbe riuscire ad uti­liz­za­re un framework o a risolvere uno specifico problema uti­liz­zan­do il minor codice possibile.

• Con­ven­tion over Con­fi­gu­ra­tion: più si configura qualcosa, più di­spen­dio­sa sarà la sua gestione. Invece, le con­ven­zio­ni offrono una pos­si­bi­li­tà di ridurre la com­ples­si­tà. I framework do­vreb­be­ro infatti stabilire un metodo grazie alle im­po­sta­zio­ni standard e offrire altre pos­si­bi­li­tà di con­fi­gu­ra­zio­ne opzionali.

Se questi principi del design vengono presi in con­si­de­ra­zio­ne, l’uso di framework fornisce mol­tis­si­mi vantaggi nell’ambito dello sviluppo software. Ma le istru­zio­ni di un framework impostano anche limiti agli svi­lup­pa­to­ri, che possono quindi diventare degli svantaggi.

Uti­liz­zan­do un framework, si ri­spar­mia­no tempo e costi nello sviluppo software. L’idea di base è il riu­ti­liz­zo del codice, cosa che si riferisce so­prat­tut­to alle fun­zio­na­li­tà es­sen­zia­li come con­nes­sio­ni database, template delle pagine, processi di caching o funzioni di sicurezza, messi a di­spo­si­zio­ne dai framework come elementi già pre­im­po­sta­ti del codice. Così il lavoro di sviluppo si limita ad uno specifico codice del programma di una nuova ap­pli­ca­zio­ne web. Visto che la maggior parte dei framework vengono offerti gra­tui­ta­men­te, di solito non sus­si­sto­no costi per la rea­liz­za­zio­ne.

Inoltre i framework sup­por­ta­no la ge­ne­ra­zio­ne di un codice sorgente corretto, visto che gli svi­lup­pa­to­ri possono ricorrere a com­po­nen­ti già ve­ri­fi­ca­ti per quanto riguarda le funzioni standard. Le parti dei programmi messe a di­spo­si­zio­ne dai framework sono sot­to­po­ste il più delle volte a numerosi cicli di sviluppo e vengono ot­ti­miz­za­te con­ti­nua­men­te. La community svolge così la funzione di tester e co-svi­lup­pa­to­re. In caso di progetti grandi, le falle di sicurezza dei nuovi com­po­nen­ti vengono scoperte e risolte ve­lo­ce­men­te. Uno scambio tra utenti e svi­lup­pa­to­ri avviene ge­ne­ral­men­te nei forum del progetto, che sono in parte moderati dai team di supporto.

In rete si trovano un numero quasi il­li­mi­ta­to di framework per lo sviluppo web, che si dif­fe­ren­zia­no sia per quanto riguarda i design pattern sia re­la­ti­va­men­te alla gamma di funzioni. Diversi progetti di software possono così ri­chie­de­re l’uso di vari framework. Gli svi­lup­pa­to­ri si trovano davanti ad un enorme scelta e così devono scegliere il framework più adatto alle loro esigenze. Ben presto si giunge però a com­pro­mes­si, facendo in modo che il progetto del software de­si­de­ra­to si adatti ai limiti del framework. Visto che i framework sono pro­get­ta­ti come soluzioni uni­ver­sa­li, è raro che gli svi­lup­pa­to­ri uti­liz­zi­no tutte le funzioni della struttura pre­im­po­sta­ta. A seconda della sua varietà di funzioni, un’ap­pli­ca­zio­ne comprende perciò più codice di quanto sia ne­ces­sa­rio, quindi in questo caso sarà presente del codice superfluo.

Rientra tra gli svantaggi anche il fatto che agli svi­lup­pa­to­ri viene con­si­glia­to di ri­vol­ger­si ad uno specifico pro­dut­to­re o ad una community di svi­lup­pa­to­ri in par­ti­co­la­re per uti­liz­za­re al meglio un framework. In alcuni casi l’uso di un framework è legato a precise con­di­zio­ni di licenza. Inoltre possono sorgere dei problemi, se è previsto che possa essere ul­te­rior­men­te svi­lup­pa­to.

Visto che ini­zial­men­te gli svi­lup­pa­to­ri devono prendere con­fi­den­za con la struttura del ri­spet­ti­vo programma e le pos­si­bi­li­tà di utilizzo, si pre­sup­po­ne un periodo iniziale di adat­ta­men­to, sempre relativo, se si pensa a quanto tempo verrà comunque ri­spar­mia­to grazie a funzioni già pronte e agli elementi co­sti­tu­ti­vi del codice. Qui i critici vedono però il rischio che le co­no­scen­ze di base vadano perdute. Infatti gli utenti che pro­gram­ma­no esclu­si­va­men­te sulla base di framework, si con­fron­ta­no pro­ba­bil­men­te in maniera meno intensiva con i linguaggi di pro­gram­ma­zio­ne uti­liz­za­ti.

Dato che il codice sorgente della maggior parte dei framework è di­spo­ni­bi­le li­be­ra­men­te, in linea di massima tutti possono prendere con­fi­den­za con queste strutture. Se le ap­pli­ca­zio­ni da usare nelle aziende vengono svi­lup­pa­te sulla base di elementi di codice di­spo­ni­bi­le li­be­ra­men­te, questi risultano pos­si­bil­men­te più tra­spa­ren­ti per gli hacker rispetto alle app che di­spon­go­no di un codice sorgente pro­prie­ta­rio.

Come i framework in generale, anche i framework per ap­pli­ca­zio­ni web vengono de­li­mi­ta­ti dalle librerie dei programmi (libraries) e i tool di sviluppo web (Web De­ve­lo­p­ment Tools). Mentre le librerie mettono a di­spo­si­zio­ne solo alcune fun­zio­na­li­tà, un framework può essere con­si­de­ra­to come una struttura in­te­rat­ti­va del programma per processi standard, cioè quasi come un’ap­pli­ca­zio­ne semi-au­to­ma­ti­ca.

I com­po­nen­ti prin­ci­pa­li di un framework sono co­sti­tui­ti da classi collegate tra di loro a cui sono assegnati dei metodi. Si tratta di blocchi di codice, che de­scri­vo­no le proprietà degli oggetti e il loro com­por­ta­men­to. Alcuni di questi com­po­nen­ti sono statici e quindi im­mu­ta­bi­li, mentre altri possono essere adattati dagli utenti, ad esempio tramite la so­vra­scrit­tu­ra di metodi. In questo modo si ha la pos­si­bi­li­tà di modellare la struttura del programma ad uno specifico compito. I com­po­nen­ti fles­si­bi­li di un framework prendono anche il nome di “Hot spot”, mentre le parti statiche vengono invece chiamate “Frozen spot”.

I framework seguono di solito il pattern Inversion of Control (IoC) (in italiano: in­ver­sio­ne di controllo). Si può de­scri­ve­re come un’ap­pli­ca­zio­ne basata sul principio di Hollywood della pro­gram­ma­zio­ne orientata agli oggetti: “Don’t call us, we call you!“ (tra­du­ci­bi­le in italiano come “Non chiamarci, ci faremo risentire noi!”).

Spiegato in maniera semplice, IoC significa che la re­spon­sa­bi­li­tà per l’ese­cu­zio­ne dei programmi non risiede nei singoli com­po­nen­ti che vengono svi­lup­pa­ti ed eseguiti sulla base del framework, ma si trova nel framework stesso. Così ricopre la funzione di un programma prin­ci­pa­le, che coordina il flusso di controllo. Altri com­po­nen­ti che vengono im­ple­men­ta­ti nel framework e quindi re­gi­stra­ti, sono a sua di­spo­si­zio­ne in caso di necessità. Questo fun­zio­na­men­to si può comparare con un classico congedo per un casting ad Hollywood: “Sappiamo chi sei e ti ri­con­tat­te­re­mo non appena avremo bisogno di te!”.

Per poter eseguire queste funzioni di controllo prin­ci­pa­li, i framework hanno pre­im­po­sta­ta un’in­ter­fac­cia utente specifica, che deve essere im­ple­men­ta­ta da tutti i com­po­nen­ti co­sti­tuen­ti. Tramite questo principio del design, il framework è sempre in grado di portare i com­po­nen­ti co­sti­tuen­ti ad im­ple­men­ta­re i metodi di callback, che gli con­sen­to­no, se ne­ces­sa­rio, di iniettare le in­for­ma­zio­ni nei com­po­nen­ti o di attivare un com­por­ta­men­to preciso tramite l’uso di metodi. Mentre le classi e le loro relazioni nei classici approcci dello sviluppo software vengono co­di­fi­ca­ti e quindi stabiliti già in fase di com­pi­la­zio­ne, il metodo in­ver­sio­ne di controllo di un software consente di generare gli oggetti in modo dinamico durante il runtime.

Nello sviluppo software IoC ricopre la funzione di una strut­tu­ra­zio­ne generale e viene azionato da alcuni design pattern, come De­pen­den­cy Injection (DI) e De­pen­den­cy Lookup.

La maggior parte dei framework per ap­pli­ca­zio­ni web si basa su un pattern ar­chi­tet­tu­ra­le, che prende il nome di Model-View-Con­trol­ler (MVC). Il suo obiettivo è quello di operare una netta divisione dalla logica di ap­pli­ca­zio­ne e dal livello di pre­sen­ta­zio­ne, oltre che sud­di­vi­de­re i software nella fase di sviluppo in tre ambiti, cioè Model (i dati), View (la pre­sen­ta­zio­ne dei dati) e Con­trol­ler (qualunque in­te­ra­zio­ne dell’utente).

• I dati: il Model è la parte di un framework che comprende i dati da vi­sua­liz­za­re, la logica di ap­pli­ca­zio­ne e le regole. I processi, come ri­chia­ma­re i dati e apportare modifiche, si svolgono grazie a metodi previsti ap­po­si­ta­men­te. 

• Pre­sen­ta­zio­ne dei dati all’utente: il compito es­sen­zia­le del View è la vi­sua­liz­za­zio­ne dei dati messi a di­spo­si­zio­ne dal Model. Per questo il View interroga lo stato del Model tramite metodi e viene informato sempre dal Model sulle modifiche. Un altro compito del View è quello di accettare i comandi dell’utente (im­mis­sio­ni dalla tastiera, click del mouse) e inol­trar­li al Con­trol­ler.

• In­te­ra­zio­ne dell’utente: il Con­trol­ler svolge la funzione di in­ter­fac­cia tra Model e View. Così gestisce una o più Views, valuta gli input dell’utente e reagisce di con­se­guen­za, ad esempio con­se­gnan­do i dati al Model o pre­di­spo­nen­do le modifiche al View.

L’obiettivo del modello MVC è quello di creare un programma fles­si­bi­le. La se­pa­ra­zio­ne della logica di ap­pli­ca­zio­ne e del livello di pre­sen­ta­zio­ne do­vreb­be­ro sem­pli­fi­ca­re i processi per apportare modifiche suc­ces­si­ve, attivare esten­sio­ni e per­met­te­re il riu­ti­liz­zo dei singoli com­po­nen­ti. Così si riduce ad esempio il lavoro di pro­gram­ma­zio­ne, per adattare il software a diverse piat­ta­for­me (Windows, Mac, Linux) o per uti­liz­zar­lo come web app, perché solo il Con­trol­ler e il View devono essere adattati di con­se­guen­za.

Esiste anche il JSP (Java Server Pages) che si basa sul pattern MVC e viene uti­liz­za­to per la pro­gram­ma­zio­ne web in Java. Così una pagina JSP cor­ri­spon­de al View, una servlet al Con­trol­ler e una Java Bean al Model.

Il mercato delle ap­pli­ca­zio­ni web è molto variegato. Le app, che sono di­spo­ni­bi­li per gli utenti dal browser, si dif­fe­ren­zia­no a seconda del campo di utilizzo e dello spettro di funzioni, non solo per le di­men­sio­ni e le sembianze, ma anche es­sen­zial­men­te nel design del software. Motivo di ciò è la varietà dei framework di­spo­ni­bi­li, che si ap­pog­gia­no a dif­fe­ren­ti tec­no­lo­gie e seguono diversi approcci nel design del software. Si possono con­trap­po­re approcci Single-Page e Multi-Page, lato server e lato client, oltre che framework che si basano su azioni o sui com­po­nen­ti.

Le ap­pli­ca­zio­ni Multi-Page sono composte da più pagine HTML, che so­li­ta­men­te vengono aperte tramite l’in­se­ri­men­to del ri­spet­ti­vo URL nel browser e sono collegate tra loro tramite hyperlink (col­le­ga­men­ti iper­te­stua­li). L’in­ter­fac­cia utente di un’ap­pli­ca­zio­ne Single-Page invece è composta solo di una pagina HTML su cui sono impostati tutti gli input dell’utente. Si può sud­di­vi­de­re in pannelli, cursori o schede di re­gi­stra­zio­ne. Per quanto riguarda la na­vi­ga­zio­ne, l’URL di un’ap­pli­ca­zio­ne Single-Page rimane invariato.

Il modello di pro­gram­ma­zio­ne delle web app classiche cor­ri­spon­de a quello del World Wide Web, la cui ar­chi­tet­tu­ra è basata sul pro­to­col­lo di tra­sfe­ri­men­to di un ipertesto (HTTP, Hypertext Transfer Protocol). Se un’ap­pli­ca­zio­ne web viene ri­chia­ma­ta da un utente, sono coinvolti in ogni caso uno o più server o client, come ad esempio un browser. A seconda di come viene pro­get­ta­ta la co­mu­ni­ca­zio­ne tra server e client, si parla di ap­pli­ca­zio­ni lato server o lato client.

• Ap­pli­ca­zio­ni lato client: se all’avvio di un’ap­pli­ca­zio­ne viene caricata l’intera in­ter­fac­cia utente HTML com­pren­si­va di logica di ap­pli­ca­zio­ne nel client, si parla di ap­pli­ca­zio­ni lato client. Le modifiche all’in­ter­fac­cia, per via degli input dell’utente, vengono in questo caso impostate tramite linguaggi di pro­gram­ma­zio­ne lato client, come Ja­va­Script. Si consiglia un approccio del design di questo tipo per le app in cui gli utenti lavorano per un periodo di tempo più lungo sulla stessa vi­sua­liz­za­zio­ne, perché solo i dati vi­sua­liz­za­ti sull’in­ter­fac­cia utente vengono ri­ca­ri­ca­ti dal server. L’approccio lato client viene uti­liz­za­to prima di tutto per lo sviluppo di app Single-Page e viene usato da framework Ja­va­Script, come AngularJS o EmberJS.

• Ap­pli­ca­zio­ni lato server: nelle ap­pli­ca­zio­ni lato server, la logica di ap­pli­ca­zio­ne rimane sul server, che crea l’in­ter­fac­cia utente e invia al client i dati per la vi­sua­liz­za­zio­ne. Per le modifiche all’in­ter­fac­cia utente sono a di­spo­si­zio­ne così i linguaggi di pro­gram­ma­zio­ne lato server e lo sviluppo è com­ple­ta­men­te in­di­pen­den­te da possibili vul­ne­ra­bi­li­tà del client. Questo approccio viene uti­liz­za­to so­li­ta­men­te nelle app Multi-Page, in cui le diverse vi­sua­liz­za­zio­ni delle pagine, se ne­ces­sa­rio, vengono ri­chia­ma­te dal server. Un design del software di questo tipo è però collegato con tempi di ca­ri­ca­men­to più lunghi, ma riduce le richieste fatte sul di­spo­si­ti­vo client. Su alcune app si evita di me­mo­riz­za­re la logica di controllo per motivi di sicurezza. Un’ap­pli­ca­zio­ne dell’approccio lato server si trova ad esempio nei framework Django, Zend e Ruby on Rails.

Un approccio di pro­gram­ma­zio­ne lato server si trova so­prat­tut­to nei framework, che sono stati svi­lup­pa­ti per la creazione di ap­pli­ca­zio­ni web classiche con struttura Multi-Page e con un’in­ter­fac­cia utente classica HTML. Solo l’in­ter­fac­cia viene vi­sua­liz­za­ta nell’ap­pli­ca­zio­ne web e utilizza so­li­ta­men­te la na­vi­ga­zio­ne del browser. Le web app di questo tipo si possono eseguire in­di­pen­den­te­men­te dal sistema operativo o dal browser uti­liz­za­ti. La logica di controllo viene elaborata tramite la co­mu­ni­ca­zio­ne tipica, elaborata dal server tramite documenti HTML, basata sul modello Request/Response. Le ap­pli­ca­zio­ni web lato client vengono anche de­no­mi­na­te Rich Client o Rich Internet Ap­pli­ca­tion (RIA). Le ap­pli­ca­zio­ni di questo tipo im­ple­men­ta­no l’in­ter­fac­cia utente com­pren­si­va di logica di ap­pli­ca­zio­ne nel client, che viene ge­ne­ral­men­te caricata com­ple­ta­men­te all’avvio. A dif­fe­ren­za delle ap­pli­ca­zio­ni web classiche, si possono impostare con un approccio lato client anche proprietà co­no­sciu­te mag­gior­men­te per le ap­pli­ca­zio­ni desktop, come il controllo tramite drag&drop, la di­spo­ni­bi­li­tà dei contenuti in modalità offline e l’accesso all’hard disk.

Al livello del controllo delle ap­pli­ca­zio­ni, i framework si dividono in due classi. Mentre i framework basati sulle azioni (action-based) ri­pro­du­co­no lo schema Request-Response tipico del pro­to­col­lo HTTP, ci si discosta da questo pro­ce­di­men­to nei framework basati sui com­po­nen­ti (component-based). I framework basati sulle azioni: nei framework basati sulle azioni, il Con­trol­ler serve come istanza centrale, che accetta le richieste del client, le convalida e richiama l’azione cor­ri­spon­den­te. Per ogni possibile azione deve essere creato dallo svi­lup­pa­to­re app pre­ven­ti­va­men­te un oggetto, che comprende la cor­ri­spet­ti­va logica di ap­pli­ca­zio­ne, de­ri­va­bi­le so­li­ta­men­te dalle classi astratte. Se l’azione viene portata a termine, il Con­trol­ler aggiorna il Model e inoltra il risultato al View, che a sua volta crea la risposta e la rinvia al client. I framework basati su azioni fanno af­fi­da­men­to sul modello MVC e, per via della stretta ap­pli­ca­zio­ne dello schema Request-Response, vengono de­no­mi­na­ti anche request-based. Dei tipici esempi per questo tipo di framework sono:

• Django

• Ruby on Rails

• Symfony

• Spring MVC

• Co­deI­gni­ter

Visto che le possibili azioni di un framework basato sulle azioni vengono definite det­ta­glia­ta­men­te dallo svi­lup­pa­to­re app, si parla di un approccio White Box, che dà agli svi­lup­pa­to­ri maggiori libertà. È richiesta però una com­pren­sio­ne più profonda del framework in uso, dato che gli svi­lup­pa­to­ri sono re­spon­sa­bi­li per la creazione di pagine HTML, CSS e Ja­va­Script. I framework basati sui com­po­nen­ti: a dif­fe­ren­za dell’approccio con­trol­la­to tramite azioni, i framework con­trol­la­ti dai com­po­nen­ti si di­sco­sta­no dallo schema Request-Response del pro­to­col­lo HTTP, dove l’in­ter­fac­cia utente di un’ap­pli­ca­zio­ne web viene con­si­de­ra­ta come una col­le­zio­ne di com­po­nen­ti. Per ognuno di questi com­po­nen­ti, che sono collegati con oggetti lato server, vengono definite precise reazioni durante lo sviluppo delle ap­pli­ca­zio­ni web, che si sus­se­guo­no ad eventi, causati da un’in­te­ra­zio­ne utente con il com­po­nen­te. Si parla perciò anche di framework con­trol­la­ti da eventi. Dei tipici esponenti di questo tipo di framework sono:

• Lift

• Apache Tapestry

• Ja­va­Ser­ver Faces

• Apache Wicket

L’idea di base dietro ad un approccio basato sui com­po­nen­ti è quella di rag­grup­pa­re le azioni correlate. Un com­po­nen­te Ac­count­Con­trol­ler rap­pre­sen­ta ad esempio azioni come login, logout o ge­tAc­count. Un oggetto può così essere re­spon­sa­bi­le per molte più azioni. I framework basati sui com­po­nen­ti offrono so­li­ta­men­te una grande scelta di com­po­nen­ti riu­ti­liz­za­bi­li, che na­scon­do­no agli svi­lup­pa­to­ri di app i dettagli dello schema Request-Response alla base. Si parla in questo contesto di un modello Black Box. I framework di questo tipo sono quindi par­ti­co­lar­men­te utili per gli svi­lup­pa­to­ri che vogliono ap­pog­giar­si prima di tutto a com­po­nen­ti pre­de­fi­ni­ti. Chi vorrebbe avere maggiori libertà per quanto riguarda il pro­to­col­lo HTTP e i linguaggi HTML, CSS e Ja­va­Script, farà meglio ad in­di­riz­zar­si su un framework basato sulle azioni.

Visto che i framework hanno una grande influenza sulle funzioni e sulle pos­si­bi­li­tà di strut­tu­ra­zio­ne delle ap­pli­ca­zio­ni web, nonché sulla fase di sviluppo, il processo di lavoro comincia so­li­ta­men­te già con la scelta della struttura di base del programma ap­pro­pria­to. Così dovreste con­si­de­ra­re da una parte l’intento del software pro­gram­ma­to, ma anche le co­no­scen­ze già acquisite.

Le domande prin­ci­pa­li da porsi ri­guar­da­no il tipo di ap­pli­ca­zio­ne e l’ar­chi­tet­tu­ra de­si­de­ra­ta (lato server, lato client). Entrambi gli aspetti hanno effetti diretti sulla na­vi­ga­zio­ne e l’usabilità di una web app.

Per la ricerca del framework adatto rap­pre­sen­ta­no un punto da cui partire anche le co­no­scen­ze di pro­gram­ma­zio­ne che già si pos­sie­do­no e la di­spo­ni­bi­li­tà dell’in­fra­strut­tu­ra ne­ces­sa­ria. Spe­cial­men­te tra i linguaggi di pro­gram­ma­zio­ne lar­ga­men­te diffusi, come PHP (ad esempio Zend, Symfony, CakePHP o Co­deI­gni­ter), Java (ad esempio Ja­va­Ser­ver Faces o Apache Wicket) o Python (come Django), c’è un’ampia scelta di framework ben do­cu­men­ta­ti. La po­po­la­ri­tà di Ruby nello sviluppo web è so­prat­tut­to ri­con­du­ci­bi­le alla dif­fu­sio­ne del popolare framework Ruby on Rails. I framework lato client si basano so­li­ta­men­te sul lin­guag­gio di scripting Ja­va­Script.

Gli svi­lup­pa­to­ri che in passato hanno pro­gram­ma­to prima di tutto ap­pli­ca­zio­ni desktop, trovano spesso difficile il modello di pro­gram­ma­zio­ne orientato sullo schema Request-Response dei framework basati sulle azioni, rispetto agli svi­lup­pa­to­ri web classici. In questo caso un framework basato sui com­po­nen­ti può essere la soluzione migliore per co­min­cia­re ad av­vi­ci­nar­si a questo tipo di strutture.