Názory k článku
Co přináší nový ECMAScript 5?

Jsem si vědom, že pojem "třída" je nesprávný, bohužel jsem ale nepřišel na to, jak lépe a bez krkolomného opisování označit dvojici (Rectangle, Rectangle.prototype), což je to, co onou třídou myslím. Pokud vás nějaké pojmenování napadá, rád ho uslyším.

Proto je obrovská škoda, že ES4 byl zavržen - tam je třída tak, jak ji chápe každý normální programátor. Vůbec nechápu, čeho se báli. Výrobci browserů by prostě postupně doplnili implementaci ES4 jako druhého dostupného jazyka (Mozilla už ji měla k dispozici od Adobe) a vývojář by měl pořád na výběr, ve kterém z těch dvou jazyků bude vyvíjet. Přechod by mohl být pozvolný, ne žádná revoluce.

Představa, že implementátoři prohlížečů budou mít uvnitř interprety dvou podobných a přitom různých jazyků je naivní - dost by to zesložitilo (a tedy i prodražilo vývoj) a zmátlo uživatele. To určitě není schůdná cesta.

Oobně jsme z ES4 měl dost rozporuplné pocity. Na jednu stranu přibližoval JavaScript běžným jazykům a obsahoval velké množství zajímavých myšlenek (třeba poměrně sofistikovaný typový systém), na druhou stranu jazyk opravdu hodně zesložiťoval a nové funkce leckdy nebyly ortogonální a působily trochu dojmem "vezmeme všechno užitečné, co jsme kdy v jakém jazyku viděli, a přidáme to do ECMAScriptu".

Nedivím se tedy těm, kteří zavržení ES4 litují, ale ani těm, kdo s ním souhlasí. Možná je nakonec cesta postupného vylepšování nejrozumnější a ty opravdu důležité funkce ES4 se snad časem do ECMAScriptu dostanou.

Já nevím, co je na tom naivního. Stejně jako Silverlight je možné programovat v různých jazycích, i browsery by umožňovaly něco takového. Spíše mi připadá naivní snaha shodnout se na jednom jediném jazyku, jde to trochu proti ekonomickým teoriím. Zkrátka Mozilla by přišla s ES3 a ES4 (už to měla skoro připravené), jiné browsery by přišly s jinými jazyky. Jistě, tím pádem by některé aplikace fungovaly jen v některých browserech, ale to je úplně odlišná situace od toho chaosu, který tu panoval, když každý browser si interpretoval standardy po svém. Toto by fungovalo jako konkurecne, která by nutila ke zlepšování jak browsery, tak i jednotlivé jazyky. Bez konkurence celý obor zakrní nebo se vývoj zpomalí. A na tom vydělá jedině Silverlight a Flash.

Já nevím, co je na tom naivního. Stejně jako Silverlight je možné programovat v různých jazycích, i browsery by umožňovaly něco takového.

Naivní je předpokládat, že výrobci browserů budou ochotní něco takového udělat. Technicky to samozřejmě problém není, ale není k tomu (dle mého - myslím že docela informovaného - názoru) vůle. Jediný, kdo více interpretů v prohlížeči má, je Microsoft, který kromě JScriptu umožňuje používat i VBScript. Jenže u Microsoftu byla motivace usnadnit webový vývoj programátorům ve Visual Basicu, svůj skriptovací framework využili i jinde a je to velká firma. Pro ostatní výrobce prohlížečů nic z toho neplatí.

Spíše mi připadá naivní snaha shodnout se na jednom jediném jazyku, jde to trochu proti ekonomickým teoriím.

Proti jakým? Dokážete mi popsat, proč bych se jako vedoucí vývoje třeba Opery měl rozhodnout nějaký takový jazyk implementovat? Co mi to přinese za zisk?

Mimochodem, připadá vám také naivní, že se všichni shodli na HTTP, HTML a CSS jako jediných reálně používaných stadardech pro danou oblast?

Zkrátka Mozilla by přišla s ES3 a ES4 (už to měla skoro připravené)

"skoro připravené" je hodně nadsazený výraz

Jistě, tím pádem by některé aplikace fungovaly jen v některých browserech

Jinými slovy, nikdo by ony nové jazyky nepoužíval, protože by aplikace v nich napsané nebyly univerzálně použitelné (pokud by zas nějaký prohlížeč nezískal 90+ % trhu) a všichni by raději psali v "horším" ale všude fungujícím JavaScriptu (nebo do něj skripty kompilovali).

Reakce o kousek níže pod názorem pana Hassmana.

Prohlížeče se tam, kde jen můžou, vyhýbají nějakému větvení a la nová metoda/stará metoda a tam, kde k tomu z historických důvodů muselo dojít, se ještě po mnoha letech jedná o přítěž.

Rovněž si myslím, že je to naivní. Protože s tím asi nebudete souhlasit, doporučuji podrobněji nastudovat historii prohlížečů a webových technologií a případných problémů. Jedině asi tak pochopíte.

Právě že historii prohlížečů už asi 15 let sleduju, a vedle toho i historii RIA technologií, přišel jsem s tímto nápadem. Nyní ho ještě upřesním a poopravím. Skriptovací jazyk by mohl být zcela oddělen od samotných browserů, vyvíjený klidně i třetími stranami a dle potřeby doinstalovávaný jako plugin. Pak by nastala zdravá konkurence mezi jazyky, která by uživatele téměř nijak neotravovala (stejně jako ho neotravuje, když si jednou za uherský rok nainstaluje Flash a Silverlight), vývojáři by měli na výběr to, co jim nejlépe vyhovuje, a celý obor by šel efektivně kupředu, než když se tak obrovské odvětví jako je web musí shodnout na jednom jazyku a dopadá to tak, že to je jazyk nedokonalý, protože se každý bojí revoluce.

Podotýkám, že rozhodně nezpochybňuju, že HTML a DOM standardizované být musí.

Ale proč? Neříkám, že mám vše do důsledku domyšlené, a tak bych rád o tom diskutoval. Další rozvinutí toho nápadu: Zpracování JavaScriptu se posunuje a bude posunovat směrem od interpretovaného skriptovacího jazyka k JIT kompilaci, je to tak nebo se pletu? Co potom brání tomu, aby vývojář dodal BUĎ zdrojový JavaScript NEBO předkompilovaný bytecode, který si vytvořil v libovolném zdrojovém jazyku? Stačilo by standardizovat za prvé HTML/DOM a za druhé bytecode, který s ním manipuluje. Je nějaký důvod z hlediska ideálů webové platformy nutné standardizovat ty zdrojové jazyky? Není možné se inspirovat Silverlightem? Znamenalo by to snad nějaký vendor-lock? A opakuji - jako "konzervativci" byste se měli obávat, že tato jazyková rigidnost odláká lidi směrem k progresivnějším RIA technologiím.

Tak připomenu poslední iteraci mého nápadu - web platforma standardizuje pouze VM pro zpracování bytecodu, nikoliv konkrétní jazyk (a z důvodu zpětné kompatibility obsahuje i kompilátor starého dobrého JavaScriptu do bytecodu). Kdo tedy má zájem na výrobě nástrojů pro produkci onoho bytecodu? Za prvé open source komunity nadšenců, kteří se snaží prosadit svůj jazyk jako nejlepší na světě (viz třeba Ruby). Za druhé zavedené firmy, které se snaží prodat své vývojářské nástroje navázané na existující jazyky (Visual Studio, Flash Builder). Zkuste mi vysvětlit, proč je tato architektura špatná a čemu by neprospěla?

Proč to někdo neudělá? No já nevím, třeba to ještě nikoho nenapadlo. :) Můžeme o tom leda někde veřejně diskutovat, a tak se to třeba někdy donese i k někomu kompetentnějšímu. Tedy pokud mi tady někdo nějak rozumně nevysvětlí, že to je špatný nápad.

Ale mě to je v podstatě jedno, mě živí a zajímají mě především RIA technologie, takže tady vlastně napovídám milovníkům tradičních webových technologií, jak jim pomoct konkurovat a přežít. I když si pan Hassman nejspíš myslí, že mi jde o to je pohřbít. ;-)

No, asi do toho zas tak nevidíte. JIT kompilace se nedělá do bytecode, ale do nativního kódu, protože jedině ten může běžet přímo na železe.

To co popisujete je opravdu .Net. Různé jazyky se kompilují do jednoho bytecode a ten se pak kompiluje (JIT) do nativního. Samozřejmě že by to tak fungovat mohlo, je to lety prověřený princip. Problém je, že je to nahony vzdálené současné situaci v prohlížečích. JS prohlížeče umí „od přírody“, Java, Silverlight, Flash jsou ty pluginy.

Na základě právě přešteného článku Johna Resiga bych rád opravil několik menších nepřesností v popisu funkcí omezujících práci s pobjekty, které se dostaly do článku:

• Funkce Object.seal kromě zákazu mazání vlastností objetu také zabraňuje změnit jejich charakter (např. implementovat obyčjnou vlastnost getterem/setterm, vyjmout ji z procházení for..in-cyklem apod.) a navíc zabraňuje přidávání nových vlastností do objektu.
• Funkce Object.freeze dělá totéž jako Object.seal, ale navíc zabraňuje měnit hodnotu vlastností.

Za nepřesnosti se omlouvám.

Prototyp objektu nejde zjistit vůbec, pouze je možné se pomocí funkce Object.prototy­pe.isPrototype­Of nebo operátoru instanceof dotázat na to, zda řetězec prototypů objektu obsahuje nějakou konkrétní hodnotu. Poznámka: Ve Firefoxu, Safari a Chrome je ke zjištění prototypu objektu možno použít speciální vlastnost __proto__, která obsahuje odkaz na něj. Tato vlastnost ale nemá oporu ve specifikaci ES3.

Na objekt prototypu sa dá odkazovať cez objekt.construc­tor.prototype čo funguje úplne rovnako ako neštandardná vlastnosť objekt.__proto__