Proč JavaScript potřebuje kontinuace

12.11.2010 02:06 | Přečteno: 1481×

JavaScript si za dobu své existence nevydobyl zrovna nejlepší pověst a jen pozvolna se začíná prosazovat jako plnohodnotný samostatný programovací jazyk (viz projekty jako node.js). Existuje však celá řada důvodů, proč JavaScript začít brát vážně.

Při pohledu na výsledky syntetických benchmarků (http://shootout.alioth.debian.org/u32/which-language-is-best.php#about) je zjevné, že válka mezi výrobci prohlížečů o co nejrychlejší engine pro JavaScript přináší konkrétní ovoce. Už dnes jsou implementace JavaScriptu rychlejší než u většiny nejpoužívanějších dynamicky typovaných jazyků a pokud se najdou ještě nějaké rezervy, což je při míře prostředků a energie, která se do tohoto výzkumu vynakládá, více než pravděpodobné, může se JavaScript začít používat i v oblastech, kde by to dříve bylo nemyslitelné.

Už dnes existuje poměrně elegantní a jednoduchý způsob, jak s pomocí JavaScriptu docela snadno a rychle vytvořit multiplatformní desktopovou aplikaci s konvenčním vzhledem a chováním a přitom se nevzdát vymožeností, které přináší webový prohlížeč. Konkrétně například nechat zobrazit část aplikace pomocí HTML kódu či třeba pomocí SVG. Tou možností je použití XULRunneru od Mozilly, který v sobě integruje Gecko.

Taková jednoduchá aplikace vypadá tak, že si vytvoříte základní adresářovou strukturu s metadaty, do ní vložte popis GUI pomocí značkovacího jazyka XUL a okořeníte nějakým tím JavaScriptem (https://developer.mozilla.org/en/getting_started_with_xulrunner). V kombinaci například s CouchDB, u které se díky použítí JSONu pro komunikaci s databází v podstatě můžete vyhnout nepříjemnostem s objektově-relačním mapováním, to tvoří lákavý základ pro řadu aplikací.

Na rozdíl od běžných webových aplikací má lokální XULRunnerovská JavaScriptová aplikace řadu možností a bezpečnostních privilegií navíc. Může pomocí Ajaxu komunikovat s webovými servery v jiných doménách, spouštět lokální procesy (pomocí nsiProcess), pracovat s lokálními soubory, používat nativní souborové dialogy, otevírat nová samostatná okna, má bohatší možnosti v používání klávesových zkratek atd. Navíc XULRunner má v sobě integrován přímo Firefox, což znamená, že se můžete obejít bez jeho distribuce s prográmkem.

Tahle varianta mě zaujala a řekl jsem si, že by nebylo špatné se zamyslet nad možností vytvořit si nějaký elegantní framework, který by tvorbu takových jednohubek usnadnil. Začal jsem tedy zvažovat, jaká architektura by se pro něj hodila. Hlavní potíž spočívá v tom, že stejně jako u webového prohlížeče je JavaScript zpracováván v jednom vlákně. To přijímá události od uživatele (např. stisknutí tlačítka), zpracuje kód, který je jim přidělen a poslouchá dále. Krom možnosti vyhodnotit daný kód po určitém čase (či asynchronního přijetí HTTP požadavku) programátor žádné možnosti nemá.

To ale bohužel nestačí. Představte si situaci, kdy potřebujete vytvořit nějakého průvodce (wizzard), nějakou posloupnost formulářů. Teď trochu neférově pominame fakt, že XUL takovou komponentu definuje - zde mi jde o obecný problém.

V elegantním frameworku byste předpokládali, že při otevření průvodce by byla definována metoda vypadající nějak takto:

show(page1);
show(page2);
show(page3);

Jenže to by předpokládalo, že metoda show() zobrazí nový formulář, ukončí provádění aktuálního kontextu, spustí nové přijímání a zpracovávání událostí a v případě, že jedna z nich by byla stisknutí tlačítka “next” na formuláři, předala by řízení zpět do této metody na místo, kde naposledy přestala.

To by šlo provést tak, že při zavolání metody show() se zobrazí nový formulář, vytvoří se kontinuace a pomocí vyvolání výjimky se ukončí vykonávání tohoto úkolu a vlákno JavaScriptu přejde opět do režimu přijímání událostí. Při stisknutí tlačítka “next” by se obnovil aktuální kontext z uložené kontinuace a pokračuje se vesele dalším show().

Bylo by to hezké, ale bohužel JavaScript kontinuace nemá a asi mít jen tak nebude. Přesněji řečeno, Rhino kontinuace má, jenže to je pro XULRunner aplikace jen pramalá útěcha. A autoři V8 o implementaci kontinuací vůbec neuvažují.

Bohužel i ostatní možnosti, jak tento problém nějak vyřešit, Gecko úspěšně sabotuje. JavaScript není dostatečně reflektivní, aby měl tak bohatý přístup ke stacku, aby dokázal informace aktuálního stavu stacku uložit a zpětně rekonstruovat. I když se vzdáme přímo myšlenky použít kontinuace, které jsou pro tento případ stejně asi zbytečně komplexní, JavaScript nenabízí použitelné řešení. Nemá výjimky s návratem na místo vyvolání, nemá žádné uspání procesu atd. Mozilla sice umožňuje vytvářet nová vlákna (Worker), ale ta jsou silně oddělena a pro tento účel je nejde bohužel použít.

Jediná zdánlivě použitelná varianta je použít uzávěr nad zbytkem metody po každém show, bohužel to selhává především na faktu, že takový uzávěr může ovlivnit pouze aktuální kontext a kontexty se tedy nesmí zanořovat.

Bohužel nezbývá tedy než takovou aplikaci nechat plně řidit událostmi prostřednictvím nějakého MVC/MVP vzoru, kde se tok řízení aplikace ztrácí.

Krom problémů s absencí kontinuací je ještě spousta jiných věcí, co by se daly JavaScriptu vytknout a většina z nich souvisí s tím, že pro tento jazyk byla zvolena C-like syntaxe. Oddělení výrazů od příkazů (a s tím např. související dvojí možnost zapsání alternativy), indexování od nuly u jazyka bez ukazatelů, naprosto příšerný základní cyklus for, poměrně ukecaný zápis uzávěrů atd.

Navíc JavaScript trpí tím, že si v něm konkuruje několik přístupů, jak např. nahradit třídy, přičemž žádná z hlavních takto vzniklých knihoven není natolik obecná, že by předpokládala spouštění JavaScriptu bez vazby na prohlížeč. Samozřejmě nelze tvrdit, že taková konkurence je úplně špatná, ale život to komplikuje.

Přes výhrady, které bych k JavaScriptu měl, nemyslím, že je to jazyk zavrženihodný. Ale i věkem je to puberťák kterému by neuškodilo dospět.

       

Komentáře

[pavlix]

Proti javascriptovým aplikacím nic nemam (třeba nad Glib), ale XULu se snad radši vyhnu.

[mirec]

Ja som kedysi na Javascript dosť nadával pretože som nerozumel ECMA-Script-u. S ECMA-Scriptom robím momentálne takmer denne a po tom, čo som začal chápať jeho filozofii sa mi zdá aj celkom fajn.

Ćo sa týka samotného webového javascriptu ten pravdu povediac moc nemusím. Podľa mňa samotné prehliadače mali mať od začiatku niečo ako JS framework namiesto súčasných trápnych volaní ako insertHTML. V čistom JS bez frameworkov som istého času písal (a aj napísal) funkčného jabber klienta (ktorý bežal v Opere, IE >= 6, Gecko, Webkit, Konqueror >= 3.5). Ani si neviete predstaviť množstvo bugov v implementácii DOM.

Ako užívateľ JS nemám rád, často surfujem z mobilu a 10s záseky na weboch používajúcich JS frameworky sa mi nepáčia. Hlavne keď väčšina vecí by sa dala poriešiť cez CSS. Zvyšok (dynamické prvky) cez JS, ale chcelo by to pridať do browserov niečo ako framework, aby nebolo potrebné linkovať obrovské na parsovanie náročné hrúzy.

[Ladicek]

Podľa mňa samotné prehliadače mali mať od začiatku niečo ako JS framework

IMHO by prohlížeče dneska měly povinně obsahovat posledních pár verzí jQuery, nějaký meta tag pro zvolení verze a nějaký fallback. Ale už za tuhle myšlenku mne místní XHTMListi nejspíš sežerou

[pavlix]

Ja som kedysi na Javascript dosť nadával pretože som nerozumel ECMA-Script-u.

Tak ono je to de facto to samý, že :). Ale teď, když už to znáš, tak je zbytečné ti připomínat rozlišení jazyka a objektového modelu.

[________________]

JS je jednoduchý jazyk(jednoduchý jazyk pre jednoduchých ľudí), pre programátora rozmaznaného bohatými možnosťami moderných programovacích jazykov je jednoduchý až príliš (veď má cca 5 klúčových slov) a neposkytuje také možnosti ako ostatné mainstreamové jazyky, samozrejme dá sa to obchádzať rôznymi hackami, ale načo? A okrem toho to či je Javascript sám o sebe dobrý alebo zlý jazyk je v konečnom dôsledku nepodstatné, programovať sa dá v hocičom, dôležité sú knižnice a frameworky. Ale ako programátor webový-JS nemám rád. napriek tomu že som v ňom napísal už veľa aplikácií. V praxi trvá tvorba frontendu v JS / DOM (+ nejaký framework typu JQuery) 10x dlhšie ako tvorba porovnateľného GUI rozhrania napr. vo WPF alebo VCL, tým pádom aj cena aplikácie je 10x drahšia, a radosť z programovania nulová. Javascript je proste webový assembler...

[Tomáš Pěnička]

Ono je to spíš tak, že JS je dobrý jazyk, ale propojení s webem (mám na mysli propojení s HTML) je, jak to slušně říct, poněkud nešťastné.

[Amarok]

Presne neco podobneho jsem chtel napsat. Ja mam uplnou hruzu neco opet delat v Javascriptu, protoze spoluprace s DOMem v HTML je nevyzpytatelne. Delal jsem jenom 1x trosku vetsi projekt, na kterem jsem se vlastne JS poprve trochu intenzivneji ucil a silel jsem chvilema z toho. Proste se napr. neukladal stav do parametru CSS tak, jak by mel, a prijit na takovou chybu bylo pekne casove narocne a stalo me to dost nervu. Cili se od te doby divam na JS jen z dalky a odmitam jakoukoliv dalsi praci s JS. Akorat tak jeste implementuju cizi kod, dovedu to nejak rozchodit (napr. slideshow), ale vic me uz nezajima.

[Radek Miček]

Nešťastné je, že se jeden skript nechová ve všech prohlížečích stejně.

[Ladicek]

Jinak lidi od Node.js control flow docela řeší, viz třeba Step nebo Conductor, ale pro potřeby GUI to asi není použitelné. To přirovnání k puberťákovi je hluboká pravda

[sivlk]

Chcel by som varovat vsetkych ktory po precitani tohoto clanku zvazuju napisanie nejakeho projektu v XULe. Pred cca 2 rokmi som v nom napísal 2 mierne komplexnejsie aplikacie (remote xul, jeden TODO list a jednu skladovu aplikaciu) a dodnes toho lutujem. Viac zabugovany framework som v zivote nevidel. Cca 50% kodu tvorily rozne hacky a workaroundy. Cakanie na bugfixy, nutnost pouzivat devel verzie firefoxu. Ziaden alternativny klient, proste vendor lock-in. Nieco sa rozbilo pri kazdej novej verzii firefoxu. Navyse vysvetlite ludom ked chcu na to pristupovat z inernetu ze musia pouzit len firefox. Jednu z tych aplikacii som neskor za asi tyzden prepisal do html/css/ajax a bolo to neporovnatelne jednoduchsie. Takze pre mna XUL - uz nikdy viac.

[Pavel Křivánek]

Dnes situace tak tragická není, ale stejně bych nikomu nedoporučoval pouštět se do remote XUL přes prohlížeč bez lokální podpory, to za to vážně nestojí. Bylo by fajn, kdyby se XULu chytil ještě třeba Google, pro jehož ChromeOS by se určitě hodil.

[pavlix]

A ještě lepší by bylo, kdyby XUL něčím nahradil :).

[Karel]

Od HTML, CSS a javascriptu se snazim drzet nejdal co to jde...

[Saljack]

Moje řeč .

[Rezza]

No kdyz neco takoveho delat v JavaScriptu - proc nepouzit Qt Quick (QML) s Qt State Machine? Bohuzel psani beznych aplikaci zatim omezuji rozdelane Qt Components (a tedy na bezne GUItko si clovek musi pomoci sam from scratch).

[mirec]

Robím komerčné veci s Qt Quick + Qt Script (alias ECMA script) + C++. Pre vývoj špecializovaných hračiek s dotykovým ovládanim si to neviem vynachváliť. Na desktope je to už o niečom inom, tam som jednoznačne za klasické aplikácie (teraz nechcem zavrhovať QML na desktope, na tvorbu nejakého vlastného efektného widgetu, ktorý sa nenachádza v Qt knižniciach napr. coverflow widget sa môže hodiť).

[Rezza]

No Qt Components by to mely hodne zjednodusit i na desktopu. A pres Qt Scene Graph by to pak mohla byt hodne zajimava kombinace s tim, co by pak slo v aplikacich delat. Samozrejme dnes je to spis na ty dotykove specializovane hracky.

[mirec]

Poznám ten projekt a sledujem ho, ale zatiaľ keď potrebujem nejaký komponent podobný desktopovým widgetom tak si to radšej píšem sám, Qt Components sú ešte dosť nedokončené. Inak v bežných aplikáciách povedzme ako filemanager, správca nejakej databázy, download manager ... to asi uplatnenie nenájde. V prehrávači audio / video súborov by to už išlo, ale aj tam mám radšej klasické GUI, ktoré nevybočuje zo zaužívaného desktopového GUI. Tu by som skôr videl v možnosti pridať alternatívne GUI (vzhľadom na to, že Qt využíva MVC by nebolo až tak ťažké to urobiť) pre tablety / mobily.

[open]

http://www.sencha.com/

[Amarok]

Mam to oznacit jako spam?

[open]

Aky je dovod ? Je to k teme ... a nemal som cas sa rozpisovat, takze len som pridal odkaz.

[pavlix]

Já v tvém příspěvku nic k tématu nevidím, jen odkaz na nějaký neznámý web bez uvedení jakéhokoli důvodu, proč by měl mít co společného s diskuzí.

Je to typický příklad SPAMu, kdy se v diskuzi objeví pouhý odkaz bez jakékoli souvislosti (jestli cíl odkazu souvislost má, to už je jiná věc, samotný odkaz nemá).

a nemal som cas sa rozpisovat

Tak snad příště :).

[open]

Vyznam to ma v tom, ze po letmom prejdeni stranky na tom linku by ste objavil ExtJS (http://www.sencha.com/products/js/), ktory je JS Frameworkom a pani vyssie diskutovali aj o Frameworkoch.

Ja som jeden cas tiez riesil XUL a problemy s nim, az sme na jednom projekte pouzili na odporucanie dodavatela ExtJS na GUI a mnoho problemov sa vyriesilo.

Len tolko som tym odkazom chcel povedat.

Ospravedlnujem sa za ONLY link, nabuduce radsej nic ako iba link ;)

[Josef Kufner]

V Qt Scriptu by se taková věc dala vyřešit takto:

page1.accepted.connect(page2.exec);
page2.accepted.connect(page3.exec);
page3.accepted.connect(wizzard.mameHotovo);
page1.exec();

Co víc si přát?