A Ovest Di Paperino

@EnricoG

ho appena provato IE8, Firefox e Opera per aprire il tuo blog... mi dispiace, ma sono tutti e tre lenti da morire: circa 5 secondi, e su un PC con le prestazioni del mio non e' certo il rendering del browser che fa la differenza.

E' evidente che nessun browser è in grado, fino ad oggi, di risolvere i problemi di ottimizzazione di un sito.

Qunado sento dire da qualcuno che un browser e' piu' veloce di un'altro mi vien sempre da sorridere, come se un individuo fosse in grado di percepire i millisecondi di differenza tra uno e l'altro.

In effetti devo ammettere che, nelle mie affermazioni, non sempre ricordo di specificare che "...il browser XYZ sembra più veloce", anche se spesso lo faccio.

Anzi, di solito critico chi si mette lì a contarli i millisecondi, utilizzando questo o quel benchmark, perchè spesso ciò che l'utente percepisce è diverso da quel che il benchmark rileva.

Per esempio, IE8 Beta dalle prove che ho fatto, sembra moooolto più lento degli altri (non sono mai andato a verificare se e quanto è vera questa sensazione) semplicemente perchè mostra il contenuto della pagina tutto insieme, e non via via che lo carica.

IE

Allo stesso modo, Safari mi sembra molto più lento in certe occasioni, perchè mi pare sfrutti in modo meno efficace di altri browser il meccanismo di caching e precaricamento.

Penso siamo tutti d'accordo che nessun essere umano è in grado di percepire una differenza di velocità in termini di millisecondi, perciò è evidente che ciò che percerpisce è più importante delle differenza reale in millisecondi.

Attendere 5 secondi perchè compaia qualcosa nel browser è tantissimo, anche se quel qualcosa che compare è l'intera pagina richiesta.

Invece veder immediatamente comparire qualcosa, meglio se dall'alto in basso, consente di avere la sensazione che il contenuto sia disponibile immediatamente, ma in realtà accade che, mentre si guardano i primi contenuti scaricati, il browser continua il download dei contenuti visualizzabili solo con uno scrolling di pagina.

Sono principi elementari che chi si occupa di usabilità ben conosce.

Son certo perciò che la versione definitiva di IE8 sarà (sembrerà) molto più veloce della Beta.

@/V

Ma fosse anche che ORA non si vedessero le differenze (cosa che sia io sia chiunque attorno a me ha invece notato), mi sembra indiscutibile che il trend per le applicazioni prossime venture sia di spostarsi online per quanto possibile.

Secondo me le applicazioni online non sono il futuro, ma il passato remoto.

La cosa ottimale e' che ci sia un servizio online che alimenta applicazioni residenti sul client, questo per tutta una serie i ragioni.

La prima e' che i servizi devono essere agnostici rispetto al dispositivo che utilizzo per fruirne, devono fornire dati, ma non potranno mai offrire la miglior esperienza sul mio specifico dispositivo.

La seconda e' che lasciando il servizio e il client disaccoppiati le due cose possono essere sviluppate da entita' differenti, riducendo il costo di supporto da parte di chi sviluppa servizi e ampliando l'offerta di client disponibili.

La terza e' che Ajax e' cosi' anni novanta!!! Roba inventata da Microsoft per OWA e poi portata in auge da Gmail, ma sarebbe ora di guardare un po' piu' in avanti e finirla con queste ridicole applicazioni online che sono dei mezzi aborti e costano una vita per farle girare decentemente su tutti i browser in circolazione.

Devo continuare?

Insomma EnricoG, sei per i webservice?

@ilSilente

si. Che poi si possa discutere su come implementarli, con che tecnologia etc. e' un altro discorso, ma sulla "filosofia" non ho dubbi a riguardo.

Il punto e' che Google e' la prima a capire questa cosa e a sapere meglio di chiunque altro quanto sia vero che per offrire la migliore user experience serve un client dedicato: Google Maps per iPhone ne e' la prova lampante.

Il problema e' che con i client dedicati Google non vende piu' la sua pubblicita' e quindi deve prendere per i fondelli la gente facendole credere che il futuro sia un super browser con un super motore javascript, figuriamoci.

Quello non e' il futuro per la miglior user experience, quello e' il futuro per la miglior piattaforma di advertisement-delivery.

Google per lo meno ha le sue buone ragioni per "difendere" una scelta tecnologica risibile, ma che un appassionato di tecnologia possa difendere Ajax... beh quello proprio no.

Capiamoci: quando si espone un servizio va benissimo offrire anche un client via browser che usa Ajax, ma non spacciamolo per "stato dell'arte della tecnologia".

@ /V:

@Paperino: la frammentazione non e' assolutamente un problema in un mercato perfettametne concorrenziale dove il prodotto migliore tende a prevalere e i meno validi spariscono. In questa situazione la varieta', soprattutto se accessibile tra tutti, on fa che aumentare i miglioramenti a ogni passo.

Eppure la teoria, e pure la pratica, mi dicono che io ho molta più facilità a scegliere fra 5 o 6 caramelle che fra 250.

mi pare ragionevole che una delle piu' grosse aziende nel campo delle applicazioni web si tuteli da possibili colli di bottiglia offrendo un browser garantito e ottimizzato per far girare al meglio le sue applicazioni.

eppure chrome tende ad avere problemi anche con le applicazioni di google stessa. Si che è una beta, ma ci si aspetta che almeno quelle abbiano già un minimo di integrazione.

@FDG

il problema del WEB (come Linux) è l'estrema frammentazione dei client

Visto che ci lavoro, mi permetto: no, non è un problema, non così rilevante come vuoi far credere. Non c'è tutta questa frammentazione visto che i motori sono 4, solo 3 rilevanti: IE, mozilla e webkit (Chrome è basato su webkit). Opera, mi dispiace per i suoi estimatori, ha quote irrilevanti. Quindi, se mi da problemi con lo standard, posso pure permettermi di ignorarlo. È quello che faccio. In generale, se mi affido allo standard, so che Firefox, Webkit e Opera mi seguono. IE... meno. Ma da questo punto di vista Microsoft sembra aver imboccato la giusta strada con IE 8.

Invece, un problema di cui non si parla è che il web è limitato, pone problemi grossi agli sviluppatori, e non è riuscito ad evolversi per poter superare i suoi limiti. E ritorno alla carica con SVG. Se CDF ed SVG fossero una cosa comune tra i browser, si avrebbe a disposizione una gestione del layout sicuramente più potente e meno limitata.

"Chrome non serve ad una beata mazza, ma ben venga perché è OpenSource". La concorrenza già c'è (Opera, Firefox e Safari) e mi sembra che stia funzionando molto bene a giudicare dai progressi delle nuove versioni dei browser. Dove sbaglio?

Perché non ti rendi conto dell'apporto che può dare google nello sviluppo delle tecnologie web. Google sviluppa applicazioni web per consentire l'accesso ai suoi servizi. Sarà bene a conoscenza delle problematiche e dei limiti dello sviluppo sul web? In una logica open source il suo apporto va a beneficio di tutti. Quindi, ben venga google. Investe già nello sviluppo di Firefox ed ha pure deciso di mettere i suoi sviluppatori su webkit ed ha proposto la sua idea di browser. È un'idea utile? Per me si. Può condizionare positivamente l'evoluzione delle tecnologie del web? Per me si.

@EnricoG

Un componente su cui ho lavorato un anno fa era una lista scrollabile il cui contenuto veniva caricato dinamicamente con richieste ajax; la lista doveva potenzialmente poter gestire migliaia di elementi; era stata pensata per superare la soluzione tipica delle liste paginate. Le ragioni per un caricamento dinamico erano due: occupazione di memoria, velocità di creazione. Comunque, anche se il contenuto veniva caricato dinamicamente, se si voleva dare un'idea delle dimensioni reali della lista con un feedback visivo, ad esempio quello realizzato con la scrollbar, bisognava generare lo scheletro del contenuto alla creazione della lista (sul perché si deve fare questo, ci sarebbe da discutere... tornando alla questione dei limiti del web). Anche se i tempi di creazione non erano eccessivamente lunghi, comunque non erano irrilevanti. Erano accettabili se la lista non era aperta frequentemente e se si limitava nella pagina il numero delle liste gestite in questo modo.

@Paperino

mi spiego meglio: JavaScript è diventato quello che è perché ci vuole "poca" fatica per scrivere codice che funzioni su tutti i browser di oggi. Se vogliamo possiamo parlare di multi-piattaforma. È questo il motivo che ne ha decretato il successo. Tirare fuori un altro interprete che avrà i suoi problemi di compatibilità sicuramente non aiuta.

ACID 3 serve a testare anche JavaScript. Oggi il browser che meno rispetta ACID 3 è quello che è da più tempo sul mercato. Quindi i problemi non vengono dagli interpreti nuovi.

@Enrico

Penso siamo tutti d'accordo che nessun essere umano è in grado di percepire una differenza di velocità in termini di millisecondi, perciò è evidente che ciò che percerpisce è più importante delle differenza reale in millisecondi.

Allo sviluppatore invece interessano le differenze reali.

@EnricoG

La prima e' che i servizi devono essere agnostici rispetto al dispositivo che utilizzo per fruirne, devono fornire dati, ma non potranno mai offrire la miglior esperienza sul mio specifico dispositivo.

Questo avviene già. Puoi usare diverse soluzioni. Io uso RPC di GWT. JSON è un'altra soluzione interessante. Per non parlare dei classici Web Services.

Però, se come tu dici, devo trasferire logica di presentazione sul client, mi serve un client più sofisticato. Questo vuol dire che bisogna andare oggi quello che si vede oggi. E siccome il web ha una certa rilevanza, soprattutto in termini di presenza sul mercato e diffusione delle conoscenze, non penso che come soluzione client sia irrilevante per il futuro.

Il problema e' che con i client dedicati Google non vende piu' la sua pubblicita' e quindi deve prendere per i fondelli la gente facendole credere che il futuro sia un super browser con un super motore javascript, figuriamoci.

E sicuramente google fa accordi con Apple in perdita. Ma per piacere...

Quello non e' il futuro per la miglior user experience, quello e' il futuro per la miglior piattaforma di advertisement-delivery.

E infatti quando sviluppo con GWT vedo che google vende pubblicità agli utenti delle mie applicazioni.

Giusto?

No?

Allora che lo sviluppano a fare?

Però, se come tu dici, devo trasferire logica di presentazione sul client, mi serve un client più sofisticato. Questo vuol dire che bisogna andare oggi quello che si vede oggi. E siccome il web ha una certa rilevanza, soprattutto in termini di presenza sul mercato e diffusione delle conoscenze, non penso che come soluzione client sia irrilevante per il futuro.

p.s.: Air infatti usa queste tecnologie. Flex va in senso opposto, per questo non incontra tutti i favori degli sviluppatori... già, gli sviluppatori, questi sconosciuti!

un altro p.s.

Chrome serve a google per avere un maggiore controllo sul punto di accesso ai propri servizi. Ma non solo a questo. Serve anche per poter potenziare i propri servizi e renderli più appetibili agli utenti. Azzardo un'ipotesi: più questi servizi sono interessanti, più l'ecosistema online è sviluppato, più tempo trascorrono gli utenti online, meglio è per google. Che ne pensate?

Ma tutte le motivazioni di questo mondo non possono essere razionali.

Un altro pensiero.

Avere diverse tecnologie con cui realizzare i client, limitandosi ad uniformare la comunicazione, genera meno frammentazione dell'avere il web come tecnologia? Mi state dicendo che bisogna tornare all'era del client/server? Quindi, n diversi prodotti, competenze frammentate e poche garanzie sugli investimenti?

Ma forse mi sbaglio. Forse vi riferite alla possibilità di utilizzare le tecnologie del web anche per sviluppare applicazioni client. Oppure alla possibilità di mantenere una applicazione web funzionante anche quando non si è online. Vero?

Ancora... pensavo a Google Earth.

Uno dei vantaggi del web è l'integrazione. Un mockup te lo puoi permettere sul web. Puoi prendere google maps (è un esempio, da sostituire con X, dove X è un qualsiasi servizio) ed integrarlo sulla tua applicazione. Google Earth è un gran bell'oggetto il cui livello di integrazione col resto è però limitato dal fatto che non è sul web.

@FDG

mi pare che fai un po' di confusione, un po' tanta.

E sicuramente google fa accordi con Apple in perdita. Ma per piacere...

E questa da dove salta fuori? Che ne sai tu dell'accordo tra Apple e Google per GoogleMaps su iPhone?

Uno dei vantaggi del web è l'integrazione

Perche' secondo te questo non e' fattibile su un client? Mi stai prendendo in giro vero?

I punti del mio argomento sono molto semplici e chiari:

- Google ha bisogno di "uccidere" il client per mantenere il consumatore sul web a sorbirsi la pubblicita'.

- se il web diventa tutto applicazioni-online si uccidono tutti i "piccoli" sviluppatori perche' un'infrastuttura online richiede investimenti enormi, mentre scrivere un client per un device e' alla portata piu' o meno di tutti.

- l'ideale e' un mix delle due soluzioni lasciando all'utente la liberta' di scelta: voglio servizi gratuiti sorbendomi la pubblicita', bene lo faccio, voglio servizi a pagamento che non siano infestati da benner sul viagra, pago e non ho rotture di maroni.

Microsoft puo' offrire questo mix di prodotti/soluzioni, Google no, puo' solo cercare di uccidere il client.

Chi sostiene l'open source deve suo malgrado accettare il fatto che nonostante Google si riempia la bocca di open source in realta' e' piu' pericolosa di Microsoft nell'ottica di software e servizi "realmente open".

Uno dei vantaggi del web è l'integrazione

Perche' secondo te questo non e' fattibile su un client? Mi stai prendendo in giro vero?

Ti ho già risposto:

Ma forse mi sbaglio. Forse vi riferite alla possibilità di utilizzare le tecnologie del web anche per sviluppare applicazioni client. Oppure alla possibilità di mantenere una applicazione web funzionante anche quando non si è online. Vero?

Perché comunque, se non è così, non puoi mai ottenere la stessa integrazione se non hai la certezza che i diversi client sono realizzati con le stesse tecnologie. Giusto?

- Google ha bisogno di "uccidere" il client per mantenere il consumatore sul web a sorbirsi la pubblicita'.

Non so se google voglia proprio _uccidere_ il client, ma mi pare sia interessata a spostare di più l'attenzione sul web, come ho scritto in precedenza.

- se il web diventa tutto applicazioni-online si uccidono tutti i "piccoli" sviluppatori perche' un'infrastuttura online richiede investimenti enormi, mentre scrivere un client per un device e' alla portata piu' o meno di tutti.

Eh, si, perché oggi un qualsiasi sviluppatore per distribuire le proprie applicazioni non deve comunque passare dal web?

C'entra, c'entra...

La questione è tecnologica. Il limite attuale del web è che devi essere sempre collegato e che ci deve essere sempre un server. Ma è un limite che si vuole superare (es.: IE 8 prevede un DOM storage locale). Si tratta quindi di sostituire tecnologie per lo sviluppo e la distribuzione con altre che consentono sviluppo, distribizione ed aggiornamento così come lo consente il web. I miei dubbi sulla riuscita di questo sono solo tecnologici. Perché, se esiste un versiontracker.com per scaricarsi applicazioni per i client, non vedo perché un tale servizio non potrebbe esistere per "scaricarsi" applicazioni web, magari per farle funzionare in locale, magari anche con una integrazione server. È un mercato potenzialmente interessante. Del resto, aovestdipaperino.com esiste e non mi pare che il Papero debba qualcosa a Google.

Microsoft puo' offrire questo mix di prodotti/soluzioni, Google no, puo' solo cercare di uccidere il client.

No, microsoft può solo tentare di continuare a vendere una copia di windows per ogni computer. Non vedo molta differenza

@FDG

Allo sviluppatore invece interessano le differenze reali.

Ah.... e io deficente che pensavo interessassero i risultati percepiti.

Ora mi spiego il perchè di tanti software caratterizzati da scarsa usabilità.

la barra dell'applicazione su Windows e Linux non è mai attaccata al bordo

Non è detto.

Certo, non è default.. ma tutto si può

Il topic comunque mi pare esaurito.

E, come spesso accade, tanto rumore per nulla

i soliti giornalai l’hanno definito “innovativo”

Ah, quanta triste verità...

Sono gli stessi giornalai che in vari TG hanno fatto spot e propagande per l'iphone.

Grottesco.

@Paperino

FCK ha già i suoi problemi a supportare Safari. Idem dicasi per Opera. In generale FCK ha dei problemi, grazie anche al fatto che l'editing dell'HTML sul browser è una cosa poco standardizzata. Se a questo aggiungi i bug delle diverse implementazioni, come quelli di Midas su Mozilla...

Il web è client-server, solo con molte complicazioni in più. Sono dell'avviso che un client specializzato, accompagnato ad un client light-weight WEB per l'ubiquità, sia la formula vincente

Non condivido per le ragioni di cui ho già parlato. Un client specializzato costruito sulla tecnologia di un singolo produttore funziona finché stai con questo produttore e finché ti puoi permettere di farlo. Se questo è piccolo e scompare dal mercato, sei fregato. Se questo è grande, ha la tendenza a fregarti appunto perché avendo investito sulla sua tecnologia è difficile abbandonarlo. È più difficile farlo che non con una tecnologia neutrale come il web, nonostante le incompatibilità tra i browser. E l'affidarsi ad un solo soggetto non ti garatisce minori problemi. E poi devi considerare quanto sia facile trovare persone che conoscono la tecnologia, gli strumenti, quanti strumenti di supporto allo sviluppo hai a disposizione, e così via.

p.s.: comunque un concetto che sfugge, è che secondo me il web è lungi dall'esser perfetto. Quindi vedo di buon occhio tutti gli sforzi tesi a migliorarlo.

FCK ha già i suoi problemi a supportare Safari. Idem dicasi per Opera. In generale FCK ha dei problemi, grazie anche al fatto che l'editing dell'HTML sul browser è una cosa poco standardizzata. Se a questo aggiungi i bug delle diverse implementazioni, come quelli di Midas su Mozilla...

E quindi non c'entra JavaScript. Per i problemi di IE, c'era un bellissimo post scritto a proposito dei giri strani che hanno dovuto fare in jQuery per farlo funzionare pure su questo browser. Un problema per fortuna sembrano averlo risolto con IE 8:

blogs.msdn.com/.../internet-explor

"We’ve also been improving our programmability engine. In addition to working on performance gains across the entire programmability stack, including in the core JavaScript engine, we’ve implemented mutability in our Document Object Model prototypes as well as attribute getters and setters in order to enable web developers and framework builders to extend our object model"

Posto che non mi occupo e non mi occuperò mai di programmazione Web-oriented e quindi non ne conosce le problematiche, sono dell'idea che l'utente gradisca un client dedicato ed in più la possibilità di utilizzare un "client Web" in alcuni casi di estrema necessità.

L'approccio "all Web" non mi piace e se qualcuno solleva dei dubbi sul riutilizzo di client dedicati credo che la risposta migliore siano i Web Service. Esempio, se Google Maps e Live Maps esponessero la stessa interfaccia sarebbe fantastico avere un client dedicato che permette l'uso di entrambi in modo del tutto trasparente e questa è un'operazione fattibile utilizzando l'approccio dei Web Service.

@sirus

e non mi occuperò mai di programmazione Web-oriented

Non mettere limiti alla provvidenza

@ Enrico

Il problema è che mi sto specializzando su un campo completamente diverso.

Poi magari non sfondo con quello che mi piace e sarò costretto a rivedere pesantemente il mio bagaglio tecnico e dirigermi verso la programmazione Web ma spero di non doverlo fare.

Sicuramente la competizione serve a qualcosa:

webkit.org/.../introducing-squ

Gli sviluppatori di V8, TraceMonkey e SquirrelFish passano il tempo a superarsi nei benchmark. Il risultato è che nell'arco di un anno webkit ha già un interprete JS che è già di un ordine di grandezza più veloce (in un paio d'anni penso sia di due ordini di grandezza, ma dovrei verificare). Il risultato non è interessante solo per JS e il web, ma nel confronto tra linguaggi statici e dinamici.

Uhm.... mumble mumble...

Perchè nel 2008 ci si fissa sui javascript? Quando cominciai a interessarmi di web fu in occasione della mia tesi di laurea, nel luglio del 98. Infatti la mia tesi di laurea era su web. In quel periodo cominciai ad addentrarmi nell'html per poi "scoprire" nel 2000 circa che esisteva il dhtml, tramite cosa? Javascript. Molti definiscono questo linguaggio "moderno" e, a mio avviso, "molti", sbagliano.

Nel 2000 poteva avere un senso la pulizia del codice e la brevità del medesimo perchè le connessioni a banda larga non erano diffuse, mentre oggi, a parer mio, non capisco di cosa si stia parlando. Se oltretutto devo produrre dei browser che rendano "velocemente" questi codici mi chiedo se siano così necessari (non lo sono).

In realtà, ora, "moderne" sono altre cose. E nell'era del tanto declamato web 2.0 non vedo come un discorso di lettura corretta/veloce di javascript possa essere di qualche interesse. Il web 2.0 è la pagina dinamica per eccellenza, la pagina interattiva, il che significa ASP.NET o PHP (programmato o in cms che si voglia). Lo stesso discorso per css: esterno o "embedded"? Se viaggio a 10 Mbit ha senso che mi risparmi per creare una pagina di 15 kbytes (che peraltro ne richiama altre 10 da 75 kbytes ciascuna) che sia leggera? "Moderno" è ora un sistema che mi consente di creare web dinamico allo stesso modo con cui scrivo un documento di Word. "Antiquato" è un editor html/asp/php ecc che crea codice, che va validato, che va testato, ecc.

Effettivamente un nuovo browser scompagina un settore in cui non c'è solo confusione ma addirittura schizofrenia. E' come il discorso dello standard iso di Ms Office. Ha senso che chi ha l'80% del mercato si adatti ad uno standard di un produttore di software che ha, tra l'altro, resa e funzionalità largamente al di sotto? No. Oltretutto, con buona pace degli standard W3C, non c'è uniformità nella renderizzazione delle pagine. Safari rende in un modo, IE in un altro, Firefox in un altro ancora eccetera. E avere la pretesa che ci sia una regola "aurea" in un casino del genere mi sembra una cosa più folle di quanto sia la realtà dei fatti (che è abbastanza folle). Chrome, di fatto, aggiunge solo caos all'equazione e non è altro che una bieca operazione di markeing per i propri, legittimi sia chiaro, servizi. Io, però, mi sarei un po' rotto di vedere ovunque gli "ads by google", "powered by google", "approved by google", "coocked by google" ecc. E che Google abbia reso quasi tutti un po' più stupidi mi pare una triste verità.

www.theatlantic.com/.../google www.repubblica.it/.../google-frigge-i

Nel 2000 poteva avere un senso la pulizia del codice e la brevità del medesimo perchè le connessioni a banda larga non erano diffuse, mentre oggi, a parer mio, non capisco di cosa si stia parlando. Se oltretutto devo produrre dei browser che rendano "velocemente" questi codici mi chiedo se siano così necessari (non lo sono).

1) Quella banda la puoi usare per qualcoda di più interessante piuttosto che per ripassare n volte lo stesso markup d'interfaccia.

2) Per quanto possa essere veloce un server a rispondere, devi comunque introdurre un ritardo per ottenere magari un banale feedback. Se questo feedback si complica, se gli elementi in gioco sono diversi, occupi banda, i tempi di risposta si allungano e alla fine l'interfaccia diventa per l'utente evidentemente meno reattiva. In più carichi il server di un lavoro che potresti benissimo scaricare sul client.

3) A riprova di quanto detto sopra ho la mia esperienza su interfacce AJAX realizzate con JSF, che passa blocchi di markup dal server al client, e GWT, che si limita ai soli dati, e ti posso assicuare che non c'è paragone. Infatti, ho sviluppato ho una certa allergia a JSF. I casi in cui è meglio generare il markup sul server secondo me si riducono a quelli per cui il costo della generazione è eccessivo per il client (si potrebbe ovviare a questo problema facendo affidamento sull'interprete XSLT del browser).

4) La questione non riguarda solo il client ma i linguaggi dinamici in generale. Ci sono molti sviluppatori che li preferiscono per una serie di ragioni. Mi limito a dire che ti fanno scrivere meno. Però questo lo paghi in prestazioni. Se la perdita di prestazioni si riduce, è naturale aspettarsi un maggior successo di questi linguaggi.

5) È illusorio aspettarsi una compatibilità totale. Ma parlare genericamente di incompatibilità è fuorviante. Io mi aspetto che su standard maturi, su cui sono definiti adeguati test di compatibilità, la questione si risolva a poche, se non nessune, eccezioni. Se al contrario prendo standard più recenti, o adottati di recente o su cui l'interesse è ancora insufficiente, esempio SVG, mi aspetto molte incompatibilità. Del linguaggio, cioè di JavaScript, ho già parlato in precedenza. Aggiungo, nonostante su WebKit sia cambiato l'interprete JS, non ho avuto problemi ad usarlo sui miei lavori. Mi aspetto che questo si possa fare con un adeguato testing, ad esempio facendo uso di test di unità. Esempio, il primo link raccattato con google riguarda mozilla:

www.mozilla.org/.../library.html

Tu credi che tutte queste feature complicate siano state introdotte in pochissime settimane dopo l'annuncio di Chrome? Io esprimo i miei dubbi.

No, assolutamente. Mi riferivo al modo in cui viene sentita la competizione. Non penso che ne gli sviluppatori di google ne quelli della mozilla fondation staranno a guardare. Per ora giocano a chi cel'ha più lungo e, visto che ciascun interprete ha le proprie caratteristiche (SF compila nativamente le regexpr, cosa di cui tanti sviluppatori saranno contenti), è naturale aspettarsi che queste verranno prese come fonte d'ispirazione dagli altri.

Comunque, la prima versione di squirrelfish, che non aveva il JIT nativo ma solo un interprete bytecode, è stata annunciata il 3 giugno 2008. Corrono.

annunciata -> rilasciata

Hai ragione FDG ma per quanto riguarda la banda, stiamo parlando di sistemi verso i 20mbit (come tendenza)e questo mi ricorda il discorso sulla RAM. Usiamola. Forse a te sembreranno discorsi un po' "naif" (ed in effetti un po' lo sono dal tuo punto di vista).

Secondo me, sono le applicazioni "pesanti" che creano sviluppo tecnologico non il contrario. La banda larga è stata commercializzata (la connessione LAN a 10mbit come quella di Fastweb in fibra c'era già da tempo) per il semplice motivo che, col diffondersi della connettività, è cambiato il modo di navigare e quindi si è creata l'esigenza (creare "il bisogno di qualcosa" è un vecchio trucco del capitalismo). Da una/due pagine per volta si è passati alla navigazione a schede di pagine con contenuto accessorio pesante (flash in genere, link interni, foto più definite in allegato) e magari anche in refresh automatico. Ora è cambiato tutto ulteriormente [si fa un gran (stra)parlare di web 2.0] e i siti statici tendono a scomparire. proprio perchè l'ampiezza di banda consente ampi spostamenti di dati. Se la pulizia di codice diventa una filosofia però bisogna capire quanto questo sia in conflitto con una realtà che è diversa e molto più caotica/frammentata. In questa "lotta" trovo in realtà una volontà molto discutibile di rifiuto della tecnologia attraverso asupicati ritorni a linguaggi "più semplici". Come cantava Elio?

Laaaaa beeeela canAzone di una VolEtaaaaa, facieva sorideeere la genEte...

@NickelGreen

Secondo me, sono le applicazioni "pesanti" che creano sviluppo tecnologico non il contrario

Infatti, non dico di fare applicazioni meno complesse, ma di spostare la complessità, una maggiore complessità, sul browser. Quindi, sarà questo a svilupparsi.

La dinamicità del web di oggi è data da un maggiore uso delle potenzialità del browser. Si è passati dalle pagine statiche, alle pagine generate dal browser con scarso uso di JavaScript, a pagine con poco uso di markup, molto di DOM, CSS, JavaScript e framework JavaScript. Anni fa robe come Propotype, jQuery, Scriptaculous, ExtJS, e così via, non esistevano. E sono tecnologie complesse che tendono riversare il proprio peso sul client.

In questa "lotta" trovo in realtà una volontà molto discutibile di rifiuto della tecnologia attraverso asupicati ritorni a linguaggi "più semplici"

Infatti non è un'esemplificazione tecnologica.

@Paperino

No seriously, they are not for security, they are for compatibility *if* wanted. If you care to read the TargetXXXXX functions it will become obvious.

S'è sbagliato: pensava fosse un meccanismo di sicurezza, invece serve ad altro.