Framework front-end: soluzioni o problemi gonfi?

I moderni framework front-end richiedono di scaricare un ambiente di sviluppo, completo di dipendenze, e di compilare il codice prima ancora di provare a visualizzarlo sul browser. È una buona cosa? Il problema è che stiamo costruendo siti più complessi o è che i framework sono complessi di per sé, introducendo un livello di complessità non necessario?

Lo sviluppo web oggi si è evoluto molto dagli anni '90; siamo in grado di creare intere esperienze che sono molto vicine a ciò che può fare qualsiasi applicazione nativa e anche il processo di sviluppo è cambiato. Sono finiti i giorni in cui essere uno sviluppatore web front-end consisteva nell'aprire Blocco note, digitare alcune righe di codice, controllarlo sul browser e caricarlo in una cartella FTP.

Lo sviluppo Web front-end del passato

Devo iniziare affermando l'ovvio: il mondo non è come 10 anni fa. (Scioccante, lo so.) L'unica cosa che rimane costante è il cambiamento. In passato, avevamo pochissimi browser, ma c'erano molti problemi di compatibilità. Oggi non vedi molto cose come "visualizzato al meglio su Chrome 43.4.1", ma all'epoca era abbastanza comune. Ora abbiamo più browser, ma meno problemi di compatibilità. Come mai? A causa di jQuery . jQuery ha soddisfatto la necessità di avere una libreria standard e comune che ti permettesse di scrivere codice JavaScript che manipola il DOM senza doversi preoccupare di come sarebbe stato eseguito su ciascun browser e su ogni versione di ciascun browser: un vero incubo negli anni 2000 .

I browser moderni possono manipolare il DOM come standard, quindi la necessità di una tale libreria è diminuita notevolmente negli ultimi anni. jQuery non è più necessario , ma possiamo comunque trovare una serie di plugin estremamente utili che dipendono da esso. In altre parole, i framework web potrebbero non essere necessari, ma sono comunque abbastanza utili da essere popolari e ampiamente utilizzati. Questo è un tratto comune alla maggior parte dei framework Web più diffusi, da React, Angular, Vue ed Ember a modelli di stile e formattazione come Bootstrap.

Perché le persone usano i framework

Nello sviluppo web come nella vita, avere una soluzione rapida è sempre a portata di mano. Hai mai fatto un router prima in JavaScript? Perché passare attraverso il doloroso processo di apprendimento quando è possibile installare npm-un framework front-end per superare il problema? Il tempo è un lusso quando il cliente vuole che le cose vengano fatte ieri o si eredita il codice da un altro sviluppatore progettato per un particolare framework, o se si sta integrando con un team che già utilizza un determinato framework. Ammettiamolo: i framework esistono per una ragione. Se non ci fossero vantaggi per loro, nessuno li userebbe.

Quindi quali sono alcuni dei vantaggi e delle proprietà uniche dell'utilizzo di un framework di sviluppo web?

Il tempo è denaro. Quando stai sviluppando un progetto e al cliente non importa quale framework usi, anzi, probabilmente non è nemmeno consapevole di ciò che usi, si preoccupa solo di ottenere risultati e più velocemente è meglio è. I framework consolidati ti consentono di creare un senso istantaneo di progresso fin dall'inizio, che il cliente desidera ardentemente dal primo giorno. Inoltre, più velocemente sviluppi, più soldi guadagni, poiché il tempo liberato dal framework può essere reindirizzato ad assumerne di più progetti.

È tutta una questione di comunità. Quando scegli un framework, questo è un punto molto importante: chi ti aiuterà quando rimani bloccato su un problema? Tu ed io sappiamo entrambi che accadrà ad un certo punto. Raggiungerai un punto in cui devi fare qualcosa che il framework non era destinato a fare o che il framework non è mai stato progettato per darti accesso, quindi avere una community che ti supporti è essenziale. Lo sviluppo, in particolare il freelance, può essere difficile, poiché sei immerso in un mondo virtuale e se sei l'unico sviluppatore web front-end in un team, significa che sei l'unico con l'esperienza e le competenze per trovare un soluzione. Ma se il framework front-end che usi ha un supporto solido, ci sarà qualcuno dall'altra parte del mondo che ha affrontato lo stesso problema e potrebbe essere in grado di aiutarti.

Gli standard sono belli. Hai mai notato che, quando guardi in un vecchio pezzo del tuo codice, puoi navigarlo abbastanza facilmente? O almeno, più facilmente di un pezzo di codice scritto da qualcun altro? Pensi in un certo modo e hai il tuo modo di nominare le cose e organizzare il codice. Questo è uno standard. Li seguiamo tutti, anche se sono solo per noi stessi. Tendiamo a mangiare cose simili a colazione, a svegliarci a una certa ora e a mettere le chiavi nello stesso posto ogni giorno. E in effetti, se cambiassimo le nostre routine ogni giorno, la vita sarebbe molto più difficile solo per il sovraccarico di capire come fare le cose. Hai mai perso le chiavi perché le hai riposte in un posto diverso dal normale? Gli standard semplificano la vita. Quando si lavora come parte di un team o di una comunità di sviluppatori, diventano assolutamente indispensabili.

I framework forniscono uno standard dal momento in cui li installi, guidandoti a pensare e a programmare in un modo specifico. Non è necessario perdere tempo a creare uno standard con il tuo team; puoi semplicemente seguire come vengono fatte le cose nel framework. Questo rende più facile lavorare insieme. È più facile cercare una funzione quando sai che la funzione deve trovarsi in un determinato file perché è stata creata per aggiungere un percorso in una SPA e nel tuo framework tutti i percorsi sono inseriti in un file con quel nome. Persone con diversi livelli di abilità possono lavorare insieme se hai questo livello di standardizzazione, perché mentre i programmatori avanzati sanno perché le cose vengono fatte in quel modo, anche gli sviluppatori junior possono seguire lo standard stesso.

Quando i framework falliscono

Alcuni anni fa, dire qualcosa del tipo "Non uso i framework, non ne vedo alcun vantaggio reale" avrebbe portato persone con torce e forconi alla tua porta. Ma oggi, sempre più persone si chiedono: "Perché dovrei usare un framework? ne ho davvero bisogno? È così difficile programmare senza di loro?"

Sono sicuramente uno di loro: non sono mai stato un fan di alcun framework specifico e ho programmato senza di loro per tutta la mia carriera. Se ho una scelta in merito, la mia scelta è sempre "No, grazie". Ho sviluppato in JavaScript per anni e prima ancora in ActionScript. Stavo programmando in Flash quando la maggior parte delle persone lo considerava già morto. (Lo so, lo so... ma stavo facendo un sacco di animazioni, e l'animazione in semplice HTML è difficile.) Quindi, se sei uno dei tanti che non pensa mai alla codifica senza framework, lascia che ti mostri alcuni motivi per cui potresti essere in difficoltà.

"Taglia unica" è una bugia. Riusciresti a immaginare di scrivere un singolo software in grado di fare tutto ciò che hai realizzato nella tua carriera? Questo è uno dei problemi principali con i framework di sviluppo web. Il tuo progetto ha esigenze molto specifiche, che tendiamo a risolvere aggiungendo librerie, plug-in o componenti aggiuntivi per estendere l'ambito del framework. Nessun framework offre il 100% di ciò di cui hai bisogno e nessun framework è composto al 100% da cose che troverai utili.

Avere troppo codice che non usi può comportare un ritardo di caricamento del tuo sito, che diventa più importante con ogni utente aggiuntivo. Un altro problema è che la mentalità "taglia unica" si traduce in un codice inefficiente. Prendi, ad esempio, $('sku-product').html('SKU 909090'); , che è il codice jQuery che, alla fine, sappiamo tutti sarà tradotto in qualcosa come document.getElementById('sku-product').innerHTML = 'SKU 909090'; .

Quel tipo di differenza su una singola riga potrebbe sembrare poco importante, ma cambiare il contenuto di un elemento specifico della pagina è proprio il pregio di React. Ora, React passa attraverso il processo di creazione di una rappresentazione del DOM e analizza le differenze in ciò che si tenta di eseguire il rendering. Non sarebbe più semplice indirizzare il contenuto che desideri modificare dall'inizio?

Quel groviglio di erbacce che stai attraversando sta crescendo spine. Ti sei mai trovato nella situazione in cui stai utilizzando il tuo framework e stai cercando di aggiungere una libreria ad esso, solo per renderti conto che la versione della libreria di cui hai bisogno non funziona bene con la versione del framework che stai utilizzando? A volte è necessario uno sforzo maggiore per far funzionare insieme due parti di codice piuttosto che scrivere il codice da soli. E poiché i framework e le librerie che usi sono spesso costruiti su altri framework e librerie che possono avere incompatibilità nascoste che non puoi nemmeno prevedere, il problema può diventare esponenzialmente più complesso, raggiungendo un punto in cui sono impossibili da gestire se vogliono che il progetto continui a crescere.

Stare al passo con i Jones è una cosa. Hai mai lavorato a un progetto in AngularJS solo per scoprire che hai bisogno di qualcosa che non è apparso fino al rilascio di Angular 4? Sapevi anche che Angular 5 è stato rilasciato? Questo è un altro grosso problema; anche se ti stai attenendo a un unico framework front-end, quando si verifica una nuova versione principale, le cose possono cambiare così tanto che il codice per cui hai lavorato così duramente non verrà nemmeno eseguito sulla nuova versione. Ciò potrebbe comportare qualsiasi cosa, da piccole modifiche fastidiose che devono essere apportate su molti file a una riscrittura completa del codice.

Tenere il passo con le ultime build di un framework è impegnativo, ma nella stessa nota, altri framework soffrono quando gli aggiornamenti si interrompono completamente e non riescono a stare al passo con il resto della tecnologia. Nel 2010, sia AngularJS che Backbone sono stati rilasciati per la prima volta. Oggi Angular è alla sua quinta versione principale e Backbone è completamente fuori dai riflettori. Sette anni mi sembrano tanti. Se crei siti Web, probabilmente sono cambiati completamente nell'estetica e nella funzione. Se stai creando un'app, scommettere sul framework sbagliato potrebbe mettere l'azienda in una situazione difficile e costosa in seguito, quando le cose devono essere riscritte.

Quando tutto ciò che hai è un martello, tutto sembra un chiodo. Se hai utilizzato frequentemente framework di sviluppo web, probabilmente ti è successo, in cui una singola base di codice definisce la forma del codice che utilizzerai in futuro, anche se è solo marginalmente correlato. Diciamo che stai per costruire una piattaforma come YouTube e vuoi usare Framework X. Potrebbe esserci un punto in cui, anche se sembra ridicolo al giorno d'oggi, decidi di usare Flash per i video perché è quello che viene integrato con il quadro.

I framework hanno opinioni e sono forti; React, ad esempio, ti obbliga a usare JSX in un modo specifico. Puoi vedere il codice utilizzato in quel modo ovunque. C'è un'alternativa? Sì. Ma chi lo usa? Questa non è sempre una brutta cosa, ma se devi eseguire animazioni complesse, potresti aver bisogno solo di un framework per l'animazione e non dell'intero React. Ho visto persone fare cose pazze come aggiungere jQuery a una pagina solo per aggiungere un nodo a un elemento, qualcosa che potrebbe essere realizzato in vanilla JS con document.getElementById('id_of_node').appendChild(node); .

Eval è il male, ma .innerHTML è machiavellico

Voglio prendermi il tempo per esplorare questo punto separatamente perché penso che questo sia uno dei motivi per cui più persone non programmano senza framework. Quando vedi come funziona la maggior parte del codice quando provi ad aggiungere qualcosa al DOM, troverai un mucchio di HTML iniettato dalla proprietà .innerHTML . Sembriamo tutti d'accordo sul fatto che eval sia dannoso per l'esecuzione di codice JavaScript, ma qui voglio mettere .innerHTML sotto i riflettori. Quando si inserisce il codice HTML come una semplice stringa, si perde qualsiasi riferimento a uno qualsiasi dei nodi che si è creato. È vero che potresti recuperarli usando getElementsByClassName o assegnando loro un id , ma questo è tutt'altro che pratico. Quando provi a modificare il valore di uno dei nodi, ti ritroverai a eseguire nuovamente il rendering dell'intero HTML.

Questo è buono quando inizi a programmare. Puoi fare molte cose semplici facilmente senza molta esperienza. Il problema si verifica con la complessità dei siti Web moderni, che tendono ad essere più simili alle app: ciò significa che dobbiamo cambiare costantemente i valori dei nostri nodi, il che è un'operazione ad alto costo se lo fai ricollegando l'intera struttura tramite .innerHTML . React risolve questo problema in modo efficiente tramite un DOM ombra e Angular lo risolve utilizzando l'associazione come un modo semplice per modificare un valore mostrato in una pagina. Tuttavia, può anche essere risolto abbastanza facilmente tenendo traccia dei nodi che crei e salvando quelli che verranno riutilizzati o aggiornati nelle variabili. Ci sono anche altri motivi per stare lontano da .innerHTML in generale.

I più grandi miti sulla codifica senza framework

Il tempo è denaro. Sì, sto riportando questo concetto da prima. Molte persone pensano che se smettessero di usare un framework web popolare, passeremo immediatamente all'Internet degli anni '90, quando <marquee> era il tag preferito di tutti, le GIF rotanti su un sito di Geocities erano alla moda e spigolose, Alta Vista era l'ideale per le ricerche sul Web e i contatori di visite erano onnipresenti.

Con i framework web, le prime righe di codice sembrano fare molti progressi per risparmiare tempo, ma a un certo punto i guadagni si trasformano in perdite. Passi il tuo tempo a leggere come fare in modo che il framework faccia cose per cui non è stato creato, come integrare le librerie e farle funzionare bene con il framework e scoprire che il codice che hai creato seguendo gli standard del framework non funziona per funzionare e ora devi riscriverlo. Quando fai le cose senza una struttura, inizi più lentamente, ma fai progressi costanti. Alla fine, si tratta di dove vuoi che sia la parte facile. Non farà molta differenza nel tempo totale.

Il mio codice sarà più lungo della Grande Muraglia. Scrivere senza un framework è come acquistare un film invece di abbonarsi a un servizio di streaming. Non ottieni l'accesso istantaneo a centinaia di film che desideri guardare, ma non devi nemmeno spendere soldi per migliaia di altri film che non prenderesti mai in considerazione di scaricare dallo store. Puoi semplicemente scrivere quello che ti serve.

L'intermediario è utile? Sicuro. Ma di solito non è necessario . Ogni riga di codice che scrivi ha più significato, poiché non è necessario che tu ti adatti ai requisiti di un framework. Può sembrare di scrivere più codice con JavaScript puro perché il modo per creare gli elementi DOM richiede linee per creare un elemento, collegarlo al DOM e forse aggiungere una classe per lo stile, invece di richiamare una singola riga di codice in JSX. Ma se confronti il ​​codice usando una libreria come jQuery o React, vanilla JS può essere abbastanza simile in lunghezza. A volte è più lungo, ma a volte è anche più corto.

Non c'è bisogno di reinventare la ruota. Il mantra dei professori di informatica ovunque. Ed è vero, semplicemente non deve significare specificamente i framework. L'invio di una richiesta Ajax per caricare o salvare dati è un requisito in quasi tutte le app Web, ad esempio, ma non disporre di un framework non significa che sia necessario scrivere di nuovo il codice ogni volta. Puoi creare la tua libreria o codebase, oppure puoi estrarre codice da altri. Più è piccolo, più è facile modificarlo o regolarlo secondo necessità, quindi è utile quando hai bisogno di qualcosa di specifico per un progetto. È più facile modificare 100-200 righe di codice che navigare attraverso la montagna di file che potrebbe contenere una libreria o un framework di terze parti.

Funzionerà solo per piccoli progetti. Questo è un mito molto comune, ma non è affatto vero; attualmente sto lavorando a un intero sistema per gestire tutti gli aspetti di un'azienda online in un unico posto, incluso un modulo simile a Google Drive. Sia con i framework che senza di essi, eseguo passaggi molto simili e incontro problemi molto simili. La differenza è trascurabile. Tuttavia, senza framework, il mio intero codice è più piccolo e più facilmente gestibile.

VOGLIO PROVA

Bene. Smettiamo di parlare di teoria e passiamo a un esempio del mondo reale. Alcuni giorni fa, dovevo mostrare un elenco di marchi con loghi per un negozio. Il codice iniziale utilizzava jQuery, ma presentava un problema per cui, durante il caricamento in Mozilla, mostrava un'icona dell'immagine rotta per i marchi che non avevano ancora loghi caricati. Non possiamo fare in modo che il negozio sembri incompiuto solo perché l'azienda X non ha ancora terminato il lavoro, ma la funzionalità doveva essere pubblicata.

Il codice seguente utilizza l'equivalente jQuery di .innerHTML :

 var list_brand_names = ['amazon', 'apple', 'nokia']; var img_out = ''; for (i=0;i<list_brand_names.length;i++) { var brandName = list_brand_names[i].toLowerCase(); img_out += "<a href='/pages/" + brandName + "'><img src='images/" + brandName + "' /></a>"; } jQuery("#brand-images").html(img_out);

Senza approfondire i pro e i contro di jQuery, il problema qui è che non abbiamo alcun riferimento alle immagini che abbiamo creato. Sebbene ci siano soluzioni che non comportano la modifica del codice, sfruttiamo questa opportunità per vedere come è possibile farlo senza alcuna libreria:

 var brands = ['amazon', 'apple', 'nokia']; var brand_images = document.getElementById("brand-images"); for (var iBrand = 0; iBrand < brands.length; iBrand++) { var link = document.createElement('a'); link.setAttribute('href', '/pages/' + brands[iBrand]); link.style.display = 'none'; brand_images.appendChild(link); var image = new Image(); image.src = "images/" + brands[iBrand] + "png"; image.onload = function(){ this.parentNode.style.display = ''; } link.appendChild(image); }

Il codice jQuery originale era lungo sei righe, mentre la soluzione JS vanilla ne richiedeva dodici. Per risolvere il problema, nascondere ogni immagine finché non è stata caricata, richiede il doppio del tempo per codificare. Quindi diamo un'occhiata all'alternativa. Può essere risolto anche in jQuery? Controlla:

 img_out += "<a href='/pages/" + brandName + "'><img src='images/" + brandName + "' onload="showImage(this)"/></a>"; function showImage(image){ image.parentNode.style.display = ""; }

Con un paio di righe di codice aggiuntive, ora c'è solo una differenza di tre righe tra jQuery e vanilla, ma su jQuery puoi vedere che la riga img_out sta rapidamente diventando molto complessa, al punto in cui devi fare una pausa e pensa attentamente a quello che stai facendo. La codifica del DOM direttamente utilizzando le funzioni del nodo per aggiungere attributi, funzioni e simili potrebbe essere più lunga, ma ogni riga ha un significato più chiaro e preciso, rendendo più facile la lettura e la gestione in futuro.

Diamo un'occhiata a React:

 function BrandLink(props) { var url = "images/" + props.brand + ".png"; return (<a href="{props.brand}"><img src={url}/></a>); } class Brands extends React.Component { constructor() { super(); this.state = {brands: ['amazon', 'apple', 'nokia']}; } render() { const links = this.state.brands.map((step, move) => { return (<BrandLink brand={step} key={step}/>); }); return (<div className="brands">{links}</div>); } } ReactDOM.render(<Brands />, document.getElementById("root"));

Questa versione è chiaramente non ottimale. Il codice non è più breve di quello in vanilla e non siamo nemmeno arrivati ​​al punto di risolvere il problema e nascondere i collegamenti fino a quando l'immagine al loro interno non è stata caricata.

Per ogni esempio, i risultati saranno diversi. A volte, jQuery sarà più breve. A volte, React vincerà. Ci sono momenti in cui vanilla JS può essere più breve di entrambi. In ogni caso, l'obiettivo qui non era quello di dimostrare che uno era intrinsecamente superiore all'altro, ma di dimostrare che non c'è una differenza significativa tra l'utilizzo di JS vaniglia e l'utilizzo di un framework quando si tratta di lunghezza del codice.

Conclusione

Come per quasi tutti i problemi della vita reale, niente è bianco o nero. La codifica senza framework di sviluppo web potrebbe essere la soluzione migliore per alcuni dei tuoi progetti e un incubo in altri. Proprio come con ogni strumento, la chiave sta nell'imparare non solo come usarlo, ma quando e quali potrebbero essere i vantaggi e gli svantaggi dell'utilizzo. La codifica in puro JavaScript è proprio come con qualsiasi framework: padroneggiarlo richiede tempo prima che tu ti senta a tuo agio nell'usarlo.

Ma la differenza fondamentale, almeno per me, è che i framework vanno e vengono, e anche se un framework è popolare da molto tempo, può cambiare drasticamente da una versione all'altra. JavaScript puro sarà un'opzione per molto più tempo, fino a quando non smetterà di essere del tutto rilevante e emergerà qualche altro linguaggio. Anche in questo caso, ci saranno più concetti e strategie che puoi migrare direttamente da una lingua a un'altra di quanto tu possa fare con un dato framework a un altro. Essendo il tempo e lo sforzo più o meno equivalenti per un singolo progetto, la riduzione del deprezzamento delle conoscenze e le lezioni che puoi portare con te alla prossima sfida sono fattori molto importanti da considerare.