Il seminario di Alessandro Rodi (Renuo AG, Rails Foundation; 14 novembre 2025) è un hands-on workshop di circa due ore su Ruby on Rails. L'agenda: concetti e idee su Rails (15 minuti), costruire un blog insieme (60 minuti), deployment su un VPS da zero (15 minuti), conclusioni e Q&A (15 minuti), e come bonus una Android Native App (15 minuti).
Ruby on Rails è definito in due tempi: prima «a web framework for building web applications», poi, correggendosi: «a full stack web framework for building web applications». Chi può nominare altri full-stack framework? La slide risponde: Django, Laravel, Express, Flask, Phoenix. «The menu is omakase»: come in un ristorante giapponese, ci si affida allo chef — Rails sceglie per te lo stack, e le decisioni (aka configurazioni) sono già prese.
Chi usa Rails? La Rails Foundation e il Rails core team con 5000+ contributori, e aziende come Shopify, 37signals e GitHub.
Essere full-stack significa che il framework copre tutti gli strati dell'applicazione: modello dati, logica di business, viste, asset, autenticazione, deploy. L'idea «omakase» («mi affido a te») è il cuore della filosofia Rails: il framework fa per te molte scelte che altrove spettano allo sviluppatore — e questo spiega anche la critica ricorrente: «it's just too much magic».
Il paragone con il percorso del corso è immediato: lo stack MEAN/MEVN copre il full-stack con quattro tecnologie separate (MongoDB, Express, Vue/Angular, Node.js) e richiede di comporre e configurare i pezzi; Rails offre la stessa copertura con un unico framework e le decisioni già prese. È una delle differenze architetturali più importanti da capire, e il seminario la inquadra con la distinzione della sezione successiva.
Il seminario introduce la distinzione tra due architetture fondamentali:
Il costrutto primario è JavaScript e la comunicazione client/server avviene con JSON. Il client è «smart» e si assume tutta la responsabilità di costruire la UI (l'HTML); il server è «stupido» e si limita a consegnare dati. È l'architettura delle SPA che abbiamo studiato nei capitoli 8–9: Vue e Angular costruiscono l'interfaccia lato client consumando API REST.
Il costrutto primario è HTML e la comunicazione client/server avviene con HTML (pagine complete, già preparate). Il client è più «stupido» e riceve tutte le pagine già pronte dal server; il server si assume la responsabilità di costruire le pagine. È l'architettura dei framework server-side classici — e Rails, con Hotwire, la porta alle estreme conseguenze.
Il punto chiave: «Rails is a HTML-First framework» e, di conseguenza, «in Rails the distinction between SPA and Multi-Page Applications [è] obsolete». Ma attenzione: con entrambe le architetture si possono costruire sia SPA che MPA. Hotwire è il set di strumenti JavaScript che permette di costruire una SPA con architettura HTML-First — lo vedremo nella sezione successiva.
Hotwire è l'insieme di strumenti JavaScript di Rails che rende possibile la SPA in architettura HTML-First; ne fanno parte Turbo e Stimulus. Turbo offre «incredibly fast page loads» con due tecniche principali:
html e body senza un full page reload: la navigazione avviene via fetch, e solo le parti che cambiano vengono rimpiazzate.È esattamente l'obiettivo delle SPA — niente ricaricamenti completi, navigazione istantanea — ma ottenuto senza che il client costruisca la UI da JSON: il server continua a produrre HTML, e Turbo si limita a scambiare il documento (o le sue parti) in modo efficiente.
«Not only the menu is omakase, but a lot of decisions (aka configurations) are made for you, already.» Il principio guida di Rails è Convention over Configuration: se segui le convenzioni del framework (nomi di tabelle, plurali, percorsi RESTful, struttura delle cartelle), non devi configurare nulla — tutto funziona «da solo». È anche il motivo della critica: «it's just too much magic». La slide lo riassume con l'immagine del «one person framework»: un singolo sviluppatore può portare avanti un'intera applicazione perché le decisioni sono già prese.
«Enough with the theory. Let's build a chat application together!» — in realtà un blog. Il workshop parte con rails new blog e mostra la struttura delle cartelle generate, poi crea il primo modello con lo scaffolding:
# crea il progetto
rails new blog
# scaffolding: genera modello, migrazione, controller, viste e routes
rails g scaffold post title:string body:text
# seconda risorsa: i commenti riferiti ai post
rails g resource comment post:references content:textrails g scaffold genera tutto l'impalcatura CRUD per una risorsa (modello, migrazione, controller, viste, route); rails g resource genera il modello e le route RESTful senza le viste. La demo mostra scaffolding + CSS + gestione degli errori.
Rails include componenti pronti per i casi d'uso più comuni, tutti «batterie incluse»:
Il workshop mostra activestorage + actiontext dal vivo: si aggiungono upload e testo ricco al blog con poche righe.
Stimulus è l'altra metà di Hotwire: permette di definire controller JavaScript per gli elementi HTML («sprinkles» di comportamento), e gioca bene con la strategia di Turbo di prefetching delle pagine e aggiornamenti parziali. Mentre nei framework JS-first il JavaScript è il costrutto primario e l'HTML è generato, con Stimulus l'HTML resta il documento servito dal server e il JavaScript si aggancia a elementi specifici con attributi come data-controller e data-action.
La demo «nobuild» del seminario mostra come questi strumenti funzionino senza alcun passo di compilazione lato client — il tema della sezione successiva.
«Rails default is nobuild. This means that we don't transpile/bundle/compress/treeshake anything.» Il default di Rails è nobuild: niente transpile, bundle, compress o tree-shaking — niente webpack, niente Vite, niente passo di build. I due pezzi che rendono possibile tutto questo:
È il contrario esatto della toolchain JS-first: lì si scrive in moduli e si distribuisce un bundle (capitoli 8–11); qui si distribuiscono file che il browser sa già caricare.
«Ruby Rails has built-in support for websockets and live updates: this means we can push updates to the client without a full page reload.» Tre livelli, dal protocollo al risultato:
La demo «comments live-update» mostra i commenti che compaiono in tempo reale mentre un altro utente li scrive — senza reload e senza che il client costruisca nulla: il server invia l'HTML aggiornato, Turbo lo inietta.
«Your web app does not exist as long as it runs only on your machine.» Il Web è uno spazio libero: non serve il permesso di Google o Apple per essere visibili al mondo. Due strade per il deploy:
Il workshop fa il deploy su un VPS con Kamal: «We now have a full web application, with storage, database, websockets... and no external dependencies, no bundling, no limits, no constraints!»
Tre demo finali completano il quadro:
Il bonus finale del seminario: quanto codice serve per impostare una native app Android con Rails? La risposta della demo: pochissimo. E per chi vuole approfondire, il seminario annuncia la conferenza italiana RubyCon (8 maggio 2026, rubycon.it).
Il riepilogo concettuale del seminario, in una tavola:
Risorse citate: rubyonrails.org, il catalogo di Fowler sull'ActiveRecord (martinfowler.com/eaaCatalog/activeRecord.html), hotwired.dev e i tutorial ufficiali rubyonrails.org/docs/tutorials. Contatti: [email protected].
Ruby on Rails è un full-stack web framework per costruire applicazioni web (come Django, Laravel, Express, Flask o Phoenix). È sostenuto dalla Rails Foundation e dal Rails core team con 5000+ contributori; lo usano Shopify, 37signals e GitHub.
Nella JavaScript-First il costrutto primario è JavaScript e la comunicazione client/server avviene con JSON: il client è smart e costruisce la UI, il server è «stupido» e consegna dati. Nella HTML-First il costrutto primario è HTML e la comunicazione avviene con HTML: il client è più «stupido» e riceve pagine già preparate, il server costruisce le pagine. Con entrambe si possono costruire SPA e MPA; Rails è HTML-First e rende la distinzione SPA/MPA obsoleta.
Hotwire è il set di strumenti JavaScript di Rails per costruire una SPA in architettura HTML-First; ne fanno parte Turbo e Stimulus. Turbo offre page load velocissime con due tecniche: preload dei link all'hover e sostituzione di html/body senza full page reload.
Significa che molte decisioni (configurazioni) sono già prese dal framework: se segui le convenzioni (nomi, percorsi, struttura), non devi configurare nulla. È il motivo della critica «it's just too much magic», ma anche della produttività di Rails (l'idea del «one person framework»).
rails g scaffold post title:string body:text genera l'intera impalcatura CRUD della risorsa (modello, migrazione, controller, viste, route). rails g resource comment post:references content:text genera modello e route RESTful senza le viste (utile per risorse secondarie come i commenti).
ActionText (editor rich text), ActiveStorage (upload di file), ActionMailbox (ricevere email), ActionMailer (inviare email), ActionCable (websocket) e ActiveJob (job in background).
Il default di Rails è nobuild: non si transpila, bundle, comprime o fa tree-shaking. Lo rendono possibile importmap (i moduli ES caricati dal browser con nomi mappati alle URL, senza bundler) e propshaft (la pipeline degli asset statici).
Con tre livelli integrati: i websocket (canale bidirezionale sempre aperto), ActionCable (la gemma che fornisce il supporto websocket) e TurboStreams (la gemma che fornisce le live updates: il server trasmette frammenti di HTML che Turbo applica alla pagina).
I PaaS (Heroku, AWS, Google Cloud, Render, Fly.io: tutti supportano Rails) oppure nopaas con Kamal: lo strumento di deploy incluso in Rails che richiede solo una macchina con accesso a internet, senza dipendenze esterne e senza bundling.
SQLite è il database di default sia in development che in production (perfetto per iniziare, ma vanno curati i backup); la configurazione PWA è out-of-the-box; l'autenticazione si aggiunge senza sforzo.