... troufám si říct, že jsem si na toto téma v historicky již vzdálenější době zaexperimentoval docela dost. Ponechme stranou různé experimenty Microsoftu týkající se toho, jak zaujmaut i ty uživatele, kteří ještě docela nezapoměli číst a psát. Zajímalo by mě, proč se ve vývoji klient-side síťových aplikací opomělo několik směrů:
1) CGI běžící v browseru, ne na serveru: Javascriptové "document.write" je jen chabým náznakem toho, jak by mohly vypadat aplikace tvořící na základě různých podnětů opět interpretovaný vstup pro renderovací prostředí (nemusí jít jen o HTML...) Je to prostě jiná dimenze programování, která je objektovým programátorů cizí...
2) Sandbox pro běžný spustitelný binární kód: copak žádný operační systém nevěří svému setuid a chroot natolik, aby to bylo možné ?
3) A konečně to nejzajímavější: multiplatformní open source aplikace konstruované jako součást webu, které ejsou jakýmkoliv způsobem interpretované, ale na libovolné platformě se zkompilují do podoby spustitelného kódu. Něco takového je vlastně na základní textové úrovni apt-get install Debianu, ale proč něco takového nerozšířit na úroveň klikacího webového prostředí ? Jestliže se je dnes možné doklikat pouze k nějakým Javám, Flashům a Avalonům, které nemotorně plýtvají výkonem CPU na nějakou interpretaci, proč by prostě v budoucnu po kliknutí na odkaz nemohlo následovat (interně v počítačí, neviditelně pro uživatele) nějaké to ./configure a make install ?
To opravdu existují jen dvě formy distribuce programu - spustitelný kód a nějaký skript určený k interpretaci ? Proč neopustit paradigma browser=interpreter, a neudělat z webového browseru frontend pro plnohodnotný multiplatformní kompiler ?
ad 1) Je vhodné separovat parsovací, kompilační (jak layoutu, tak skriptů) a renderovací fázi tvorby HTML, jinak nároky na výpočetní výkon stoupají s kvadrátem objektů na stránce. Zkuste si 1000x přidat k tabulce metodou document.write nebo i přes DOM po jednom řádku a pochopíte, že je postupné vykreslování dokumentu pomalé. Tomu se Avalon runtime snaží vyhnout tím, že XAML dokument se načte do CLR jako jeden celek, naráz se předkompiluje do MSIL - a naráz se prezentuje i GUI. Proto může být rychlejší než JVM a Java based browsery (layout je statický, jako HTML), tak XUL intepretovaná Mozilla (vlastní aplikace je kompilovaná), dokonce rychlejší než MSIE (skriptovací jazyk je taktéž předkompilovaný do MSIL kódu).
ad 2) Sandbox existuje jak u .NETu (CAS), tak u Javy. Myslím ale, že by se dalo hodně udělat pro jeho zjednodušení a zpřehlednění - dnešní funkcionalita je složitá - a stejně tak je pro běžného uživatele složité nastavení i sandboxu (seznam toho, co se dá v snadboxu kódu na klientu povolit či zakázat čítá desítky položek: namátkou použití LDAP, služby DNS a dalších usermode služeb, syslogu, dialogových oken a popup dialogů, fronty zpráv, DB rozhraní jako je OLE DB a SQL NET knihoven, čítačů výkonů a profileru, tisku a/nebo výstupu na porty, použití registru a jeho jednotlivých sekcí, řadiče služeb, přístup k socketům, čtení zápis do proměnných prostředí, I/O do file systému a sandboxu, použití reflection, serializace a interop, security (Kerberos, ACL's, adresářových služeb, atd., přístup na jednotlivé porty (Web, FTP), volání unmanaged kódu, použití zásad zabezpečení systému a domény, vzdálené řízení, kvoty na GC paměť, disk nebo prioritu procesoru.).
3) To poslední se týká web start technologie Javy nebo .NETu - ovšem s native code kompilací. Myslím, že vývoj k tomu pozvolna konverguje už dnes v podobě JIT kompilace Javy apod. (aplikace se dokompiluje za chodu a postupně tak jak se moduly zavádějí do paměti) - ale pro plnou kompilaci by startovací doby aplikací byly v současné době neúnosné. Nezapomeňte, že funcionalita .NETu se opírá o nějakých 20 MB knihoven - i jen statické slinkování za takové situace hezkou chvíli trvá, nemluvě o kompilaci.
A pak - zavání to taky trochu neefektivitou - proč znovu a znovu kompilovat aplikaci jen proto, aby byla opět spuštěná ? Myslím, že zlatá střední cesta je ta, kterou realizují dnešní runtime platformy - není to ani zbytečně interpretované a dynamická jako JavaScrip či Ruby, ale ani tak statické, jako C apod. a navíc využívají on demand kompilace a CLR cache (opakovaně volaný kód se tahá z cache a nekompiluje se znovu).
Ale jinak máte pravdu - má smysl se nad základními koncepcemi zamyslet obecněji a revidovat je s ohledem na současný vývoj a dostupné kombinace a varianty.
