{"id":7001037,"date":"2019-04-23T08:14:16","date_gmt":"2019-04-23T08:14:16","guid":{"rendered":"https:\/\/alistapart.com\/it\/?post_type=article&p=7001037"},"modified":"2019-10-23T09:56:35","modified_gmt":"2019-10-23T09:56:35","slug":"javascript-responsabile-parte-prima","status":"publish","type":"article","link":"https:\/\/alistapart.com\/it\/article\/javascript-responsabile-parte-prima\/","title":{"rendered":"JavaScript Responsabile: parte prima"},"content":{"rendered":"\n

Stando ai numeri, JavaScript \u00e8 un peso in termini di performance<\/a>. Se questo trend persiste, a breve, la pagina media invier\u00e0 almeno 400 KB di JS e questo \u00e8 a malapena quello che viene trasferito<\/em>. Come altre risorse basate su testo, JavaScript \u00e8 quasi sempre inviato compresso, ma ci\u00f2 potrebbe essere l’unica cosa consistente riguardo al suo invio.<\/p>\n\n\n\n

Sfortunatamente, sebbene ridurre il resource transfer time \u00e8 una parte importante dell’intera questione della performance, la compressione non ha effetti sul tempo impiegato dai browser per processare uno script una volta che arriva nella sua interezza. Se un server invia 400 KB di JavaScript compresso, la quantit\u00e0 effettiva che i browser devono processare dopo la decompressione \u00e8 pi\u00f9 di un megabyte. Quando bene i device gestiscano questi carichi pesanti dipende, beh, dal device<\/em>. \u00c8 stato scritto molto<\/a> su quanto siano abili i vari device nel processare molto JavaScript, ma la verit\u00e0 \u00e8 che la quantit\u00e0 di tempo che occorre per processarne anche una quantit\u00e0 trascurabile varia enormemente tra device.<\/p>\n\n\n\n

Prendete, per esempio, questo mio progetto buttato l\u00ec tanto per fare<\/a>, che invia circa 23 KB di JavaScript non compresso. Su un MacBook Pro mid-2017, Chrome si pappa questo piccolo carico in circa 25 ms. Tuttavia, su un telefono Nokia 2 Android<\/a>, questo tempo schizza a 190 ms. Non \u00e8 una quantit\u00e0 di tempo insignificante, ma in ciascun caso, la pagina diventa interattiva in un tempo ragionevolmente veloce.<\/p>\n\n\n\n

Adesso la grande domanda: come pensate che si comporter\u00e0 quel piccolo Nokia 2 con la pagina media? Soffoca. Anche su una connessione veloce, usarlo per navigare nel web lo fa diventare un esercizio di pazienza dato che le pagine web piene zeppe di JavaScript lo rendono simile a un mattone per la maggior parte del tempo.<\/p>\n\n\n\n

\"A
Figura 1. <\/em>Una panoramica della performance timeline di un telefono Nokia 2 Android mentre naviga su una pagina in cui del JavaScript eccessivo monopolizza il thread principale.<\/figcaption><\/figure>\n\n\n\n

Sebbene sia i device sia le reti su cui navigano siano in continuo miglioramento, ci stiamo mangiando quei guadagni, come suggeriscono i trend. Dobbiamo usare JavaScript responsabilmente<\/em>. E si comincia dal comprendere quello<\/em> che stiamo creando cos\u00ec come il modo<\/em> in cui lo stiamo creando.<<\/p>\n\n\n\n

La forma mentale di \u201csiti\u201d vs. \u201capp\u201d<\/h2>\n\n\n\n

La terminologia a volte \u00e8 strana: identifichiamo genericamente cose con termini inaccurati il cui significato \u00e8 compreso da tutti. A volte sovraccarichiamo il termine \u201cape\u201d per indicare anche \u201cvespa\u201d, nonostante le differenze tra api e vespe siano sostanziali, a tal punto da indurvi a gestire ciascuna delle due in maniera diversa. Per esempio, dovreste distruggere un nido di vespe, ma dal momento che le api sono insetti incredibilmente benefici e vulnerabili, potremmo optare per una ricollocazione del loro nido.<\/p>\n\n\n\n

Potremmo essere altrettanto rapidi e approssimativi nello scambiare i termini \u201cwebsite\u201d e \u201cweb app\u201d. Le differenze tra i due sono meno chiare di quelle tra vespe e api, ma fonderli pu\u00f2 portare a risultati dolorosi, derivanti dalle possibilit\u00e0 che ci concediamo quando qualcosa \u00e8 semplicemente un \u201csito web\u201d rispetto a quando \u00e8 una \u201cweb app\u201d completa. Se state facendo un sito web informativo per un’azienda, ci saranno meno probabilit\u00e0 che vi appoggerete a un potente framework per gestire i cambiamenti nel DOM o per implementare il routing client-side, almeno spero<\/em>. Usare tools cos\u00ec poco adatti per questo compito non solo sarebbe dannoso per le persone che usano il sito ma probabilmente anche meno produttivo.<\/p>\n\n\n\n

Quando realizziamo una web app<\/em>, per\u00f2, dobbiamo stare attenti<\/em>. Stiamo installando dei package che danno inizio a centinaia, se non migliaia<\/em>, di dipendenze, alcune delle quali<\/a> non sappiamo nemmeno se siano sicure. Stiamo anche scrivendo delle configurazioni complicate per i module bundlers. In questo tipo di ambiente di sviluppo delirante ma tuttavia onnipresente, occorre conoscere e stare attenti per essere sicuri che quello che viene creato sia veloce e accessibile. Se dubitate di ci\u00f2, eseguite npm ls --prod<\/code><\/a> nella root directory del vostro progetto e vedete se riconoscete tutto quello che c’\u00e8 nell’elenco.<\/a> Anche in caso affermativo, questo comando non include gli script di terze parti, e sono sicuro che il vostro sito ne ha almeno qualcuno.<\/p>\n\n\n\n

Quello che tendiamo a dimenticare \u00e8 che l’ambiente occupato da website e web app \u00e8 unico ed \u00e8 lo stesso. Entrambe sono soggetti alle stesse pressioni ambientali<\/em> imposte dall’ampio spettro di reti e device. Questi vincoli non svaniscono improvvisamente quando decidiamo di chiamare \u201capp\u201d quello che creiamo, n\u00e9 i telefoni dei nostri utenti guadagnano nuovi poteri magici quando lo facciamo.<\/p>\n\n\n\n

\u00c8 nostra responsabilit\u00e0 valutare chi usa quello che realizziamo e accettare che le condizioni sotto le quali accedono a internet possano essere diverse da quello che abbiamo supposto. Dobbiamo conoscere il risultato che stiamo cercando di offrire e solo allora<\/em> potremo creare qualcosa che mirabilmente miri a quello scopo, anche se non \u00e8 esaltante da realizzare<\/a>.<\/p>\n\n\n\n

Ci\u00f2 significa rivalutare la nostra dipendenza da JavaScript e come il suo uso, in particolare quando esclude HTML e CSS, pu\u00f2 tentarci ad adottare pattern insostenibili che danneggiano performance e accessibilit\u00e0.<\/p>\n\n\n\n

Non permettete ai framework di forzarvi ad usare pattern insostenibili<\/h2>\n\n\n\n

Sono stato testimone di alcune strane scoperte nelle codebase mentre lavoravo con dei team che dipendevano dai framework per poter essere altamente produttivi. Una caratteristica comune a molti di loro \u00e8 la scarsa accessibilit\u00e0 e i pessimi pattern di performance che spesso ne derivano. Prendete, per esempio, il componente React qui sotto:<\/p>\n\n\n\n

import React, { Component } from \"react\";\nimport { validateEmail } from \"helpers\/validation\";\n\nclass SignupForm extends Component {\n  constructor (props) {\n    super(props);\n\n    this.handleSubmit = this.handleSubmit.bind(this);\n    this.updateEmail = this.updateEmail.bind(this);\n    this.state.email = \"\";\n  }\n\n  updateEmail (event) {\n    this.setState({\n      email: event.target.value\n    });\n  }\n\n  handleSubmit () {\n    \/\/ If the email checks out, submit\n    if (validateEmail(this.state.email)) {\n      \/\/ ...\n    }\n  }\n\n  render () {\n    return (\n      
\n        Enter your email:<\/span>\n        \n