Egészen a közelmúltig az Opera büszkén hirdette, hogy az övék a leggyorsabb JavaScript motor a piacon. Jelenleg is ez található meg az Operában, a 9.5-ös szériában, és a 10-es verzió előzeteseiben egyaránt. Ennek a motornak a fejlesztési kódneve Futhark (a rúnaírás egy észak-európai változata).

A Futhark a maga idejében valóban a leggyorsabb motornak számított annak ellenére, hogy a fejlesztése során a legfontosabb szempont nem a sebesség, hanem sokkal inkább az alacsony memóriahasználat és a kis kódméret volt. Az Opera ugyanis sok olyan eszközben is felhasználta, ahol az erőforrások igencsak korlátozottak, a motor ennek ellenére meglepő sebességről tett tanúbizonyságot. Egészen a közelmúltig nem is volt vele különösebb probléma. A Chrome és a Firefox 3 megjelenése viszont rendesen felkavarta az állóvizet, mivel új, soha nem látott sebességeket értek el saját JavaScript motorjaikkal, és azóta is lelkesen fejlesztik azokat. Ráadásul a WebKit készítői sem tétlenkednek, az internetes fórumok pedig ma már a V8, Tracemonkey és Squirrelfish ütközeteinek zajától hangosak.

Az Opera a régi motorral már csak a sor végén kulloghat (az Internet Explorert leszámítva), ráadásul az új, gyors motorok elterjedésével egyre több oldal ki is használja a nagyobb sebességből fakadó előnyöket. Nem lehet lazán legyinteni, hogy csak néhány milliszekundumról van szó: a Gmailhez hasonló komplex oldalakon tisztán érezhető a különbség.

A fejlesztői blogon olvasható mai bejegyzés alapján azonban az Opera felveszi a kesztyűt. Az utóbbi hónapokban ugyanis titokban egy új ECMAScript motort fejlesztettek, ami a Carakan nevet kapta. Az Opera ugyanis régi írásformák neveit adja  JS motoroknak, mint Linear A, Linear B vagy a már említett Futhark, míg a Carakan egy jávai írásforma neve.

A fejlesztők több módon kívánják növelni a futtatás sebességét. Egyrészt az eddigi verem-alapú bájtkód-futtatás helyett áttértek a regiszter alapúra, ami szükségtelenné tesz bizonyos verem átrendezési utasításokat. A másik technika bizonyos bájtkód-részletek natív kóddá alakítását jelenti, ami jelentős sebességnövekedéssel járhat. Tovább gyorsul a reguláris kifejezések kezelése is. Végezetül, sok apróbb optimalizálás mellett, változik az objektumok kezelése. Ezentúl a böngésző igyekszik őket osztályokba rendezni, ezáltal gyorsítva a kezelésüket és csökkentve a tárolásukhoz szükséges memóriát. Ezek után már csak két fontos kérdés maradt, amit laikusként fel tudunk tenni: milyen gyors valójában, és mikor érkezik.

Ami a tempót illeti, erről vannak információink. A félkész, tehát natív kódot nem fordító jelenlegi verzió sebessége a népszerű SunSpider teszt alapján nagyjából két és félszerese az Opera 10 mostani megoldásáénak. Más mérések szerint a natív kódokat is felhasználva a különbség 5 és 50(!)-szeres mértékű, az alkalmazott teszttől függően.

A megjelenésről csak annyit tudok mondani, hogy már nagyon várom, de konkrét időpont nem szerepel sehol. Egy hivatalos személytől származó blogbejegyzés szerint azonban sajnos nem valószínű, hogy az új motor a maga teljes pompájában bekerül majd a végleges Opera 10-be...