I principi di Meteor
I fondamenti che hanno dato forma alla progettazione di Meteor sono sette.
Inviare dati, non pagine. Meteor manda al client solo i dati necessari per costruire la pagina, ma la costruzione effettiva della vista avviene dal lato del browser. Esiste comunque uno strato di rendering dal lato server che si può usare per non confondere gli spider dei motori di ricerca.
Un unico linguaggio: JavaScript. Come abbiamo osservato quando abbiamo parlato di Node.js, il JavaScript lato server ha senso e può garantire prestazioni del massimo livello. Consideriamo anche che il linguaggio è popolare, quindi è facile trovare talenti e componenti software. In effetti npmjs.org, il sito che ospita i componenti aggiuntivi per Node.js, dichiara quasi 125.000 pacchetti.
L’abbondanza di ruote già inventate porta a un altro dei principi di Meteor: abbracciare quello che è già stato creato senza creare inutili alternative a framework e strumenti esistenti, ma invece integrandoli, come il framework jQuery, il linguaggio Coffeescript, il motore di template Jade, il linguaggio Markdown.
Il codice dell’applicazione vuota aperto direttamente nello storico e collaudato editor emacs in una finestra di comando.
Database ovunque. L’uso di MongoDB e l’architettura del framework consentono di usare nello stesso modo il database, sia dal lato server, sia dal lato client. Una versione più magra del database, Minimongo, permette di trattare i dati in una cache lato client e usare le stesse primitive che si usano lato server. Su Quora abbiamo trovato un piccolo articolo dell’autore che racconta qualcosa di più sull’architettura.
Compensazione della latenza. Meteor, secondo la documentazione, cerca di anticipare le interrogazioni e le modifiche al database, salvo compiere un rollback, in modo da ridurre il tempo di esecuzione delle query e dare l’impressione che si completino istantaneamente.
Reattività di tutto lo stack. Ogni strato dell’applicazione si aggiorna quando è necessario. Per esempio, quando modifichiamo i sorgenti di un’applicazione in esecuzione, il browser contiene i risultati aggiornati subito dopo la modifica dei sorgenti, mostrando che server e client hanno reagito alla modifica rigenerando il contenuto e ricaricandolo.
Semplicità uguale produttività . Questo principio è il più facile da capire e da confrontare con la propria esperienza. Per esempio, consideriamo l’applicazione scheleton, una semplice pagina con un pulsante e un testo che indica quante volte il pulsante è stato premuto, mostrando il modo in cui si tiene traccia di variabili di sessione con il browser.
Ecco l’esempio di codice
<head>
<title>meteor_app</title>
</head>
<body>
<h1>Benvenuto in Meteor!</h1>
{{> hello}}
</body>
<template name="hello">
<button>Clicca qui</button>
<p>Hai premuto il pulsante {{counter}} volte.</p>
</template>
Questo esempio mostra due caratteristiche interessanti di Meteor. La prima è l’inserimento di un template fra le doppie graffe seguite da un segno di maggiore {{> hello}}. Il template viene definito di seguito, in un tag stile html. All’interno del codice del template una variabile di session, chiamata counter, viene incorporata nel codice, come potremmo fare scrivendo $counter in Php.
Quello che non c’è nell’esempio è significativo: non abbiamo indicazioni del foglio di stile associato alla pagina, non includiamo file JavaScript, non c’è un tag <html>.
Queste cose non ci sono perché non è necessario metterle: ci pensa il framework e il foglio di stile associato alla pagina è gestito correttamente dal browser. Per concludere, nella pagina riservata al progetto su meteor.com, l’obiettivo del gruppo è espresso così: «Creare una piattaforma per lo sviluppo di applicazioni cloud che diventi ubiqua, come le piattaforme Unix, http e il database relazionale». Si tratta di un obiettivo molto ambizioso, ma la missione di una startup deve essere ambiziosa, così come lo era un computer su ogni scrivania per Microsoft. Inoltre, in Meteor hanno i fondi e le persone con cui possono mirare a raggiungere l’obiettivo.