Archivi categoria: javascript

Web App e App per smartphone: 12 regole per Javascript

front end, javascript,

Ti avverto: sotto parlo in assoluti per brevità (quasi ogni regola in programmazione ha eccezioni).

Oggi, la maggioranza delle Applicazioni Web sono scritte in HTML5, CSS3 e JS. Se sei un imprenditore, e hai una bella idea per il mercato online, ma ti serve una interfaccia web che anche tua nonna saprebbe usare, go for it!

  • HTML5 è HTML, non c’è niente di magico in cosa fa, ma per fortuna i browser sono sempre più robusti veloci e capaci, e quindi novità minime creano funzionalità importanti, che fanno notizia (peccato per la retro-compatibilità con le versioni precedenti…)
  • CSS3 serve giusto per rendere la grafica gradevole.
  • JS, o JavaScript, è il re del trio, quello che fa la differenza. JS è una brutta bestia. Si evolve così velocemente che spesso non sai se lo usi male. Talvolta, le parti cattive sembrano più di quelle buone. Personalmente, mi vergogno un pò di come ho scritto spediamo.it, meglio con smartfix.it, ma sono orgoglioso dalla segretaria virtuale in poi.

Questa settimana, mi prendo una pausa dalle tematiche di Web Marketing e SEO, e dò consigli – forse – più ai programmatori che vorrai assumere, se ti è venuta una bella idea di prodotto e vuoi una interfaccia web funzionale e semplice per tutti.

libri javascript
Non combatterlo, JavaScript sta conquistando il mondo. Pensa a scriverlo bene.

1. Metti JS in un file .js

Intendo tutto quel che hai. Perchè? Aiuta la leggibilità, rafforza la struttura e salva banda. JavaScript inline si scarica ogni volta che la pagina si carica, invece i file .js separati vanno in cache. Questa regola aiuta a supportare la lunga lista di regole sotto, per cui è la regola #1.

2. Il codice JS dovrebbe essere statico

Ho visto molti hack creativi per rendere JavaScript dinamico. C’è chi usa linguaggi server-side come C# Ruby o Java per scrivere JavaScript dinamico in una stringa. Non farlo. Perdi colore al codice, evidenza della sintassi e supporto intellisense. Tu tieni JavaScript in un file .js (regola #1).

Piuttosto, usa JSON per il comportamento dinamico. Lo chiamo JavaScript Configuration Object Pattern. Ecco come: inietta JSON in testa all’applicazione e usa quei dati per forkare la logica quando serve. Magari pensi “Ahi, contraddice la regola #1”, io vedo JSON come dati, non codice, per cui faccio un eccezione per supportare file JavaScript separati e statici.

StackOverflow usa questo pattern. Come fa Google. Sei in buona compagnia. Guarda il loro codice: StackOverflow inietta le impostazione personali come isNoticesTabEnabled, uno snippet di JSON che dà i dati utili per avere comportamento dinamico mentre usi file di codice JavaScript statici. Per farlo anche tu, serializza una classe server-side in JSON e piazza il risultato in <head>, poi referenzia quella struttura dati alla bisogna nel codice JavaScript statico, sapendo che sarà disponible proprio perchè è iniettato in <head>.

3. Minifica JS

Minificare riduce le dimensioni dei file, il chè velocizza il caricamento pagina. Ricorda, la performance è una funzionalità. E certo, per minificare, ti serve inserire JavaScript in un file a parte (di nuovo, regola #1). Una volta la minificazione era ardua, oggi è automatico e semplice. Ci sono molti modi per farlo ma io preferisco Gulp con gulp-uglify.

4. JS va in fondo

I tag <script> in <head> bloccano il rendering. Gli script in <head> sono caricati prima che il body sia visualizzato. Quindi, inserire i tag <script> in fondo alla pagina appena prima di </body> le permette di essere visibile, senza aspettare che i tuoi script siano (s)caricati. Questo migliora la performance percepita, dando ai tuoi utenti qualcosa da vedere subito. Se scrivi JavaScript in <head>, almeno usa $(document).ready di jQuery, così lo script non gira finchè il DOM non è pronto.

5. JS dovrebbe essere lintato in tempo reale

Il linting rafforza le linee guida di stile, trova refusi ed evita gli errori. Consiglio ESLint, che puoi eseguire via Gulp con gulp-eslint. Gulp può esaminare tutti i tuoi file JS ed eseguire il linter ogni volta che premi Salva. Oh, e di nuovo, hai bisogno di inserire JS in un file .js separato per fare lint. Cominci a capire perchè ho creato la regola #1 “JS va in un file separato”?

6. JS dovrebbe avere test automatici

Anni fa, i test per il server erano importanti, ma sono stati completamente ignorati in JavaScript fino a ieri. Oggi, una tipica applicazione JavaScript è così grande che non te la cavi facendo test a mano una volta ogni tanto. Con JavaScript che maneggia così tanta logica, è (quasi) obbligatorio ricorrerere a test automatici.

Puoi fare automated integration testing con tool come Selenium ma è roba fragile, per cui suggerisco di focalizzarti sul cosìdetto automated unit testing. Ci sono parecchie opzioni per l’automated unit testing: consiglio Jasmine se sei nuovo e Mocha con Chai se hai un debole per la configurabilità.

7. JS dovrebbe essere incapsulato

Conosci il pericolo delle variabili globali da anni. Per fortuna, oggi, ci sono molto modi di incapsulare JavaScript:

I moduli ES6 sono il futuro. La grande notizia è che già adesso, sebbene non sono ancora supportati dai browsers, puoi usare i moduli ES6 se fai transpile con Babel (aspetta #9 per riuscirci).

Se non vuoi fare transpile, CommonJS è probabilmente la miglior scelta. Visto che Node usa i pattern di CommonJS, puoi usare npm per importare il pacchetto che vuoi. Ma CommonJS non gira su browser senza shim, quindi usa un tool che lo pacchettizzi come Browserify Webpack o JSPM.

8. Le dipendenze JS dovrebbero essere esplicite

Questa regola è strettamente connessa alla #7. Una volta cominciato a incapsulare il tuo JavaScript, hai bisogno di un modo facile di referenziare altri moduli. Questa è la bellezza di sistemi di moduli moderni come CommonJS e i moduli ES6. Specifichi semplicemente le tue dipendenze all’inizio del file, proprio come un import o istruzioni affini in Java o C#. JavaScript è finalmente cresciuto.

//CommonJS
var react = require(‘react’);
//ES6 Modules
import React from ‘React’

9. Transpila a JS

L’ultima versione di JavaScript, EcmaScript 2015 (aka ES6), è stata ufficialmente rilasciata in Giugno. I browser non supportano ancora la maggior parte delle nuove feature, ma non importa. Oggi puoi goderti la lunga lista di nuove funzionalità usando Babel. Babel transpila ES6 a ES5. E assumendo che puoi vivere con qualche quick di performance, puoi spassartela già adesso. Ci sarà un nuovo rilascio di JavaScript ogni anno, così è probabile che faremo transpiling per sempre. Lo transpiling ci dà il futuro oggi.

O forse sei più quello che ama i tipi strong? Allora considera TypeScript che compila giù fino a JavaScript.

Il punto è:

Non devi più scrivere ES5. Usa un'astrazione che ti dà potere extra.

10. JS dovrebbe avere un build automatico

Abbiamo già parlato di linting, minificazione, transpilation e testing. Ma come lo fai automaticamente? Semplice: con un build automatico che esamina i file. Di nuovo, Gulp è un tool popolare per incollare tutto con la sua watch function, ma anche Grunt e  Webpack sono opzioni eccellenti. O, se sei un mago con Bash, puoi semplicemente usare npm come tool di build. Il punto è di non aspettarti che i tecnici si ricordino di eseguirlo manualmente, automatizza e goditi i benefici!

11. Usa un Framework o Librerie

Allo scaffale hai l’imbarazzo della scelta. Vuoi stare leggero? Prova Backbone o Knockout. Anche solo jQuery è sufficiente. Vuoi qualcosa con più funzionalità e presuntuoso? Prova Angular Ember o React con Flux.

Il punto è:

Non rifare la ruota. Stai sulle spalle dei giganti.

React con Flux sarebbe anche il mio combo favorito per lo sviluppo client-side, ma per i committenti faccio il programmatore e poi il seo e poi il customer care in fase di startup, per cui preferisco un approccio lean e scelgo Backbone.

Indipendentemente dal framework, assicurati di separare le tue “tematiche”. Il chè porta al prossimo punto…

12. JS dovrebbe separare le “tematiche”

È facile assuefarsi ad inserire tutto il JavaScript in un singolo file, o seguire ciecamente i consigli del tuo framework. Non dimenticare le lezioni che hai imparato sul server, quando passi al client.

Separando le tematiche, non intendo solo modelli viste e controllori, come fai in framework stile MV* tipo Angular e Knockout. Sto dicendo:

Quando scrivi JavaScript, pensa come un programmatore server-side. Separa la presentazione dalla logica di business e dall'accesso ai dati.

Significa mettere tutte le chiamate AJAX in un posto. Crea un “data access layer” centralizzato client-side. Questo significa anche che la logica dovrebbe stare in “POJO” separati (Plain ‘ol JavaScript objects). I moduli di logica business dovrebbero contenere semplice JavaScript — in altre parole, nessun codice specifico del framework dovrebbe risiedere dentro. Ciò rende la logica facile da riusare e da testare, in più non cambia se abbandoni Angular per la nuova figata del mese.

Bè, tanta roba, vero?

Sì, lo è.

Siamo entrati in un’era dove il front-end è tanto complicato da richiedere specialisti front-end.

Sei interessato a migliorare i processi di sviluppo del tuo front-end? Offro consulenza on-site su pratiche di coding pulito e sviluppo di web app moderne.

Interessato? Parliamone.

Non sei d’accordo? Mancano dei pezzi? Dì la tua.

authorAutore: Johnny T. è sviluppatore full-stack, seo, copywriter e specialista in marketing web. In aggiunta a creare interfacce user-friendly come spediamo.it e smartfix.it ed a lanciare progetti come la segretaria virtuale, Johnny si diverte a leggere libri eccezionali e a pensare di avere ancora del tempo libero. Contattalo su LinkedIn.