E’ sabato mattina,
sono in studio da solo,
perchè dovrei fare un mucchio di cose entro stasera,
e stasera vorrei anche preparare una cena per qualche amico,
e dovrei fare la spesa prima,
e c’è una mostra di sub alla libreria ars che non vorrei perdere,
e quindi butto un po’ di tempo per scrivere sul blog.
che è un po’ che non ci scrivo.
fare il grafico ai tempi di internet.
io mi sono personalmente rotto i coglioni di fare il grafico ai tempi di internet. e per essere sinceri non lo faccio più da un po’ il grafico, ma faccio solo il programmatore.
detta in breve, la grafica su internet è un’utopia.
NON
VA
MAI
UN
CAZZO.
i CSS? non vanno. potete raccontarmi tutto quello che volete sulla bellezza dei fogli di stile, potete tirarmi scemo per giorni e notti davanti a zen garden, ma ormai lo so, sono troppi anni (tutti quelli disponibili, visto che ho iniziato a fare siti quando hanno iniziato a vendere abbonamenti internet in italia) che ci sto dentro: i CSS sono una delle creazioni più contorte che la mente umana abbia mai partorito. oggetti che flottano, flusso dei contenuti, posizionamento relativo, fisso, extrasensoriale, assoluto, ateo, dimensioni enfatizzate, pixel, percenti, pica, punti, allineamenti, e poi “clear: left” (questa poi…), marginpaddingpudding, sucami sta minchia…
e alla fine?
non va.
un esempio semplice: con i CSS non è possibile fare un layout a colonne in float left, con dentro una griglia di miniature di foto (piuttosto che di abstract di articoli) che abbiano altezza uguale (le miniature). non si può. ho mosso i maggiori esperti mondiali del settore, gente che si fa validare dal W3C anche il cibo che mangia. niente. o le foto hanno la stessa misura, oppure tutto il layout si accartoccia sulle diverse misure delle immagini, colpa del float. come si risolve? con le buone e vecchie tabelle. peccato che le tabelle non siano allowed, anzi, peccato che siano proprio deprecated, peccato che le tabelle sono la bestemmia fatta html per la filosofia zen dei CSS. ma senza tabelle non va. quindi tutti i maggiori esperti mondiali di CSS che ho sentito alla fine hanno confessato, a bassa voce, mangiandosi le parole sperando che non si capisse quello che stavano per dire: “ci ho dovuto mettere una tabella…”.
e da qui mi scatta la digressione violenta.
una volta c’era l’HTML. perfetto. quattro cose in croce, con cui facevi tutto. TABLE, IMG, HREF, finito. finito un cazzo. subito dopo arriva il DHTML. col DHTML si potevano muovere oggetti HTML. mai visto delle porcherie come quelle create con il DHTML. era l’esatto opposto della fluidità, il delirio assoluto del posizionamento, il florilegio dell’incompatibilità.
poi hanno voluto separare i contenuti dal layout. bravi! bel proposito! lo dico sul serio, una cosa buona. quindi sono nati i CSS (che già uno dice “cascading style sheet”: fogli di stile che cascano? ma che cazzo vuol dire?!?! cascano dove? già dal nome uno deve sospettare che tutto il layout finirà con l’essere un cascading layout, una merda insomma). così devi fare l’HTML e i CSS. e hanno bandito nell’HTML tutto quello che c’è nell’HTML, tranne i DIV e gli SPAN. tutto è stato spostato nei CSS che non funzionano. quindi doppio lavoro. complessità al cubo. e funzionamento rotto. pensate che la filosofia alla base dei CSS è che uno fa una volta il foglio di stile, e poi lo applica ogni volta a contenuti diversi. in pratica nessuno è mai riuscito a riusare un CSS per due siti diversi. perchè nel CSS finisci immancabilmente col metterci workaround specifici per il conenuto HTML cui vanno attaccati. in pratica hanno separato il layout dai contenuti solo nel senso che devi fare due file separati invece di uno.
poi giustamente tutto evolve, e hanno fatto i CSS2, e poi i CSS3, tipo rocky, rambo, il ritorno dei CSS, i CSS e l’ultima crociata. e ogni volta un macello di reference, un inerpicarsi di bibbie dello stile, un pavoneggiare di bellezza formale, uno stuolo di caproni che gli americani chiamano gli “enthusiast” di questo o di quello, pronti a sbranarti un braccio se osi criticare. alzi la mano chi conosce i CSS3. chi li usa, insomma…?
ma non basta. XHTML, mobile HTML, wap HTML. ve la butto lì: perchè non gli XCSS? o un bel CSSML?
il povero (ma forse anche un po’ ottuso) W3C ha creato i validators. siti che ti dicono se un sito rispetta le regole o no. ovviamente il 90% dei siti (ma forse anche di più, non è uno scherzo, basta provare) non è valido secondo il W3C. l’accademia della crusca di internet non valida nessuno insomma. l’unico sito validato è lo stesso sito del W3C. un sito autoreferenziale. a casa mia si dice che se una legge mette tutti fuori legge, non è una legge giusta. non è utile. in definitiva fa danno.
il grafico ai tempi di internet ci si mette d’impegno ogni volta. i primi anni impara l’HTML, poi si studia i CSS, poi si studia i CSS2, poi, dopo dieci anni che il grafico fa siti, capisce che c’è qualcosa di perverso in questo meccanismo, ha la netta sensazione che sarà sempre così, che tutto quello che ha imparato non è comunque valido secondo le ultime specifiche. è una rincorsa disperata e infinita ai nuovi standard. io ho capito che la normalità è non conoscere lo standard vigente. la normalità è fare cose che non vanno bene.
poi è arrivato Javascript. certo, chè siamo pezzenti e ci accontentiamo di HTML, DHTML, XHTML, CSS, CSS2, CSS3? prima Javascript veniva usato solo per fare i bottoni in rollover. poi, con AJAX, si è arrivati ad includere in una pagina web migliaia, se non decine di migliaia di righe di codice Javascript (anche qui, lo sapete, quando si tratta di cifre non invento mai nulla: provate a fare un sito con prototype e scriptaculous e ditemi quante righe di Javascript importate nel vostro HTML). oltre ovviamente a XHTML e CSS.
è nato quindi il WEB 2.0.
non so voi, ma io quando sento parlare di WEB 2.0 mi viene solo in mente lapo, coi suoi occhiali del cazzo e il suo look da immigrato clandestino su una carretta del mare, che parla di aria fritta con la faccia emaciata da cocaina. ecco a cosa serve il WEB 2.0: a riempire la bocca del nostrano “genio del marketing”.
e tutto questo AJAX per fare cosa? per tabellare una manciata di dati che arrivano dal database. esattamente come si faceva in HTML con le tabelle.
mica finisce qui.
prendiamo Flash. appena è uscito Flash, nella cartella dei samples c’erano quattro file con un’orribile palla colorata che rotola su una spiaggia. grafica da vignette della settimana enigmistica. e infatti non se l’è cagato nessuno per un bel po’. finchè qualcuno non ha iniziato ad usare trasparenze, oggettini minuscoli che svolazzano qua e là, tutto che si muove, siti che hanno più caos, esplosioni, colori di un carnevale. e Flash ha spopolato. è nata l’era della “intro in Flash”.
poi gli hanno letteralmente appiccicato un linguaggio di scripting. ci voleva, per fare più carnevale bisognava scrivere del codice. prima l’Actionscript 1, poi il 2 che deprecava tutto quello che c’era nell’1, e alla fine il 3 che depreca tutto quello che avevate imparato del 2. un deja vu insomma. il solito meccanismo.
ma almeno Flash e il suo Actionscript funzionano? io adoro Flash, penso di conoscerlo abbastanza, lo uso intesivamente fin nelle sue ultime incarnazioni come Flex2. epperò, purtroppo, mi sento di dire che, no, nemmeno Flash funziona. cioè: l’Actionscript è una cosa meravigliosa. si può letteralmente dare vita ad un sito. peccato che puntualmente usando Flash si incappa in qualche cazzo di riga di codice che non va. semplicemente non funziona, dovrebbe funzionare, è sintatticamente corretta, ma non va. allora i guru di Flash ti spiegano che sì, in quel caso, ma solo in quel caso, devi usare un’altra procedura un po’ strana, deci chiamare “_root” che sarebbe deprecato, ma senza “_root” non va. poi con l’Actionscript3 tutto diventa object oriented. fichissimo. trovo che la programmazione orientata agli oggetti sia la cosa più bella partorita dal mondo dell’informatica da quando è nato. peccato che lo scope dei metodi chiamati da eventi non vada. si devono usare dei workaround dei più folli. per far sì che un metodo triggerato da un evento conosca qualcosa del suo parent bisogna imboccarlo dal buco del culo, bisogna passargli come parametro istanze della classe chiamante, bisogna replicare variabili di classe dentro al metodo, altrimenti il metodo si perde in un limbo di nulla. oppure ci sono casi in cui, per pura magia, su dieci immagini PNG che volete visualizzare, una perde la trasparenza. puttana eva: cambiate il PNG, lo risalvate, lo sostituite con uno degli altri 9 che funzionano, ma niente, il decimo perde la trasparenza. dopo una settimana di prove, rifate tutto il sito da zero, uguale identico, con gli stessi PNG, lo stesso codice, e adesso il sito va. “eh, avrai sbagliato qualcosa, ti è sfuggito qualcosa!” direte voi. no, un par di palle. anche qui: ci ho visto morire i migliori Flash guru del pianeta. quel cazzo di PNG flash non lo bucava. senza motivo. non capita spesso, ma capita, e quando capita…
e il garbage collection del Flash Player? provate una cosa semplicissima: aprite una decina di siti flash in dieci tab di firefox. e andate a casa. quando tornate il giorno dopo in ufficio il pc sarà crashato causa riempimento della ram.
che dire poi dei linguaggi lato server? prima c’era il fantomatico CGI, Common Gateway Interface. l’unico modo di far fare qualcosa al server che non fosse contenuto statico. l’unico modo di collegare un sito a un software, l’unico modo di rendere una pagina dinamica. so che non è propriamente cosa da grafici, ma visto la piega minestronica del discorso, come non citare tutto quello che è venuto dopo? Perl, Python, PHP, ASP, Rail, per non parlare di Java e C#.
ma la vita del grafico ai tempi di internet non è così rosea (!!!) come ve l’ho raccontata fino qui.
perchè nel mondo reale esiste Microsoft Internet Explorer. e nel mondo reale Microsoft Internet Explorer è il browser di gran lunga più usato al mondo. e i vostri clienti non sono mai troppo gioiosi quando gli dite che il sito funziona perfettamente in Firefox. i clienti ci tengono a quel 90% di utenti internet che usano Microsoft Internet Explorer.
ebbene: Microsoft Internet Explorer è semplicemente malvagio.
il problema non è che ha dei bachi, non è che è fatto col culo, non è che sbaglia tutto quello che si potrebbe sbagliare parlando di browser. il problema è che è proprio cattivo, ha un allineamento caotico, per dira alla D&D. è nato per fare danni.
sembrerà un’esagerazione, ma è esattamente così.
quando bill, dopo aver sostenuto apertamente che internet sarebbe stato un flop, per riparare alla sciocchezza, ha chiamato i suoi mejo programmatori, gli ha detto: dobbiamo fare un browser anche noi. esiste Netscape che ha il 100% del mercato. Netscape funziona. rispetta gli standard aperti. noi dobbiamo fare un browser che dice di rispettare gli standard ma che non li rispetta. noi dobbiamo fare un browser che dice di rispettare l’HTML, ma poi rispetta solo l’HTML creato con i nostri prodotti. dobbiamo dire che rispetta gli standard, sennò gli utenti non lo usano. dobbiamo farlo che non rispetta gli standard perchè sennò l’utente non usa i nostri prodotti: gli unici che conoscono come funziona il nostro browser.
Microsoft Internet Explorer è malvagio perchè è nato per distruggere gli standard. l’hanno fatto apposta, e ci sono riusciti benissimo.
il W3C dice che l’HTML ha quei 10 tag? bene, noi ne inventiamo altri 10 non previsti, e facciamo funzionare bene quelli.
per inserire Flash in una pagina bisogna usare EMBED? bene, noi usiamo OBJECT. i CSS hanno definito HOVER per l’evento del mouse sopra un oggetto? bene, noi non lo implementiamo così com’è, e invece ci inventiamo i BEHAVIOR. tutti i browser usano i plugin? noi inventiamo gli ActiveX. che vanno solo su windows. potrei andare avanti all’infino. la lista di standard distrutti da Microsoft Internet Explorer è infinita. chiudo con una ciliegina sulla torta: non so con Microsoft Internet Explorer 7 (che non ho perchè microsoft dice che il mio windows sotto vmware è piratato, anche se è originale, e quindi non me lo installa), ma fino al 6 compreso l’HTML entity ' non funziona. incredibile? no, vero. hanno implementato tutti gli html entities tranne '.
geniale.
perchè hanno fatto questo? perchè i capi programmatori di microsoft sono degli scarsoni e piuttosto che imparare gli standard preferiscono inventarli? no, ovviamente, bensì perchè microsoft ha il potere di imporre i propri standard. ovvero microsoft non ha nessun interesse negli standard aperti. microsoft non ha nessun interesse nel bene del consumatore. microsoft, come ogni azienda, ha un unico interesse: incrementare il fatturato. quindi qualunque cosa fa microsoft non è fatta per migliorare la vita degli utenti (scopo che invece, almeno nelle intenzioni, hanno tutti gli enti di certificazione di standard aperti, come il W3C), è fatta per fare soldi.
la mia sensazione, dopo anni che faccio questo lavoro, è che gli standard nell’informatica (ma forse nell’elettronica di consumo in generale) non vengano fatti per il bene dell’utente, ma per preservare il vantaggio del produttore. la mia netta sensazione è che un grafico ai tempi di internet sarà costretto vita natural durante a imparare nuovi standard e a disimparare i vecchi. è come essere dei criceti che corrono nella rotella. tutto quello che hai imparato è costantemente messo in uno stato di “deprecated”. e più impari, più devi disimparare. più sei un “guru”, più sei obsoleto.
io ci ho sempre creduto negli standard. chi legge questo blog da un po’, sa con quale passione mi butto in tutte le cose nuove che mi capitano a tiro. ma alla soglia dei 35 anni mi sono rotto i coglioni. non è possibile che qualunque cosa uno impari, poi è vecchia. per anni ho creduto che fosse evoluzione, che fosse progresso, che fosse miglioramento. ora comincio a credere che sia interesse di qualcun altro, non il mio, e non quello dei clienti per cui lavoro.
quando studiavo all’università (cristo, quasi quindici anni fa!) mi spiegarono che il modello client/server era un modello superato, e che l’avvento dei PC dimostrava che il modello vincente era quello delle workstation, dei computer standalone con cui facevi tutto. e invece oggi tutto è diventato client/server :-) con internet, il paradigma unico e incontrovertibile è quello del client che prende servizi e contenuti dal server. fra poco persino fotosciòp lo useremo via internet (adobe lo sta per fare con tutti i suoi pacchetti principali). ma allora, perchè abbiamo fatto tutto sto giro del cazzo per passare da un paradigma ad un altro, e poi ritornare a quello di prima? non potevamo fermarci al risultato ottenuto inizialmente?
io credo che si tratti di un dominio culturale, che viene imposto da qualcuno, per mettere i bastoni fra le ruote agli altri, ai possibili competitors. chi è partito per primo ha imparato per primo a fare le cose, e ha imposto i suoi standard. poi gli altri ci hanno messo il loro tempo per impararli, per allinearsi, per essere “compatibili”. ma se davvero gli altri fossero diventati compatibili e produttivi, sarebbe decaduto il predominio dei primi. e infatti quello che succede è che nel mentre gli altri si allineano, i primi non stanno fermi, ma vanno avanti, inventano nuove cose, e quando gli altri sono finalmente allineati, i primi sono già “one step beyond”, e ti piazzano il nuovo standard: ti flaggano come “deprecated”, ti rendono obsoleto, ti obbligano a ricominciare a rincorrere.
il grafico ai tempi di internet ha iniziato giocando con fotosciòp, ed è finito col dover conoscere una decina di linugaggi di programmazione. che, sempre e comunque, sono quelli vecchi.
se ne può uscire da sta ruota da criceti?
pensiamo alle scienze classiche: quando hanno scoperto il modello atomico, non è che l’anno dopo hanno inventato il modello cacatomico, o il modello bidonico, o altro. è rimasto il modello atomico. è stato studiato da tutti. è stato imparato da tutti. viene usato da tutti. e nessun nuovo modello potrà mai esistere se non sarà comprovato, con il sano metodo scientifico, che spieghi meglio la realtà, che rappresenti meglio i fenomeni che ci circondano, insomma, che sia utile a tutti.
è possibile anche nell’informatica instaurare un processo del genere?
quale è il modello atomico dell’informatica?
cosa vale veramente la pena di sapere e cosa no?
è una domanda difficile, cui dovrebbe rispondere qualcuno più anziano di me, qualcuno che ha iniziato negli anni 60 sui mainframe, qualcuno che conosca bene l’informatica teorica. insomma non io. ma io c’ho l’urgenza logorroica e quindi butto lì la mia (che poi l’ho già buttata lì prima): la risposta alla domanda sul senso della vita e tutto il resto è: linguaggio Assembly per il micro, programmazione orientata agli oggetti per il macro, unix per l’architettura.
vi piacciono i computer? studiatevi Assembly e Java. assembly per capire come funzionano le cose a livello atomico. java per creare. il c++ è una gran cosa, forse unisce il meglio di Assembly e Java, ma non è platform independent, che è una bella fregatura.
grafici di tutto il mondo: volete davvero fare grafica ai tempi di internet? imparate a programmare. ma non quello che vi dicono gli altri, non quello che va di moda, non quello che gli americani vi propinano come “new era”, come “killer app”, come “definitive standard”, bensì quello che sta sotto a tutto, quello che resterà perchè da quando è nato non è mai stato snaturato. bisogna legarsi alle basi, non alle cime, non agli “edge”. e le basi sono sempre le stesse. architettura unix (ovvero client/server), linguaggio macchina e programmazione orientata agli oggetti.
giusto per spingere il discorso agli estremi: qualsiasi cosa si voglia fare con un computer, bisogna imparate a programmare. usare programmi scritti da altri vuol dire usare parole dette da altri, vuol dire esprimere concetti pensati da altri. vuol dire rincorrere. tanto di più se ci piace la grafica :-)
