C’era una volta il programmatore davanti al <body> bianco : si faceva un’analisi di massima, si riportava tutto facendo riferimento all’entità e alle relazioni e poi si disegnavano bellissime interfacce in puro html e una spruzzatina di javascript.
Programmatori che usavano a stento degli editor e costruivano a mani nude strutture con tabelle, righe e colonne indentate all’inverosimile, che se solo ti scordavi un tag di chiusura potevi far esplodere il monitor, di solito un 14’ a tubo catodico con mascherina ‘anti radiazioni’.
Leggenda vuole che, vista la forza fisica e mentale necessaria per una fatica del genere, molti lavorassero seminudi o coperti solo da pochi stracci.
Citiamo spesso (troppo?) Steve Jobs per la sua genialità nell’innovazione del prodotto, per le sue capacità nel marketing e per tante altre caratteristiche e idee che lo hanno reso, giustamente, un personaggio importantissimo anche per chi non lavora nell’informatica.
Personalmente una delle cose per cui mi piace ricordarlo è stato che ha deciso e decretato la fine di flash praticamente da solo.
Per chi non avesse mai avuto a che fare con Flash, ecco un video che ne mostra le potenzialità
How to Animate a Transformation – In depth Flash Animation Tutorial!
Perché Flash è stato abbandonato? Le ragioni principali :
Elevato consumo di risorse: le animazioni Flash richiedevano un notevole dispendio di risorse hardware, penalizzando le prestazioni di computer e dispositivi mobili.
Problemi di sicurezza: il suo funzionamento “isolato” rispetto al browser lo rendeva vulnerabile a malware e attacchi informatici, mettendo a rischio la privacy degli utenti.
Nonostante la sua scomparsa, Flash Player ha lasciato un’eredità indelebile. Ancora oggi, è possibile imbattersi in contenuti realizzati con questo software. In questi casi, per visualizzarli correttamente, è necessario utilizzare l’apposito player (assicurandosi di avere l’ultima versione disponibile) e tenere sempre a mente i rischi per la sicurezza derivanti dall’esecuzione di tali contenuti su un browser connesso a internet.
Jobs decise che era abbastanza e impose di eliminarlo dai prodotti Apple.
Tabula rasa o quasi, arriva html5 e i social sono ormai dappertutto, anche grazie a Jobs ed al suo iphone, il problema adesso diventa avere la stessa pagina web visibile su una moltitudine di device.
Twitter (oggi x) sforna un framework chiamato Bootstrap dando strumenti pronti e dettando regole precise per far sì che le proprie paginette siano visibili in maniera impeccabile su ogni schermo di qualsiasi misura.
All’inizio è una manna, ci ha un pò uniformato a livello grafico, ma le interfacce erano pulite e minimali e molte “cafonate” sono sparite dal giorno alla notte, notte in cui abbiamo iniziato a dormire invece di cercare ‘important’ sotto ogni tag.
Poi anno dopo anno, annuncio dopo annuncio, i framework sono diventati lo standard e non si è più tornati indietro.
Abbiamo incominciato a dare tutto per scontato, nessuno si è più chiesto come funzionassero certi meccanismi e in nome della velocità ci siamo sempre più affidati a delle “scatole magiche” che risolvevano problemi in maniera assolutamente inintelligibile.
Andando avanti infatti i framework sono diventati più facili da usare ma molto più complessi nel loro codice intrinseco, tanto che pochi hanno continuato a chiedersi cosa ci fosse sotto al cofano perdendo molto know how.
Abbiamo iniziato ad usarli come il classico cannone contro il moscerino:
scaricando mega di codice per fare landing page, o usandoli per garantire uniformità a crud di 4 paginette. Non rimpiango certo il routing fatto modificando htacces a manina, però vorrei tanto che le persone se ne ricordassero, specialmente per capirne i meccanismi e, volendo, personalizzandone il comportamento in casi estremi senza sentirmi rispondere “questo Angular non lo permette”.
Che poi “non lo permette” sono parole grosse; la maggior parte delle volte lo permette ma con un bagno di sangue.
La complessità di certe soluzioni, che fatte senza framework si risolverebbero in poche righe di codice, adottando i framework vi portano in dimensioni parallele dove il su è il giù e viceversa, quindi per non diventare pazzi si fa come dice lui.
Chiaramente, portandosi appresso un blocco enorme di codice, le performance ne risentono.
E ne risentiranno sempre, perchè vista la complessità, pochi saranno in grado di capire esattamente cosa diavolo fa il Javascript sul nostro pezzettino di html.
Coda, prega e mangiati il fegato.
Visto tutto il casino successo sulle vulnerabilità dei moduli npm dell’anno scorso, non voglio soffermarmi più di tanto sul tema della sicurezza : non si può pensare di essere sempre al sicuro e bisogna provvedere a implementare gli strumenti giusti.
Avere a che fare con i framework spesso coinvolge skill e figure professionali diverse come i devops, e se siete dei freelance o dei craftman lo sbattimento è veramente tanto.
Ultimo punto è l’indipendenza, essendo soggetti a continui aggiornamenti e cambiamenti, che possono introdurre incompatibilità o richiedere modifiche significative al codice esistente. Evitare l’uso di un framework significa non dover dipendere da questi, dormendo tranquilli, o quasi, ogni volta che il vostro server installa un aggiornamento.
I framework offrono tantissimi vantaggi e ci permettono di lavorare condividendo best practice, garantendo standard e non dovendo sviluppare tutto from scratch.
Se avessi un euro per ogni maledizione mandata al programmatore fantasma che mi ha lasciato prodotti senza test, senza documentazione e senza commenti che non fossero improperi contro il programmatore che lo aveva preceduto, adesso sarei ricchissimo.
E senza dubbio avrei evitato la figura barbina di dire al cliente “ chi ha scritto questo codice è un deficiente” per sentirmi dire che era codice che avevo scritto io un anno prima.
Quindi da Angular a Slim ben vengano gli strumenti che ci aiutano a risolvere il nostro problema quotidiano, ma attenti a non farvi “incastrare” ricordandovi sempre che quando sbattete la testa su un problema banale risolto in modo astruso potete immaginare il vostro framework vestito come Jessica Rabbit sussurrarvi all’orecchio “Non sono cattiva, è che mi disegnano così…”
Ben sapendo che l’argomento è controverso e che non poteva essere esaurito in poche righe Codemotion ha preparato una Tech Chat per il 13 giugno con Paolo Insogna e Fabio Biondi (uno dei più grandi utilizzatori di ActionScript che io conosca, ogni volta che gli ricordo che Flash è morto lo vedo incupirsi improvvisamente 🙂 )
