Motori Javascript, i conti non tornano
di - Lunedì 29 Settembre 2008 alle 11:53
La comparsa di Google Chrome e i suoi impressionanti risultati di velocità nei test Javascript hanno messo fretta a tutti i concorrenti. Le performance Javascript, difatti, sono essenziali per tutti quei siti che fanno uso intensivo di Ajax, la tecnologia basata su Javascript che permette di realizzare vere e proprie applicazioni Web, da Facebook a Google Docs.
L’ultimo arrivato è SquirrelFish Extreme, la nuova versione dell’interprete/compilatore Javascript di WebKit, il motore di rendering di Apple Safari (e anche di Chrome). Ma i test di velocità, in questo caso, lasciano qualche dubbio.
Secondo alcuni, difatti, il nuovo SquirrelFish sarebbe più veloce tanto di V8 (usato da Google Chrome) che di TraceMonkey (usato da Firefox 3.1, la prossima versione del browser di Mozilla). Precisamente, utilizzando il test SunSpider sviluppato dal team di WebKit, i risultati sarebbero questi:
- SquirrelFish Extreme: 943.3 ms;
- V8: 1280.6 ms;
- TraceMonkey: 1464.6 ms;
Allora Firefox 3.1 è più lento di Google Chrome? In realtà le cose stanno diversamente: Firefox 3.1 è più veloce nel test di Google Chrome, come sottolineato da Mozilla e come noi stessi abbiamo avuto modo di verificare.
La spiegazione sta nel fatto che il test pubblicizzato dal team di WebKit è stato effettuato da linea di comando, senza il browser “intorno” e quindi non in una situazione reale. “In the wild”, invece, Firefox 3.1 risulta più performante di Google Chrome. Accadrà qualcosa di simile anche quando SqirrelFish Extreme verrà iniettato dentro Safari?
Comunque sia, chiunque vincerà la guerra per il motore Javascript più veloce, a prevalere sarà comunque il software libero: WebKit, V8 e TraceMonkey sono tutti e tre open source, mentre le performance di Opera e Internet Explorer (anche nella versione 8 in sviluppo) rimangono al palo.
Va precisato che Ajax non è altro che una chiamata al server e di una risposta. E’ la successiva interpretazione dei dati e le relative modifiche alla pagina che sono sensibili alle performance del motore JS. Altrimenti è la velocità della connessione a fare la differenza, anzi, visto che il volume dei dati generalmente scambiati non è grande, conta parecchio anche la latenza.
di DnaX - 29 Settembre 2008 - 14:17
va comunque ricordato che la qualità di un browser non è data solo da ms di velocità ma anche da usabilità, semplicità, sicurezza e personalibità.
staremo a vedere se i browser proprietari saranno all’altezza…
di luimors - 29 Settembre 2008 - 19:18
Bisogna anche iniziare a standardizzare i motori javascript: alcune cose funzionano su Firefox,ma non su IE, altre su Safari e non su Chrome.. ecc. ecc. Per uno sviuluppatore e’ dura dover far testing con 10.000 browser diversi e perdere il 90% del development time a trovare una patch per i bug di alcuni.. quindi.. essendo io un Ajax-Developer non vedo l’ora.. che un browser abbia la meglio.. per favore decidete in fretta ed eleggiamo uno standard!! con uno motore standard (di cui almeno gli altri dovrebbero rispettarne le specifiche funzionali) potremmo sviluppare codice 2.0 molto molto piu’ infretta.. quindi produrne di piu’..
di stefano gargiulo - 30 Settembre 2008 - 21:12
@stefano: Lo standard c’è, ed è JavaScript 2. Il problema sono le classi aggiuntive implementate in ogni motore, sono quelle che andrebbero standardizzate. Le specifiche DOM per esempio sono utilissime, anche se al momento non so se sono completamente supportate da qualunque browser. E cmq ci sono poche cosette supportate solo da determinati browser. L’oggetto XHR e alcune procedure per intercettare gli eventi.
Spero di non aver detto sfondoni, la mia esperienza è puramente autodidatta.
di DnaX - 01 Ottobre 2008 - 15:55