Circa 15 anni fa lavoravo in un'azienda in cui creavamo app per agenti di viaggio, lavoratori aeroportuali e compagnie aeree. Abbiamo anche creato il nostro framework interno per i componenti dell'interfaccia utente e le funzionalità delle app a pagina singola. Avevamo componenti per tutto: campi, pulsanti, schede, intervalli, tabelle dati, menu, datepicker, selezioni e selezioni multiple. Avevamo anche una componente div. Il nostro componente div era eccezionale tra l'altro, ci permetteva di ottenere angoli arrotondati su tutti i browser, il che, che ci crediate o no, non era una cosa facile da fare in quel momento.

Il nostro lavoro ha avuto luogo in un momento della nostra storia in cui JS, Ajax e l'HTML dinamico erano visti come una rivoluzione che ci ha portato nel futuro. All'improvviso, potevamo aggiornare una pagina in modo dinamico, ottenere dati da un server ed evitare di dover navigare verso altre pagine, che veniva considerata lenta e faceva lampeggiare un grande rettangolo bianco sullo schermo tra le due pagine. C'era una frase, resa popolare da Jeff Atwood (il fondatore di StackOverflow), che diceva: “Qualsiasi applicazione che può essere scritta in JavaScript prima o poi verrà scritta in JavaScript.”— Jeff Atwood

Per noi in quel momento, sembrava una sfida andare a creare davvero quelle app. Sembrava un'approvazione totale per fare tutto con JS. Quindi abbiamo fatto tutto con JS e non ci siamo presi il tempo di ricercare altri modi di fare le cose. Non sentivamo davvero l’incentivo ad apprendere adeguatamente cosa potevano fare HTML e CSS. Non percepivamo davvero il Web come una piattaforma di app in evoluzione nella sua interezza. Per lo più lo vedevamo come qualcosa su cui dovevamo lavorare, soprattutto quando si trattava del supporto del browser. Potremmo semplicemente utilizzare più JS per portare a termine le cose. Prendermi del tempo per saperne di più su come funzionava il web e cosa era disponibile sulla piattaforma mi avrebbe aiutato? Certo, probabilmente avrei potuto eliminare un sacco di codice che non era veramente necessario. Ma, all’epoca, forse non così tanto. Vedete, le differenze tra i browser allora erano piuttosto significative. Era un periodo in cui Internet Explorer era ancora il browser dominante, con Firefox al secondo posto, ma iniziava a perdere quote di mercato a causa della rapida popolarità di Chrome. Sebbene Chrome e Firefox fossero abbastanza bravi nel concordare gli standard web, gli ambienti in cui venivano eseguite le nostre app ci hanno costretto a supportare IE6 per molto tempo. Anche quando ci è stato permesso di supportare IE8, abbiamo dovuto fare i conti con molte differenze tra i browser. Non solo, ma il web dell'epoca non aveva molte funzionalità integrate direttamente nella piattaforma.

Avanti veloce fino ad oggi. Le cose sono cambiate enormemente. Non solo disponiamo di queste funzionalità come mai prima d’ora, ma è anche aumentata la velocità con cui diventano disponibili. Vorrei quindi porre nuovamente la domanda: prendersi il tempo per saperne di più su come funziona il web e cosa è disponibile sulla piattaforma ti aiuterebbe oggi? Assolutamente sì. Imparare a comprendere e utilizzare la piattaforma web oggi ti offre un enorme vantaggio rispetto ad altri sviluppatori. Che tu lavori su prestazioni, accessibilità, reattività, tutti insieme o semplicemente sulle funzionalità dell'interfaccia utente, se vuoi farlo come ingegnere responsabile, conoscere gli strumenti a tua disposizione ti aiuta a raggiungere i tuoi obiettivi più velocemente e meglio. Alcune cose per le quali potresti non aver più bisogno di una biblioteca Sapendo cosa supportano i browser oggi, la domanda, quindi, è: cosa possiamo abbandonare? Abbiamo bisogno di un componente div per ottenere angoli arrotondati nel 2025? Naturalmente no. La proprietà border-radius è supportata da tutti i browser attualmente utilizzati da più di 15 anni. E presto arriverà anche la forma degli angoli, per angoli ancora più elaborati. Diamo un'occhiata alle funzionalità relativamente recenti che sono ora disponibili in tutti i principali browser e che puoi utilizzare per sostituire le dipendenze esistenti nella tua base di codice. Il punto non è abbandonare immediatamente tutte le tue amate librerie e riscrivere la tua base di codice. Come per tutto il resto, dovrai prima prendere in considerazione il supporto del browser e decidere in base ad altri fattori specifici del tuo progetto. Le seguenti funzionalità sono implementate nei tre motori browser principali (Chromium, WebKit e Gecko), ma potresti avere requisiti di supporto del browser diversi che ti impediscono di utilizzarli immediatamente. Ora è ancora un buon momento per conoscere queste funzionalità e magari pianificare di utilizzarle prima o poi. Popover e dialoghi L'API Popover, l'elemento HTML

e lo pseudo-elemento ::backdrop possono aiutarti a eliminare le dipendenze da popup,tooltip e librerie di finestre di dialogo, come Floating UI, Tippy.js, Tether o React Tooltip. Gestiscono l'accessibilità e la gestione del focus per te, immediatamente, sono altamente personalizzabili utilizzando i CSS e possono essere facilmente animati. Fisarmoniche L'elemento
, il suo attributo name per elementi mutuamente esclusivi e lo pseudo-elemento ::details-content eliminano la necessità di componenti Accordion come Bootstrap Accordion o React Accordion. Il semplice utilizzo della piattaforma qui significa che è più facile per le persone che conoscono HTML/CSS comprendere il tuo codice senza dover prima imparare a utilizzare una libreria specifica. Significa anche che sei immune da modifiche sostanziali alla libreria o dall'interruzione di quella libreria. E, naturalmente, ciò significa meno codice da scaricare ed eseguire. Gli elementi di dettaglio che si escludono a vicenda non necessitano di JS per l'apertura, la chiusura o l'animazione. Sintassi CSS Livelli a cascata, per una base di codice CSS più organizzata, annidamento CSS, per CSS più compatti, nuove funzioni di colore, colori relativi e mix di colori, nuove funzioni matematiche come abs(), sign(), pow() e altre aiutano a ridurre le dipendenze dai preprocessori CSS, dalle librerie di utilità come Bootstrap e Tailwind o persino dalle librerie CSS-in-JS runtime. Il punto di svolta :has(), una delle funzionalità più richieste da molto tempo, elimina la necessità di soluzioni più complicate basate su JS. Utilità JS I moderni metodi Array come findLast() o at(), così come i metodi Set come differenza(), intersezione(), union() e altri possono ridurre le dipendenze da librerie come Lodash. Query sui contenitori Le query sul contenitore fanno sì che i componenti dell'interfaccia utente rispondano a fattori diversi dalla dimensione del viewport e quindi li rendono più riutilizzabili in contesti diversi. Non è più necessario utilizzare una libreria dell'interfaccia utente pesante per JS per questo e non è nemmeno necessario utilizzare un polyfill. Disposizione Grid, subgrid, flexbox o multi-colonna esistono ormai da molto tempo, ma guardando i risultati dei sondaggi sullo stato dei CSS, è chiaro che gli sviluppatori tendono ad essere molto cauti nell'adottare nuove cose e aspettano molto tempo prima di farlo. Queste funzionalità sono di base da molto tempo e potresti usarle per eliminare le dipendenze da cose come il sistema di griglia di Bootstrap, le utilità flexbox di Foundation Framework, la griglia fissa Bulma, la griglia Materialise o le colonne Tailwind. Non sto dicendo che dovresti abbandonare il tuo framework. Il tuo team lo ha adottato per un motivo e rimuoverlo potrebbe essere un grande progetto. Ma guardare cosa può offrire la piattaforma web senza un wrapper di terze parti in più comporta molti vantaggi. Cose di cui potresti non aver più bisogno nel prossimo futuro Ora diamo una rapida occhiata ad alcune delle cose per le quali non avrai bisogno di una libreria nel prossimo futuro. Vale a dire, le cose che seguono non sono ancora pronte per l'adozione di massa, ma esserne consapevoli e pianificare un potenziale utilizzo successivo può essere utile. Posizionamento dell'ancora Il posizionamento dell'ancora CSS gestisce il posizionamento dei popover e dei tooltip rispetto ad altri elementi e si occupa di mantenerli in vista, anche durante lo spostamento, lo scorrimento o il ridimensionamento della pagina. Si tratta di un ottimo complemento all'API Popover menzionata in precedenza, che renderà ancora più semplice la migrazione dalle soluzioni JS ad alta intensità di prestazioni. API di navigazione L'API di navigazione può essere utilizzata per gestire la navigazione nelle app a pagina singola e potrebbe essere un ottimo complemento, o addirittura un sostituto, per le attività di routing React Router, Next.js o Angular. Visualizza l'API Transizioni L'API View Transitions può animarsi tra i diversi stati di una pagina. Su un'applicazione a pagina singola, ciò semplifica molto le transizioni fluide tra gli stati e può aiutarti a sbarazzarti delle librerie di animazione come Anime.js, GSAP o Motion.dev. Ancora meglio, l'API può essere utilizzata anche con applicazioni a più pagine. Ricordi prima, quando ho detto che il motivo per cui abbiamo creato app a pagina singola nell'azienda in cui lavoravo 15 anni fa era evitare il lampo bianco dei ricaricamenti delle pagine durante la navigazione? Se quell'API fosse stata disponibile in quel momento, saremmo stati in grado di ottenere bellissimi effetti di transizione di pagina senza un framework a pagina singola e senza un enorme download iniziale dell'intera app. Animazioni guidate da scorrimento Le animazioni basate sullo scorrimento vengono eseguite in base alla posizione di scorrimento dell'utente, anziché nel tempo, rendendole un'ottima soluzione per la narrazione e i tour dei prodotti. Alcune persone hanno esagerato un po', ma se usato bene, può essere uno strumento di progettazione molto efficace e può aiutare a sbarazzarsi di librerie come: ScrollReveal, GSAP Scroll oWOW.js. Selezioni personalizzabili Una selezione personalizzabile è un normale elemento

No spam. Join 138,000+ creators. Unsubscribe anytime.

Create Your Free Bio Page

Join 138,000+ creators on Seemless.

Get Started Free