Vlákno názorů ke zprávičce Firefox zvažuje převzetí Flashe a čtečky PDF z Chromu od Franta Kučera - Co je špatného na použití nativního pluginu (např....

A proč se JavaScript nepoužívá i pro zobrazovače JPEG, PNG, GIF, SVG, WEBM…?

Přijde mi to jako hloupá móda posledních let – cpát všechno do JS. Asi nějaká mentální porucha, která se rozšířila mezi lidmi kolem webu.

Protože ty zobrazovače měla Mozilla dávno napsané ještě z doby, kdy to byl Netscape Navigator. A přidat do toho podporu WEBM bylo jednodušší, než psát nový zobrazovač v JS. Navíc u bitmapových formátů je ta implementace jednoduchá, jde jenom o dekódování těch bitmapových dat. PDF je mnohem složitější formát. SVG je zase součástí DOMu, takže potřebuje podporu v jádru prohlížeče.

Mně se to taky nelíbí, že se dnes všechno píše v „HTML“ a JavaScriptu, pro tenkého klienta se vybrala ta druhá nejhorší možná platforma. Sun a později Oracle dobrovolně vyklidili pole, přestože měli mnohem lepší technologii, takže teď holt tenké klienty píšeme v podivném skriptovacím jazyce, který se postupně ohýbá tak, aby připomínal zjednodušenou Javu (ještě pár verzí, a bude to opravdový JavaScript), a k zobrazení GUI se používá jazyk pro značkování dokumentů. Ale když chceš psát tenkého klienta, dneska prakticky jinou možnost nemáš.

Když se rozhodneš do prohlížeče, který má i své vlastní GUI postavené na JavaScriptu, integrovat PDF prohlížeč, a existuje PDF prohlížeč napsaný v JavaScriptu, je to ta nejjednodušší možná volba. Cokoli jiného by bylo daleko pracnější. Mozilla má bohužel od začátku nedostatek vývojářů, takže nemají čas hrát si ještě s PDF prohlížečem. Můžeme být rádi, že tu Mozilla pořád ještě je a že je schopná Chrome a Internet Exploreru konkurovat. Ale obávám se, že to s ní jde z kopce, a jestli jí odhození PDF.js pomůže zůstat o něco déle ve vzduchu, bude to jedině dobře. Protože jestli budeme mít jenom dva majoritní webové prohlížeče od Microsoftu a Googlu, tedy od největších webových firem, nebude to podle mne dobře. Je s podivem, že do Mozilly neinvestuje Amazon, protože ten se jednoho dne bude divit, až se probere a zjistí, že celý jeho byznys je závislý na Googlu a Microsoftu, jeho dvou největších konkurentech.

Já jsem nepsal o tom, jaký bych JavaScript chtěl mít, ale o tom, jak se vyvíjí. Podívejte se na EcmaScript 2015, 2016, na TypeScript…

Tou technologií Sunu a Oracle jsem myslel Java WebStart. Ta se spustí z prohlížeče a aplikace se stáhne zkompilovaná ze serveru.

Ad „Aha. Takže prohlížeč bude mít java dependency a bude tahat kompiláty. “

Prohlížeč z toho můžeš úplně vynechat – ono se to sice jmenuje WebStart, ale prohlížeč nepotřebuješ, můžeš mít normálně ikonu na ploše a spouštět to jako desktopovou aplikaci. Jen to má výhodu, že se to automaticky aktualizuješ, takže snadno dostaneš novou verzi ke všem zaměstnancům nebo zákazníkům a oni potřebují jen jedinou závislost – JRE.

Nicméně balíčkovací systémy (DEB/RPM/…) jsou stejně lepší, o tom žádná.

„Opravdovým JavaScriptem“ jsem myslel to, že to bude skriptovací jazyk podobný Javě. JavaScript má OOP od začátku, akorát že používá prototypovou dědičnost, které programátoři zvyklí na třídní dědičnost z Javy, C++, Cx, Pythonu nebo PHP nerozumí. Takže se přidá třídní dědičnost. Přidá se řízení přístupu (moduly a privátní přístup), pro lambda výrazy (které má JavaScript opět od začátku) se přidal stejný syntaktický cukr, jako přidala Java. TypeScript přidává typový systém. Ale nic moc z vyšších úrovní, možná tak generátory. Porád to zůstává takovým „objektovým assemblerem“, jako je Java.

Prohlížeč na Javě žádnou závislost nemá. Java WebStart funguje už mnoho let, a pokud máte nainstalovanou Javu, funguje vám to. Je to standardní způsob, jakým prohlížeč spouští programy pro obsah, který neumí sám zpracovat – před nástupem vestavěných pluginů pro PDF se takhle třeba zobrazovalo PDF v externím prohlížeči. A ne bylo to samozřejmě myšlené pro weby, ale pro aplikace, o kterých je řeč. Vykreslovat poštovního klienta, textový editor, tabulkový kalkulátor nebo účetní systém pomocí HTML a JavaScriptu je šílenost, napsat něco takového v Javě, C# nebo C++ a Qt by bylo mnohem přirozenější. A Java právě měla a má technologii WebStart, což je způsob, jak ty aplikace snadno a bezpečně (WebStart běží v sandboxu podobně jako prohlížeč, třeba pro zápis do souborového systému musí uživatel aplikaci explicitně udělit oprávnění) distribuovat na koncové počítače. Jenže Sun se na klientskou Javu vykašlal a s ní i na WebStart. Když se probudili a vytvořili JavaFX a začali opravovat WebStart, bylo už dost pozdě – navíc dali JavaFX do placu, nijak to nepodpořili a čekali, jestli se neprosadí sám. Což se samozřejmě nestalo, takže to (v tu chvíli už Oracle) zase zabalil, nechává JavaFX přežívat, ale nejeví žádnou snahu ho nějak rozvíjet nebo podporovat.

A vedle toho zatím ve světě webu vzniká Web Assembly, což je právě programovací jazyk pro VM běžící v prohlížeči, tedy přesně to, co má Sun/Oracle už spoustu let hotové, slušně vyladěné a existuje pro to obrovský ekosystém. Oracle má zřejmě pocit, že má Javu na serverech jistou, a vůbec nebere vážně varování v podobě Node.js, které velice slušně dostalo JavaScript i na servery – což se zdálo být nesmyslné vzhledem k povaze JavaScripu. Jenže psát klienta i server v jednom jazyce je velmi lákavé, a když je na straně klienta jediná možnost, musí se přizpůsobit server.

Java WebStart aplikace je také distribuována ze serveru a běží na klientovi. V tomhle je úplně stejná, jako JavaScript, akorát neběží ve virtuálním stroji JavaScriptu, ale v javovském virtuálním stroji, a není distribuovaná jako zdrojový soubor JavaScriptu, ale jako přeložený bajtkód. JavaScript nijak benevolentní není, když tam máte chybu, tak se prostě celý skript ignoruje. To je velká nevýhoda oproti kompilovaným jazykům, kde se už při kompilaci odhalí spousta chyb.

To, že je Java náročná na zdroje, není vlastností Javy, ale příslušné aplikace. Když budete mít stejnou aplikaci napsanou stejným stylem v JavaScriptu, bude na zdroje ještě mnohem náročnější.

Kvůli WebStartu není nutné nic přizpůsobovat, jak už jsem psal – pokud máte na počítači nainstalovanou Javu, můžete si tam dnes (a už před pěti nebo před deseti lety) Java WebStart aplikaci spustit. Přizpůsoboval jste snad všechno okolo?

Znovu připomínám, že se nebavíme o webech, ale o webových aplikacích.

Nevýhoda. Ano, výhoda bajtkódu je jasná. Podložené měřením to nemám, ale svým "zkušeným okem" to vidím tak, že běh něklika tisíc řádků kódu v JS ve JS VM Browseru je celkově rychlejší a méně náročné než stejný počet řádků bajtkódu Javy v JVM.
Nic vám nebrání posílat na klienta zdrojový kód Javy a překládat ho teprve tam. Když si myslíte, že čas kompilace je záporný…

Jenomže chybu v tvém JS odhalíš tím, že si to po sobě vyzkoušíš, nebo si napíšeš testy
Kompilátor odhalí chyby ve všech možných stavech programu, zkoušení nebo testy odhalí chyby jenom v tom, co jste vyzkoušel nebo otestoval. Na čím vyšší úrovni se chyba odhalí, tím je dražší, tím je náročnější ji opravit, a tím je pravděpodobnější, že se na ni vůbec nepřijde.

že to očetřuješ v kódu
Jak chcete v kódu ošetřit, že máte špatnou syntaxi a program se vůbec nespustí? Když uděláte překlep ve jméně proměnné, sice můžete ošetřit, že nedojde k vyhození výjimky, ale ten kód se stejně neprovede, takže je to ve výsledku stejně k ničemu.

Ovšem Java běží na JVM a už jenom to něco žere a už jenom tím vznikají nároky navíc.
Oproti javascriptové VM (třeba V8) jsou nároky JVM naopak nižší. Například proto, že javascriptová VM musí překládat kód ze zdrojového kódu, JVM dostává bajtkód, který je na zpracování mnohem efektivnější. Dále proto, že JVM může provádět spoustu optimalizací, protože má například údaje o typech. No a také proto, že JVM je tu déle, takže se na těch optimalizacích odvedlo podstatně víc práce.

Není nutno nic přizpůsobovat, kromě toho mít v PC Javu a kromě toho mít browser v kterém toto umí běžet.
Pro Java WebStart žádný prohlížeč nepotřebujete. Pro běh aplikací v Javě potřebujete Javu, pro běh aplikací ve webovém prohlížeči potřebujete webový prohlížeč? Vy v tom vidíte nějaký principiální rozdíl?

Ale to neznamená, že jdou tvořit jenom v Javě notabene že kvůli jedné takové WA musím mít v PC aktuální Javu když existuje tuna jiných webových technologií, ale uznávám že ty "jiné WA " nejsou pro javisty plnohodnotné a lidi co je píšou jsou "jenom kodéři" ( to poslouchám pořád ) a bez kompileru se asi jako chyby odhalovat nedá atd . . . ne to je jenom o tom, na co jsi zvyklý a jestli přijmeš to, jaký jazyk je . . .
Ono těch webových aplikací, které lidé běžně používají, je docela dost. A nejde o to, že by webové technologie byly nevhodné pro javisty, ony jsou jsou extrémně nevhodné pro tvorbu aplikací. Vždyť i tak základní věc, jako je vícevláknové zpracování, je teprve ve fázi návrhu. GUI se „vykresluje“ pomocí značkovacího jazyka pro formátování textů. To, že píšu webové aplikace pomocí jediné reálně dostupné technologie neznamená, že tu technologii nemůžu označit za extrémně nevhodnou, když taková je.

Když jsem zkoučel to Sublime Text - a to už není nějaký kalendářík, byl jsem překvapený jak jednoduché a výkoné to je
Což je ale dané jedině přebytkem výkonu dnešních počítačů. Představte si, jak výkonné by to bylo, kdyby to nebylo napsaná v něčem tak náročném na zdroje, jako je JavaScript a HTML.

Pro příště si odpusťte ty soudy, když o tom nic nevíte. „Ošetřit chybu“ znamená, že se program s tou chybou nějak vyrovná a v rámci možností pokračuje dál. V JScriptu (teď se můžete předvést, že víte o co jde) není povolena nadbytečná čárka za posledním prvkem pole. Když na takový kód Internet Explorer narazí, vypíše do konzole – pokud ji mám zapnutou – chybu syntaxe, a z příslušného skriptu neprovede ani čárku. Tomu já neříkám „ošetřit chybu“. Ano, dnes už JSLint a další existují a dá se tu spustit Gruntem nebo Gulpem nebo něčím jiným. Ovšem kde je ta výhoda oproti Javě? Ten kód se musí při vývoji rozparsovat a zkontrolovat, a pak se to zahodí a pošle se na klienta původní zdroják, aby ho mohl rozparsovat a zkontrolovat znova prohlížeč. Nějak mi uniká výhoda dělat znova něco, co už jednou bylo provedeno.

Ano, když se bavíme o rychlosti a využití zdrojů, je důležité i to, že příslušná JVM je lépe optimalizovaná a v průměru tedy provádí kód efektivněji. Váš osobní odhad je zcela mimo.

Když vlezete na web a kliknete na odkaz na soubor PDF, spustí webový prohlížeč a předá mu odkaz na ten PDF soubor (pokud nepoužíváte plugin pro PDF). Když kliknete na odkaz na Wordovský dokument, spustí webový prohlížeč Word a předá mu odkaz na ten soubor. A když kliknete na odkaz na WebStart aplikaci (JNLP soubor), spustí webový prohlížeč zavaděč Java WebStart a předá mu odkaz na ten JNLP soubor. Zavaděč WebStartu soubor stáhne, zjistí, jaká je vyžadovaná verze Javy, pokud není dostupná, vyřeší to s uživatelem, podívá se do cache, zda už aplikaci nemá staženou nebo neexistuje novější verze, stáhne potřebné aktualizace a aplikaci spustí.

Jak už jsem psal, díky obrovskému přebytku výkonu a úsilí, které se do webových technologií nacpalo, jsou dnes webové aplikace použitelné. Ale je to za cenu, že je jejich provádění extrémně neefektivní a jejich vývoj je zbytečně pracný. Vy tady oslavujete JSLint, že už je možné při vývoji zkontrolovat syntaktickou správnost JavaScriptového kódu. No hurá, ale Java tohle měla v roce 1995, C to mělo v roce 1972.

Notepad oproti Wordu taky nežere ani polovinu. Ale není to použitým programovacím jazykem, je to tím, že Notepad jaksi nemá některé funkce Wordu.

WebStart jsem vysvětlil výš v tomto komentáři, snad to stačí. je dost smutné, že dneska někteří vývojáři mají zkušenost jenom s webovými aplikacemi a považují ty rovnáky na vohejbáky za něco normálního. Je to podobné jako s IPv6, kdy někteří správci neznají nic jiného než IPv4+NAT a těžko se jim vysvětluje, ať postaví normální IP síť a NAT zahodí někam hodně daleko. Je pravda, že když člověk musí s takovými rovnáky na vohejbáky dnes a denně pracovat, musí sám sebe přesvědčit, že je to vlastně normální, jinak by se z toho zbláznil. Já jsem to taky bral jako sport a jako výzvu, že ten web v MSIE 5.0 prostě rozchodím, protože kdybych bral vážně, že prohlížeč zaktualizuje DOM a přepočítá hodnoty stylů, jak jsou vidět z JavaScriptu, ale zapomene výsledek nakreslit na obrazovku, prohodil bych počítač už druhý den oknem. (A teď jsem křivdil MSIE 5.0, protože tohle myslím dělala sedmička – sice se začala přibližovat standardům, například podporovala CSS position: fixed, akorát ten prvek občas zapomněla nakreslit).

Ad „Používám 3 aplikace na Javě a ruku na srdce, Java dokáže vyžrat zdoje jak tank bez mrknutí oka . . .“

Tohle nejde svádět na platformu/jazyk. I kdyby Java byla neefektivní (jako že většinou není – naopak), tak by spotřebovávala o nějaký násobek víc RAM nebo o nějaký násobek víc CPU. Ale když ti aplikace překročí všechny meze, vyžere RAM, tak že se začne swapovat nebo ji sestřelí OOM killer, nebo zatíží procesory a disky tak, že se počítač pomalu nedá používat, tak to není způsobeno jazykem/platformou, ale tím, jak špatně je program napsaný – a špatně se dá psát v libovolném jazyce.

To se mi spíš stává, že se mi zpomalí počítač a když začnu zkoumat, co se děje, tak zjistím, že CPU vytěžuje prohlížeč (a v něm samozřejmě běžící JavaScripty).

Ad „Když se rozhodneš do prohlížeče, který má i své vlastní GUI postavené na JavaScriptu, integrovat PDF prohlížeč, a existuje PDF prohlížeč napsaný v JavaScriptu, je to ta nejjednodušší možná volba. Cokoli jiného by bylo daleko pracnější.“

Kdysi jsem si integroval Okular do Firefoxu přes kpartsplugin – jen tak ve volném čase, jako jednotlivec, ne žádná firmy nebo organizace – tolik tedy k té pracnosti. PDF dokumenty se mi pak otevíraly v prohlížeči, ale používal se k tomu nativní program/knihovna, nevyžíralo to CPU nebo RAM.

To jsi ten Okular dokázal upravit tak, aby i se závislostmi měl 350 kB? Jistě že je snadné integrovat nějaký plugin z celé platformy, která je pro tu integraci připravena. Akorát by asi nikdo nebyl nadšen z toho, že velikost instalačky prohlížeče se zvětšila na trojnásobek kvůli distribuci celé platformy, ze které se použije jen PDF prohlížeč. A osekat to tak, aby se dal použít jenom samotný PDF prohlížeč – to by byla právě ta pracnost.

Myslím, že ti lidé, kteří dělají na těch experimentech, nejsou ti samí, kteří mohou dělat na jádru prohlížeče. Nedostatek vývojářů asi proto, že na větší počet vývojářů by ty „slušné příjmy“ musely být ještě větší. Mimochodem, já za takový zbytečný experiment považuju i Firefox pro Android – což je asi důvod, proč se ty experimenty dělají, protože když je vyjmenujete, vždy se najde někdo, kdo daný experiment bude považovat za užitečný.

To ty sám?
No pěkně.