Vlákno názorů k článku Webové aplikace podle WHATWG od Ritchie - Z krátkodobého pohledu představují WebApplication pravděpodobně přínos, z...

Z krátkodobého pohledu představují WebApplication pravděpodobně přínos, z dlouhodobého napáchají víc škody, než užitku, stejně jako tomu bylo u čtyřkových verzí dvou tehdy oblíbených prohlížečů. Návrh WebApplications mně přesně připomíná toto období, neboť se v něm nekoncepčně vedle sebe objevuje markup, DOM, ne-DOM, objekty prohlížeče, atd.

Více než dříve se ukazuje, že spoustu aplikací má podobné požadavky na technologie. W3C se snaží psát svá doporučení tak, aby vyhovovala co největšímu počtu těchto aplikací. Všimněte si, kolik doporučení převzal ODF, i když nebyla vytvářeny přímo pro něj. Možná je chybou, že některá z doporučení W3C nejsou modulární, takže mohou být implementovány buď plně, nebo vůbec, i když pro některé účely je jejich plná implementace zbytečná. Správným řešení však není vytvoření nové technologie, ale modularizace stávající.

Nechci znovu zažít válku, teď už ne webových prohlížečů mezi sebou, ale mezi webovými prohlížeči a ostatními aplikacemi. Možná to většině uživatelů a programátorů tak nepřijde a považují textový procesor a webový prohlížeč za zcela oddělené aplikace, které spolu nemají nic společného. Já však používám KDE, které obsahuje technologii KParts, takže pro prohlížeč nepředstavuje problém vykreslil vstupní prvek s funkcionalitou textového procesoru. Prostě si jej od textového procesoru "vypůjčí". Pro úspěšnou spolupráci různých "části" je zásadní, aby byly postaveny na nejlépe stejných technologiích.

Pro programátora je rovněž příjemnější, pokud může stejnou technologii použít na straně web serveru, ve webovém prohlížeči či při psaní maker do textového procesoru.

Myslím si, že technologie jako KParts představují budoucnost desktopu. Považuji proto za krátkozraké, když si každá aplikace definuje své vlastní technologie s ničím nekompatibilní. To je případ i WebApplications, které za hranice současných prohlížečů nedohlédnou. Důsledkem toho bude zpomalení rozvoje desktopu jako celku, až nakonec budou WebApplications zavrhnuty a nahrazeny novou technologií. Proč to tedy rovnou neudělat pořádně?

Jednoduse proto, ze neexistuje sjednocujici technologie typu KParts v ruznych OS. A domluva na vytvoreni takoveto technologie by byla jeste horsi nez domluva na html standardu. Prohlizece jsou proste takove sandboxy a je to i rozumne z hlediska bezpecnosti a prenositelnosti.

To jste mě ne zcela pochopil. Není nutné, aby různá desktopová prostředí v různých OS měla stejnou či navzájem kompatibilní technologii typu KParts, i když by to bylo samozřejmě lepší. Důležité je, aby dokumenty obalené pomocí KParts (či podobné technologie) měly stejné rozhraní, jak komunikovat s rodičovským dokumentem.

Nevím, co si mám představit pod tím, že prohlížeče jsou sandboxy, můžete mně to prosím trochu rozvést? Každopádně přenositelnost prohlížeče není kvůli KParts (či podobné technologii) nikterak ohrožena. Stejně jako má Mozilla knihovnu Necko, která obaluje síťové záležitosti, tak může mít podobnou knihovnu, která bude obalovat KParts záležitosti. Nevyužívat možnosti OS/DE a vše si vytvářet znovu a po svém, považuji za zbytečné plýtvání sil programátorů.

Vám nevadí, že se prohlížeče často chovají z pohledu uživatelského rozhraní jinak, než zbytek desktopového prostředí? Mně velmi.

Pokusím se načrtnout nějaké (ideální) příklady, snad má vize bude jasnější:

Komponenta obsahuje ODT dokument s odkazy, které potřebuji dále zpracovat v rodičovském dokumentu. ODT implementuje odkazy standardním způsobem přes xlink, takže mohu použít skript předpokládající xlink na odkazy. Jiná komponenta obsahuje SVG obrázek. I SVG implementuje odkazy pomocí xlink, takže opět mohu použít ten samý skript. Vlastně ani nemusím přesně vědět, co se v dané komponentě ukrývá, pouze mně stačí vědět, že odkazy se vždy implementují jako xlink. Je zde vidět, že technologie xlink je navržena tak, že vyhovuje různým aplikacím.

Mám ODT dokument s formulářovými daty, která potřebuji předat webové aplikaci. Zkopíruji část ODT dokumentu s formulářovými do komponenty, což automaticky předvyplní relevantní XForms políčka na webové stránce. Celé je to jednoduše možné proto, že jak webová stránka, tak ODT používají XForms pro práci s formuláři. XForms představují další široce využitelnou technologii.

Jak jsem již psal, WHATWG nedohlédne za hranice současných prohlížečů. Vymýšlení si vlastních doporučení nekompatibilních s doporučeními používaných v ostatních aplikacích povede k další válce prohlížečů, tentokrát však proti ostatním aplikacím.