sobota 24. července 2010

JavaScript vládne všem

Varování tento článek může budit velkou kontroverzi. Pokud se v něm mluví o minulosti, přítomnosti a budoucnosti, je tak činěno v kontextu internetových aplikací. Eneterprise (podnikové) aplikace mají vlastní svět s jinými zákonitostmi nicméně bylo by zarážející kdyby se jich níže napsané vůbec nedotklo.

Když člověk pracuje s partou lidí, kteří píšou aplikaci v určité technologii, jako se to stalo mě v GoodData, otevře mu to prostor k tomu, aby se dozvěděl plno nových informací a posunul svoje vnímání určité oblasti do širšího kontextu. Od dob kdy jsem psal v JavaScriptu já už uběhlo pěkných pár let. A upřimně už bych ten dnešní kód považoval za jiný jazyk. On ten jazyk ve skutečnosti zůstal v hodně rysech stejný, jenom se posunul způsob jak vypadá architektura klientských aplikací a to mělo pochopitelně za následek, že se začaly používat konstrukce a přístupy, které před tím nebyly potřeba.

Dříve bylo opravdu běžné, že JavaScript sloužil na straně klienta pouze k tomu, aby umožňoval připravit data k odeslání na server případně k manipulaci s UI prvky na stránce. Ta doba skončila ve chvíli, kdy se objevil koncept asynchronního dotazování serveru známý pod názvem AJAX a servery místo komplexních odpovědí začaly poskytovati i ty dílčí. Najednou se architektura aplikací posunula k něčemu co označujeme jako rich client.

Točíme se v kruhu

Se softwarovou architekturou, je to stejné jako s módou, historií, designem či čímkoliv jiným. Točíme se v kruzích, jenom s každou otáčkou maličko chytřejší, dlužno dodat doufejme. Stejně jako jsme utíkali od konceptu tlustých klientů, abychom mimo jiné ušetřili jejich omezené zdroje, se teď k těmhle klientům vracíme, protože zdroje serveru jsou ještě omezenější. Jisté koncepty fungují jinak v prostředí lokální sítě a jinak v prostředí Internetu.

Namísto toho, aby se JavaScript používal na straně klienta jako doplněk, přebírá roli tažného koně. Už to není server, kdo rozhoduje o posunu aplikace z jednoho stavu do druhého, ale je to klient. To sebou samozřejmě nese nároky na to kolik kódu je najednou na klientu. Najednou se i v JavaScriptu hledají způsoby jak psát klientský kód (část aplikační logiky) podle Model-View-Controller vzoru, aby byl kód udržovatelný a nebyla z něj koule špaget. Daleko není doba (možná už nastala), kdy vznikne i v klientských aplikacích silná poptávka po Inversion of Control k řešení problémů těsných vazeb.

Změna architektury klientských aplikací rovněž vedla k velké zátěži prohlížečů, především v oblasti výkonných a paměťově šetrných JavaScript podvozků. Takový V8 engine běhající v Google Chrome je natolik výkonný, že je nad ním postavený nodeJS server kompletně založený na JavaSciptu.

JavaScript jako dominantní jazyk "desktopu"

Jestliže se mění architektura aplikací je na místě ptát se proč se tomu děje. Odpověď je ukrytá v tom kam se posouvají naše data a služby, které používáme. Už to není desktop, lokální počítač, ale vzdálený počítač, a desktop respektive prohlížeč je pouze terminál (nevracíme se opět na začátek?). Budeli nějaký jazyk v budoucnosti dominovat desktopu, v našem smyslu chápání místo odkud používáme služby a data, bude to bez pochyby JavaScript jako jazyk platformy (prohlížeče), na které aplikace běží.

Pokud se mě zeptáte, jaký jazyk se učit s výhledem do budoucnosti, odpovím vám bez váhání JavaScript. Samozřejmě i celý ten ekosystém okolo jako je JSON, HTML 5.

A naopak je zbytečné se bavit o tom, který jazyk je budoucností pro server, protože to není vůbec podstatné z pohledu architektury, kterou mají a budou mít internetové aplikace.

čtvrtek 22. července 2010

Příběh jedné URL

Mohla to být úplně nezajímavá změna, něco co prostě přejdete mávnutím ruky, ale není. V maličkostech se skrývají podstatné rozdíly. Když Oracle "udělal" Sun, slyšeli jsme mnoho zpráv o tom, jak Oracle bere Javu vážně. Od doby permanentního připojení k internetu a schopností Google splnit mé nejtajnější přání nemám na disku Javadoc (dokumentace) k standardnímu API Javy. Prostě pokud se potřebuju na něco v API podívat, zásadně tak dělám přes Google. Prostě a jednoduše zadám jméno třídy, bum a voala tady je výsledek.

Protože Google indexuje a hledá tak jak hledá, někdy dostane člověk starší verzi Javadocu. Příklad dostanete URL http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Object.html, vás zajímá verze 1.6, tak co uděláte, změníte číslo pět za šest, bum a voala tady je výsledek podle očekávání.

Pardon, nenechte se uvést v omyl, takhle to fungovalo, než se Sun stal součástí Oracle. Nastala migrace na IT infrastrukturu Oraclu. Místo těhle člověku pochopitelných URL vás teď čeká následující paskvil v podobě URL http://download.oracle.com/docs/cd/E17476_01/javase/1.5.0/docs/api/java/lang/Object.html. Kromě toho, že URL je opravdu příšerné, tak změny verze záměnou čísel nefungují. Opravdu by mě zajímalo, co nebo kdo je E17476_01 a co znamená magické cd v URL. Perličkou pak je, že Oracle servery jsou opravdu příšerně pomalé. Ono to tedy spíš vypadá, že ten server bude jeden.

Někdy minulý týden jsem si na to stěžoval na Twitteru. Dneska jsem tam zaznamenal, že si toho všimli i další lidé. Oracle už s tím asi někdo pěkne vyplísnil protože: @oracletechnet: Yes, have noted javadoc URL issues and we are exploring solutions with IT right now. Please stand by..

Nejenom tahle událost (viz Mračna, sluníčko a nebo smrádek a teploučko nad Javou ) ve mě budí dojem, že se Java prostě dostala u Oraclu na druhou kolej. Neberu jakékoliv argumenty o přechodu na novou infrastrukturu. Jestliže beru Javu seriozně, jak můžu jednoduchost dostupnosti její dokumentace takhle zpriznit. Odpověď je, že jí asi moc seriozně neberu.