Il mondo frontend negli ultimi anni è cambiato radicalmente!
C’era una volta
Quando sono arrivato in Intesys nel 2008, il frontend era considerata un’attività di basso livello, spesso dedicata allo smontaggio delle grafiche e all’installazione di qualche plugin per rendere le pagine più dinamiche dal punto di vista grafico.
Pur essendo un’attività di basso livello, era comunque fondamentale per la buona riuscita di un progetto, come lo era la parte backend.
Questi due mondi (backend e frontend), pur essendo molto differenti tra loro, sono sempre stati mescolati sotto lo stesso progetto. Questo però ha sempre portato dei grossi limiti alla parte frontend, in quanto non c’era un modo standard di sviluppare, ma bisognava sempre adattarsi alle regole che il framework (backend) imponeva.
Al giorno d’oggi
Negli ultimi anni il mondo frontend si è trasformato, soprattutto con l’avvento di Node.js e con il consolidamento di alcuni framework come React (di cui avevamo già parlato in seguito al ReactJsDay 2016) e Angular. Tali framework hanno permesso di strutturare in maniera più solida il mondo frontend, di dargli una sua indipendenza e un’identità molto più chiara. Grazie a loro si è cominciato a parlare di Single Page Application!
Cos’è una Single Page Application
Una Single Page Application (SPA) è a tutti gli effetti una applicazione web, che ha come obiettivo quello di migliorare molto l’esperienza utente, in quanto la navigazione è molto più fluida e simile ad un’applicazione desktop.
Vediamo molto velocemente i maggiori vantaggi delle SPA:
- Velocità: quando navighiamo un normale sito web, ogni pagina che cambiamo viene ricaricata completamente. In una SPA le risorse principali vengono caricate in fase iniziale, mentre durante la navigazione successiva vengono fatte solo richieste di dati, senza dover ricaricare la pagina, e senza obbligare il browser a renderizzare nuovamente tutto, se non le parti che devono cambiare.
- Frontend indipendente: il frontend diventa a tutti gli effetti un mondo a sé, non è più vincolato alle regole del framework/tecnologia backend, e quindi si può strutturare in maniera molto più solida, con scelte condivise che possono essere riutilizzate in diversi progetti.
- Backend a servizi: separando il frontend dal backend l’unica maniera per comunicare tra i due layer è tramite API. Impostando un backend a servizi (o API) è molto più semplice e molto più vantaggioso, in quanto gli stessi servizi che vengono esposti per la SPA possono essere utilizzati da un’app mobile, o da un servizio terzo che abbia bisogno di comunicare con il backend.
- Facilità di test: separando i due mondi, ognuno può testare meglio ciò che è di sua competenza, alzando enormemente la qualità di ciò che si realizza.
- Facilità di integrazione: una SPA può integrarsi con qualsiasi framework/tecnologia, in quanto la comunicazione avviene tramite un formato standard, il JSON, che può essere prodotto da qualsiasi backend.
- Dati fake: in attesa che il backend implementi dei veri e propri servizi, si può facilmente lavorare con dei dati finti (o fake), e cambiare contesto velocemente una volta che i servizi backend sono pronti.
Questo nuovo approccio porta molti benefici alla sviluppo di un progetto. Va a colpire bisogni dell’utente, in quanto l’esperienza utente viene migliorata: più un’applicazione è reattiva, più l’utente finale è facilitato ad utilizzare la piattaforma. Inoltre si vanno a colpire anche bisogni di development, in quanto sviluppando in questa maniera si ha molta più flessibilità e molta più qualità in ciò che si va a realizzare.
La nostra esperienza
Ne avevamo sentito parlare, e avevamo provato a fare qualcosa, ma sempre in contesti molto piccoli.
Nel 2016 siamo stati coinvolti in due progetti molto ambiziosi, durati quasi un anno ciascuno, dove abbiamo realizzato due SPA veramente complesse. Questi due progetti ci hanno permesso finalmente di sperimentare concretamente quelli che erano i cosiddetti vantaggi teorici, e darci consapevolezza dei benefici che portano, sia a livello di sviluppo che a livello utente finale.
Nel 2017 siamo già stati coinvolti su altri due progetti di questo tipo, che sono attualmente in sviluppo. Questo metodo di sviluppo ci sta dando molte soddisfazioni e ci fa sentire davvero sulla strada giusta.
La nostra visione
Questo nuovo approccio è sicuramente il futuro dello sviluppo delle applicazioni web. Consapevoli di tutto ciò, ci siamo strutturati anche in Intesys con un nuovo team frontend, che possa rispondere in maniera puntale alle richieste del mercato, e che possa proporre questa nuova modalità di sviluppo, in qualsiasi progetto enterprise.
Sviluppare in questa modalità, sta portando molto più valore al risultato finale: valore per il cliente, valore per l’utente, valore in ciò che realizziamo.
Che dire: siamo pronti, siamo sul pezzo, e siamo molto motivati!
E voi cosa ne pensate?
Amazing
Good
Bad
Meh
Pff
Bello l’articolo e interessante come il mondo dello sviluppo web/mobile si sia negli anni evoluto. Domanda da ignorante in materia: l’utilizzo di frameworks frontend aiuta a risolvere la “battaglia fra i browsers” e le relative fasi di test, soprattutto ora che non si può più non avere un sito responsive?
Grazie Mirko, provo a rispondere alla tua domanda!
Diciamo che per esperienza la “battaglia fra i browser” era più legata a componenti di User Interface che al codice Javascript, in quanto lo stesso codice (html/css) non veniva interpretato ugualmente dai diversi browser. Per risolvere questi problemi di incompatibilità spesso bisognava lavorare di html/css. (Dico spesso, ma non sempre, perché a volte anche il Javascript poteva aiutare)
L’utilizzo di questi framework, per la costruzione di Single Page Application, in realtà cambiano il modo in cui viene realizzata la parte frontend, ma quello che producono è sempre del codice html, css, js come prima, solo organizzato meglio, e che potrebbe avere gli stessi problemi di compatibilità che c’erano una volta.
Quindi la risposta alla tua domanda fino a questo punto è no, non risolvono la “battaglia fra i browser”.
Esistono però dei framework frontend (che non c’entrano nulla con framework per la costruzione di SPA) che mettono a disposizione una serie di componenti, i quali sono stati già testati sui vari browser. Utilizzando il più possibile i loro componenti, si riduce di molto il problema di incompatibilità. Uno tra i più famosi framework di questo tipo è bootstrap (http://getbootstrap.com/), il quale mi ritrovo ad utilizzare nella maggior parte dei progetti, ma ne esistono davvero tanti altri (https://www.keycdn.com/blog/front-end-frameworks/).
Spero di aver risposto.
Ciao Federico, post molto interessante! A questo punto rimane solo il vedere all’opera queste SPA. Avresti qualche link da mostrare, se non le vostre, le più “riuscite” o che hai preso a modello? Grazie
Ciao Matteo,
diciamo che in questo momento purtroppo non possiamo farti vedere qualcosa relativo ai 2 progetti, in quanto non ci è ancora concesso 🙁
Considera però che le Single Page Application che realizziamo, a differenza dei siti web che troviamo in giro e accessibili a chiunque, spesso funzionano in ambito privato e quindi coperti da credenziali, per cui non sono accessibili e visualizzabili a tutti. Questo impedisce anche a noi di ispirarsi ad una soluzione specifica.
Ci tengo comunque a precisare che l’output di quello che abbiamo realizzato è si la Single Page Application, ma il lavoro che abbiamo fatto è molto molto più ampio.
In uno dei due progetti siamo partiti da un analisi con il cliente, sfruttando il metodo del Google Design Sprint, attraverso il quale abbiamo realizzato dei prototipi reali e testati sul campo. Dopo di quello sono state realizzati dei wireframe e delle grafiche e da quello lo sviluppo di una (super) Single Page Application. Come già detto non ci siamo ispirati a qualcosa di specifico, ma più che altro a metodologie che riteniamo consolidate nel nostro iter di proposta verso il cliente, e che sappiamo portano risultati soddisfacenti.
Spero di aver risposto alla tua domanda. Sei avessi qualche altro dubbio sono qui.
Ciao Federico, complimenti per l’articolo è veramente ben fatto e mi dispiace di averlo letto solo ora.
Io da circa un anno sto cercando di comprendere quale sia il modo migliore per sviluppare SPA, l’idea da cui sono partito è quella di utilizzare vanilla javascript, infatti da quello che ho avuto modo di leggere in giro per la rete l’utilizzo di un qualsiasi framework rallenta notevolmente l’applicativo finale.
Mi sembra di capire che per il vostro progetto avete utilizzato un framework quindi vorrei chiederti, se possibile saperlo, quale avete utilizzato (AngularJS?) e se effettivamente avete riscontrato problemi di lentezza della webapp finale.
Ti chiedo questo perché lo sviluppo di un framework homemade, che quindi contenga solo ed esclusivamente le funzioni strettamente necessarie, non è proprio regalato e quindi sarebbe da capire da chi ha avuto esperienze con altre tecnologie se il gioco vale la candela.
Inoltre visto che il mio fine ultimo resta comunque quello di costruire SPA solide e funzionali volevo chiederti se sai cosa studiare e dove reperire tutto il necessario per apprendere al meglio questa tecnica.
Ti saluto e magari ti interessasse resto a disposizione per uno scambio di idee sull’argomento.
Ciao Christian,
non ti consiglio di buttarti in un’impresa come lo sviluppo di un framework, che richiede competenze ed esperienza molto elevate. I framework di oggi sono software realizzati da team con una notevole esperienza e rappresentano lo stato dell’arte del software, meglio studiarli e usarli approfonditamente prima di scrivere qualcosa di simile per conto proprio: don’t reinvent the wheel!
Relativamente ai problemi di performances, considera che i browser sono sempre più potenti e i framework sul mercato sempre più ottimizzati, quindi non preoccupartene finché non ti scontri veramente con un problema di lentezza (e ricorda: “premature optimization is the root of all evil (or at least most of it) in programming” Da https://en.wikiquote.org/wiki/Donald_Knuth )
Concludendo, scegli un framework in base al tuo livello attuale e alle tue preferenze personali, se vuoi un consiglio puoi prendere in considerazione: Vue.js, HyperApp, React, Angular (elencati in ordine di facilità d’uso).
Alessandro Falezza
Grazie Alessandro per la tua risposta.
Come già detto, all’inizio del mio percorso verso le SPA avevo pensato che scrivere da solo un framework snello sarebbe stata la mia soluzione ideale, poi nel tempo ho iniziato a vedere che forse utilizzando qualche framework il lavoro sarebbe stato nettamente più semplice.
Ora tu mi confermi questo, specificando anche che i rallentamenti di cui spesso ho sentito parlare sono pressoché insignificanti, quindi posso dirti che mi hai ampiamente convinto.
Ora la domanda che mi sorge è, considerando che per le mie piccole esigenze non lavorative ho a disposizione un hosting dove non posso installare framework come node.js o angular, purtroppo ho letto che anche questo framework ha bisogno di essere installato :(, ma posso solo inviare librerie javascript in ftp, secondo te quale sarebbe la soluzione migliore da adottare?
Ti ringrazio ancora per qualsiasi consiglio tu voglia darmi
Ciao Christian,
ti do una bella notizia: puoi utilizzare il framework che preferisci!
Quando leggi che il framework deve essere installato, ci si riferisce all’installazione dell’ambiente di sviluppo: oggigiorno tutti i framework richiedono questo passaggio.
Dovrai quindi installare Node.js e git sul computer dove scrivi il codice, e quindi installarti il framework che preferisci (troverai certamente istruzioni dettagliate sul sito del tuo framework).
Tutti i framework più noti dispongono di due funzioni: la modalità di sviluppo e la funzione “build”. La prima ti consente di avviare la tua SPA sul tuo computer ed è configurata per assisterti durante lo sviluppo, mentre la seconda è un comando che “costruisce” il codice da trasferire in ftp.
Il procedimento dunque è il seguente:
Buon lavoro!
Che dirti?
Grazie mille, non reputo la tua notizia bella, ma molto molto di più ed ora che mi hai aperto gli occhi non vedo l’ora di buttarmi su un nuovo progetto che mi permetta di imparare qualcosa di nuovo.
Grazie ancora.