Vlákno názorů k článku
Douglas Crockford: JavaScript brzdí pokrok a měl by jít do důchodu od RRŠ - Možná je načase, aby se JavaScript vrátil k...

Mohl byste napsat, jaké problémy s bezpečností, spolehlivostí a nemožností izolovat aplikace jednu od druhé máte na mysli?

Ano, taby z jedné domény si vždycky můžou vyměňovat informace přes server, takže je zbytečné pokoušet se jim ve výměně informací bránit. Naopak je logické poskytnout jim tu možnost rovnou v prohlížeči, aby to bylo efektivnější. Co tam máte dál?

"Ale prosím", řeklo sluchátko:

1) První blud "JS je v prohlížeči interpretovaný" tady už vyvrátili jiní, tím se detailně zaobírat nebudu.

2) Druhý blud o "těsné integraci s prostředím prohlížeče", respektive její "škodlivosti": JS se dnes používá i na serveru zcela bez prohlížeče. Samozřejmě, pokud běží v prohlížeči, tak jsou k dispozici funkce pro integraci s ním (jak se pozná, že jsou "těsné"?). Nicméně pokud by byl jiný systém, integraci by musel mít podobnou. Aktuální mizerná nepoužitelnost WASM je i v tom, že tahle integrace tam zatím chybí.

3) Třetí blud "kdyby zůstalo u interpretování kódu - nevznikla by spousta užitečných aplikací, ale nebylo by tolik problémů s jejich bezpečností a spolehlivostí". SPA s interpretovaným kódem přímo nesouvisí, maximálně nepřímo dostupným výkonem. Že by byly webové aplikace méně spolehlivé než klasické to nevím a co se týče bezpečnosti, jsou na tom dokonce lépe. A tedy, celkově je ten způsob uvažování dost absurdní, jak už naznačil martinpoljak.

4) Čtvrtý blud "[JS] aplikace [nelze] rozumně isolovat jednu od druhé", "je to jak na Windows 3.1": Naopak, JS aplikace na různých doménách jsou od sebe izolovány velmi striktně. Windows 3.1 měly kooperativní multitasking, zatímco jednotlivé JS aplikace jsou přepínány preemptivně. I s tím vyžráním CPU a paměti jednou aplikací to není tak jednoduché a může se vám to stát i s "běžnými" aplikacemi. Ano, prohlížeče by mohly mít možnost explicitního nastavení limitů pro jednotlivé taby, ale to by stejně 99.9% uživatelů neumělo použít (*), stejně jako si 99.9% lidí nenastavuje kvóty pro jednotlivé aplikace v OS.

5) Pátý a největší blud "browsery stále chovají obdobně, jako v dobách, kdy JS jen mírně upravoval zobrazovaný obsah". Tady jste právě jednou větou popřel 25 let vývoje celé platformy :-D Těch změn byla spousta. Na začátku třeba ani neexistoval DOM. Bezpečnost se postupně zvyšovala, možnosti osekávaly, nové přidávaly...

*) Kolik procent lidí vůbec ví, že v Chrome se dá vyvolat interní task manager...?

1) stale je interpretovany, este som nevidel interpreter (akehokolvek jazyka) ktory by nepouzival bytecode. Ono aj wasm je interpeter. Kompilovany kod je priamo spustitelny na procesore pre ktory bol zkompilovany.
2) tak serverova aplikacia v javasripte tiez nie je ziadne bezpecnostne terno
3) ako sa ti vezme, nativna aplikacia moze tiez pouzivat aplikacny sever
4) to nie je ale vastnost javascriptu, ale planovaca operacneho systemu. Javascript spravidla bezi v jednom procese a pouziva envent loop, takze v ramci aplikacie mozete na peemptivny multitasking zabudnut
5) njn DOM prisiel az s javascriptom... primarne poslanie ma ten prehliadac stale to iste, zobrazovat hypertextove dokumenty

* ten sa da vyvolat aj vo firefoxe...

ad 1) Omlouvám se za zkratku s vynecháním JIT překladače.
ad 2) JS používám i na "serveru" (desktopu) v několika drobných utilitkách pro Windows, spolu s VBasicem. Tuším, že to je považováno za překonané a nedoporučované, nahrazeno PowerShellem...
ad 3) Spolehlivost u aplikací, které obecně běží jen jako smyčka a mají jen minimum možností ošetření chyb je diskutabilní. Bezpečnost je pak lépe či hůře zajišťována "zvenku" a zdaleka bych to nepovažoval za dokonalé nebo dostačující. Řízení přístupových práv pro prohlížeč v rámci firemní politiky je peklo, ve kterém vítězí ďábel.
ad 4) Netvrdím, že JS programy nemohou běžet jako samostatné tasky preemptivně, ale zařídit to musí někdo jiný, samotný JS k tomu (pokud vím) nemá žádné nástroje. Pokud jde o hospodaření se systémovými prostředky, obávám se, že ty prohlížeče jsou spíše na úrovni DOSu: co si aplikace vezme, má. TaskManager to nezachrání.
ad 5) Stále je jejich hlavním účelem interpretace HTML kódu a zobrazení stránky. Žel, vstupují do toho programy a tu stránku jim pod rukama mění. Čtvrt století probíhá boj o to, nakolik je možné a jak to udělat efektivně. (Vzpomínám na MS DHTML s předobrazem DOM...)

V modernich browserech bezi kazdy tab v oddelenem procesu. JS muze zablokovat svuj tab, nic vic.

9. 8. 2022, 01:22 editováno autorem komentáře

Off Topic: už i ve Firefoxu? (Prosím, nechci flamewar o tom, jak moc už je dnes ignorovatelný.) S tou izolovaností tam chlapci a děvčata posledně mlžili, když jsem to měla dobrou vůli nastudovat.

R. R. Šimek:

Ad 2) Vygooglete si, co je Node.js nebo Electron.

Ad 3) Jako smyčka běží každá GUI aplikace a každá serverová aplikace, vlastně každá aplikace, která běží dlouhodobě a zpracovává více úloh. Možnost ošetření chyb se smyčkou nijak nesouvisí. Spolehlivost také ne.

Netuším, co myslíte tím, že bezpečnost je zajišťována zvenku. Na desktopu (Windows, Mac, Linux) jsou webové aplikace zdaleka to nejbezpečnější, co tam běžně spouštíte. Nativní aplikace mohou volat libovolná systémová volání (dobře, na Linuxu to můžete omezit, když si s tím dáte tu práci), takže mohou např. komunikovat libovolně po síti, mohou číst a zapisovat do všech souborů, ke kterým má uživatel práva…

Řízení přístupových práv pro prohlížeč v rámci firemní politiky je možná peklo, ale zkuste si takhle řídit přístupová práva pro nějakou jinou aplikaci. Nejde to vůbec.

Ad 4) To je princip preemptivního multitaskingu, že to řídí někdo jiný. A buďte za to rád – kooperativní multitasking, kdy se proces sám musí vzdát procesoru, není žádný med.

Ad 5) Ne, hlavním účelem prohlížečů dávno je zobrazování dynamických stránek a běh webových aplikací.

Na Node.js a Electron jsem málem zapomněl... Zejména Electron mi přijde na některé věci poměrně těžkotonážní. Ale je to přesně taková mezivrstva, která běh (nejen)JS aplikací umožňuje. Když už ty webové aplikace mají v něčem běžet, slušelo by jim prostředí, oddělené od prohlížeče.
PRotože jsem přesvědčený, že prohlížeč by opravdu měl být primárně na prohlížení (dynamických) stránek, ale ta dynamika by neměla být na úkor obsahu. Protože většina použití prohlížečů je stále zobrazování obsahu.

Když už ty webové aplikace mají v něčem běžet, slušelo by jim prostředí, oddělené od prohlížeče.
Proč? Neexistuje ostrá hranice mezi webem a webovou aplikací.

PRotože jsem přesvědčený, že prohlížeč by opravdu měl být primárně na prohlížení (dynamických) stránek, ale ta dynamika by neměla být na úkor obsahu. Protože většina použití prohlížečů je stále zobrazování obsahu.
Zobrazování obsahu se ovšem nijak nevylučuje s dynamikou. V kině si také jenom „prohlížíte“ film, ale pro jeho natočení je potřeba docela dost dynamiky.

Právě ta neexistence hranice mezi webem a webovou aplikací mi vadí. Uvedu příklad: pokud přistupuji na webmail, předpokládám, že mám v prohlížeči v podstatě jen zobrazování a jednoduchou editaci e-mailů, kontrolu, zda je "na serveru" něco nového, a podobně. Nepotřebuji, aby mi tam běžel kompletní (SMTP/POP3/IMAP/­...) klient. (Na to mám Outlook, Thunderbird, atd...)
Dynamikou na úkor obsahu mám na mysli - například to školení, které tu musím vyplňovat: spočívá ve vyhledávání "na co kliknout" na obrázcích, takže hledání aktivních oblastí mi bere mnohem více pozornosti, než čtení těch zajisté důležitých textů; například program pro sdílení informací ve "znalostní bázi", který má editor příspěvků na úrovni Wordu, přičemž uživatelé nikdy nepoužili víc, než dva typy nadpisu, tučné, podtržené písmo, kurzívu a odkazy; například webové rozhraní synchronisační ("cloudové") aplikace, které se sápe po každém USB úložišti, aby mi zasynchronisovalo obrázky a jenom nadává, že k tomu USB pak nemá přístup...
Ano, jsou to příklady špatných aplikací. Ale dobře ilustrují trend, kdy je důležitější, aby to něco dělalo, než samotný obsah. A to jsem ani nechtěl vzpomenout weby, kde dynamická, animovaná a multimediální reklama zastiňuje obsah, kvůli kterému na ně zavítám. Nejen zastiňuje - taky tvoří většinu kódu.

Právě ta neexistence hranice mezi webem a webovou aplikací mi vadí.
Jenže ta hranice neexistuje z podstaty věci.

pokud přistupuji na webmail, předpokládám, že mám v prohlížeči v podstatě jen zobrazování a jednoduchou editaci e-mailů, kontrolu, zda je "na serveru" něco nového, a podobně.
Já teda ve webmailu nechci jen jednoduchou editaci e-mailů. Já tam chci plnohodnotný editor, s kontrolou pravopisu, napovídáním, plnohodnotným formátováním, vkládáním obrázků a příloh, drag-and-drop…

Nepotřebuji, aby mi tam běžel kompletní (SMTP/POP3/IMAP/­...) klient.
On ale také ve webmailu takový klient neběží a ani běžet nemůže.

Dynamikou na úkor obsahu mám na mysli - například to školení, které tu musím vyplňovat: spočívá ve vyhledávání "na co kliknout" na obrázcích, takže hledání aktivních oblastí mi bere mnohem více pozornosti, než čtení těch zajisté důležitých textů;
To je ovšem plně v rukou autora té webové aplikace. A může to být záměr, protože vyhledávání toho, na co kliknout, vás nutí se na to soustředit a zamyslet se nad tím. Pokud by vám na obrázku rovnou zvýraznili, kam kliknout, nebudete přemýšlet nad tím, kde může vzniknout požár, ale jenom budete jak cvičená opice klikat na označená místa.

například program pro sdílení informací ve "znalostní bázi", který má editor příspěvků na úrovni Wordu
To opět není problém prohlížeče, ale té aplikace. Někdo chce mít v prohlížeči i ten Word.

například webové rozhraní synchronisační ("cloudové") aplikace, které se sápe po každém USB úložišti, aby mi zasynchronisovalo obrázky a jenom nadává, že k tomu USB pak nemá přístup...
K tomu by mne fakt zajímalo víc. Protože webová aplikace v prohlížeči standardně nemá žádný přístup k souborovému systému, a pokud jí uživatel přístup dá, dává ho jenom ke konkrétní složce.

Ale dobře ilustrují trend, kdy je důležitější, aby to něco dělalo, než samotný obsah.
Což ovšem vůbec nesouvisí s JavaScriptem, dokonce ani s prohlížeči. Takové aplikace se psaly a píšou ve všech jazycích. Vzpomínám na dobu, kdy „nejdůležitější“ funkcí hudebního přehrávače na desktopu bylo to, jak je skinovatelný. Ty přehrávače byly psané v C++, některé možná v Delphi.

A to jsem ani nechtěl vzpomenout weby, kde dynamická, animovaná a multimediální reklama zastiňuje obsah, kvůli kterému na ně zavítám. Nejen zastiňuje - taky tvoří většinu kódu.
Ve skutečnosti ta reklama nemá žádný JS kód.

> JS používám i na "serveru" (desktopu) v několika drobných utilitkách pro Windows, spolu s VBasicem. Tuším, že to je považováno za překonané a nedoporučované, nahrazeno PowerShellem...

Koukám, že vy máte tak velké neznalosti problematiky, že vůbec ani netušíte nic o server-side renderingu, serverovém JS atp... Serverem nemíním nějaké "drobné utility", ale server co se spustí, poslouchá na portu a vyřizuje requesty.

> Spolehlivost u aplikací, které obecně běží jen jako smyčka a mají jen minimum možností ošetření chyb je diskutabilní.

A víte, že normální windows UI aplikace také běží jako smyčka? S bezpečností to, mimochodem, nemá nic společného.

> Řízení přístupových práv pro prohlížeč v rámci firemní politiky je peklo, ve kterém vítězí ďábel.

Ano, řídit práva / kvóty odděleně pro jednotlivé taby prohlížeče je současnými systémovými prostředky problematické, v tom souhlasím. Akorát nevím, jak to souvisí s tím, zda aplikace je nebo není bytekód. Tady by mohl prohlížeč implementovat nějaké (explicitní) kvóty, ale poptávka po tom je evidentně malá.

> Netvrdím, že JS programy nemohou běžet jako samostatné tasky preemptivně, ale zařídit to musí někdo jiný, samotný JS k tomu (pokud vím) nemá žádné nástroje.

Vzhledem k tomu, "kde" v ekosystému JS je, tak to dává smysl a nevidím v tom problém. I samotný JS může spouštět nová vlákna, viz WebWorkers.

> že ty prohlížeče jsou spíše na úrovni DOSu: co si aplikace vezme, má. TaskManager to nezachrání.

To rozhodně ne, v DOSu nebyl žádný multitasking, ochrana paměti, nic.

> Stále je jejich hlavním účelem interpretace HTML kódu a zobrazení stránky. Čtvrt století probíhá boj o to, nakolik je možné a jak to udělat efektivně.

Ten boj, který zmiňujete, byl dobojován plus minus někdy před dvaceti lety. Ano, prohlížeč zobrazuje stránku. Je to prostě jiná reprezentace UI. Windows také zobrazuje nějak definované UI a aplikace jej mění, úplně stejný princip. V čem je problém?

Na opravdu serverové aplikace mi přijde JavaScript jako poměrně málo vhodný jazyk. Řekl bych, že na to existují efektivnější řešení.
S tou smyčkou jsem to napsal málo pochopitelně, tedy opravuji: běží jako smyčka a zároveň mají jen minimum možností ošetření chyb. Nesouviselo to tolik s bezpečností, ale spolehlivostí. Takovou aplikaci (bez ohledu zda v JS či něčem jiném) pak máte možnost v případě poruchy jedině zabít - a je otázkou, zda zavření záložky v prohlížeči bude možné a pomůže.
Aplikace v rámci jedné záložky mají IMHO opravdu blíž k onomu DOSovskému chování. Dnešní prohlížeče už mají celkem slušný sandboxing, ale stále se mi stávají situace, kdy pád jedné záložky shodí celý prohlížeč, případně zatuhne celé prostředí desktopu.

Na opravdu serverové aplikace mi přijde JavaScript jako poměrně málo vhodný jazyk. Řekl bych, že na to existují efektivnější řešení.
Souhlasím, ale to neznamená, že by to v JS nešlo ani že by to v JS bylo nějak extrémně nevhodné.

Nesouviselo to tolik s bezpečností, ale spolehlivostí.
Většina aplikací běží jako smyčka, spolehlivost s tím nijak nesouvisí. Nevím, jaké jazyky mají podle vás mnohem více možností ošetření chyb, než JavaScript, aby byly spolehlivější.

Takovou aplikaci (bez ohledu zda v JS či něčem jiném) pak máte možnost v případě poruchy jedině zabít - a je otázkou, zda zavření záložky v prohlížeči bude možné a pomůže.
Pokud se s takovými poruchami na webu setkáváte, je to problém vaší instalace. Nevím, kdy jsem se naposledy na webu setkal se stránkou, kterou bych musel zabít. Spoustu věcí hlídá přímo prohlížeč (díky interpretovanému jazyku je to relativně snadné), reálně můžete nějaký problém způsobit vlastně jen nekonečným (nebo dlouhým) cyklem, který nic zajímavého nedělá. A nekonečný cyklus můžete vyrobit v libovolném jazyce.

Aplikace v rámci jedné záložky mají IMHO opravdu blíž k onomu DOSovskému chování.
Ano, protože v rámci jedné záložky běží jenom jedna aplikace. Ale netuším, co je na tom podle vás špatně.

Dnešní prohlížeče už mají celkem slušný sandboxing, ale stále se mi stávají situace, kdy pád jedné záložky shodí celý prohlížeč, případně zatuhne celé prostředí desktopu.
To vůbec nesouvisí s žádným sandboxingem. Pokud vám spadne celý prohlížeč, nezpůsobil to pád jedné záložky, ale naopak toho hlavního procesu/procesů, kde není žádný web, ale jen řízení procesů a GUI prohlížeče. Když zatuhne celé prostředí desktopu, je to jeho chyba – to se nemá nechat zlikvidovat žádnou aplikací v něm běžící, stejně jako se OS nemá nechat zlikvidovat žádným procesem v něm běžícím, a stejně jako se nemá webový prohlížeč nechat likvidovat žádnou webovou stránkou.

Píšete naprosté nesmysly, je to přesně naopak. Když si spustím desktopovou aplikaci, tak má by default (*) přístup ke kameře, mikrofonu, lokálnímu filesystému atp. Když si pustím webovou aplikaci, tak jí přístup ke kameře a telefonu musím explicitně povolit a s FS je to ještě složitější.

*) Asi to jde nějak nastavit někde hluboko v systémových politikách, ale o tom nevím nic ani já, natož nějaký BFU.

No, on ten BFU je na "B. F." Windows přímo vhozen na nastavení přístupu ke kameře a mikrofonu podle aplikací, skoro kdykoliv potřebuje nastavit něco jiného kolem těch periferií. ;oD
Nicméně: pokud povolím prohlížeči přístup k těmto zařízením (z pohledu administrátora), už nemám moc možností zabránit, aby to některé stránce (aplikaci v prohlížeči) povolil uživatel. (Poznámka: já vím, že to ve skutečnosti jde, nicméně princip je ten, že o povolení pro aplikace rozhoduje ten, kdo spravuje počítač, o povolení pro stránky ten, kdo prohlíží.)

pokud povolím prohlížeči přístup k těmto zařízením (z pohledu administrátora), už nemám moc možností zabránit, aby to některé stránce (aplikaci v prohlížeči) povolil uživatel.

Coz neni pravda. Chrom na to ma rozhrani, ale bohuzel jsem nikde v rychlosti nenasel nastroj treti strany ktery by to umel nastavit. Nicmene pokud si firma zaplati Google Workspace (konkurence Office365 od MS), tak ma i spravu zarizeni. A stejne jako uzivatel si muze v prohlizeci povolit pro ruzne domeny, pristup k HW(zejmena kamera a mikrofon) muze administrator udelat presne tato nastaveni a zablokovat uzivateli moznost toto menit. Jinymi slovy pokud povolim jako sysadmin prohlizeci pristup ke kamere a mikrofonu pres MS Group policies(netusim zda je to mozne, ale z dizkuse jsem pochopil ze asi jde), tak mohu jako administrator G Workspace zakazat kameru a mikrofon pro vsechny weby krome Google Meet dejme tomu. Mimochodem androidi Chrome si toto krasne prebere automaticky sam - pokud je telefon logicky ve sprave domeny.

Dokonce je to neni cernobile a neni moznost jen povolit a zakazat, ale i nechat rozhodnout uzivatele jestli chce napr. blokovat cookies 3. stran apod.

Zde je screen primo z nasi administrace a fakt to zadne peklo neni :)
https://drive.google.com/file/d/1YBqzVRlXpXZekXLa7llocKF3fm0GNHev/view?usp=sharing

Jenže v prohlížečích dnes běží poměrně komplexní aplikace a bylo by vhodné, aby ten přístup k RAM, USB, apod. byl nějak rozumně řízený.
Stále nechápete, že přístup k RAM nebo USB si nemůže řídit aplikace sama, ale ty zdroje jí přiděluje operační systém.

Žel, prohlížeče jdou spíše cestou přidávání API pro přístup ke kdejaké komponentě, než aby ty přístupy byly nějak rozumně řiditelné.
Je to přesně opačně, než píšete. V prohlížeči ty přístupy jsou rozumně řiditelné, mimo prohlížeč to (na desktopu) není řízené nijak a aplikace má přístup ke všemu, k čemu má přístup uživatel.

Pokud má být prohlížeč běhovým prostředím pro aplikace (což IMHO asi nemá být...), měl by tak být i koncipovaný.
Proč by neměl být? A jak jinak by měl být koncipovaný, než že uživatel bude přidělovat oprávnění k zajímavým zdrojům?

Ale situace, kdy si Chrome sebere 1 CPU jen pro vlastní běh, dvě další jádra pro zobrazování poměrně jednoduché stránky, na které běží 5 reklamních videí ze tří domén
Chrome si žádné CPU nesebere. Na Windows, Linuxu i Macu máte preemptivní multitasking, takže CPU přiděluje OS.

jedna komunikační aplikace s přístupem k mikrofonu, webové kameře a (sic!) nastavení hlasitosti v systému
Každý ten přístup můžete v prohlížeči ovládat. Porovnejte to s jakoukoli nativní aplikací, která má přístup k těmto třem službám také, zakázat jí to nijak nemůžete – a vedle toho má přístup i ke všemu ostatnímu, k čemu má přístup uživatel.

postupně užírající RAM, odpovídá spíše tomu, že jde o OS v OSu.
Postupně užírat RAM může kterákoli aplikace, ne jen webový prohlížeč.