La lotta per il web

Ieri, parlando delle ultime mosse di Apple, abbiamo accennato alle nuove possibilità offerte dal web, e di come in questi ultimi anni le più grandi società del settore siano impegnate nella lotta per far emergere le proprie soluzioni software nella realizzazione di  quelle che sono le cosidette RIA (Rich Internet Applications).

Nello specifico possiamo individuare due fronti, quello che spinge per il web a standard aperti (in cui il maggiore sostenitore è Google seguito dalla stessa Apple), e un frammentato universo di soluzioni proprietarie (in cui individuiamo Adobe con Flash/AIR, Microsoft con Silverlight e infine Sun con Java [1]).

Durante questi mesi molti utenti si sono sorpresi alle reazioni negative di Apple, spesso piuttosto dirette, alla richiesta del supporto di Flash in iPhone (lo stesso Jobs, in una occasione, ha definito lo stesso Flash una schifezza).

Potrebbe invece essere una sopresa scoprire come l'attacco a Flash e il rinnovato interesse in Cocoa per Windows [2] (che per ora si è limitato al porting di qualche applicazione) possano essere in qualche modo legati.

Ma andiamo con ordine.

Proprio qualche giorno fa Apple ha rilasciato MobileMe (non senza problemi a dire la verità), portando nelle scrivanie di milioni di nuovi utenti il concetto di sviluppo in stile Cocoa. Questa volta però non l'ha fatto distribuendo un runtime per ogni piattaforma (così come avvenne nel 1997 con la Yellow Box) ma utilizzando il web.

Questa volta Cocoa non si è trattato di un porting di tutte le librerie, ma di un framework in grado di consentire lo sviluppo su web utilizzando gli standard aperti.

La lotta per il controllo dello sviluppo delle RIA non è iniziata però in questi giorni, ma affonda le sue radici già nei tardi anni '90 quando prima Sun con Java e poi Adobe con Flash hanno cercato di alimentare l'hype intorno ai propri tool di sviluppo. Ognuna delle parti in gioco ha sperato e spera tutt'ora che prima o poi la sua soluzione possa diventare uno standard de-facto nel web development.

In verità le più famose web applications non usano ne provengono da nessuno di questi toolkit. Maps, Reader, Docs and Sheets (e tutto quello che ruota intorno alle web app di Google) rappresentano ad oggi l'esempio lampante di quello che è possibile realizzare con il web aperto (HTML, JavaScript e CSS) senza doversi aggrappare ad altre aziende.

La pensa come Google anche Apple, che non troppo tempo fa ha deciso di rimuovere tutti gli elementi Flash inutili dal proprio sito, rimpiazzandoli con soluzioni aperte (una decisione che è passata un pò inosservata ma che è indice di un nuovo percorso).

Perchè questa voglia di web open?
Ma perchè Google ed Apple spingono per il web aperto?

La storia ricalca a grandi linee quello che sta avvenendo con Linux nel mondo dei sistemi operativi (e al di quello che molti fans del pinguino pensano non è che aziende come IBM siano diventate più umane di quanto non fossero prima).

Spesso, sbagliando, si pensa che tutti gli sviluppatori vorrebbero utilizzare soluzioni aperte anzichè affidarsi ad un sviluppo chiuso. Dopo tutto, una volta che la battaglia tra questi toolkit finirà, anche tutta l'energia spesa nella frenetica ricerca di migliorarli, da parte delle rispettive società, verrà meno (un esempio eclatante è proprio Internet Explorer su Windows, rimasto fermo per anni semplicemente perchè non c'era niente con cui combattere).

Lo stesso ragionamento vale per Linux. Perchè tutti i produttori di hardware non passano a Linux? [3]

Il problema in entrambi i casi è che gli standard aperti non fanno arricchire (in maniera *diretta*) nessuna delle parti in gioco. Nessuno li possiede e nessuno può crearci intorno un modello di businnes e di sviluppo... a meno che non si tratti di una strategia indiretta.

Questa strategia, che utilizza l'open come ponte per arrivare ad un diverso modello di guadagno, è utilizzata da società come IBM e RedHat per Linux.

Lo stesso ovviamente vale per Google ed Apple ed ora andiamo a spiegare perchè.

Sin dalla sua nascita la società di Sunnyvale ha investito negli standard per un web aperto; Google vorrebbe un web che non sia in mano ad Adobe o Microsoft semplicemente perchè così non potrebbe sperare di competere vendendo gli ads (che rappresentano ad oggi la sua principale fonte di sostentamento e guadagno). Flash e Silverlight trasformerebbero il contenuto delle pagine web in 'semplici' (e chiusi) binari da eseguire.

Apple dal canto suo non vende ads, ma hardware (e ancora una volta lo ripetiamo: il software è per Apple una strategia trasversale, così come il web). Mettersi nelle mani di queste società potrebbe significare un web chiuso che da un giorno all'altro potrebbere precludere l'accesso ad altri sistemi operativi (leggi Mac OS X, ma leggi anche Linux) oppure semplicemente rendere l'esperienza più povera rispetto a Windows (Flash su Mac è stato per anni una pena, anche se con l'uscita della nuova versione sembra che qualcosa si sia mosso).

Anche se tutto questo può sembrare troppo distante dalla realtà, basta leggere un pò della storia commerciale di Microsoft per trovare abbastanza spunti di convincimento.

E così oggi Google ed Apple si ritrovano sulla stessa barca, seppur con interessi differenti tra loro: Google vuole un web aperto per i suoi ads, Apple lo vuole per consentire una buona esperienza d'uso. Entrambe stanno portando avanti questo scopo utilizzando strategie indipendenti ma comunque complementari.

I passi di Google
Google ha introdotto Google Gears come meccanismo per consentire uno storage offline locale per le web applications. Tuttavia questa esperienza è ancora limitata e per ora è in uso solo nei propri servizi come Maps o Gmail. Per ora non abbiamo ancora visto una prova esterna di questi tool.

La stessa SDK per Android introdotta a Novembre dello scorso anno è stata letteralmente eclissata prima sia dal punto di vista della qualità che dei tempi di rilascio dell'iPhone SDK, il cui debutto è avvenuto nel Febbraio di questo anno.

Un altro problema di Google è che non ha una grande base di utenti: benchè abbia messo a disposizione e aiutato molto la comunità non è detto che questo codice venga realmente utilizzato.

Apple e le API
In contrasto con quella che è l'inesperienza di Google, Apple ha degli strumenti per lo sviluppo decisamente migliori e più robusti, utilizzati per anni nel mercato.

L'esperienza di Apple nasce più di venti anni fa ed è stata utilizzata come base per sistemi operativi come Windows che poi l'hanno un pò eclissata durante il caos venuto con il progetto Copland nella prima metà degli anni 90.

L'esperienza portata con l'acquisizione di NeXT (di cui facevano parte, oltre ovviamente Jobs, alcuni ex dipendenti Apple) ha portato in seno ad apple dei frameworks per lo sviluppo mainstream object oriented davvero solidi e che hanno fatto da apripista a Taligent (IBM), Java (Sun) e anche a Cairo (un progetto mai uscito fuori dai laboratori Microsoft).

La filosofia dietro lo sviluppo delle API di NeXT (e quindi poi di Mac OS X) è quella di offrire funzionalità utili, astenersi dallo sviluppo di API non necessarie, revisionare il codice continuamente per perfezionarlo, privilegiando la qualità sulla quantità (che detta così potrà sembrarvi una pubblicità, però i risultati sono ben visibili).

L'introduzione stessa di una versione mobile di iPhone ha fatto si che parecchie API vecchie beneficiassero (e beneficeranno con nuovi update) delle nuove tecniche di sviluppo utilizzate per iPhone.

Direttamente da "iPhone Getting Started Docs":

"Una delle più grandi differenze (tra le API Mac e quelle iPhone ndr) è l'uso estensivo delle proprietà nelle dichiarazioni dell'UIKit (si tratta dell'omologo di AppKit per il mobile ndr). Le proprietà sono strate introdotte da Mac OS X 10.5 e molte classi di AppKit già incominciano ad utilizzarle.Anzichè mimare lo stesso comportamento di AppKit in UIKit è stato deciso di adottare le proprietà per semplificare le interfacce delle classi."

Oggi Apple sta portando il modo di sviluppare con Cocoa fuori i propri device: sul web. Negli ultimi giorni abbiamo visto (con MobileMe e tutte le applicazioni della suite) la sua abilità nello sviluppare RIA con interazioni tipiche delle normali applicazioni desktop. Tutto questo è stato possibile grazie a SproutCore, che beneficiando di una licenza aperta, ha portato da una parte lo stile Cocoa sul web, e dall'altra un competitor importante rispetto alle soluzioni proprietarie.

Conclusioni
Sono partito con l'intento di scrivere questo articolo per illustrare quello che è il nuovo corso di Apple nel web development (SproutCore in particolare). Tuttavia però mi sono preso la libertà di analizzare un pò meglio i motivi che spingono le diverse società in campo, ognuna con i suoi scopi, nella battaglia per un nuovo web.

E' inutile stare qui a dirvi come la soluzione migliore (al di la degli interessi con cui questa idea viene promossa) è quella di un web open.

Per quanto riguarda invece SproutCore vi invito alla lettura del prossimo post (sono già due post che lo rimando....).

^1
2
3

• Oltre SproutCore: Objective-J & Cappuccino