Spor o budoucnost JavaScriptu vyřešen

Programovací jazyk JavaScript si zaslouží řadu přívlastků. Je to jazyk nenáviděný i milovaný, nedotažený i nepochopený. Jazyk, který byl ještě před několika lety považován na webu za zbytečnost a čisté zlo, se s rozvojem webových aplikací pomalu zařazuje mezi nejdůležitější programovacích jazyky současnosti.

Poslední široce používaná verze ECMAScript 3 pochází z roku 1999, kdy se o současných webových aplikacích a JavaScriptových frameworcích nikomu nesnilo. Není proto divu, že vývojáři i implementátoři přemýšlí o budoucnosti a hledají cesty, jak JavaScript zmodernizovat, aby vyhovoval současným potřebám.

Pozn.: Název JavaScript je ochrannou známkou společnosti Sun Microsystem, proto standardizační proces používá termín ECMAScript. Pro účely tohoto článku si dovolíme oba termíny zaměňovat.

Odvážný ECMAScript 4

V roce 2007 byl představen návrh jazyka ECMAScript 4, označovaný též JavaScript 2, tedy JavaScript budoucnosti. Na návrh dohlížel mj. Brendan Eich, duchovní otec JavaScriptu a CTO Mozilla Corporation.

A návrh to byl odvážný. Nejednalo se o drobné úpravy a rozšíření, ale o velký skok, téměř o vytvoření nového jazyka. Návrh přidával mj. jmenné prostory, rozhraní, objekty a třídy s klasickou dědičností, konstanty, gettery, settery a proměnné s typy. A to vše při udržení zpětné kompatibility s původním jazykem, takže vedle klasické dědičnosti šlo používat i původní dědičnost prototypovou, vedle proměnných s typy zároveň proměnné bez typů atd. Více najdete v samotném návrhu nebo v prezentaci Johna Resiga.

ECMAScript 4 sklidil rozporuplné reakce. Hlavní výtkou byla jeho složitost a rychlý skok oproti stávající verzi. Volání po evoluci JavaScriptu namísto revoluce se objevilo i na blogu vývojářů Internet Exploreru. Chris Wilson (architekt IE) si s Brendanem Eichem ohledně ECMAScriptu otevřeně vyměňovali nesouhlasné reakce (Chrisovo vyjádření, Brendanův otevřený dopis a Chrisova odpověď).

Rozpory uvnitř ECMA

Problém nastal i v samotné pracovní skupině TC39 u ECMA. V březnu 2007 podali zástupci Yahoo a Microsoftu návrh na vytvoření nové verze ECMAScriptu, která by nebyla tolik revoluční a místo kompletního předělání jazyka se soustředila na základní problémy.

Poté se skupina rozštěpila. Zatímco část jejích členů (převážně zástupci Mozilly, Adobe, Opery a Googlu) pracovala na revolučním ECMAScriptu 4, další členové (převážně zástupci Yahoo a Microsoftu) začali práci na ECMAScriptu 3.1, který měl být toliko revizí a evolucí stávajícího ECMAScriptu 3.

Takové tříštění sil bylo neproduktivní pro obě strany. Jelikož specifikace vznikaly nezávisle, nebyla verze 4 kompatibilní se vznikající verzí 3.1, implementátoři zainteresovaní na tvorbě jedné specifikace neměli zájem na implementaci druhé atd. Problém trval déle jak rok.

Teprve nedávno, koncem července, bylo nalezeno kompromisní řešení. Na setkání v Oslu na půdě Opera Software se všem stranám podařilo na budoucnosti ECMAScriptu dohodnout. Řešení je označováno názvem Harmony.

Harmony – nalezený kompromis

Všichni zástupci pracovní skupiny se nyní spojí na tvorbě ECMAScriptu 3.1, který bude evolucí stávajícího ECMAScriptu 3. Začátkem roku 2009 budou hotovy jeho dvě nezávislé implementace.

Přitom se bude pomalu připravovat i další verze (její označení není určeno, možná to bude ECMAScript 3.2, možná ECMAScript 3.5 nebo ECMAScript 4, zatím je ale označována jako ECMAScript post-3.1 nebo prostě Harmony). Ačkoliv by měla přinést jistou revoluci, bude výrazně skromnější, než byl původní návrh ECMAScriptu 4.

Brendan Eich poznamenává: Je to dobrá správa pro všechny, jak pro ty, kdo dávají přednost menším změnám v jazyku, tak pro ty, kdo obhajují pokračující evoluci, která si žádá novou syntaxi, pokud ne rovnou novou sémantiku.

Co nás čeká v ECMAScriptu 3.1

Podívejme se zběžně na současný ECMAScript 3.1, ze kterého se bude vycházet. Velmi se podobá ECMAScriptu, který známe dnes (najdeme v něm např. pouze prototypovou dědičnost), ale obsahuje několik zajímavých rozšíření. Zlepšena je práce s objekty a důraz je kladen na bezpečnost při spolupráci skriptů z různých zdrojů (mashupy).

Najdeme zde mj. konstanty, gettery, settery, metody Object.freeze, Object.seal, Object.preven­tExtention a Object.clone, dlouho chybějící metodu String.trim, metody pro práci s JSON a funkcionální práce s poli z JavaScriptu 1.6. Je možné, že budou zahrnuta i některá další rozšíření JavaScriptu 1.6 a JavaScriptu 1.7 z Mozilly.

Čeho se v JavaScriptu nedočkáme

Ačkoliv podoba Harmony nám není jasná, je známo, že některé části se zahodí. John Resig (JavaScript evangelist Mozilla Corporation) upozorňuje: Zapomeňte na řadu věcí, které jste o ECMAScriptu 4 dosud slyšeli. Mnoho komplikovaných konceptů jsme zahodili.

Jedná se o jmenné prostory, mechanismus balíčků (packages) a early binding. Podle návrhářů tyto principy na Web nepatří a navíc zpomalují interpretaci jazyka. Brendan Eich prohlásil: Jedná se o finální rozhodnutí, nebudou zvažovány ani do budoucna.

Návrháři zároveň nehodlají slepě kopírovat současné trendy ale budují vlastní vizi. Brendan Eich říká: Hlavním bodem, podle mě stejně důležitým jako je vyřazení jmenných prostorů, je že komise má vizi pro rozšiřování jazyka a nebude se jen snažit naroubovat novou sémantiku na kombinaci existujících syntaxí ‚tří ze čtyř hlavních prohlížečů‘ a běžných rozšiřujících knihoven.

Stanovisko Adobe

Adobe, které se na ECMAScriptu 4 rovněž podílelo, se nechce některých odvážnějších myšlenek vzdát. Proto ačkoliv bude nadále spolupracovat na vývoji společného ECMAScriptu, do jeho ActionScriptu 3 se nejspíš dostanou i některá ze zavržených rozšíření. Adobe je na rozdíl od ostatních implementátorů ve specifické pozici. Zatímco pro výrobce prohlížečů je otázka interoperability klíčová, u ActionScriptu ji není třeba řešit, protože je používán pouze v produktech Adobe (Adobe Flash, Adobe Flex); navíc Adobe již některé z vlastností implementovalo a vzít vše zpět by pro ně bylo zbytečnou komplikací.

Závěr

Původní ECMAScript 4 se zařadil mezi odvážné návrhy (slůvko „odvážné“ je skutečně namístě), které nejspíš nebudou nikdy v praxi realizovány (maximálně částečně u Adobe), ale měl vliv na zrání nové vize a pomohl tak jistým způsobem při vytváření dalších verzí ECMAScriptu.

Je dobře, že se obě strany na budoucím vývoji ECMAScriptu dohodly, jinak konflikt mohl trvat mnohem déle se všemi negativními následky, které by mohl přinést. Pokud budou na novém návrhu pracovat všichni implementátoři, je velká šance, že se jej v příštích letech dočkáme ve všech prohlížečích.

Odkazy k tématu

• After Oslo: Thoughts on Harmony and Evolution
• ECMAScript Harmony
• The Only Thing We Have To Fear Is Premature Standardization
• Brendan Eich and Arun Ranganathan on ECMAScript Harmony