Framework frontend
Man mano che i siti internet ad uso del pubblico generalista sono diventati sempre più numerosi, sono aumentate anche le esigenze dei visitatori di questi siti. Le tecnologie web si sono evolute per soddisfarle: carichi di traffico sempre più intensi, recupero di dati distribuiti su numerosi server, soluzioni in cloud, aumento della sicurezza, controlli e validazioni. Ma non sono cambiate solo le cose dietro le quinte, gli effetti più evidenti di questa trasformazione del web li abbiamo davanti gli occhi ogni giorno: ogni pagina internet ha il potenziale di essere una vera e propria applicazione. Alcuni hanno sostituito i software tradizionali: ad esempio, in questo momento sto scrivendo questo articolo su un editor di testo online: accedo ai miei documenti tramite una pagina web, li edito tramite un’interfaccia, tutto in browser senza dover installare del software aggiuntivo.
Queste cose sono possibili anche grazie agli avanzamenti che ci sono stati nello sviluppo delle interfacce. Nel vecchio web l’unico modo possibile era creare una pagina assemblando da soli HTML, CSS, JavaScript. Questi linguaggi erano meno sviluppati rispetto ad oggi e offrivano meno strumenti. Con delle librerie si riusciva a mettere insieme delle cose interessanti, che operavano sulla pagina e i suoi elementi interni. Usando questo approccio, solitamente, si tende a costruire uno scheletro della pagina con il documento HTML, e poi renderlo accattivante e interattivo con JavaScript e CSS. L’approccio è poi cambiato: da un focus sugli elementi e la pagina, a uno che tiene in considerazione l’intero sistema-interfaccia e i suoi componenti interni.
Nei primi anni del web 2.0 il CSS era diventato abbastanza potente, mentre JavaScript soffriva ancora un po’ il modo frammentato in cui veniva implementato nei diversi browser (Internet Explorer, Mozilla, i primi browser mobile). Questo ha consentito alla nascita dei primi framework frontend basati su CSS, come ad esempio YAML, Blueprint, 960. Offrivano al programmatore uno “scheletro” grafico su cui andare a costruire i propri layout. Ad oggi il framework CSS più utilizzato rimane Bootstrap, un prodotto di Twitter, che permette lo sviluppo di interfacce gradevoli e ben strutturate. Manca della reattività dei dati che vedremo più avanti con l’altro tipo di framework, ma ciononostante rimane uno strumento molto valido che prevede i suoi casi d’uso. Quando nel 2010 JavaScript era ormai standardizzato e solido da tempo su tutti i maggiori browser, questi framework basati sul CSS iniziano a cedere il passo agli altri, più moderni, basati su JavaScript. Alcuni esempi sono Angular, React, Vue.js.
I framework di quest’ultima categoria permettono di fare cose in maniera radicalmente diverse. Solitamente si tratta di sistemi basati su un’architettura MVC che permette al programmatore di infondere una logica profonda a tutti gli elementi della propria interfaccia. Grazie a quest’approccio è possibile creare dei modelli di dati (ad esempio: Utente) e dei componenti (ad esempio: presentazione dell’Utente) in cui presentazione e dati sono legati a doppio giro tra di loro: un cambiamento nei dati comporta un cambiamento in interfaccia e viceversa. Questo permette non solo di avere UI interattive e efficienti, ma che aiutano i programmatori a trattare davvero i dati che stanno rappresentando, semplificando di molto i giri di chiamate che devono essere fatti tra il frontend, il backend e il database.
In SocialCities abbiamo scelto di usare Django e Laravel come framework backend. Ma non è a questo punto che finiamo di definire il nostro stack tecnologico: anche i framework frontend giocano un ruolo importante.
In fase di progettazione c’è una certa elasticità per quanto riguarda la scelta del frontend. I diversi approcci che abbiamo elencato sopra (HTML puro, framework basati sul CSS e su JavaScript) sono tutti idonei ad essere impiegati in un progetto. Come si può immaginare, l’approccio utilizzato scala con la complessità dell’interfaccia prevista per il progetto: nel caso in cui dovesse servire una semplice pagina che ci dia un feedback sulle operazioni del backend, ci appoggeremo ad HTML, ai Template di Django o i file Blade di Laravel; se è qualcosa ad uso interno, ma che prevede comunque un grado più alto di usabilità, complessità e sofisticazione nella presentazione, Bootstrap è lo strumento giusto. E per finire, se l’interfaccia deve essere utilizzata da un pubblico non specialistico e che ci siano livelli di interazione più complessi della semplice presentazione, i framework JavaScript sono solitamente la soluzione preferibile.
Un altro impiego dei framework JavaScript è quello di fornire una base per delle app cross platform. Grazie all’utilizzo di strumenti come Ionic è possibile realizzare le viste di un’applicazione per smartphone che Ionic convertirà in un eseguibile iOS o Android.
Come abbiamo visto, questi strumenti provengono da una storia ricca e complessa e si sono evoluti con l’evolversi dei servizi su Internet. In questo periodo ci crescita e sviluppo sono emersi diversi approcci, e non tutti sono stati definitivamente soppiantati da quelli che li hanno succeduti. Ad oggi ci ritroviamo con tre famiglie di tecniche: assemblaggio semplice di HTML/CSS/JavaScript, framework grafici CSS, framework grafico-logici JavaScript; ognuna di esse porta i suoi vantaggi e svantaggi e ha i suoi casi d’uso, dal semplice feedback alle applicazioni per telefono. Ognuno di questi approcci è abbastanza flessibile da potersi combinare con un qualsiasi altro framework backend.
E tu, vuoi stupire i tuoi utenti con interfacce veloci e accattivanti?
Cosa vuoi creare?
👇
