Che la scelta sia opinabile è palese. Nel comunicato di yahoo non vengono espresse le motivazioni di questa svolta e vengono tessute le lodi degli sviluppatori: Mirek Grymuza e il suo team.  Mentre yahoo parla di quanto bello sia il suo nuovo giocattolo però voci autorevoli (anche se fortemente di parte) dicono che la scelta non è dovuta alle prestazioni, bensì alle diversificazioni in termini di advertising, ossia l’incapacità del flash player di gestire flash ads a differenti fps.Perfortuna le API flash\flex\as di yahoo maps  non sembrano aver subito il colpo, nessun comunicato infatti è stato rilasciato da yahoo sul futuro dei propri component.

Ad ogni modo mi sento di quotare Ted Patrick nel dire “Yahoo! Maps on Flex 1.5, you will be missed!”

Questa la situazione:

Tanto tempo fa lo chiamavamo DHTML e per lo pi√π lo si vedeva nei siti “da smanettoni”, ingredienti: HTML e Javascript.
Si, lo stesso javascript che fino a poco tempo fa veniva denigrato anche per i controlli sui mail form…adesso sembra che Javascript sia diverso, sia pi√π buono, oserei dire quasi indispensabile per un sito web tanto se ne parla, perchè questo non è pi√π il “www”, questo è il “web 2.0″…ingredienti: HTML e Javascript….-.-’

Un Javascript in framework, beninteso, lungi dall’essere paragonabile a quanto popolava i siti prima dell’avvento di prototype, jquery, scriptaculous e quant’altro, ma pur sempre Javascript. Google ci sta scommettendo da un bel pezzo, gran parte delle sue applicazioni sono AJAX, anzi, sono le antesignane delle applicazioni web-based di un certo calibro (basti pensare a google maps, google documents o alla stessa gmail), ora la segue a ruota Microsoft dopo aver provato a fare il verso ad Adobe con il suo Silverlight.
Certo è che la via che si sta percorrendo (o che almeno Google e ora Microsoft hanno intrapreso) è quella di portare i programmatori al web, o meglio…ai soliti 2 ingredienti: HTML e Javascript.

Perplessità

Sono perplesso. Da quando sono al mondo (digitale ) ho sempre sentito parlar male da tutti (anche all’università tra l’altro…) di Javascript per i motivi pi√π diversi…ne elenco alcuni:

• è un linguaggio weak typed
• è interpretato dai client pi√π disparati (per lo pi√π gecko webkit e internet explorer) con tutte le problematiche che ne conseguono (ogni browser “capisce quello che vuole lui“)
• non tutti lo abilitano, i browser pi√π diffusi danno la possibilità all’utente di disattivarlo (anche di default volendo)
• è difficilmente debuggabile (a causa delle interpretazioni e del weak typing)
• ha una mediocre (per non dire scarsa) capacità di gestione degli eventi
• in ogni caso si appoggia ad un linguaggio di output anch’esso di libera interpretazione…HTML

Come da ultimo punto…HTML. Oltre a tutti i problemi relativi allo scripting Javascript bisogna appoggiarsi ad un output HTML sommando dunque tutti i problemi relativi all’interpretazione del box model.

Prospettive

Sono pessimista a riguardo, Javascript (che venga sputato da un “compilatore” Java o .NET o da un framework o da quel che sia) resta un linguaggio DEBOLE, e lo si sta sopravvalutando TROPPO.

Tuttavia è l’unica alternativa free e open per lo scripting lato client su web. Esistono anche altre realtà: flash player e java applet per citarne due, ma sono tecnologie proprietarie che funzionano senz’altro meglio, ma richiedono all’utente plugin o interpreti per girare sul browser “sporcando” la concezione purista di web (anche se Adobe Flash Player è installato praticamente ovunque).

Un motore di rendering HTML e un interprete Javascript unico risolverebbero qualcosa? non credo, o meglio, in minima parte: ci sarebbero meno problemi nella visualizzazione corretta di un documento HTML, ma rimarrebbe la “pochezza” di un linguaggio di programmazione approssimativo come Javascript.

Javascript VS Actionscript

Faccio un parallelo con Actionscript, visto che è il linguaggio che padroneggio con maggior sicurezza ed è (o meglio era) molto simile a Javascript per certi versi (e poi qui siete a casa di un flasher ricordate?:D).
Per come la vedo io Javascript attualmente riesce a fornire all’utente un’interazione con il browser pi√π o meno pari a quanto Actionscript riusciva a fare ai tempi di Flash 5 (quando venne abbandonata la sintassi della barra per quella del punto per intenderci..) nel lontano 2000 sotto l’ombra del millennium bug.
Da allora Actionscript ha implementato lo strong typing, è passato all’OOP e ha reso possibili le Rich Internet Applications grazie ad una piattaforma sempre pi√π aggiornata e diffusa come Flash Player…Javascript dal canto suo non è passato all’OOP (se non in modo fittizio) nè è stato implementato lo strong typing…e l’interprete continua ad essere diverso da browser a browser limitando non poco chi si accinge a farne uso.

Conclusioni?

Avevo già affrontato l’argomento flash vs ajax in passato, ma la faccenda si sta evolvendo in fretta e in direzioni “impreviste”, quindi ho preferito ritornarci sopra, anche solo per chiarirmi le idee a riguardo. Non voglio trarre conclusioni univoche, suppongo che venga piuttosto facile intuire che “tifo” per l’ulteriore affermazione di flash, ma a breve assisteremo ad una nuova svolta online con l’avvento di HTML5…sperando che le sorprese non finiscano con una rivisitazione del box model… e chissà che non sia capace di farmi cambiare parere a riguardo

…ad ogni modo, se avete letto i miei penseri fin qui, bè…avanzate una birra

stay tuned

Volta sarà un toolkit che si integrerà con le tecnologie .NET (per ora ho letto solo di C#, ma suppongo si possa programmare anche con gli altri linguaggi .NET) fornendo loro un “traduttore” capace di rendere accessibile lo sviluppo di applicativi AJAX anche ai programmatori “veri” (concedetemi le virgolette…:))  che con il web non hanno voglia\tempo\modo di cimentarsi.

Volta si integra con Visual Studio, il quale fornisce un ambiente di debug inedito per “AJAX.NET” (continuo con le supposizioni…lo chiameranno così?:)) permettendo ai coder “desktop” di sviluppare in un tool a lui familiare utilizzando linguaggi a lui familiari un qualcosa che di familiare per lui non ha nulla: AJAX.

La stessa strada è stata affrontata da big G con il suo Web Toolkit di qualità indubbia e già ampiamente consolidato (i case history a riguardo ormai non si contano…).

Google Maps va in 3D, e non sto parlando del famoso Google Earth, ma di un nuovo servizio (per ora presente solo negli states) che letteralmente “controlla” chiunque.

Nel software è stata aggiunta la rete di telecamere di sicurezza nelle strade degli USA, cliccando ovunque siano presenti queste cam sarà quindi possibile vedere un VR (in flash) del punto in questione, inoltre, cliccando sulle frecce presenti all’interno del VR stesso è possibile “percorrere” le strade e guardarsi intorno.

L’iniziativa è sensazionale ma piena di controversie, molte infatti sono le voci che si sono levate contro questa integrazione di Google Maps, che vede ledere la privacy di milioni di americani. Camminando lungo i VR infatti non è raro incappare in volti ben visibili, o persone fare le cose pi√π diverse (pi√π o meno legali), o ancora incidenti stradali, e così via.

Per accedere a questo servizio basta andare su maps.google.it, navigare verso gli USA, impostare la visuale “vista stradale” e cliccare ovunque tra le strade evidenziate in blu…

The matrix has you…

La scelta è tra 4 pattern di compressione (none:  toglie solo gli spazi, normal: toglie gli spazi e riduce i nomi variabile [shrink vars], numeric: converte tutto lo script in un eval(‘stringa codificata’), ascii: come numeric ma con un altro tipo di codifica [ascii appunto ^^]) , differenti tra loro in compatibilità e compressione (ad esempio non tutti i sistemi saranno in grado di interpretare la compressione ascii).Attenzione però!
Lo strumento è potente, ma crea parecchi disagi… mi spiego meglio:
sono riuscito a comprimere di parecchio (da 21k a 11k °_°) un’applicazioncina ajax, ma ho dovuto correggere il codice per delle banalità.

Esempio:
se scrivessi un qualcosa tipo

var a = 8

var b = 'ciao'

l’interprete javascript del browser interpreterebbe il new line come segno di un nuovo statement.
Comprimendo le 2 righe scritte poc’anzi si verificherà un errore in quanto mancano i punti e virgola.

Ad ogni modo non c’è da preoccuparsi, basta abituarsi a scrivere codice corretto (entrate in strict mode ) e nessuno si farà del male. Inoltre sempre nello stesso sito c’è anche una sezione “how to” che spiega nel dettaglio le potenzialità del packer.

Tra i vari bug di internet explorer sono incespicato su un qualcosa di parecchio fastidioso: ie gestisce male gli onload delle immagini.
All’inizio pensavo che non fossero gestiti del tutto, o solo in parte (?) , ma a volte ricaricando la pagina dispacciava l’evento, altre no, apparentemente a caso.

Ecco una porzione di codice che presenta il problema descritto:

Così explorer entra in modalità cagacazzo random error…
Non occorre scervellarsi (come ha fatto il sottoscritto), la soluzione è più facile del previsto:

Cos’è cambiato? Per un comune mortale, e per la maggior parte dei browser NULLA!
Per ie invece è cambiato il “preavviso”, in soldoni, PRIMA si aspetta che gli sia comuncato cosa deve fare a questo o quell’evento (come si è presentato il bug su onload potrebbe presentarsi su click, mousedown o chissachè), e POI si aspetta di caricare un’immagine a cui assegnare i gestori di evento….-.-””

In soldoni, per evitare il bug è necessario specificare src come ultimo attributo del tag img.

Questo è  il motto di StripeMania, un’applicazione web nata per forgiare righette da piazzare nei background dei nostri siti.
Il generatore è piuttosto facile da usare e secerne immagini pronte da wrappare negli sfondi.Unico neo: non accetta i valori esadecimali dei colori in input, dovete trovarveli col con il color picker (piuttosto impreciso…)

Fatevi una riga, dite pure che vi mando io

//creo i vari nodi
var obj = document.getElementById("id");
var tbl = document.createElement("table");
var tr = document.createElement("tr");
var td = document.createElement("td");
var tn = document.createTextNode("Io sono il campo di una tabella ma non mi vedi su IE gnè gnè");
//attacco i vari nodi
td.appendChild(tn);
tr.appendChild(td);
tbl.appendChild(tr);
obj.appendChild(tbl);

Con Firefox tutto ok, con Opera tutto ok, con Safari tutto ok, con Camino tutto ok, con Konqueror tutto ok, con Galeon tutto ok…non ho provato con la psp, ma diciamolo…con chi non funzionerà questo script se non con LUI?

ecco come risolvere il problema…

Il workaround è piuttosto semplice se ne avete tenuto conto da principio, altrimenti dovrete modificare un po’ il vostro layout.
Semplicemente Internet Explorer si rifiuta di fare il render del contenuto delle tabelle se esse non contengono il tag tbody.
Sottolineo il termine “render” in quanto i nuovi nodi vengono effettivamente attaccati alla tabella, solo che non vengono mostrati a video. E’ piuttosto curioso infatti fare un alert dell’innerHTML della tabella in questione (seguendo l’esempio qui sopra basterà aggiungere un ‘alert(obj.innerHTML)’ alla fine) e vedere IE mentre sputa il codice corretto pur non visionandolo…-.-’
Ben inteso, il tag tbody non è obbligatorio secondo lo standard HTML4, tuttavia sappiamo pi√π o meno tutti che l’atteggiamento del browser microsoft è piuttosto incline a “interpretare” gli standard secondo un’ottica tutta sua.

Ma veniamo al codice corretto:

var obj = document.getElementById("id");
var tbdy = document.createElement("tbody");
var tbl = document.createElement("table");
var tr = document.createElement("tr");
var td = document.createElement("td");
var tn = document.createTextNode("Questa volta sono visibile al mondo");
td.appendChild(tn);
tr.appendChild(td);
tbdy.appendChild(tr);
tbl.appendChild(tbdy);
obj.appendChild(tbl);

Buon divertimento con IE7

Ajax, Flash, e Flex sono le tre principali tecnologie di cui si può discutere in termini di RIA, ma cosa sono?
Come strutturare il proprio progetto e che tecnologia usare dipende sostanzialmente dalle skills di cui si dispone e dal tipo di risultato che si vuole ottenere.

Le Piattaforme
Esiste una sostanziale dicotomia tra queste tecnologie:

Flash e Flex producono dei filmati che possono essere visualizzati tramite il Flash Player, quindi si può asserire che siano crossbrowser in quanto non si appoggiano direttamente a questo o quel browser di destinazione quanto piuttosto alle potenzialità del flashplayer.

Decifrando la sigla “AJAX” si può invece capire di che pasta è fatta questa “tecnologia”: Asynchronous Javascript and XML.
Ajax quindi non è una vera e propria tecnologia, quanto piuttosto un modo di programmare javascript.
Molte persone identificano Ajax con quello che una volta era chiamato DHTML, ossia animazioni e transizioni javascript su html; tuttavia Ajax altro non è che un modo per ricevere\inviare dati on demand direttamente dal client (quindi dal browser) ..non a caso una delle applicazioni pi√π diffuse di ajax è “inviare un form senza cambiare la pagina”.

Una volta capita questa sostanziale differenza di piattaforma si può passare a considerare Flash Flex e Ajax come potenziali candidate allo sviluppo del vostro progetto in essere.

Pro e Contro
Se esistesse un tag “” lo utilizzerei per scrivere quanto segue, d’altra parte FlashFuck tratta principalmente di flash e affini e, come tale, la valutazione di pro e contro pende certamente da una parte

Penso che le caratteristiche delle tre tecnologie possano essere riassunte da questa tabellina, con le dovute precisazioni.

CrossBrowser:
Come già scritto sopra flash e flex si appoggiano a flash player, quindi non sono propriamente crossbrowser.
Ajax dal canto suo ha le limitazioni di javascript che non è propriamente un linguaggio crossbrowser.

Free:
Ajax è free, il programmer non dipende da questo o quel programma di authoring per realizzare qualcosa con questa tecnologia. Anche Flex è recentemente diventato open source ed è possibile sviluppare in flex utilizzando liberamente l’SDK.

SEO friendly:
la pecca principale di flash e flex è senza dubbio l’aspetto SEO. Ajax lavora su pagine html, quindi con i dovuti accorgimenti si può ottenere ugualmente un buon risultato quanto a posizionamento sui motori di ricerca.
Anche per flash e flex esistono dei modi per ovviare al problema, ma la strada è impervia e piena di pericoli.

RIA Capable:
Non ho checkato questa voce per Ajax perchè non fornisce esattamente la possibilità di creare una RIA vera e propria.
Ajax necessita dell’ausilio di altre tecnologie per conseguire il risultato di una RIA che non contempli solo testo e immagini, non è quindi in grado di mostrare video, realizzare streaming audio, autonomamente. Cose che Flash e Flex sono in grado di fare grazie alle potenzialità del flash player.

Customization:
Il pi√π customizzabile dei tool è senza dubbio Flash. Con flash è possibile creare delle interfacce grafiche ad hoc per il proprio progetto, uscendo addirittura dalla mera scomposizione in box tipica di html. Ajax fornisce tutte le possibilità di customizzazione di html, in fin dei conti dà la possibilità di mostrare dell’html on demand..
Anche Flex si basa sui tag di mxml… è leggermente customizzabile, ma lo sviluppo di accorgimenti grafici per flex ricade quasi certamente nella creazione di component per flex con l’uso di flash, quindi ho preferito non checkare questa voce.

Framework(s):
Flash ha delle librerie standard che comprendono delle classi base per poter lavorare nell’ambiente di authoring, in linea di massima è il coder a crearsi le classi actionscript per il proprio progetto. Flex utilizza il proprio framework scritto interamente in actionscript3, il coder puo’ comunque estenderlo a piacere creando i propri package, come peraltro è possibile in flash.
Per Ajax il discorso è un filino diverso. Esistono svariati framework che implementano le funzioni pi√π disparate, dalla gestione del caricamento di contenuti all’highlight degli oggetti del DOM HTML alla creazione di vere e proprie “animazioni” di blocchi html.
I framework Ajax pi√π famosi (o quantomeno quelli che ho potuto testare di persona su alcuni progetti) sono:

• Prototype
• Scriptaculous
• Mochikit

IMHO
Concludendo, creare un’applicazione, un sito, una RIA, un generico progetto, richiede una considerazione sulla\e tecnologia\e da usare. Ognuna ha i suoi pro ed i suoi contro, vanno sicuramente valutati gli obiettivi che il progetto si pone e come raggiungerli al meglio scrivendo meno codice possibile rendendo il risultato il pi√π appetibile possibile.
Bè…che altro aggiungere..
Stay tuned e buon lavoro