Il mio primo CSSday

Venerdì 1 aprile 2022 ho partecipato come speaker al CSSday, evento a tema CSS organizzato dal GrUSP, portando “Framework CSS si o no? Questo è il dilemma”. Non era il primo talk dal vivo, ma il mio primo CSSday si.

Il mio talk voleva essere un momento di confronto tra me e il pubblico, perché ho pensato che non c’è posto migliore per scoprire punti di vista nuovi sul CSS se non tra gli speaker e il pubblico di un evento dedicato al CSS. Quindi slide alla mano e un pò d’ansia (sempre presente quando si parla in pubblico) ho fatto questo breve talk di circa 15-20 minuti poi subito ho lanciato la palla al pubblico. Il confronto che ho avuto con loro è stato davvero qualcosa di inaspettato, moltissime domande e spunti di riflessione.

Un evento davvero indimenticabile e organizzato alla perfezione in ogni dettaglio.

Di seguito vi lascio un riassunto del mio talk e le slide che ho utilizzato.

Framework css si o no? ovviamente la risposta è dipende

Il css può essere scritto nei seguenti modi, ovviamente se state seguendo questo evento li conoscerete già tutti ma faccio giusto un ripasso veloce

• css → css nativo, senza build tooling, robusto dato che sta resistendo nel tempo evolvendosi alle nuove necessità
• sass, less & stylus → sass è il più famoso dei pre-processori css. ha un processo di build quindi pregi e difetti, si possono concatenare file, fare minificazione, utilizza una cache. less e stylus sono pre-processori per il node-land (il mondo di node)
• css modules → (sviluppato in postcss → post-processore) processo di build fatto da webpack o simili che modifica i nomi delle classi e dei selettori per avere uno scope locale. I file possono essere scritti in css oppure con sass/less
• css-in-js → vue, angular, svelte → hanno il loro modo di farti scrivere del css, react → styled component, styled-jsx, emotion
• framework css → tailwind (utility-first), bootstrap (object-first)

Detto ciò darei un occhiata all’evoluzione di queste tecnologie per capire meglio in che contesto sono nate ognuna di queste tecnologie

• 1994 CSS
• 1996 primo utilizzo del CSS
• 2006 Yahoo UI kit
• 2007 SASS
• 2011 Bootstrap
• 2013 Atomic Design → We’re not designing pages, we’re designing systems of components.
• 2014 Material Design
• 2014 BassCSS
• 2015 CSS Module
• 2016 Style Component, Storybook
• 2017 TailwindCSS

Dove voglio andare a parare? Che dipende dal tipo di progetto visto che di tecnologie a disposizione ne abbiamo diverse.

Layout-oriented e Atomic-oriented

Prima di procedere vorrei introdurre due concetti, layout-orientend e atomic-oriented. Per layout-oriented intendo i design che vengono forniti a pagine mentre atomic-oriented è il design a componenti.

Fino a qualche anno fa si tendeva a fare il design in base al framework css che si utilizzava, purtroppo, oramai però ci sono altri metodi secondo me migliori.

Quindi framework CSS si o no?

Piccoli progetti e MVP

Se si ha in mano lo sviluppo di una landing page o di un mvp (minimum viable product) dove si hanno dei layout da replicare, quindi layout-orientend, conviene andare con un utility-first, dove si ha massima flessibilità a differenza di un framework object-first, e delle prestazioni discrete visto che viene compilato e con postcss vengono eliminate tutte le classi che non ci servono.

Attenzione però che si lavora con micro-frontend bisogna ricordarsi che quando usiamo questi strumenti ci portiamo dentro comunque un file css compilato che può essere “pulito” se utilizziamo lo shadow dom ma va comunque tenuto sotto controllo l’utilizzo di più tecnologie css insieme.

Quando si sviluppa layout-orientend abbiamo bisogno di molta libertà senza dover pensare subito a tutti i possibili componenti atomici.

Utility-first

Con l’approccio l’utility-first ci portiamo dietro un debito tecnico, cioè quello di dover imparare il framework utilizzato che per quanto sia vicino al css non si scrive del vero css. Questo debito tecnico può essere anche positivo se pensiamo che molti sviluppatori odiano scrivere css, quindi utilizzando questo tipo di strumenti si trovano avvantaggiati, come anche chi non conosce bene il css ma vuole ottenere un risultato bello e il più velocemente possibile. Oltre a questo abbiamo il fatto che deve essere compilato e “pulito” da postcss, ma che comunque non ci salva da progetti molto grandi dove vengono utilizzati più framework css e dove il risultato sarà un vero melting pot. Il debito oltre che essere tecnico è anche “formativo” nel senso che già il css rilascia aggiornamenti, ovviamente i vari framework rilasciano i propri aggiornamenti (e bug fixing) quindi bisogna ipoteticamente essere aggiornati su entrambi.

Pre-processori

Con l’approccio dei pre-processori abbiamo ovviamente la potenza di strumenti come mixin, possibilità di una sintassi innestata, dividere gli stili e importare solo quelli strettamente necessari. Qui come nell’approccio utility-first ci portiamo dietro un debito tecnico anche se di tipo differente rispetto a quello precedente, perché con sass iniziamo ad avere qualcosa di più simile ad un linguaggio css che di qualcosa immerso nel javascript, quindi il dev deve avere confidenza con il mondo css e non necessariamente con il mondo javascript.

Progetti medio-grandi

Se abbiamo in mano progetti medi o grandi dove il reparto design ha studiato e realizzato un design system completo, quindi parliamo di atomic-oriented, possiamo procedere su tre strade: da una parte abbiamo la strada dell’utility-first dove andremo ad utilizzare un framework come tailwind, dall’altra parte invece abbiamo la scelta del css-in-js, nativo se usa vue/angular, o meno se si utilizza react, che incapsula il css dentro al componente svincolando il singolo componente dal css globale, in ultimo abbiamo la possibilità di utilizzare pre-processori come sass. Tutti questi approcci sono buoni e ognuno di questi hanno anche dei difetti.

In questa tipologia di progetti può venirci in aiuto uno strumento come Storybook che ci permette di vedere ogni singolo componente potendo variare le varie prop direttamente da questa dashboard e di andare quindi a testare il design e avere una sorta di “versionamento del design”.

Conclusione

“L’abito non fa il monaco, ma aiuta a riconoscerlo”.

Da anni sento dire che scrivere css non è come scrivere codice, che un bravo o una brava developer non scrive css... ecco io penso si sbaglino. Rendere l’interfaccia utente il migliore possibile non è un compito ad esclusiva del team design, ma è un lavoro che va fatto insieme ai/alle developer soprattutto con chi scriverà il CSS.

Qualsiasi sito o web-app con una algoritmo o logica impeccabile ma senza una buona interfaccia grafica non avrà lunga vita (ovviamente il concetto di “buona grafica” è in relazione al target degli utenti). Quindi chi sviluppa CSS ha un ruolo chiave nella buona riuscita del prodotto e della sua crescita.

Infine vi lascio il link alle slide.

Grazie e alla prossima! 😊