Před cca měsícem a půl byl vydán finální pracovní návrh 5. edice specifikace ECMA-262, která definuje podobu JavaScriptu (nebo přesněji ECMAScriptu). Tento článek je prvním dílem dvoudílného miniseriálu, ve kterém se seznámíme s nejdůležitějšími změnami a novinkami, které nová verze specifikace přináší.
Vysvětlíme, co znamená Infrastructure as Code, popíšeme výhody tohoto přístupu, alternativy a testování.
SameSite cookies poskytují mechanismus, jak rozpoznat, co vedlo k načtení stránky. Jestli to bylo prokliknutí odkazu na jiném webu, odeslání formuláře, načtení uvnitř iframe, pomocí JavaScriptu atd.
V kroužku programování se snažím prvních deset minut věnovat nějaké aktivitě bez počítače. Jsou znalosti, na kterých byly počítače postavené a které by bylo vhodné znát.
RE: Co přináší nový ECMAScript 5?
Velmi důležité je, že uživatel třídy změnu implementace vůbec nezaznamená
Přimlouval bych se za to, vůbec nepoužívat slovo třída v souvislosti s JavaScriptem. Jinak fajn článek, těším se na pokračování.
RE: 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.
RE: Co přináší nový ECMAScript 5?
Asi bych se držel označení konstruktor a prototyp konstruktoru. Možná to zní krkolomně, ale přpadá mi to méně matoucí – je to jen můj názor. Ono existuje dost JS frameworků, které si zavádějí všelijaké vlastní implementace klasické "třídové" dědičnosti, člověk si pak při čtení různých článků musí v mysli pojem "třída" přepínat na různé významy.
RE: Co přináší nový ECMAScript 5?
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.
RE: Co přináší nový ECMAScript 5?
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.
RE: Co přináší nový ECMAScript 5?
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.
RE: Co přináší nový ECMAScript 5?
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í.
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?
„skoro připravené“ je hodně nadsazený výraz
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).
RE: Co přináší nový ECMAScript 5?
Reakce o kousek níže pod názorem pana Hassmana.
RE: Co přináší nový ECMAScript 5?
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.
RE: Co přináší nový ECMAScript 5?
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í.
RE: Co přináší nový ECMAScript 5?
Obavam se, ze tento krok by webovou platformu pravdepodobne zabil.
RE: Co přináší nový ECMAScript 5?
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.
RE: Co přináší nový ECMAScript 5?
Nesleduju vývoj v oblasti JS tak do detailu, takže mi možná něco podstatného uniká a plácnu pitomost, ale myšlenka JS pluginu vypadá velmi logicky. Po technické stránce je toto řešení naprosto čisté …
Ale z ekonomického hlediska?
… Za Flash Playerem stojí Adobe a má ekonomický zájem na prodeji nástrojů pro tvorbu Flash aplikací – mimo jiné … za Silverlightem je Microsoft … kdo se podobným způsobem postaví za "JS-player" a proč?
RE: Co přináší nový ECMAScript 5?
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?
RE: Co přináší nový ECMAScript 5?
No, ta architektura se mi nezdá špatná … ale to je houby platný … tady je důležité, proč to tedy někdo právě takto neudělá (nebo už neudělal)?
Neberte tu otázku jako protiargument. Ta otázka prostě visí v luftě, ať si o tom my dva, nebo kdokoli jiný myslí co chce :o)
RE: Co přináší nový ECMAScript 5?
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. ;-)
Re: RE: Co přináší nový ECMAScript 5?
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.
Upřesnění
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:
Object.sealkromě 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.Object.freezedělá totéž jakoObject.seal, ale navíc zabraňuje měnit hodnotu vlastností.Za nepřesnosti se omlouvám.
Re: Co přináší nový ECMAScript 5?
Prototyp objektu nejde zjistit vůbec, pouze je možné se pomocí funkce Object.prototype.isPrototypeOf 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.constructor.prototype čo funguje úplne rovnako ako neštandardná vlastnosť objekt.__proto__