Kdy přesuneme aplikace do prohlížečů?

Celá řada webových aplikací, kancelářskými počínaje a některými utilitami konče, by mohla fungovat lokálně, tedy běžet plně v prohlížeči, protože server teoreticky nepotřebují. Ve skutečnosti jej potřebují, a ještě nějaký čas potřebovat budou. Co přesně brání přesunu aplikací do webových prohlížečů?

Aplikace běžící v prohlížeči jsou v HTML5/CSS3 a JavaScriptu krásným snem. Jejich většímu rozšíření stojí v cestě celá řada problémů. Především vyšší náklady na vytvoření kvalitního UI, protože webové technologie až donedávna nebyly navrhovány pro aplikace. Technologie je ve specifikacích HTM5 téměř připravená, ale stále chybí několik věcí, spíš technicko-organizačních, bez nichž si lze představit intenzivnější vývoj aplikací pro prohlížeče jen stěží. Pojďme si probrat některé z těch nejzávažnějších, které brání zásadnímu posunu, tj. přesunu větší části logiky ze serveru do prohlížeče.

Přesun logiky mezi serverem a klientem je přírodní cyklus, který zachvacuje celý obor IT už od počátků. Střídání módy tlustých a tenkých klientů, vzývání jedné z těchto technologií a nesmiřitelný boj se zpátečníky, tj. s těmi, co stále ještě lpí na té druhé, patří k IT už neodmyslitelně. V posledních letech se zdálo, že bude rozumné vše přesunout na servery – síťová infrastruktura posilovala, přenosové rychlosti rostly a serverový čas a prostor skoro nic nestojí. Zlom přišel s mobilními zařízeními, které jsou navržené jako „webové“, ovšem musí se nějak popasovat s paradoxním faktem, že pro ně není připojení dostupné neustále. Jako jedny z prvních proto implementovaly appcache a podobné technologie a vypadá to, že se opět blíží doba zvýšené popularity aplikací, co poběží na klientské straně (tentokrát ale v prohlížeči) a server použijí jen na vzájemnou komunikaci či pro ukládání dat. Tvrzení „prohlížeč je operačním systémem zítřka“, které je leitmotivem Chrome OS, je dnes možná radikální, ale pravděpodobně se stane realitou.

Můžeme proti tomu protestovat, můžeme s tím nesouhlasit, nemusí se nám to líbit a můžeme být stokrát přesvědčení, že to je takto špatně, že by vývoj měl jít jinudy. Historie nás ale učí, že se to nestane, že vývoj půjde tou cestou, která je špatná, nepohodlná, nepraktická, ale jde po ní většina.

Kudy půjde vývoj podobných aplikací?

Zkusme si vyjmenovat největší technické překážky, které – z dnešního pohledu – na té cestě leží.

1. Otevřený JavaScript

JavaScript, který je motorem celé klientské části webové aplikace (resp. kompletní aplikací u prohlížečových aplikací), se posílá jako otevřený text. Kdokoli se do něho může kdykoli podívat a zjistit si o vašem programu vše. Čím víc bude funkcí v JavaScriptu, tím víc jich bude „veřejných“. Pokud chceme něco (know-how?) před cizími zraky skrýt, musí to být na serveru, byť i s otevřeným API. Obfuskace je jen částečné řešení.

Druhým faktorem je, že otevřený kód, který bude umět „všechno“, vám může velmi snadno někdo odcizit a provozovat na svém serveru. Dokonce i bez znalosti jeho fungování – teoreticky mu stačí použít „Uložit stránku jako kompletní HTML…“ a použít vaše API.

Chybí tedy třeba binární JavaScript? Nikoli, nechybí. Tedy minimálně ne z důvodu uzavření kódu. Převedení do binární podoby není v tomto případě nic jiného než forma obfuskace. Ztíží jeho dešifrování a posune laťku nutných znalostí o kousek výš, ale neuzavře kód.

Pomohla by nějaká metoda „podepsaného šifrovaného JavaScriptu“, jakési obálky, v níž by byl JS uložen a který by zajistil, že prohlížeč ověří původ a integritu skriptu před tím, než jej spustí, a zároveň zabrání zobrazení nebo uložení kódu? Pravděpodobně ne – vytvoření patche pro prohlížeč, který by tuto kontrolu obešel, by byla otázka hodin.

Platí, že v případě jakéhokoli programu (u interpretovaných jazyků v mnohem větší míře, u kompilovaných s obtížemi, ale také) může ten, na jehož stroji je kód vykonáván, s menší či větší námahou získat ekvivalentní zdrojový kód. Podle licenčních ujednání to většinou dělat nesmí.

Spoléhat na to, že lidé něco dělat nebudou proto, že nesmí, i když mohou, je neefektivní, a založit obchodní model jen na tom je pošetilé (a potřebuje velké výdaje na represivní nástroje). Jediná možnost, jak mohou webové aplikace přenést těžiště na klienty (prohlížeče), je změnit obchodní model tak, aby nebyl založen na tom, že nikdo nevidí zdrojový kód. Tedy defacto open source model.

Při známé setrvačnosti velkých společností je pravděpodobnější, že dřív vzniknou otevřená Windows 11 a prohlížeči budeme říkat WebKit, než že by velké IT společnosti změnily zaběhaný obchodní model „prodám škatuli za peníze“ – stále nižší výnosnost tohoto modelu pravděpodobně u mnohých nepovede k úvahám nad změnou modelu, ale k pokusům o posílení represí a restrikcí vůči všemu, co jej narušuje. Bude to stát stále víc peněz a mít stále menší účinnost, jako každá represe.

Dokud nedojde u alespoň několika významných hráčů ke změně pohledu na obchodní model, bude „otevřený JavaScript“ něčím, přes co vlak nejede, a pravděpodobně i největší překážkou pro vytváření aplikací běžících převážně v prohlížeči. Po změně obchodního modelu tento problém zmizí sám.

2. Autentizační systém

Je pěkné, že uživatel má ve svém prohlížeči editor textů, který je schopen offline práce, že si může texty ukládat na disk a otvírat je z něho, ale na to nepotřebuje aplikaci založenou na webových technologiích, na to sežene desítky, či spíš stovky desktopových aplikací, které totéž udělají bez prohlížeče. Ne, to není dobrý argument pro webové aplikace. Webová aplikace je zajímavá tehdy, když nabídne něco, co desktopová nabídnout nemůže – nejčastěji plně transparentní synchronizaci dat (ukládání v cloudu) či realtime kooperativní přístup k dokumentům.

Výše uvedené funkce a fíčury, co mohou nabídnout webové aplikace, mají společného jmenovatele: Jejich funkčnost závisí na tom, jestli lze jednoznačně ověřit přihlášeného uživatele. Zde je v současnosti další kámen úrazu, protože neexistuje bezpečná a standardizovaná metoda pro ověření uživatele, která by fungovala čistě v prohlížeči / JS.

Navíc technika pro autentizaci požadavků na serverová API, totiž OAuth, která je mainstreamem tolik milována, není s JavaScriptem či s jinými čistě prohlížečovými řešeními příliš použitelná. Současná řešení proto provozují autentizaci na straně serveru, a klient v prohlížeči má k dispozici API proxy. Čímž je problém vyřešen – ve skutečnosti pouze přibylo další místo, které je možné napadnout, problém „implementace OAuth“ se přesunul z klienta na server, a na klientské straně byl nahrazen novým: Jak se autentizovat vůči serverovému API tunelu?

Ideální autentizační metodou by byla taková, při níž by nikam neputovaly uživatelovy přihlašovací údaje, ty by zůstaly „uzamčené“ v prohlížeči, a požadavky na API různých služeb (třeba „cloud storage“) by byly podepsány a ověřeny jiným způsobem než „pošli heslo“.

Ve skutečnosti taková univerzální a standardizovaná metoda existuje, je jí HTTP Digest Authentication. Problémem je její silně nesympatická implementace, jejíž UI jako by vypadlo z poloviny 90. let, a obtížný způsob, jak rozumně skriptem obsloužit takové požadavky. Ostatně si zkuste sami zachytit HTTP status 401 při volání XHR a zabránit prohlížeči ve vyvolání onoho hnusného dialogového boxu (třeba proto, že máte heslo a jméno uložené jinde).

3. Lokální ukládání souborů

Představme si, že přesuneme většinu naší aplikace na klientskou stranu; do prohlížeče. Skript v prohlížeči bude obsluhovat UI, bude vykonávat další akce (Web Workers!), bude se starat o ukládání dat v lokálním úložišti, popřípadě se synchronizací s cloudem – to je všechno proveditelné už dnes. Ale jak uložit text (nebo obecně obsah), který vznikl v klientu a který je držen kdesi v JavaScriptové proměnné, na lokální disk? Nějak jako

var data = "Ahoj světe";
File.saveLocal (data, 'text/plain'); //nehledejte, neexistuje

Proč ukládat na lokální disk, když „vše“ bude v cloudu? Třeba k tomu, abyste mohli výsledek své práce jako prezentaci vzít na IT konferenci, kde – jak známo – internetové připojení vždy spadne.

Metoda, která by dovolila JavaScriptu přímo ukládat soubory, neexistuje, a to z pochopitelných a dobrých důvodů. Metoda, která by dovolila JavaScriptu vyvolat dialogové okno Save file as... a předat mu data k uložení, neexistuje rovněž. Nové File API nabízí několik možností, jak pohodlně data z lokálního disku číst, ale zápis neumožňuje nikdo. Funguje možnost „podstrčení“ data URI do document.location.href, kde za určitých příznivých okolností (tj. neznámý MIME typ) některé prohlížeče otevřou ukládací dialog a data uloží – pod naprosto obskurním jménem, jako třeba „PWctFwtFFz.part

Pro takové účely nezbývá než použít flashový workaround (Downloadify), který vám bude např. v iOS nanic, nebo cimrmanovský „úkrok stranou“, při němž pomocí XHR pošleme data na server, a ten nám je vrátí s hlavičkou „ Content-Disposition: attachment“. Což potěší lidi co platí za přenesená data, lidi s omezeným nebo žádným přístupem k internetu („application cache? Che che!“) a lidi, co mají zapnutou featuru „man-in-the-middle“. (A nešlo by dát content disposition do data URI? Můžete si zkusit…)

Závěr

Nic z výše uvedeného není smrtící problém, kvůli němuž by nebylo možné vytvářet aplikace běžící v prohlížeči. Vše lze obejít, nejsnáze tím, že přesuneme menší či větší část logiky na server. Ovšem pokud se rozšíří přenosná zařízení s OS postaveným právě na prohlížeči (Chrome OS), stanou se situace, kdy nebude server dostupný, statisticky významnými. Navíc se tím zbavujeme možností hostovat aplikace velmi levně v CDN / cloudech nebo např. v databázích a la CouchDB (existují webové aplikace, které mají uložené HTML/JS/CSS právě jako dokumenty v této DB, celé fungují u klienta a používají REST API ke komunikaci s databází).

Výše uvedené technické problémy nejsou zdaleka jediné, ale představují pravděpodobně největší technické překážky pro masivnější přesun aplikací do prohlížečů. Napadají vás další? Důležitější, zásadnější? Podělte se v diskusi…

Jaká je hlavní současná překážka přesunu aplikace do prohlížeče?

Ilustrace: Open Clip Art

Začal programovat v roce 1984 s programovatelnou kalkulačkou. Pokračoval k BASICu, assembleru Z80, Forthu, Pascalu, Céčku, dalším assemblerům, před časem v PHP a teď by rád neprogramoval a radši se věnoval starým počítačům.

Komentáře: 33

Přehled komentářů

oj pár poznámek
rooobertek Re: pár poznámek
oj periférie
oj Re: periférie
pas Re: periférie
Jitka Dařbujanová Díky z nadhled
asitakhle No...
X Ale no tak...
pas Re: Ale no tak...
richard Re: Ale no tak...
pas Re: Ale no tak...
michal Re: Kdy přesuneme aplikace do prohlížečů?
sycho Re: Kdy přesuneme aplikace do prohlížečů?
100% Lenin Re: Kdy přesuneme aplikace do prohlížečů?
pas Re: Kdy přesuneme aplikace do prohlížečů?
kbl virtualna platforma
srigi_nl Re: virtualna platforma
srigi_nl Re: virtualna platforma
kbl Re: virtualna platforma
Ron Data na webu, v cloudu, na serveru.... aplikace lokálně?
srigi_nl Re: Data na webu, v cloudu, na serveru.... aplikace lokálně?
František Kučera Re: Data na webu, v cloudu, na serveru.... aplikace lokálně?
X Re: Data na webu, v cloudu, na serveru.... aplikace lokálně?
Pavel Kysilka kdo to zaplati
Jakub Spíše tu jde o pojmenování
Josef Richter tahle otázka nemá správnou odpověď
bauglir Re: tahle otázka nemá správnou odpověď
MyOwnClone Google Gears
bauglir Hm....
František Kučera Re: Hm....
pas Re: Hm....
bauglir Re: Hm....
bauglir Re: Hm....
Zdroj: https://www.zdrojak.cz/?p=3372