Rome — Frontend Development Toolchain
Il panorama JavaScript è ormai (piuttosto) stabile ma camionate di tools continuano ad uscire a raffica, rendendo la vita di noi sviluppatori sempre più fatiguosa!
C’è però all’orizzonte una possibilità che ci viene offerta da uno dei big player che, con molte delle sue innovazioni, ha reso il panorama JavaScript quello che è oggi…quei geniali simpaticoni di Facebook!
Il progetto di cui parlo è Rome, una frontend development toolchain, nato dalle mani di un pivello qualunque e cioè Sebastian McKenzie, un tizio che a malapena è autore di Babel e Yarn…oltre ad essere nel React Team di Facebook! :D
Una toolchain può fare la differenza?
Da tempo molti linguaggi sono diventati forti e blasonati anche grazie a delle robuste toolchain, come ad esempio GoLang e Rust
Ne abbiamo parlato abbondantemente sul canale YouTube di Acadevmy…mi raccomando, iscrivetevi!
Avere una serie di strumenti robusti e utili rende di certo la vita più semplica agli sviluppatori, ed anche noi frontend developers ce ne siamo resi conto da quando le CLI hanno preso piede nel nostro mondo!
Tutte le strade porteranno a Rome!
Ciò che rende nuovo ed interessante Rome (fino a qualche tempo fa RomeJS), è che questo potrebbe avvernire anche nel mondo del frontend.
Rome difatti nasce come una frontend development toolchain e dovrebbe quindi portare in un unica soluzione tutti i tools più comuni che ogni frontend developer moderno utilizza, come linter, formatter, compiler, bundler, type checker, testing framework e tanto altro.
La cosa quindi veramente interessante è che la soluzione proposta da Rome è pensata per essere all-in-one e per lavorare con JavaScript, TypeScript (è scritto con quest’ultimo tra l’altro e gira su NodeJS), JSON, HTML, Markdown, e CSS.
Rome è disegnato per unificare tutta la toolchain, che è sempre stata composta da tools separati tra loro, offrendo (finalmente) con un’unica soluzione un rimpiazzo per i vari Babel, ESLint, webpack, Prettier, Jest e via dicendo.
Le aree coperte da Rome dovrebbero quindi essere:
- Bundling
- Compiling
- Documentation Generation
- Formatting
- Linting
- Minification
- Testing
- Type Checking
- … e tanto altro!
La filosofia è vincente!
Ciò che lo rende estremamente promettente è anche la filosofia che sta alla base del progetto e che, a mio vedere e per come viene proposta, è tanto scontata quanto rivoluzionaria.
La filosofia infatti su fonda su:
- Nessuna dipendenza esterna;
- Gli errori devono suggerire le soluzioni, ove possibile;
- Gli errori devono essere specifici e non generalisti, così da identificare esattamente il problema;
- Le API devono essere minimaliste e consistenti;
- Il gergo utilizzato deve essere semplifice e ridotto al minimo;
- Il naming dei comandi e dei flags devono essere autoesplicativi (anche se verbosi);
- Bisogna usare una terminologia inclusiva;
- Deve essere utilizzabile ed ottimizzato su clients generici;
- Deve avere una tipizzazione forte;
- Deve evitare ambiguità sull’output.
Da questi punti appare chiaro che lo scopo è rendere più semplice la vita dello sviluppatore, evitare ambiguità e rendere l’esperienza chiara e genuina.
Lo stato attuale del progetto
Fino a qualche tempo fa il progetto era ospitato su https://romejs.dev/ ed era possibile provare (con tanto di pseudo-documentazione) buona parte della toolchain ma allo stato attuale l’unico tool documentato ed utilizzabile è il Linter.
La scelta del team è difatti quella di rendere stabili i tools uno per volta, nonostante buona parte del lavoro è stata già fatta per quasi tutti.
Data la filosofia a monte è infatti necessario che l’esperienza sia gratificante ed armonica, quindi la scelta è a mio vedere valida dato che, avendolo provato qualche tempo fa, ho avuto non poche difficoltà a tirare fuori qualche ragno dal buco con il resto degli strumenti che non fosse il Linter.
I tools non ancora ufficializzati potete comunque provarli anche adesso (venite avvisati che i comandi sono ancora nascosti) giusto per farvi un’idea…ma dimenticate la stabilità o le prestazioni, dato che il team stesso ha preferito renderli pubblici man mano che diventeranno stabili.
In ogni modo, linko alcuni articoli precedenti che vi consentiranno di farvi un’idea e provare qualche comando attualmente nascosto.
In ogni modo avrete già tanto da valutare dall’help della CLI di Rome, oltre che nella documentazione ufficiale del progetto.
Conclusioni e speranze
Rome non ha alcuna dipendenza esterna ed è scritta (nella documentazione è indicato ampiamente) from scratch, il che fa ben sperare in un progetto innovativo e fuori dagli schemi.
Se da un lato assumere una toolchain completa non è detto che soddisfi tutti (magari il Linter potrebbe piacerci ma il builder no), dall’altra evita la follia dettata dall’utilizzo di tools completamente diversi tra loro, da integrare e far convivere, con documentazione differente da studiare, con gerghi ed architetture differenti, etc…
Attualmente il progetto è in pieno sviluppo ma sono molto fiducioso e continuerò a seguirlo, sperando che possa vedere la luce presto e dare una nuova ventata di aria fresca al mondo del frontend development.
Infine suggerisco di andare a dare un’occhiata anche al Governance model adottato, che è molto inclusivo e particolarmente partecipativo.
Alla prossima e ci vediamo a Rome! :D
Per suggerimenti (o aggiunte perché no!), critiche, insulti, lodi, donazioni di enormi quantità di denaro, partite a padel o consigli non serve altro che scrivere nei commenti!
