Názory k článku
Douglas Crockford: JavaScript brzdí pokrok a měl by jít do důchodu

...: Jak je vidět, to, že vás web živí, neznamená, že těm technologiím rozumíte.

Bezpečnost moc nesouvisí s použitým jazykem. Respektive pokud by se web psal třeba v C a hrozily tam chyby typu buffer overflow, byla by bezpečnost snížená programovacím jazykem. Ale JavaScript má automatickou správu paměti, takže tento typ chyb nehrozí, stejně jako nehrozí jiné typy bezpečnostních chyb dané programovacím jazykem. Zkrátka z pohledu bezpečnosti je na tom JavaScript stejně dobře, jako desítky dalších jazyků.

Za „náročností na HW prostředky“ je podle mne DOM a ne JavaScript. Ale když to porovnáte s jinými přístupy, nejsou na tom webové aplikace nijak zle. Multiplatformní aplikace napsané v Javě nebo s Qt na tom budou co se týče zdrojů podobně.

JavaScript je jednovláknový, což ale například dává velké možnosti interpretu/JIT, takže to nemusí být na škodu. Nepodpora asymetrických CPU jader nebo úsporných režimů je blábol – když už si něco vymýšlíte, zkuste se alespoň zamyslet nad tím, zda by to alespoň teoreticky mohla být pravda (plánování procesů na CPU a řízení spotřeby dělá OS, programovací jazyk je od toho kilometry daleko). Izolace procesů opět není věcí programovacího jazyka – proces je objekt operačního systému, procesy od sebe musí izolovat operační systém, nemůžete to nechat na procesech samotných.

Nevím, co myslíte „prostorem pro bezpečnou implementaci šifrovacích algoritmů“. Šifrovací algoritmy můžete bezpečně implementovat i v JavaScriptu. Pokud vám jde o to, abyste měl třeba lépe chráněné klíče v paměti, to je věc běhového prostředí a ne programovacího jazyka – a kdyby někdo chtěl, může takové běhové prostředí implementovat i pro JavaScript.

Zpřístupňování různých služeb skrze API webového prohlížeče nedělá jen Chrome, dělají to všechny prohlížeče. Nijak to nesouvisí s JavaScriptem – ten můžete používat i mimo prohlížeč a opačně, ta webová API nejsou principiálně vázána na JavaScript, akorát je shodou okolností v tuto chvíli JavaScriptový engine v prohlížečích jediný, kdo k nim má přístup. Ale v budoucnu budou přístupná i pro WebAssembly.

Navíc to, že jsou tyhle služby zpřístupňovány skrze omezené API chráněné oprávněním, je v pořádku. Porovnejte si to s tím, jak se to dělá mimo prohlížeč – prostě ty služby může volat každá aplikace, neomezeně, nepotřebuje k tomu od uživatele žádné oprávnění.

Nikdo neměl v plánu udělat z JavaScriptu univerzální jazyk pro vývoj. Ale byl to jediný jazyk dostupný v prohlížečích, tak ho prostě vývojáři používali, jak jen to šlo. Teprve v závěsu za tím šel vývoj jazyka a webových prohlížečů, které jen reagovali na to, co se v praxi používalo. Podle vás se asi měl vyvinout zcela nový jazyk pro prohlížeče a vše ostatní se do té doby mělo zastavit. Jenže ten nový jazyk se vyvíjí – WebAssembly. A podívejte se, jak dlouho to trvá. To se podle vás měl webový vývoj na deset nebo patnáct let zastavit? On by se nezastavil, jenom by šel jinou cestou – třeba Flashe nebo Silverlight.

Bezpečnost moc nesouvisí s použitým jazykem

K tomu nemám komentář. Vždyť to i sám hned v tom odstavci popíráš.

Kdyby za tím byl jen DOM, problém by vyřešily nástroje jako react nebo vue, ne? Neřeší to. JS nenabízí efektivní cesty a vede k spamování event loopy (např. způsob zpracování promise nebo timerů). Jen režije timerů je třeba u webových aplikací i desítky % (tab throttling toho je důkazem). JS nenabízí lepší možnosti. Však si zkus vzít profiler na JS kód v prohlížeči a uvidíš.

Ano, jednovláknový, to nedává OS moc možnosti, jak jeho práci správně plánovat a rozložit, vede to k protěžování jednoho CPU jádra a zvedání jeho frekvence, místo aby se práce rozložila přes více. Výrobci HW a prohlížečů musejí dělat ohejbáky, aby to fungovalo lépe.

JS nechrání proti útokům jako code injection nebo side-channel attacks. Nelze zabezpečit vstupy od uživatele a zabránit, aby citlivé údaje unikly (to se týká i node.js). Web crypto api od W3C problém neřeší, je to pouze částečná záplata.

Nikdo neměl v plánu udělat z JavaScriptu univerzální jazyk pro vývoj
Na to odpovíám citací ze standardu:
This Standard defines the ECMAScript 2021 general-purpose programming language.

Ano, wasm měl vzniknout daleko dříve, aktivita se začala už s ES4, pak dlouho nic a až herní průmysl (a lidi kolem webgl v mozille) to začal více tlačit, nebýt třeba Alona Zakai, asi by to ještě dlouho nikam nevedlo.

> ...: Ano, jednovláknový, to nedává OS moc možnosti, jak jeho práci správně plánovat a rozložit, vede to k protěžování jednoho CPU jádra a zvedání jeho frekvence, místo aby se práce rozložila přes více. Výrobci HW a prohlížečů musejí dělat ohejbáky, aby to fungovalo lépe.

To samé můžeš říct i o C/C++ ;-) Taky je jednovláknové a musíš používat speciální funkce pro vytvoření a práci s dalšími vlákny*. A protože je to pro méně zkušené programátory komplikované, tak spousta GUI aplikací vytěžuje jedno jádro CPU na max a "zamrzá". Ano, jsou knihovny, které některé operace umí rozložit na více vláken automaticky, ale takové nadstavby jsou i pro ten JS (knihovny pro usnadnění využívání více jader).

Jinak pro OS je naopak mnohem jednodušší plánovat jednovláknové aplikace. Naopak taková Electron aplikace na 20 vláken, co se rozleze na všechna jádra, to je peklo.

EDIT: *) I v C/C++ je spousta knihoven, včetně GUI a grafických, bez plné podpory multithreadingu. Takže na tom nejseš o nic líp než v JS, kde WebWorker dělá jen početní práci, ale nemůže např. přímo "kreslit do okna".

9. 8. 2022, 13:36 editováno autorem komentáře

K tomu nemám komentář. Vždyť to i sám hned v tom odstavci popíráš.
Nepopírám. V následujícím odstavci jsem napsal, že bezpečnost může ohrozit třeba chybějící automatická správa paměti. Což ale není věc přímo programovacího jazyka – i v C můžete používat automatickou správu paměti, když použijete nějakou knihovnu.

Kdyby za tím byl jen DOM, problém by vyřešily nástroje jako react nebo vue, ne?
Proč píšete o něčem, o čem vůbec nic nevíte? React nebo Vue samozřejmě také používají DOM.

JS nenabízí efektivní cesty a vede k spamování event loopy (např. způsob zpracování promise nebo timerů). Jen režije timerů je třeba u webových aplikací i desítky % (tab throttling toho je důkazem).
Což ovšem není problém JS, nýbrž nějakého „programátora“, který nějaké vizuální efekty programuje pomocí JavaScriptu, místo toho, aby použil CSS.

Ano, jednovláknový, to nedává OS moc možnosti, jak jeho práci správně plánovat a rozložit, vede to k protěžování jednoho CPU jádra a zvedání jeho frekvence, místo aby se práce rozložila přes více.
Naopak to, že je jednovláknový a interpretovaný, dává možnosti interpretu to optimalizovat. Jinak z hlediska spotřeby je samozřejmě lepší, když běží jedno CPU s vyšší spotřebou než dvě CPU s jednotkovou nižší spotřebou, ale v součtu vyšší spotřebou.

JS nechrání proti útokům jako code injection nebo side-channel attacks.
To žádný jazyk.

Nelze zabezpečit vstupy od uživatele a zabránit, aby citlivé údaje unikly
Lze. if existuje i v JavaScriptu.

Web crypto api od W3C problém neřeší, je to pouze částečná záplata.
Web crypto API slouží k něčemu úplně jinému.

Zhruba rámcově souhlasím, protože u hodně věcí je správná odpověď "it depends". U CSS vs JavaScript nesouhlasím. Je řada věcí, které čistě v CSS udělat nejde vůbec nebo to bude tak složité, že to bude nepraktické. Dost pravděpodobně to bude mít grafické glitche/ nebude to rychlé. Někdy je to naopak, ale opravdu CSS není obecně uplatnitelný nástroj na vizuální efekty.

Děláme jeden takový "drobný" projekt, který odhaluje různé nešvary/ limity "webových" API.

Adam Kalisz: To je pak zase na domluvě s designery, zda tam opravdu musí být takový efekt, který nejde udělat pomocí CSS. Protože to často vznikne jenom tím, že takový efekt designer snadno vyrobí ve svém nástroji, ale v CSS jde udělat jiný, velmi podobný efekt – a designerovi je vlastně jedno, který se použije. (Tohle už naštěstí přestává být problém s Figmou, která je zaměřená primárně na web.)

Samozřejmě že někdy narazíte na limity a někdy má ten efekt smysl a musí se naprogramovat v JavaScriptu. Ale asi ne přes timery, že.

"... pamatuješ na tanečky kolem ECMAScript 4? Tenhle okamžik je hodně důležitý, ovlivnilo to jak dnes JS vypadá a proč dnes JS je špatný jazyk."

Samozřejmě. A já osobně zcela souhlasím (a říkám to už léta) s tím, že snahou namontovat do JS něco, co tam původně nebylo ten jazyk zprasili velice solidně. To se naprosto nevylučuje. Bohužel.

JS v současné době je neskutečná bariéra pro to, aby weby mohly být výrazně bezpečnější.

A čím tu bariéru konkrétně tvoří?

Stejně tak JS stojí za tím, že současné weby jsou neskutečně náročné na HW prostředky.

Většinu výkonu sežere renderování, nikoliv běh skriptů. Je naprosto jedno, čím budete ten renderovací engine rozhýbávat. I když pravda, dost výkonu žerou některé frameworky, které se snaží řešit některé problémy ve vývoji (nikoliv s platformou) čímž efektivně způsobují další problémy.

Nenabízí jiné řešení než to brát hrubou silou ala React.

Což je nesmysl. Třeba Svelte to tak skutečně nedělá. A když budete modifikovat přímo DOM, taky se to dít nebude. Naopak: React tím začíná být poněkud zastaralý. Ale to je jiná diskuze.

Aha, další, co nechápe co je návrhem JavaScript vlastně zač ale má plnou hubu odsudků. U pohovorů je takových tak polovina. A jinak JavaScript mohl Javě konkurovat asi jako VBScript céčku; od začátku se používal pro úplně jiné úlohy a trochu se jí přiblížil až v posledních letech a to ještě ne úplně.

V době, kdy JavaScript vznikal byla Java jazyk víceméně na psaní javových appletů do browserů (tj. čistě front-end). Serverová a korporátní popularita Javy jako jazyka pro psaní back-endu přišla později. Ještě v roce 1996 knížka o Javě, kterou jsem si tehdy pořídil byla čistě o psaní apletů, o nějakém použití na serveru v ní nebylo ani písmenko. První specifikace Java servletů pochází z konce roku 1996, JSP 1999... Takže jak to myslíte, že Java a JavaScript byly od začátku určené na něco jiného?

Skriptování na straně klienta a psaní appletů byly absolutně rozdílné technologie. Applety vycházely z tehdy rozšířeného principu remote objects, a byly odpovědí na ms technologii DCOMu. JavaScript původně sloužil k automatizaci klienta - byla to analogie s microsoft vba v Microsoft Office.

Java rozhodně nebyla designovaná pro applety - vznikla v době, kdy http protokol byl v plenkách. Ale byla navržená tak, aby byla platformě nezávislá už s podporou remote objects, a s velice dobrou podporou TCP/IP. První applety byly defakto tlustí klienti běžící v prohlížeči. V druhé polovině 90 let byly jen dvě technologie, na kterých by se to dalo postavit - Java nebo DCOM. DCOM byl čistě Microsftí. Java byla univerzální - ale výrazně pomalejší a výrazně žravější. DCOM byl zase relativně nebezpečný. Takže se hledaly cesty, jak se obojího zbavit.

Alternativy byly tři - flash, JavaScript a VBScript. Flash a VBScript byly proprietární technologie. VBScript navíc byl zase jen MS záležitost. Vyhrál JavaScript. Java je jazyk a univerzální prostředí navržené v 90 letech, kdy v době návrhu nikdo netušil, že něco jako web bude. JavaScript byl jednoduchý skriptovací jazyk určení k skriptování - automatizaci browseru.

“Applety vycházely z tehdy rozšířeného principu remote objects, a byly odpovědí na ms technologii DCOMu”

DCOM byla úděsná technologie, ale jinak byla myšlenka “distributed objects” poměrně zajímavá a dost “hajp”, než to zabil REST. A k appletům, díky Bohu пошли на х*й.

Borek Lupoměský: To je nějaká alternativní historie? Java i JavaScript byly představeny v roce 1995, Java 1.0 oficiálně vyšla v roce 1996. Netscape v roce 1995 řešil, jak zavést interaktivitu webových stránek, a měl dvě varianty – vložit do prohlížeče Javu od Sunu nebo vytvořit nový skriptovací jazyk. To dostal za úkol Brendan Eich a Netscape dal nakonec přednost této variantě. (Ale Sun využil NPAPI, které už v roce 1995 v Netscape Navigatoru bylo, a umožnil tak vkládat do webových stránek Java Applety.)

JavaScript byl od počátku určen pro interaktivitu samotné webové stránky. Java Applety byl způsob, jak do stránky vložit jako jeden objekt nějakou aplikaci (a stejně se tam dali vkládat jiné objekty). Java Applety neměly možnost manipulovat s obsahem webové stránky – tu získaly právě až s JavaScriptem, kdy z Java Appletu šlo zavolat JavaScriptový kód, který mohl stránkou manipulovat. A Java samozřejmě nebyly jenom Applety, to byl jenom jeden z více způsobů použití.

Ale chápu to správně, že bajtkódové jazyky jsme postupně vždycky opustili (Shockwave, Flash, Java, Silverlight), ale teď přišel ten jediný správný, který nás zachrání? :D

Soucasny JS je take zalozen na JIT bytecode

Co je to proboha JIT bytecode?

JIT je JIT, z čeho je zkompilovaný je irelevantní. JS žádnou specifikaci pro bytecode nemá, a jestli JS-VM nějaký bytecode používá je jen na něm. První verze V8, což byl první JIT VM pro JS třeba žádný bytecode neměl, jen AST a IR, pak přímo machine code. Trvalo možná dekádu než do V8 ten bytecode dali, aby to mohlo běžet i tam, kde JIT není možný (třeba iOS tuším).

Petr Polášek> Jaký myslíte? WASM není jazyk, ve kterém byste psal. Píšete v nějakém vyšším, C/C++, C#, ... I ta Java jde zkompilovat do WASM. WASM právě řeší to, abychom mohli programovat jako dřív, ale aby to běželo stejně bezpečně jako JS (WASM běží v enginu a sandboxu JS). Bezpečnost byl jediný důvod, proč ty dřívější technologie umřely (prohlížeče zrušily podporu pluginů).

9. 8. 2022, 11:17 editováno autorem komentáře

Ne, chápete to špatně. Bajtkódové jazyky jsou ty zdaleka nejpoužívanější (JavaScript, Java, C#, Python, PHP), hodně kódu kompilovaného do nativního kódu je psaného v daných jazycích spíše z historických důvodů (C, C++), nové jazyky kompilované do nativního kódu zas tolik rozšířené nejsou (nejlépe je na tom Swift a Objective-C, o Go nebo Rustu je sice hodně slyšet, ale zas tak rozšířené nejsou).

K čemu přesně potřebuju knihovnu pro napsání

typeof var === "number"

nebo nastavení stylu?

Další kdo plácá o něčem, o čem vůbec nic netuší...

A jinak velké aplikace se píšou spíš v TS a ne v JS, protože ve skutečnosti největší problém JS z jejich hlediska je notně omezená typová kontrola.

> typeof var === "number"

To neexistuje lepší test typu než string compare na jméno? Vždyť u dynamicky typovaného jazyka jsou kontroly typů veliká část toho, co interpret dělá.

Jiří Havel: V čem by ten test měl být lepší? Proč si myslíte, že u dynamicky typovaného jazyka je kontrola typů častá?

Vždyť i ten operátor === porovnává napřed typy, pokud ten test nedokáže optimalizátor vyhodit. Což není až tak jednoduché. Obzvlášť v místech, kde ten typ potřebuje otestovat programátor. Takže uvnitř téhle nešikovné typové kontroly je schovaná jedna lepší (uvnitř toho typeof). Jen k ní programátor nemá přístup přes nějaké rozumné api.

Třeba v pythonu nedostanu jen jméno typu, ale objekt co toho umí podstatně víc. Kdekoliv jinde bych knihovny jako https://github.com/jonschlinkert/isobject/blob/master/index.js považoval za recesi.

V čem je teda ta kontrola lepší?

No přece v tom, že tam není ten mezikrok přes string. A teď budu ignorovat výkon, protože mi jde o něco jiného. Když se podíváte na ten můj odkaz :
export default function isObject(val) {
return val != null && typeof val === 'object' && Array.isArray(val) === false;
};
tak to "val != null && typeof val === 'object'" potřebuje udělat interně i to isArray. Tohleto je dost fundamentální operace, kterou potřebujete pro všechno ostatní. Switch podle typu proměnné. Jenže jednoduché je to jen uvnitř interpretu. Vy jako programátor ten test musíte udělat dvakrát, protáhnout tu informaci různými kanály, protože každý ji zmrší nějak jinak a pak zase rekonstruovat.

Skoro jako kdyby v nějakém systémovém programovacím jazyce nešlo pořádně udělat add-with-carry. :D

9. 8. 2022, 15:26 editováno autorem komentáře

Jaký mezikrok přes string? Pro programátora je úplně jedno, jestli píše typeof x === "string" nebo typeof x === String nebo nějak jinak. Že isArray volá interně val != null && typeof val === 'object' je vaše ničím nepodložené domněnka. Jsem přesvědčený o tom, že by to platilo jen pro nějaký velmi naivní interpret JavaScriptu, který v prohlížeči mohl být možná před dvaceti lety. Dnešní JS enginy nejspíš ten kód často ani neprovedou, protože vědí, že jsou v branchi, kde ta proměnná musí být pole. A nebo se jen podívají na příznak označující, že je to pole.

Vy jako programátor ten test musíte udělat dvakrát
Vy možná, já bych ten test dvakrát nedělal.

Abychom se k něčemu dobrali, vezmeme to po malých krůčcích. Ten test typeof x === 'string' vám tedy vadí z hlediska programátora, protože je ten kód nějak špatně čitelný nebo může být chybný, nebo vám vadí z hlediska interpretu?

> Pro programátora je úplně jedno...

To teda určitě není jedno, jesli porovnávám string nebo třeba enum. A to nejen kvůli rychlosti. U enumu je množina možných hodnot součástí rozhraní, kterému rozumí i překladač. Takže můžu dostat třeba warning, že jsem nepokryl všechny možnosti. K nezaplacení, pokud třeba v budoucnu nejaká přibude.

IsArray určitě nevolá ten kód, ale čistší logický ekvivalent toho kódu. Tohle jsem zapomněl zdůraznit. A že to dělá mám podložené dokumentací chování toho IsArray.

> A nebo se jen podívají na příznak označující, že je to pole.

Ano, to je přesně ta fundamentální operace "switch podle typu", ke které skrz api javascriptu nemáte jednoduchý přístup.

> Abychom se k něčemu dobrali ...

1) string compare je nesrovnatelně komplikovanější a pomalejší než porovnání enumu. Je možné, že interprety mají speciální optimalizace tohohle případu. Ale tam se zas platí komplexitou a délkou překladu. A programátor do téhle optimalizace vždycky může nechtěně hodit vidle.

2) String má daleko víc možných hodnot než enum. Jak už jsem psal, u enumu můžu celkem jednoduše dostat warning, že jsem nějakou možnost nepokryl. Může mi vyskočit i ve starém kódu, když přibude v tom enumu položka. Se stringem mi lintery, statické analyzátory a pod. můžou pomoct podstatně hůř.

3) A typeof v JS má ještě historický bonus, že null se tváří jako objekt kvůli implementačním detailům prvního prototypu. To jsou ty dva testy, které jako programátor musíte udělat - test na null a test na objekt. I když interpret na to určitě bude mít nějakou lepší operaci, protože tohle je součást sémantiky hromady dalších věcí.

Takže místo toho, aby nějaké základní operace, které interpret stejně musí dělat, byly zpřístupněné přes nějaké příčetné api, tak se pro ně v JS světě tahají NPM balíčky. Co by se jen mohlo podělat (ehm ehm, leftpad, ehm ehm)

> 2) Jak už jsem psal, u enumu můžu celkem jednoduše dostat warning, že jsem nějakou možnost nepokryl. Může mi vyskočit i ve starém kódu, když přibude v tom enumu položka. Se stringem mi lintery, statické analyzátory a pod. můžou pomoct podstatně hůř.

Javascript statickou typovou kontrolu nemá, takže tam to opravdu tak je. Ale v Typescriptu je to jiná. Typeof tam podle definice totiž nevrací string, ale jeden z množiny stringů (string literals). Takže tam ta kontrola (nepokrytí možnosti, testu na hodnotu, kterou typeof nemůže vrátit) funguje.

> 3) To jsou ty dva testy, které jako programátor musíte udělat - test na null a test na objekt.

Marně vzpomínám, kdy jsem potřeboval naposledy testovat, jestli je něco "objekt". No, ani si vlastně nevzpomínám. Protože typicky je to tak, že v proměnné je například objekt nebo null - tak otestuju na null a pokud tam není, je tam objekt.

“typicky je to tak, že v proměnné je například objekt nebo null - tak otestuju na null a pokud tam není, je tam objekt.”

Tohle taky používá překladač (JIT) k optimalizaci. Pokud si umí odvodit, že instance je vždy typu Union{AnObjec­t,Nothing}, nemusí se za běhu provádět typová kontrola a nativní kód vypadá, jako kdyby vylezl třeba z Rustu. Nikdo to ale negarantuje.

To teda určitě není jedno, jesli porovnávám string nebo třeba enum. A to nejen kvůli rychlosti.
Bohužel se stále ukazuje, že vůbec netušíte, o čem mluvíte. JavaScript žádné enumy neměl, ale hlavně to, že ve skriptu vidíte porovnání se stringem, vůbec neznamená, že to tak provádí interpret. typeof x === "něco" je výraz, který může interpret vzít a vykonávat ho úplně jinak, třeba ho interně přeloží na ten enum, nebo jakkoli jinak.

U enumu je množina možných hodnot součástí rozhraní, kterému rozumí i překladač.
JavaScript žádný překladač nepotřebuje. A IDE a lintery ten kód analyzovat umí a vědí, které hodnoty může vracet typeof.

IsArray určitě nevolá ten kód, ale čistší logický ekvivalent toho kódu. Tohle jsem zapomněl zdůraznit.
Ale stejně to není pravda. Interní implementace javascriptových objektů v interpretu vypadá jinak, než jak to vidíte v JavaScriptu. Jak jsem psal, klidně každý objekt může mít příznak, jestli je nebo není pole a isArray() jenom otestuje hodnotu tohoto příznaku.

Ano, to je přesně ta fundamentální operace "switch podle typu", ke které skrz api javascriptu nemáte jednoduchý přístup.
Máte k tomu přístup. typeof vrací string a nad stringem můžete udělat switch.

string compare je nesrovnatelně komplikovanější a pomalejší než porovnání enumu.
Chyba je v tom, že bezdůvodně předpokládáte, že tam interpret dělá string compare.

Ale tam se zas platí komplexitou a délkou překladu.
Dnešní javascriptové enginy dělají především spoustu různých optimalizací, samotné běhové prostředí je ta nezajímavá část. Takže jedna takováhle jednoduchá optimalizace navíc není žádný problém. Uvědomte si, že všechny objekty jsou řešené jako hashmapy, které mají jako klíče stringy. Pokud by tohle JS engine neuměl optimalizovat, bude mít daleko horší problémy, než je typeof.

Se stringem mi lintery, statické analyzátory a pod. můžou pomoct podstatně hůř.
Mýlíte se, tyhle nástroje samozřejmě vědí, jaké jsou povolené návratové hodnoty typeof.

A typeof v JS má ještě historický bonus, že null se tváří jako objekt kvůli implementačním detailům prvního prototypu.
To je holt nevýhoda zpětné kompatibility.

To jsou ty dva testy, které jako programátor musíte udělat - test na null a test na objekt.
Ne, nemusím.

Takže místo toho, aby nějaké základní operace, které interpret stejně musí dělat, byly zpřístupněné přes nějaké příčetné api, tak se pro ně v JS světě tahají NPM balíčky.
Pořád jste nenapsal, co by ta základní operace měla dělat jiného, než dělá typeof. V JS světě se na to žádné balíčky netahají. To, že nějaký balíček existuje, ještě neznamená, že ho někdo příčetný používá.

Ach jo, to jsou zas bláboly. Jasně, že to jde zoptimalizovat, vždyť jsem to i explicitně napsal. Takže zareaguju jen na ten největší úlet :

> Dnešní javascriptové enginy dělají především spoustu různých optimalizací, samotné běhové prostředí je ta nezajímavá část. Takže jedna takováhle jednoduchá optimalizace navíc není žádný problém.

Běhové prostředí vůbec není nezajímavá část, protože ten JIT kompilátor co všechny tyhle optimalizace dělá je část toho běhového prostředí. Jednu každou takovouhle optimalizaci musí provádět běhové protředí znova a znova u každého klienta. Takže každá tahle jednoduchá optimalizace je malý střípek velkého problému, protože počet provedení je astronomický.

Ta kompilace je nechutně drahá, takže třeba v8 ty výsledky cachuje. Ale jen někdy, protože to cachování je taky drahé.

> To, že nějaký balíček existuje, ještě neznamená, že ho někdo příčetný používá.

Jo, na tomhle závisí jen necelých 1000 dalších npm balíčků a má to 50k stažení za týden. Až děsivé na balíček s jedinou funkcí.

Jiří Havel: Ano, z vaší strany jsou to bláboly. Proč tedy argumentujete tím, jak by to zpracovával naivní interpret před dvaceti lety, když víte, že dneska javascriptový runtime vypadá úplně jinak?

Běhovým prostředím jsem myslel tu část bez optimalizátoru. Snažil jsem se vám naznačit, že zatímco dříve byl javascript runtime hlavně interpret, který měl možná nějaké drobné optimalizace, posledních 15 let se vývoj javascriptových enginů soustřeďuje hlavně na optimalizace. A schopnost optimalizovat běh JS je to, co dnes rozhoduje o tom, jak je který engine dobrý a je to to, co je na enginech to zajímavé. Protože s interpretem bez optimalizací by už dnes nikdo neuspěl.

Ano, JIT kompilátor je náročný jak na vývoj tak na provoz. Ovšem měl byste si uvědomit, že se tu bavíme o webových prohlížečích. Kdyby si prohlížeč stáhl nativní kód optimalizovaný pro svou platformu, mohla by se JIT kompilace zrušit. Ale myslím, že byste nechtěl na svém počítači spouštět nativní kód stažený náhodně z internetu. Takže ať budete v prohlížeči spouštět cokoli, vždy to bude kód, který bude kontrolovaný prohlížečem. Což se snáze udělá s kódem, který není nativní. No a jestli to bude nějaký bajtkód nebo skript, to ovlivňuje složitost JIT ale ne jeho výkon.

Takže to, co vám vadí, bude v prohlížečích vždy, ať už se bude používat jakýkoli jazyk. A mimochodem jazyků používajících bajtkód nebo interpretovaných je čím dál víc i mimo prohlížeče, protože dělat optimalizace až za běhu aplikace má svoje podstatné výhody.

Z toho, že to používá dalších 1000 npm balíčků, bych si hlavu nedělal. Vy nevíte, že operátor typeof v JavaScriptu nemůže vracet enum, protože v době, kdy byl zaveden, žádné enumy v JS neexistovaly, někdo jiný zase neví, že nepotřebuje funkci isObject().

@Filip Jirsák

function isObject(value) {
  return typeof a === 'object' && !Array.isArray(a) && a !== null;
};

let a = new Array();

console.log(typeof a === 'object');          // true
console.log(Array.isArray(a));                // true
console.log(isObject(a))                      // false

Something fishy here ...

10. 8. 2022, 20:15 editováno autorem komentáře

Altan Sarnai: Když na tom něčemu nerozumíte, musíte se na to zeptat. Nemám křišťálovou kouli, abych z tohohle poznal, čemu na tom nerozumíte.

Co je na tom nejasne?

@Altan: Prostě v JS je pole objekt, co je na tom divného?

Fascinuje mě posedlost zdejších diskutérů zjišťováním, jestli je něco "nějaký objekt jiný než pole". Dělám v JS/TS fulltime posledních pět let a nepamatuji se, kdy jsem něco takového naposledy potřeboval. K čemu by to bylo dobré? Jo, kontrola, jestli je nějaký objekt instancí konkrétní třídy, to bych pochopil, ale tohle...?

Používá se to v typových asercích, ale na to jsou specializované knihovny, řešit to takto nízkoúrovňově je nesystémové.

Já si pamatuju, kdy jsem něco takového naposledy potřeboval: nikdy. A to jsem JavaScript začal používat v době, kdy Internet Explorer 5.0 byla žhavá novinka.

Když člověk jen tak prasí a ignoruje veškeré good practices, tak to nepotřebuje.

Calculon: Tak ukažte nějaký dobře napsaný kód podle good practices, kde potřebujete vědět, že je něco objekt, je vám jedno, jaký je to objekt, ale nesmí to být pole.

Element obsahující HtmlInputy. Se všemi prvky se pracuje jako s objekty, kromě radiobuttonu, ten je kolekce.

Bone Flute: Tam vám ovšem není jedno, o jaké se jedná objekty.

V daném kontextu je. Potřebuju jen rozlišit, zda je to pole, nebo jen objekt. Že jsou to objekty HTMLInput, to mám ošetřenou o úroveň víš.

Ale já se zrovná s vámi nechci přetahovat. Byl tu dotaz na příklad, já ho shodou okolností měl v čerstvé paměti, tak jsem ho uvedl. Dále mě to nezajímá.

Tak si v té úrovni výš ošetřete, i jestli je to pole ;-)

To se nejevilo praktické ani čisté.

No už tam nějakou kontrolu děláte, takže to jen přihodíte ;-)

15. 8. 2022, 12:01 editováno autorem komentáře

Ale no tak.

Mám selektor, který mi vrátí všechny inputy.
Pak mám funkci, která nad každým inputem provede nějakou práci.

Mám dvě možnosti:
1/ Buď napíšu dva selektory, kdy prvý mi vrátí inputy bez radiobuttonu, a druhý, který mi vrátí radiobuttony(a ty další, co si nepamatuju).

nebo 2/ napíšu selektor vracící všechny inputy a pak podle toho, jestli je ten input jakože pole (radiobutton a ty další, co si nepamatuju) projedu jej ještě v ciklu.

Můžete se mnou nesouhlasit, ale mě prostě ten druhý způsob přijde z mnoha důvodů lepší a ten první vůbec.

Bone Flute: Funkce, která umí vracet víc inputů ( querySelecto­rAll()), vrací vždy NodeList. Výše uvedená funkce isObject() by vám v tomhle případě byla k ničemu.

Bone Flute: Děkuji za potvrzení, že ani v tomto případě nepotřebujete zjišťovat, zda je něco libovolný objekt, ale není to pole. To vaše rozlišení je obyčejný test, zda se jedná o pole, pomocí Array.is.Array().

Že vás nezajímají věci, ze kterých byste se mohl poučit, je vaše chyba, ne moje.

@L.

Mě to nepřipadně divné. Dělám i s PHP ;-) Ovšem můj příklad jednoduše dokazuje, že s obyčejným typeof si prostě v některých případech nevystačíte (např. is really really object?), jak tady zase urážel Jirsák. A jazyk sám pro tyto případy žádnou funkci nepostkytuje - pro mě za mě nemusí, ale neposkytuje.

Dělám v JS/TS fulltime posledních pět let a nepamatuji se, kdy jsem něco takového naposledy potřeboval.

Nechci na vás mít nějaké nepříjemné poznámky, ale takové výroky bych být vámi ani radši neříkal.
Kde byste to chtěl použít? Např. tam kde potřebujete iterovat přes opravdový objekt a potřebujete uživatele upozornit, že vám tam přišlo nějaké pole.

11. 8. 2022, 13:14 editováno autorem komentáře

Altan Sarnai: Pole v JavaScriptu podle vás není opravdový objekt? Jaké vlastnosti má podle vás opravdový objekt?

@Filip Jirsák

Altan Sarnai: Pole v JavaScriptu podle vás není opravdový objekt? Jaké vlastnosti má podle vás opravdový objekt?

Třeba takový, který zároveň ale nereprezentuje pole. Netvrdím, že "opravdový objekt" je JS terminologie, ale když jste tak inteligentní, už z toho příkladu by vám to mělo být jasné.

Ten příklad který jsem sem dal neslouží jako urážka, ale abyste viděl, že i pole může být pomocí typeof objekt, protože JS používa strukturu objekt k reprezentaci dalších typů. Jinými slovy, typeof nemusí v některých případech stačit. Takhle narychlo si nevzpomínám, že by ještě nejaký jiný jazyk měl takto zamotané typy a neúplné operátory nebo funkce k porovnání typu proměnné.

function isObject(value) {
  return typeof a === 'object' && !Array.isArray(a) && a !== null;
};

let a = ['A']

console.log(typeof a === 'object');          // true
console.log(Array.isArray(a));               // true
console.log(isObject(a))                     // false

A kde se vám to může hodit? Třeba zde:

const myObject = {i: 2};

for(const key of myObject) {
  console.log(key);
}

TypeError: myObject is not iterable ...

Takže jak vidíte, není to jedno.

Difference between for...of and for...in
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/for...of#difference_between_for...of_and_for...in

11. 8. 2022, 20:17 editováno autorem komentáře

Altan Sarnai: To je ovšem vaše arbitrární definice objektu, která je v praxi úplně k ničemu. Taky bych si mohl nadefinovat objekt jako cokoli, co není primitivní typ, není to pole, není to funkce, má to alespoň jednu stringovou property a nemá to property pojmenovanou name.

Že je v JavaScriptu pole objekt samozřejmě vím. Stejně jako funkce je objekt. Nebo DOM element je objekt. JavaScript nepoužívá strukturu objekt k reprezentaci dalších typů. JavaScript několik primitivních typů (takže není čistě objektový) a všechno ostatní jsou objekty. Nevím, co tady na tom spoustu lidí tak překvapuje – v čistě objektových programovacích jazycích je úplně všechno objekt, JavaScript k tomu jen (jako spousta dalších jazyků) přidává i pár primitivních typů.

Takhle narychlo si nevzpomínám, že by ještě nejaký jiný jazyk měl takto zamotané typy a neúplné operátory nebo funkce k porovnání typu proměnné.
Třeba C, C++, Java, Python…

A kde se vám to může hodit? Třeba zde:
To nemyslíte vážně, že ne? Tušíte alespoň přibližně, co by ten váš kód dělal? Kdybyste tam přidal ten test na isObject, zabránil byste iterování některých objektů, které iterovatelné jsou, a naopak byste pustil do iterování i objekty, které iterovatelné nejsou.

Kdybyste chtěl testovat, zda můžete přes daný objekt iterovat, použijete třeba následující kód:

myObject && typeof myObject[Symbol.iterator] === 'function'

Opět jenom fabulujete. V Pythonu je funkce, která vám o poli řekne že je to objekt, resp. nemůžete určit že se jedná o pole?

Dostal jste konkrétní příklad. To teď jste tvrdil, že nic víc než typeof není potřeba. Je. A proto vznikají i různé další knihovny.

myObject && typeof myObject[Symbol.iterator] === 'function'

To je hezké, ale "vy" chcete iterovat přes cokoliv. Pokud pouze přes pole, toto je vám k ničemu.

Co víc napsat, konkrétní případ jste dostal. Bádejte ...

12. 8. 2022, 09:25 editováno autorem komentáře

Jestli chcete iterovat jen pole (a ne vše, co jde iterovat), tak vás zajímá, jestli je na vstupu pole. Ne ve kterých objektových jazycích je i pole objekt.

> Proč tedy argumentujete tím, jak by to zpracovával naivní interpret před dvaceti lety, když víte, že dneska javascriptový runtime vypadá úplně jinak?

Bingo! Já tak neargumentuju. To vy si tam urputně dosazujete 20 let staré interprety. Prosím, aspoň zkuste interpretovat moje odpovědi v kontextu toho, že mám aspoň hrubou představu o možnostech JIT interpretu.

> Běhovým prostředím jsem myslel tu část bez optimalizátoru.

A k čemu tohle dělení je? Pro kohokoliv kromě vývojářů v8 je ten optimalizátor a všechno za ním jeden blok. Copak můžu tomu za tím strčit nějaký svůj bytecode? Ten kompilátor + optimalizátor nejde obejít. Svým způsobem je to rozhraní k tomu, čemu říkáte to běhové prostředí.

> No a jestli to bude nějaký bajtkód nebo skript, to ovlivňuje složitost JIT ale ne jeho výkon.

Takže to, jestli ta kompilace může jet minuty a víc, nebo jestli musí doběhnout v rozumném čase na nějakám uživatelově střepu, nemá vliv na výkon? Jestli se bude jitovat a optimalizovat textový zdroják nebo předoptimalizovaný bytecode neovlivní výkon? Fakt?

> Takže to, co vám vadí...

Ne, tahle větev začala tím, že jsem ryl do typeof, protože mi to přijde jako mizerné rozhraní. Porovnejte to třeba s tím Array.IsArray. Co všechno musí runtime udělat aby zoptimalizoval to použití typeof vs zoptimalizoval volání nějakého předpřipraveného predikátu? Jo, jednotlivě se to vsákne, ale tyhle drobečky se sčítají.

Jo, spousta lidí tady něco takového nepoužilo. To beru. Ale ten odkazovaný balíček je nechutně používaný na to, že je jeho obsah skoro srovnatelný se složitostí jeho importu. V kolika dalších projektech se vyskytujou stejné obraty si netroufám ani odhadovat.

Že je pole taky objekt je implementační detail JS. Nebo je to možná implementační detail prvního JS. Ani programátoři tak IMO obvykle nepřemýšlejí. Že je absence čehokoliv taky objekt už je regulérní WTF. A argument "typeof je starý krumpl, takže v novém kódu použijte XYZ" jsem tu nezahlédl.

Bingo! Já tak neargumentuju.
Ale argumentujete. To vy tvrdíte, že javascript engine provádí výraz typeof x === 'object' tak, že z operátoru typeof vrátí obecný string a ten pak znak po znaku porovnává s 'object'.

Prosím, aspoň zkuste interpretovat moje odpovědi v kontextu toho, že mám aspoň hrubou představu o možnostech JIT interpretu.
Zkuste vy tu hrubou představu promítnout do vašich odpovědí.

A k čemu tohle dělení je?
K tomu, abyste pochopil, že posledních 15 let se vývojáři věnují právě té části, která řeší optimalizace. A že to je ta podstatná část, kterou má smysl se zabývat, když řešíte výkon dnešních javascript runtime.

Takže to, jestli ta kompilace může jet minuty a víc, nebo jestli musí doběhnout v rozumném čase na nějakám uživatelově střepu, nemá vliv na výkon?
Má, ale o tom já jsem nepsal.

Jestli se bude jitovat a optimalizovat textový zdroják nebo předoptimalizovaný bytecode neovlivní výkon?
No, paradoxně lepší možnosti optimalizace nabízí ten texťák. Je tam sice nějaký overhead kvůli parsování textu, ale to není žádná tragédie. Pak ale v tom texťáku mohou být konstrukce, které se překladem do bajtkódu ztratí, ale které by mohly optimalizátoru napovědět, jak kód optimalizovat.

Ne, tahle větev začala tím, že jsem ryl do typeof, protože mi to přijde jako mizerné rozhraní.
Ano, přijde vám to jako mizerné rozhraní pro 20 let starý naivní interpret. Což ovšem nevypovídá nic o dnešním stavu běhových prostředí. Navíc jste stále nenapsal, jak by to mělo být lépe – u dynamicky typovaného jazyka, který logicky nemá enumy.

Co všechno musí runtime udělat aby zoptimalizoval to použití typeof vs zoptimalizoval volání nějakého předpřipraveného predikátu?
Musí poznat, že typeof X === 'object'> je předpřipravený predikát. typeof je operátor, takže musí poznat, že za typeof se nachází operátor porovnání a za ním stringová konstanta. Vyloženě raketová věda, do dneška nikdo nepřišel na to, jak tohle udělat.

V kolika dalších projektech se vyskytujou stejné obraty si netroufám ani odhadovat.
Nejde o počet projektů, ale o to, jak jsou používané.

Je dost pravděpodobné, že z webu se stala univerzální aplikační platforma právě díky tomu, jak je JavaScript benevolentní k začátečníkům. Existují samozřejmě daleko hezčí a propracovanější jazyky – ale kolik je v nich toho napsáno?

JavaScript má samozřejmě spoustu nešvarů. JavaScript s oblibou kouše do zadku programátory, kteří mu nerozumějí a chtějí dělat něco kapánek složitějšího. Ale typeof vracející string fakt není jeho problém.

Že je pole taky objekt je implementační detail JS. Nebo je to možná implementační detail prvního JS. Ani programátoři tak IMO obvykle nepřemýšlejí.
To, že je všechno objekt, nebo se alespoň umí do objektu automaticky zapouzdřit, je naopak hodně dobrá vlastnost JavaScriptu.

Že je absence čehokoliv taky objekt už je regulérní WTF.
No, díky tomu začíná trošinku dávat smysl rozdíl mezi null a undefined. Ale to je něco, co se v JavaScriptu doopravdy nepovedlo.

A argument "typeof je starý krumpl, takže v novém kódu použijte XYZ" jsem tu nezahlédl.
Protože takový argument neplatí. typeof se nepoužívá nějak moc často, a když už se použije, jeho použití je v pohodě, nevadí ani programátorům, ani javascript runtime. Problém z toho děláte akorát vy.

> To teda určitě není jedno, jesli porovnávám string nebo třeba enum.

JavaScript internuje stringy, v obou pripadech porovnani cisla.

V js je vse objekt, ta vase funkce vraci true, pokud objekt neni pole nebo null, coz jsou take objekty.

Typ objektu (ekvivalent pythonovskeho isinstance) ziskate pres __proto__.

> V js je vse objekt

Ne, není. Podívejte se do dokumentace typeof, co všechno kromě objektů JS umí.

Pri pozornejsom nahlade do dokumentacie zistite ze vsetky typy ktore JS pozna maju metody...

Napr:

(134).toString()


10. 8. 2022, 09:02 editováno autorem komentáře

dw : Mám to chápat tak, že tenhle syntaktický vzor je argument pro to, že v JS je všechno objekt? :)

neco.neco() je syntaktický cukr, který nemusí mít nic společného s OOP (v jakékoliv variantě). Některé jazyky to mají prostě jako alternativní syntaxi pro pro předání prvního parametru do funkce.

Tohle je problém s OOP. Ono není pořádně definované, co to to OOP vůbec je, a v různých jazycích se to tváří výrazně odlišně. A samotné slovo "objekt" je zatraceně vágní a občas se nepoužívá konzistentně ani v kontextu jednoho jazyka.

Neskusite predsa len tu dokumentaciu?

The Number object overrides the toString() method of the Object object. (It does not inherit Object.prototy­pe.toString()).

No tak podle dokumentace je "Number" wrapper objekt pro boxování primitivních hodnot, které objekty nejsou.

"Number is a primitive wrapper object..."
"In JavaScript, a primitive (primitive value, primitive data type) is data that is not an object and has no methods or properties."

Javascript tomuhle zmatení pojmů výrazně napomáhá tím, že věci automaticky boxuje a unboxuje.

Java má taky automatic boxing/unboxing. takže JS není jediný.

Aspoň že už automatický, nebývalo to tak. Boxing/unboxing v Javě má zajímavou historii, převzali ho z Objective-C (po akvizici týmu, který psával aplikace pro NeXTStep, Sunem). Ten Jobs měl prsty všude :)

> Aspoň že už automatický, nebývalo to tak.

Já bych teda automatický boxing jako dobrou vec nepovažoval, rozhodně ne univerzálně. Třeba při vývoji v Unity (C#) je to víc past než pomoc. A na podobné názory jsem narazil i u Javistů Androiďáků.

Jakkoliv rychlá alokace je vždycky výrazně pomalejší než žádná alokace. A nejvíc to vynikne právě v situacích, kdy nějaká trivialitka spustí nečekaný autoboxing.

Univerzálně ne, ale jestvuje několik typů (auto)boxingu. Například compile-time boxing (jako v Go) je úplně zadarmo, protože za běhu se nic navíc neprovádí. A “skutečný” (runtime) boxing také může být levný, překladač může provést escape analýzu a alokovat na zásobníku (což je taky téměř zdarma). Případně se dá provádět boxing/alokace jako v Julii, kde se také dynamická alokace obchází. Jen v jazycích, které tupě alokují vše na haldě (Java, ale i například Objective-C, kde ostatně boxing v dnešní podobě vzniknul), to může být problém.

“Tohle je problém s OOP. Ono není pořádně definované, co to to OOP vůbec je, a v různých jazycích se to tváří výrazně odlišně.”

Dokud někdo nespojuje OOP s dědičností, je to úsměvné.

> Dokud někdo nespojuje OOP s dědičností, je to úsměvné.

A která dědičnost, třídní nebo prototypová? Potkal jsem i něco mezi, co si vůbec netroufám klasifikovat. :)

A myslím, že Alan Kay by dědičnost mezi nějaké důležité věci pro OOP rozhodně nezahrnul. ;)

To je fuk, kterákoliv :)
Jo, Kay to charakterizoval úplně jinak, mnohem logičtěji. Ale co naplat, C++ a později Java přišly s vlastní definicí.

Celkem zajímavý koncept dědičnosti a objektovosti má Julia, tam se rozhodli, že OOP je zlo a GC je taky zlo, a napsali si to po svém.

dw: Což ale neznamená, že všechno v JavaScriptu jsou objekty. Objekt v JavaScriptu je speciální datový typ, vedle něj existuje ještě 7 primitivních typů.

https://www.npmjs.com/package/is-number ma 70 milionov stiahnuti, takze az take obskurne to nebude.

Pro zajímavost, i ten extrémně hypovaný jazyk Rust se do kernelu dostává postupně. Aktuálně je v podobě, že je prakticky nepoužitelný (nemá svou hlavní feature).

Kvůli unsafe? Unsafe nevypíná všechny garance které Rust poskytuje. Navíc je pořád lepší mít pár míst kde je explicitní unsafe, než bez garancí všechen kód.

V jadre operacniho systemu vyssi uroven abstrakce mozna vadi.

Napriklad v oblasti crypta, web3 aplikaci, je javavascript asi nejpouzivanejsi jazyk.

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č.

Od té doby WebAssembly implementovalo Safari a Chrome implementovalo vlákna. A vzniklo několik návrhů navazujících standardů (mimo jiné WebAPI).

Podpora Safari, a to včetně Safari/iOS, byla kruciální. Protože teď už se nemůže nikdo vymlouvat, že to někde neběží.

Takze na GC budeme cakat dalsich 5 rokov, pokial si to aplovske IE zmysli, ze uz je cas to implementovat? A podpory DOM-u sa dockame v roku 2056?

5 rokov je v IT neskutocne dlha doba.

To je jako nadávat na C++, že ještě nemá GC. Přitom máte naprostou svobodu a můžete si udělat vlastní. Takové projekty už běží i pro WASM (pro usnadnění kompilace jazyků s GC, např Java). A co furt máte s tím DOMem? To fakt chcete měnit barvičky elementů v C++? Si najděte knihovnu nebo sám zapouzdřete tu glue vrstvu.

Mne ten GC nechyba.

> To fakt chcete měnit barvičky elementů v C++?
Ano chcem a nie len s C++ ale s cohokolvek co sa dak skompilovat do wasm. Chcem mat konecne slobodu vo webovom vyvoji.

Skutečné svobody dosáhnete jen s vlastním webovým prohlížečem.

oss:
> To fakt chcete měnit barvičky elementů v C++?
Ano chcem a nie len s C++ ale s cohokolvek co sa dak skompilovat do wasm. Chcem mat konecne slobodu vo webovom vyvoji.

Priznam se, ze tak bych to chtel take.
Ale musim akceptovat, ze existuji programatori, kteri pracuji podle nejake vlastni nebo 'moderni' programatorske filozofie a filozofii, jakou se ridim ja proste neakceptuji.
Ja patrim k te generaci programatoru, kteri vyrostli s C a pracuji a resim problemy jak to doporucoval Dennis Ritchie -> minimalisticky jazyk, za pomoci ktereho vytvarim nastroje, pomoci kterych pak resim konkretni zakaznicke pozadavky.
A to je ta svoboda, o ktere mluvite. Take bych si ji pral.

oss: Je klidně možné, že na GC budeme čekat pět let. WebAssembly není nic, na co by se čekalo – je to jenom zjednodušení některých věcí. Ví se, že transpilovat vše do JavaScriptu není ideální řešení, takže je vhodné někdy v budoucnosti JS nahradit bajtkódem. Ale není to nic akutního. Tak se na tom beze spěchu pracuje, aby to někdy v budoucnosti bylo.

Mimochodem, teď si stěžujete, že JavaScript byl ušit horkou jehlou a chtělo by to nahradit ho něčím lepším. Jenže nahradit něco ve světě prohlížečů je strašně těžké – musíte počkat, až to začnou podporovat všechny prohlížeče, pak se to může začít používat, a pak zase musíte počkat, než se to staré přestane používat i na historických webech, abyste to staré mohl z prohlížeče odstranit. A vy byste chtěl, aby se s WebAssembly spěchalo, udělalo se tak, že se bude špatně používat, a za pár let se řešilo to samé, jako teď s JavaScriptem?

Tu je vsak veky rozdiel medzi skriptovacim jazykom a bytecodom (kde su prakticky len dva smery, ktoprymi sa moze uberat). Pricom mame velmi dobre piklady dobrych bytecodov aj s GC - Lua, java bytecod, C# bytecod...
Par schopnych inzinierov to daokaze dat za par mesiacov a nehcal by som dva roky na pripomienkovanie od komunity.

Navyse ak by na nom prtacovali co i len tyzden, tak horsie ako javascript to nebude :D

Tak problémy JS nejsou o tom, že by za týden nešlo vymyslet lepší jazyk (i díky zkušenostem s dřívějšími jazyky, což tehdy přeci jen nebylo). Ale o tom, že další vývoj musel zachovat kompatibilitu.

Ještě k tomu DOM: Díky WASM můžete na UI použít třeba C++ a Qt a žádný HTML DOM vás nezajímá. Plochu, kam budete kreslit, jednoduše roztáhnete přes celou stránku.

12. 8. 2022, 08:57 editováno autorem komentáře

Qt ve WASM jsem ještě neviděl, ale zní to dost hrůzostrašně :)

Pro mě na úrovni Qt ve Windows a na macOS. "Nativně" vypadá jen v Linuxu.