Servo Engine už umí renderovat HTML tabulky vícevláknově

Není to tak jednoduché. Apple dává do WebKitu věci, které ostatní jen z části kopírují. Safari má prostě jiné cíle, např větší výkon (JS engine je provázaný s HTML enginem) a menší spotřebu (větší výdrž na baterii - zrovna Firefox byl ve spotřebě na macOS dost problém donedávna). "Frikulínské" technologie ho netankují, protože na tvorbu aplikací má macOS/iOS bohatá SDK.

Lidi zapomínají, že HTML byly původně formátované dokumenty, s lehkou interaktivitou (např rozbalení kapitoly). Nema to být náhrada Javy, .NET a podobných jazyků, kde jeden bajtkód jede všude.

EDIT: Já např používal ve svých dobách IE, protože oproti FF mělo rychlejší parser HTML (statické stránky načítal rychleji), menší spotřebu RAM, plynulejší videa na YouTube (pluginy se kreslily odděleně od prohlížeče - proto vše překrývaly, i když IE 9+ to pak dokázal obejít) a ve firemním systému FF leakoval paměť.

2. 8. 2024, 14:26 editováno autorem komentáře

Jenže ty „frikulínské“ technologie třeba znamenají, že se něco dá udělat pomocí CSS, a webový prohlížeč to může optimalizovat a počítat na grafické kartě. Jenže Safari to nepodporuje, tak se to na Safari počítá JavaScriptem v hlavním vlákně. Takže to má ve výsledku menší výkon a větší spotřebu.

Pokud se někdo chce podívat na nějaký web, nebo chce jednorázově použít aplikaci, nebude si kvůli tomu instalovat nativní aplikaci. Ty důvody Applu jsou v posledních letech už jenom výmluva, proč do Safari investuje málo. A vzhledem k tomu, že teď musel iOS otevřít i pro jiná jádra prohlížečů, bude muset do Safari buď pořádně investovat, aby ten skluz dohnal, nebo mu reálně hrozí, že ho Chrome převálcuje. Protože to vývojáře webových aplikací prostě přestane bavit řešit všechny ty výjimky pro Safari, dají uživatelům Safari nějakou lite verzi s lištou, že pokud chtějí použít plnohodnotnou aplikaci, ať si nainstalují Chrome.

Webové prohlížeče už dávno nejsou jen zobrazovače HTML, píší se pro ně webové aplikace. Že ten základ v podobě HTML a CSS není pro psaní aplikací zrovna ideální je pravda, ale dnes už se s tím nedá nic dělat.

Jestli nějaký prohlížeč převálcuje Safari, nezávisí na vývojářích ale na uživatelích. A spousta z nich preferuje Safari před Chrome z důvodů, které jsem jmenoval. Mimoto na Chrome je už spousta lidí alergická. A ostatní prohlížeče nemají ten silný marketing, takže se síly tříští.

Zrovna Safari je z pohledu uživatelů nejvíc optimalizovaný, protože má nejdelší výdrž na baterii. Nejde o jednotlivosti, jestli nějaká nová věc v CSS jde lépe akcelerovat přes GPU.

A co se týče webových aplikací, dnes už málokdo programuje lowlevel. Třeba takový industry standard React pokrývá 2 miliardy uživatelů Facebooku a je primárním frameworkem nejen v 1,5miliardové Indii. Málokdo dnes píše aplikace jen pro jednu platformu a s embedovanou web app jsou problémy nejen na iOS, ale i v Androidu. A nakonec on i ten Safari na macOS/iOS umí WebAssembly, takže máš plnou volnost v programovacích jazycích a technologiích. Ty jeden "nedá se s tím nic dělat" ;-)

Uživatelé Safari používají, protože jim nic jiného nezbývá a vývojáři webů ho pořád ještě podporují.

Máte v tom dost zmatek. React pořád používá JavaScript, WebAssembly je také jenom alternativa k JavaScriptu. Cokoli psané v Reactu, Vue, Svelte a dalších nebo cokoliv ve WebAssembly jsou webové aplikace – tedy přesně to, proti čemu jste se vymezoval, když jste tvrdil, webové prohlížeče sloužily původně k zobrazování dokumentů ve značkovacích jazycích.

> Uživatelé Safari používají, protože jim nic jiného nezbývá a vývojáři webů ho pořád ještě podporují.

Nepletete si macOS s iOS? A i tam to pro nás za chvíli nebude platit.

> Máte v tom dost zmatek. React pořád používá JavaScript

"React uses an HTML-in-JavaScript syntax called JSX (JavaScript and XML). Familiarity with both HTML and JavaScript will help you to learn JSX, and better identify whether bugs in your application are related to JavaScript or to the more specific domain of React."
[https://www.google.com/search?q=does+react+uses+javascript%3F]

Je to i kvůli mobilům, že tam jsou problémy s web jádrem, takže kompiluje do nativního kódu. Tím pádem jejich "JS" je subset skutečného.

> WebAssembly je také jenom alternativa k JavaScriptu.

Alternativa, díky které místo JS můžu psát C/C++/Rust/C#/Ja­va/Python/...

> Cokoli psané v Reactu, Vue, Svelte a dalších nebo cokoliv ve WebAssembly jsou webové aplikace – tedy přesně to, proti čemu jste se vymezoval, když jste tvrdil, webové prohlížeče sloužily původně k zobrazování dokumentů ve značkovacích jazycích.

Asi tak webové aplikace jako byl Flash a Java v prohlížeči, které jste si mimochodem mohl stáhnout na disk a spustit bez toho web prohlížeče. Jak jsem již připomněl, nejlépe to bylo vidět v IE, kde pluginy jely "nad" prohlížečem a všechno z něj zakryly (IE 9 přidal feature, že do pluginu poslal obraz stránky pod pluginem a masku, kam kliknutí má plugin poslat do stránky - tím emuloval chování, že je plugin integrován).

Nepletete si macOS s iOS? A i tam to pro nás za chvíli nebude platit.
Nepletu, na iOS nic jiného než jádro Safari používat nešlo. Teprve teď se to po zásahu EU mění.

O Reactu si toho asi budete muset přečíst víc. Nebo si aspoň všimnout těch slov „JavaScript“ v textu, který jste citoval.

Alternativa, díky které místo JS můžu psát C/C++/Rust/C#/Ja­va/Python/...
Jenomže těmi různými jazyky pořád jen ovládáte ta samá API prohlížeče, která ovládáte i z JavaScriptu. Respektive ani to není u velké části API pravda, ve skutečnosti z WebAssembly voláte JavaScript, kterým teprve ovládáte ta webová API.

Asi tak webové aplikace jako byl Flash a Java v prohlížeči
Nikoli, Flash nebo Java byly pluginy, které spustily samostatný kód, který akorát umožňoval kreslit do obdélníku na webové stránce. Java Applety umožňovaly i manipulovat s DOMem, ale to se používalo minimálně. Zda to uměl i Flash nevím. To, co se píše dnes pomocí HTML+, CSS a JavaScriptu, jsou webové aplikace, tedy kód interpretovaný přímo prohlížečem a manipulující přímo s DOMem stránky.

Původně jsem chápal diskuzi o desktopových prohlížečích, protože na mobilech nic jiného než Chrome a Safari není a ani nebylo, takže není moc co diskutovat. Ale budiž: I na tom iOS máte Chrome a Firefox, akorát jádro je ze Safari. Díky tomu máte po ruce své záložky, hesla a případně i doplňky (nicméně Chrome je ten jediný prohlížeč na světě, který je zakazuje, ne Safari/iOS).. Málokdo si v posledních letech vybíral prohlížeč podle jádra, protože buď to byl WebKit/Blink, nebo Gecko, které musí emulovat Blink, jinak na tom weby "optimalizované pro Chrome" nepojedou. No a teď budete mít i to jádro...

> O Reactu si toho asi budete muset přečíst víc. Nebo si aspoň všimnout těch slov „JavaScript“ v textu, který jste citoval.

Nestačí si přečíst, co jsem již citoval? Pokud chcete mít web app skutečný HTML + JS na mobilu, tak použijete např. Cordova. React má vlastní subset HTML a JS, který kompiluje do nativní app, aby na mobilu nepoužíval webový engine:

"React Native is all about building a true mobile app, while Cordova instead implements web technologies in a mobile solution."
https://www.google.com/search?q=Cordova+vs+reatc

> Jenomže těmi různými jazyky pořád jen ovládáte ta samá API prohlížeče, která ovládáte i z JavaScriptu. Respektive ani to není u velké části API pravda, ve skutečnosti z WebAssembly voláte JavaScript, kterým teprve ovládáte ta webová API.

Asi jako když nativní C/C++/Rust/Pyt­hon/... aplikace pro Android (NDK) má glue vrstvu v Javě...

> Nikoli, Flash nebo Java byly pluginy, které spustily samostatný kód, který akorát umožňoval kreslit do obdélníku na webové stránce. Java Applety umožňovaly i manipulovat s DOMem, ale to se používalo minimálně. Zda to uměl i Flash nevím. To, co se píše dnes pomocí HTML+, CSS a JavaScriptu, jsou webové aplikace, tedy kód interpretovaný přímo prohlížečem a manipulující přímo s DOMem stránky.

Neříkám, že všechny moderní frameworky kompilují do WebAssembly. Některé jsou tím HTML+JS způsobem, který popisujete. Ale pro ilustraci, že už neplatí "dnes už se s tím nedá nic dělat", jsem uvedl příklady těch, kde máte volnou ruku. WebAssembly je jen moderní podoba pluginů, aby to bylo nezávislé na architektuře CPU a běželo v sandboxu (pro pohodlnost v tom, který tam je už pro JS).

Bavíme se o vykreslovacích jádrech prohlížečů. Protože ta rozhodují o tom, jaké webové standardy jsou podporovány. Na iOS nebylo možné používat jiné jádro než WebKit.

Gecko Blink neemuluje. Prostě jen obě jádra podporují stejné standardy.

Ne, přečíst si úryvky z vyhledávání vám zjevně nestačí. React se nekompiluje do nativního kódu. React Native je něco jiného než React. Cordova neslouží pro vytváření webových aplikací, ale naopak pro vytváření nativních aplikací pomocí webových technologií.

Žádné moderní frameworky (React, Angular, Vue, Svelte) se nekompilují do WebAssembly. Při současném stavu WebAssembly by to nedávalo žádný smysl, protože většina kódu by stejně musela zůstat v JavaScriptu, akorát by tam byla velká režie při předávání dat mezi JavaScriptem a WebAssembly.

Moje „dnes už se s tím nedá nic dělat“ se vztahovalo k tomu, že dneska se prostě frontend aplikací v drtivé většině případů píše pro webové prohlížeče, které byly původně určené pro prohlížení dokumentům založených na jednoduchém značkování. S tím už nic nenaděláme, nejde změnit historii, aby se místo HTML5 používala pro frontend webových aplikací třeba Java.

A abyste se nemusel dál trápit čtením úryvků ve vyhledávání Google – já programuju webové aplikace přes dvacet let, React školím, takže vaše „znalosti“ získané před deseti minutami z úryvků ve vyhledávání Google mne nepřesvědčí.

> Bavíme se o vykreslovacích jádrech prohlížečů. Protože ta rozhodují o tom, jaké webové standardy jsou podporovány. Na iOS nebylo možné používat jiné jádro než WebKit.

Pro weby ale problémy nejsou, webové stránky zvládnou prohlížeče už desítky let. Problémy jsou s aplikacemi, a tam Apple prostě upředňostňuje ty nativní.

> Gecko Blink neemuluje. Prostě jen obě jádra podporují stejné standardy.

Musí i věci, co nejsou ve standardu definované ;-)

> Ne, přečíst si úryvky z vyhledávání vám zjevně nestačí. React se nekompiluje do nativního kódu. React Native je něco jiného než React.

A co se kouknout na GitHub a prokliknout z homepage do dokumentace? I React (bez Native) používá ten samý HTML-like JS-like subset pseudojazyk, např.:
https://react.dev/learn/describing-the-ui

Na webu generuje HTML+JS, jinde nativní app skrze React Native. To je ale v pozadí, od toho je programátor odfiltrován.

> Cordova neslouží pro vytváření webových aplikací, ale naopak pro vytváření nativních aplikací pomocí webových technologií.

Používá klasický webový engine.

> Žádné moderní frameworky (React, Angular, Vue, Svelte) se nekompilují do WebAssembly. Při současném stavu WebAssembly by to nedávalo žádný smysl, protože většina kódu by stejně musela zůstat v JavaScriptu, akorát by tam byla velká režie při předávání dat mezi JavaScriptem a WebAssembly.

Uvědomujete si, že jmenujete frameworky staré i 10 let? Za tu dobu jste možná nějaký vývoj prošvihl. Např frameworky od Microsoftu jedou na WebAssembly (NET Multi-platform App UI - .NET MAUI, Blazer, ...). Váš argument s režií bych přirovnal tomu, jak jsem jmenoval, jak fungují nativní (NDK) aplikace na Androidu. Ono i na tom iOS je třeba glue vrstva v ObjC nebo Swift.

> Moje „dnes už se s tím nedá nic dělat“ se vztahovalo k tomu, že dneska se prostě frontend aplikací v drtivé většině případů píše pro webové prohlížeče, které byly původně určené pro prohlížení dokumentům založených na jednoduchém značkování. S tím už nic nenaděláme, nejde změnit historii, aby se místo HTML5 používala pro frontend webových aplikací třeba Java.

Však na tom se shodneme. Proto Apple prosazuje nativní aplikace a vedle "old school" HTML+JS začaly prohlížeče podporovat WebAssembly, což je taková dohodnutá náhrada klasických pluginů + sandboxing pro bezpečnost.

A abyste se nemusel dál trápit čtením úryvků ve vyhledávání Google – já programuju webové aplikace přes dvacet let, různě školím, třeba tady v diskuzích na Rootu ;-), takže vaše „znalosti“ mne nepřesvědčí.

2. 8. 2024, 20:43 editováno autorem komentáře

Pro weby ale problémy nejsou, webové stránky zvládnou prohlížeče už desítky let. Problémy jsou s aplikacemi, a tam Apple prostě upředňostňuje ty nativní.
Ona hranice mezi stránkami a aplikacemi není pevná. Některé z těch nových standardů se hodí spíš pro stránky než aplikace – a Safari je stejně nepodporuje.

Apple upřednostňuje nativní aplikace, ale spousta zadavatelů aplikací upřednostňuje webové aplikace. Třeba proto, že pak jedna aplikace funguje na desktopech, Androidu a iOS (aspoň nějak).

Musí i věci, co nejsou ve standardu definované ;-)
Nikoli.

A co se kouknout na GitHub a prokliknout z homepage do dokumentace?
No tak si tu dokumentaci nastudujte a přestaňte tu psát ty bláboly.

Používá klasický webový engine.
Ano, webový engine zabalený do nativní aplikace.

Uvědomujete si, že jmenujete frameworky staré i 10 let? Za tu dobu jste možná nějaký vývoj prošvihl.
Jmenuji moderní webové frameworky, které se používají v roce 2024. Ostatně o Reactu jste začal psát vy.

Např frameworky od Microsoftu jedou na WebAssembly (NET Multi-platform App UI - .NET MAUI, Blazer, ...).
Nesmysl.

Však na tom se shodneme.
Pak nechápu, proč s tím polemizujete.

vedle "old school" HTML+JS začaly prohlížeče podporovat WebAssembly, což je taková dohodnutá náhrada klasických pluginů + sandboxing pro bezpečnost.
Ne, není. Vedle toho, co je React, zjevně potřebujete nastudovat i co je WebAssembly.

> Ona hranice mezi stránkami a aplikacemi není pevná. Některé z těch nových standardů se hodí spíš pro stránky než aplikace – a Safari je stejně nepodporuje.

Ty stránky musí fungovat i na ostatních a starších verzí prohlížečů, takže původní řešení stejně musí mít. Některé vychytávky se stejně ještě několikrát předělají, než budou ve verzi bez prefixu.

> Apple upřednostňuje nativní aplikace, ale spousta zadavatelů aplikací upřednostňuje webové aplikace. Třeba proto, že pak jedna aplikace funguje na desktopech, Androidu a iOS (aspoň nějak).

Proto jsou technologie, které pro web generuji HTML+JS a nativní kód pro mobily, některé pro obojí HTML+JS (s integrovaným webovým jádrem) a - to jsem vás musel dovzdělat - i takové, které i pro web generují "strojový" kód (WebAssembly bajtkód).

>> Musí i věci, co nejsou ve standardu definované ;-)
> Nikoli.

To jste se za 20 let nesetkal s odlišným chováním Chrome a Firefoxu a neukázalo se, že ve standardu to takto do detailu není definováno?

> No tak si tu dokumentaci nastudujte a přestaňte tu psát ty bláboly.

Takže to pojede, když ten ukázkový kód uložím jako .html a pustím v Chrome/FF?

> Jmenuji moderní webové frameworky, které se používají v roce 2024. Ostatně o Reactu jste začal psát vy.

Hned vedle ale píšete, že tyto staré frameworky chápají web browser stále jako trochu lepší prohlížeč formátovaných dokumentů s jednoduchým skriptováním.

>> Např frameworky od Microsoftu jedou na WebAssembly (NET Multi-platform App UI - .NET MAUI, Blazer, ...).
> Nesmysl.

Je tam vyložene ikona během načítání WebAssembly, jako znáte při spouštění např. aplikací na mobilu ;-) Mimoto on ani neexistuje žádný C#-->JS transpiler. Více např. zde: https://www.reddit.com/r/csharp/comments/l8zwqk/has_anyone_had_any_luck_with_a_c_to_javascript/

> Ne, není. Vedle toho, co je React, zjevně potřebujete nastudovat i co je WebAssembly.

Já vím, co je WebAssembly. Ale radši si poslechnu vaší verzi, když se nechytáte ani s bodem výše.

2. 8. 2024, 21:11 editováno autorem komentáře

Ty stránky musí fungovat i na ostatních a starších verzí prohlížečů, takže původní řešení stejně musí mít.
Nemusí.

Některé vychytávky se stejně ještě několikrát předělají, než budou ve verzi bez prefixu.
Já ale píšu o schválených standardech.

Proto jsou technologie, které pro web generuji HTML+JS a nativní kód pro mobily,
Žádná taková technologie se masivně nepoužívá.

o jsem vás musel dovzdělat
:-D

i takové, které i pro web generují "strojový" kód (WebAssembly bajtkód)
Vážně byste si nejdřív měl nastudovat, co je WebAssembly.

To jste se za 20 let nesetkal s odlišným chováním Chrome a Firefoxu a neukázalo se, že ve standardu to takto do detailu není definováno?
Setkal. Akorát že Gecko nic neemuluje.

Takže to pojede, když ten ukázkový kód uložím jako .html a pustím v Chrome/FF?
Když ten kód přeložíte JSX kompilátorem, dostanete JavaScript používající JavaScriptové knihovny (třeba React). Ovšem JSX je pouze syntaktický cukr, jenom jiný zápis volání JavaScriptových funkcí. A React sice používá JSX, ale není to nutné (můžete psát ručně to volání funkcí, akorát je to méně pohodlné, než JSX). A naopak JSX můžete používat bez Reactu.

Hned vedle ale píšete, že tyto staré frameworky
Já jsem o žádných starých frameworcích nepsal.

Je tam vyložene ikona během načítání WebAssembly, jako znáte při spouštění např. aplikací na mobilu ;-)
Teď už vám zbývá jen vyřešit, jak spouštění aplikací na mobilu souvisí s webovými stránkami.

chápají web browser stále jako trochu lepší prohlížeč formátovaných dokumentů s jednoduchým skriptováním.
To jsem nepsal. Ale prohlížeč pořád je zobrazovač dokumentů založených na značkovacích jazycích, stylovaných pomocí CSS a modifikovaných JavaScriptovým kódem. K tomu pak podporují prohlížeče (často až na Safari) různá další API, která lze volat z JavaScriptu.

Já vím, co je WebAssembly. Ale radši si poslechnu vaší verzi, když se nechytáte ani s bodem výše.
Nevíte.

Když se pro webové aplikace (frontend) píše kód v jiném jazyce, než JavaScript, musí se pak následně transpilovat do JavaScriptu. JavaScript ovšem není úplně ideální cílové platforma, ostatně javascriptové enginy v prohlížečích jej také aspoň částečně kompilují do bajtkódu. Proto vznikla myšlenka udělat něco jako univerzální javascriptový bajtkód přenositelný mezi prohlížeči. Takový assembler pro webové prohlížeče. Který ovšem nebude mít přístup k ničemu jinému, než k čemu má dnes přístup JavaScript.

WebAssembly je tedy standard pro virtuální stroj (pro spouštění bajtkódu, podobně jako třeba JVM nebo VM pro bajtkód Pythonu), který postupně definuje jednotlivé vrstvy VM, od jednotlivých instrukcí nahoru. Takový virtuální stroj může běžet v prohlížeči nebo i samostatně. Naposledy byla přidána vrstva automatické správy paměti, v prohlížečích je to implementováno pár měsíců. WebAssembly v prohlížečích ještě nemá přístup k žádným webovým API (takže ani k DOMu), veškerá webová API lze zatím z WebAssembly používat pouze voláním JavaScriptu, který teprve může volat ta webová API.

WebAssembly v prohlížečích nikdy nebude mít přístup k ničemu navíc oproti JavaScriptu. Pořád to bude bajtkód běžící v sandboxu prohlížeče, který s okolním světem bude komunikovat jenom prostřednictvím webových API, nebude volat libovolný nativní kód.

Proto se to nedá přirovnávat k pluginům v prohlížečích, jako byly Java Applety nebo Flash, což byl nativní kód spouštěný vedle prohlížeče, který mohl dělat naprosto cokoli.

>> Ty stránky musí fungovat i na ostatních a starších verzí prohlížečů, takže původní řešení stejně musí mít.
> Nemusí.

Osobní projekt nemusí, ale zákazník nebude mít radost.

> Já ale píšu o schválených standardech.
> Setkal. Akorát že Gecko nic neemuluje.

A o těch standardech jsem vám řekl, že někdy nejdou do takových detailů, aby nemusel Firefox upravit svoje chování podle majoritního Chrome kvůli nějakému webu. Emulovala i Opera a Edge a Firefoxu nic jiného nezbývá s 1% podílem.

>> Proto jsou technologie, které pro web generuji HTML+JS a nativní kód pro mobily,
> Žádná taková technologie se masivně nepoužívá.

https://www.google.com/search?q=react+native+is+web+engine+on+mobile+or+not
* Is React Native just a WebView?
"React Native WebView is a node package that introduces a WebView component that allows developers to display web content seamlessly within a React Native application. Earlier, the component was part of React Native, but now it's its package and is community-driven."

Takže se skutečně pro mobily kompiluje a webview (pro doplňující funkce) už ani není v základním balíku.

> Vážně byste si nejdřív měl nastudovat, co je WebAssembly.

Jak sjem psal předtím, rád porovnám svoji znalost s vaší.

> Když ten kód přeložíte JSX kompilátorem, dostanete JavaScript používající JavaScriptové knihovny (třeba React). Ovšem JSX je pouze syntaktický cukr, jenom jiný zápis volání JavaScriptových funkcí. A React sice používá JSX, ale není to nutné (můžete psát ručně to volání funkcí, akorát je to méně pohodlné, než JSX). A naopak JSX můžete používat bez Reactu.

Pro web přeloží do HTML+JS, pro mobily do nativní app (nepoužívá webové jádro - příslušná komponenta ani neni v základní instalaci, viz část odpovědi výše).

> Já jsem o žádných starých frameworcích nepsal.

React: 11 let, Angular: 7 let, Vue: 10 let, Svelte: 8 let.

> Teď už vám zbývá jen vyřešit, jak spouštění aplikací na mobilu souvisí s webovými stránkami.

Uvedl jsem pro srovnání z pohledu uživatele.

> To jsem nepsal. Ale prohlížeč pořád je zobrazovač dokumentů založených na značkovacích jazycích, stylovaných pomocí CSS a modifikovaných JavaScriptovým kódem. K tomu pak podporují prohlížeče (často až na Safari) různá další API, která lze volat z JavaScriptu.

+ WebAssembly, které nahrazuje klasické pluginy.

> (...) Proto vznikla myšlenka udělat něco jako univerzální javascriptový bajtkód přenositelný mezi prohlížeči. Takový assembler pro webové prohlížeče.

WebAssembly není JS bajtkód. A ani bajtkód Flashe, Javy, C#, ... Byl navržen od nuly ("from scratch"). Pro zajímavost, WebAssembly není nový ani z pohledu bajtkódu (kromě ActiveX spouštěly pluginy svůj bajtkód), ani z pohledu sandboxingu (NaCl pluginy v ChromeOS).

> Který ovšem nebude mít přístup k ničemu jinému, než k čemu má dnes přístup JavaScript.

Tzn. má přístup ke všemu, co JS.

> Naposledy byla přidána vrstva automatické správy paměti, v prohlížečích je to implementováno pár měsíců.

I bez podpory prohlížeče už předtím existovala rozpracovaná komunitní implementace a implementace Javy to vtipně (ale pomalu) obcházela alokováním porměnných vně, v JS glue vrstvě.

> WebAssembly v prohlížečích ještě nemá přístup k žádným webovým API (takže ani k DOMu), veškerá webová API lze zatím z WebAssembly používat pouze voláním JavaScriptu, který teprve může volat ta webová API.

To je ta glue vrstva. Stejně jako nativní aplikace pro Android a iOS musí volat API OS skrze primární jazyk(y). Nebo třeba .NET/Java/Python na desktopu.

> WebAssembly v prohlížečích nikdy nebude mít přístup k ničemu navíc oproti JavaScriptu.

A proč by měl? Jde o náhradu JS, pokud chci programovat frontend v nečem jiném než JS (glue vsrtva je v mnoha řešeních generovaná automaticky).

> který s okolním světem bude komunikovat jenom prostřednictvím webových API, nebude volat libovolný nativní kód.

Pro zajímavost, v rámci rozšíření prohlířeče (extenzí) může JS/WebAssembly volat nativní kód (nativní aplikace) vně prohlížeče.

> Proto se to nedá přirovnávat k pluginům v prohlížečích, jako byly Java Applety nebo Flash, což byl nativní kód spouštěný vedle prohlížeče, který mohl dělat naprosto cokoli.

Toho jsem se záměrně zbavili tím sandboxingem.

A o těch standardech jsem vám řekl, že někdy nejdou do takových detailů, aby nemusel Firefox upravit svoje chování podle majoritního Chrome kvůli nějakému webu. Emulovala i Opera a Edge a Firefoxu nic jiného nezbývá s 1% podílem.
Vaše ničím nepodložené spekulace o věcech, které jste „nastudoval“ před 10 minutami z Googlu, mne vážně nezajímají.

Takže se skutečně pro mobily kompiluje a webview (pro doplňující funkce) už ani není v základním balíku.
Už jsem vám vysvětloval, že React Native je něco úplně jiného, než „webový“ React.

React: 11 let, Angular: 7 let, Vue: 10 let, Svelte: 8 let.
Ty současné verze jsou podstatně jiné, než byly první verze. A pořád jsou to moderní webové frameworky, není nic novějšího, co by se široce používalo. Jen různé experimenty. Pokud si myslíte, že existuje něco modernějšího, napište co. (Jsem zvědav, co vygooglíte.)

WebAssembly, které nahrazuje klasické pluginy.
Nenahrazuje. WebAssembly bude moci v budoucnosti nahradit JavaScript.

A proč by měl? Jde o náhradu JS
Ještě o dva odstavce výš ve svém komentáři jste si myslel, že WebAssembly nahrazuje nativní pluginy prohlížeče. Fajn že jste si to mezi tím rozmyslel a pochopil jste, že WebAssembly nahrazuje Javascript, nic víc.

Ano, nahrazuje JS, abychom mohli programovat stejně jako dříve v těch pluginech. Tj. kód ve svém zvoleném jazyce. Mimochodem sandboxing byl i u toho Flashe a Javy, akorát děravý. A "široce používaný" jde často proti "moderní". Těžko jakákoli nová technologie v blízké době překoná např. ten dekádu starý React (ale ty ostatní vámi jmenované nejsou o moc mladší).

Ty pluginy byly normálně nativní kód, prohlížeč tam nedělal žádný sandboxing. To, že Java nebo Flash měly sandbox v sobě, je jenom „náhoda“. Jako plugin jste mohl mít jakýkoli nativní kód.

Ty pluginy se používaly právě pro možnost volat nativní kód, ne pro možnost psát v jiném jazyce kód volající v prohlížeči webová API (což je cíl WebAssembly).

I nové technologie, které třeba mohou mít ambice pro webové aplikace nahradit třeba React, jsou pořád buď JavaScriptové knihovny, nebo něco transpilovaného do JavaScriptu. Protože nic jiného dnes prohlížeče neumí.

Kdybych chtěl psát nativní kód a bez sandboxingu, tak nepoužiju ten Flash nebo Javu, ne? (Později ještě byl plugin pro C# engine Unity, pro zajímavost.) Ano, sandboxing nejprv dělaly ty runtimy sami, až později se přidal okolo nich i do prohlížeče (NaCl v ChromeOS). A nakonec se využil ten pro JS.

> I nové technologie, které třeba mohou mít ambice pro webové aplikace nahradit třeba React, jsou pořád buď JavaScriptové knihovny, nebo něco transpilovaného do JavaScriptu. Protože nic jiného dnes prohlížeče neumí.

Umí ještě ten WebAssembly ;-) Jak jsem psal výše, pro půlku těch podporovaných jazyků ani neexistuje (použitelný) transpiler.

Kdybych chtěl psát nativní kód a bez sandboxingu, tak nepoužiju ten Flash nebo Javu, ne?
Kdybyste chtěl psát nativní kód, tak napíšete plugin. Java nebo Flash se používaly proto, že je spousta lidí už měla v prohlížeči nainstalované. To ale neznamená, že by nebylo možné psát další pluginy.

až později se přidal okolo nich i do prohlížeče
Nepřidal. Kolem nativního kódu nemůžete udělat sandbox.

Umí ještě ten WebAssembly ;-)
Jenže WebAssembly zatím nemá přístup k webovým API.

Jak jsem psal výše, pro půlku těch podporovaných jazyků ani neexistuje (použitelný) transpiler.
Taky se v nich nepíše webový frontend.

WebAssembly má zatím (v prohlížečích) smysl v případě výpočetně náročných operací, nebo když už máte nějaký algoritmus implementovaný v jiném jazyce, nebo pro algoritmicky náročné věci, které mají úzkou vrstvu integrace s prohlížečem (třeba jen vykreslují do canvasu).

1. Tehdy nebyl problém, aby si člověk nainstaloval plugin (mohly být např. podepsané autoritou - pro méně důvěřivé). Lidi volili i podle jazyka a jeho možností (standardní knihovny daného pluginu).
2. Nastudujte si prosím, jak fungovaly pluginy v ChromeOS. Tam právě už byl sandboxing okolo nativních pluginů (když to beru z pohledu prohlížeče a OS - kód vývojáře byl sandboxovaným už tím pluginem).
EDIT: Ten sandboxing pak přidal Chrome i do desktopové verze. Byl použit jen pro interní plugin pro Flash a asi i ten pro PDF. Ne pro třetích stran.
3. Ne v takové míře jako v zajetých dekádu starých frameworcích. Ale umožňují to a funguje to všude (i iOS umí WebAssembly).
4. Naštěstí vy nerozhodujete, jestli a pro koho má WebAssembly smysl ;-)

2. 8. 2024, 23:15 editováno autorem komentáře

2. Nastudujte si prosím, jak fungovaly pluginy v ChromeOS. Tam právě už byl sandboxing okolo nativních pluginů (když to beru z pohledu prohlížeče a OS - kód vývojáře byl sandboxovaným už tím pluginem).
EDIT: Ten sandboxing pak přidal Chrome i do desktopové verze. Byl použit jen pro interní plugin pro Flash a asi i ten pro PDF. Ne pro třetích stran.
Příště si nemusíte sám sobě dávat pokyn „nastudujte si“, pak si to nastudovat a napsat, že teda po nastudování jste zjistil, že je to jinak, než jste si myslel.

Ne v takové míře jako v zajetých dekádu starých frameworcích. Ale umožňují to a funguje to všude (i iOS umí WebAssembly).
Akorát pořád potřebujete JavaScript jako most mezi WebAssembly a webovými API. Takže pro klasické webové aplikace, které hlavně manipulují s DOMem, byste stejně měl daleko víc kódu v JavaScriptu než ve WebAssembly.

Naštěstí vy nerozhodujete, jestli a pro koho má WebAssembly smysl ;-)
Nerozhoduju, ale na rozdíl od vás aspoň vím, co WebAssembly je.

Každopádně stále platí, že když prohlížeč nepodporuje nějaké webové API, WebAssembly vám nijak nepomůže. Teď proto, že nyní nepodporuje žádné webové API. A v budoucnosti proto, že bude logicky podporovat pořád jen ta webová API, která prohlížeč bude umět. WebAssembly nebude umožňovat nic jiného, než co jde napsat v JavaScriptu. Akorát to v jiných jazycích může jít napsat snáze nebo to může být efektivnější.

> Příště si nemusíte sám sobě dávat pokyn „nastudujte si“, pak si to nastudovat a napsat, že teda po nastudování jste zjistil, že je to jinak, než jste si myslel.

Ne? Sandboxing pluginů pak zkopíroval i Firefox. Security fixy např. na ten Flash přicházely až moc se zpožděním.

> Akorát pořád potřebujete JavaScript jako most mezi WebAssembly a webovými API. Takže pro klasické webové aplikace, které hlavně manipulují s DOMem, byste stejně měl daleko víc kódu v JavaScriptu než ve WebAssembly.

Tady asi došlo k tomu nedorozumění. Proč bych pracoval s celým HTML DOM, stačí mi jeden canvas.

> Každopádně stále platí, že když prohlížeč nepodporuje nějaké webové API, WebAssembly vám nijak nepomůže. Teď proto, že nyní nepodporuje žádné webové API. A v budoucnosti proto, že bude logicky podporovat pořád jen ta webová API, která prohlížeč bude umět. WebAssembly nebude umožňovat nic jiného, než co jde napsat v JavaScriptu. Akorát to v jiných jazycích může jít napsat snáze nebo to může být efektivnější.

Opět nedorozumění. Já nechci, aby WebAssembly uměl víc než JS. Já akorát chci psát ve svém oblíbeném jazyce a ne v JS. Čímž se dostávám k tomu, jestlo to "jinak nejde" ;-)

2. 8. 2024, 23:39 editováno autorem komentáře

Proč bych pracoval s celým HTML DOM, stačí mi jeden canvas.
To jsem psal o několik komentářů výše.

Já nechci, aby WebAssembly uměl víc než JS.
Pak vám ale WebAssembly nijak nepomůže, když nějaký prohlížeč (třeba Safari) nějaké API nepodporuje.

Tím se vracíme na začátek: K čemu mi je chybějící např. vlastnost v CSS, když přes WebAssembly si kreslím všechno po svém, ve svém oblíbeném jazyce (už nejsme povinni používat JS).

Jo, z toho budou všichni nadšení, když si pro vykreslení nějaké prezentační webové stránky naimplementujete kompletně vlastní vykreslovací engine, pomocí kterého celou stránku vyrenderujete do canvasu, jenom abyste obešel chybějící podporu třeba @scroll-timeline v Safari. A určitě to uděláte tak, aby s tím fungovaly hlasové čtečky nebo aby to vyhledávače dobře zaindexovaly.

A pak jste jaksi zapomněl na to, že webová API nejsou zdaleka jenom o vykreslování. Takže až budete potřebovat použít třeba Image Capture API, WebTransport, nebo budete chtít použít zstd kompresi, budete mít stejně se Safari i s WebAssembly smůlu.

Tak zrovna ten @scroll-timeline je "červeně" i pro Firefox, takže bych neházel špínu jen na Safari. Naštěstí weby nečekaly roky, místo toho si to implementovaly samy ručně u dávno.

Když si nakreslím vlastní textbox, tak samozřejmě nedostane automaticky funkčnost nativního. Pokud tedy nechci z WASM generovat HTML DOM, ale kreslit vlastní UI, je třeba implementovat API pro ty screen readers: "The trick is to build a parallel accessibility tree annotated with ARIA attributes." Umí to vedle Flutteru třeba i WebGL renderer PixiJS:

"Accessibility
PixiJS is an inclusive technology and all content can be made to be screen reader accessible with ease. The only WebGL renderer out there that does."

Indexování vyhledávači už musíme rešt dávno i v klasických HTML+JS webových aplikacích.

A na Capture API, WebTransport apod. je ta glue vrstva JS (stejně jako je glue vrstva na nativní API v iOS, Android, .NET, Java, Python apod.).

3. 8. 2024, 00:41 editováno autorem komentáře

Jenže Safari těch webových API implementuje zdaleka nejméně. Ano, weby si to implementují po svém – jenže daleko méně efektivně, než to může dělat prohlížeč. Takže až to bude podporovat Chrome, budou pro něj stránky používat nativní implementaci, zatímco pro Safari implementaci v JavaScriptu, která nebude tak plynulá a bude mát větší spotřebu baterky. To je to, čeho chce APple dosáhnout?

Stejně tak s tím kreslením do canvasu. Implementujete si vlastní vykreslovací engine, který bude z WASM přes JS kreslit do cnvasu. Nebo si možná rovnou přeložíte do WASM Servo. Takže to bude daleko méně výkonné a bude to žrát více baterku. To je cíl Apple?

Indexování vyhledávači už musíme rešt dávno i v klasických HTML+JS webových aplikacích.
Kde to ovšem řešení má. Ale nevšiml jsem si, že by vyhledávače uměly OCRkovat text vykreslený do canvasu.

A na Capture API, WebTransport apod. je ta glue vrstva JS
Jo, jenže právě nejdřív musí ta API podporovat prohlížeč. A Safari je nepodporuje. Jako mnoho dalších API.

Jenže Apple má rychlý i ten JavaScript. Vždyť on si dělá i vlastní procesory, včetně instrukcí pro jeho akceleraci. Naproti tomu, i kdyby Chrome měl všechno super duper akcelerované na GPU, tak to zmrší celkovým fungováním toho prohlížeče, aneb premature optimization:
https://www.reddit.com/r/MacOS/comments/17iz63z/safari_battery_life_vs_chrome_after_recent/

A zase argmentujete nepoužívanými API, které nemá ani Firefox a samozřejmě žádný mobilní prohlížeč?

PS: Indexování je ze všech těchto problémů to nejjednodušší. Prostě hlavní údaje vypíšete i do hlavičky a HTML DOM. U klasických HTML+JS aplikací sice Google podporuje JS pro čtení generovaného obsahu, ale 1) je to ořezaný JS engine, takže stejně musíte podporovat i "staré prohlížeče", a 2) podle mě nečeká dýl něž nějaký krátký timeout (některé aplikace se inicializují i několik sekund).

EDIT:
> Ale nevšiml jsem si, že by vyhledávače uměly OCRkovat text vykreslený do canvasu.

Zrovna tohle dokáže AI rychleji a s méně spotřebovanou energií než analyzovat čím dál komplexnější HTML DOM a spouštění čím dál složitějších skriptů. Prostě udělá screenshot výsledku a OCR. Možná bude dřív, než si myslíme.

3. 8. 2024, 13:50 editováno autorem komentáře

To je úplně jedno, zda má rychlý JavaScript, když se to bude počítat na CPU a v hlavním vlákně vykreslovat do canvasu.

Image Capture API má Firefox za konfigurační volbou, takže se dá očekávat, že to v dohledné době bude dostupné pro všechny. Má to Chrome pro Android, a tedy všechny mobilní prohlížeče založené na Blinku.

Web Transport má desktopový i mobilní Chrome, má ho desktopový Firefox, nemá ho samozřejmě Safari a mobilní Firefox (který ovšem nikoho nezajímá).

zstd má i ten mobilní Firefox, Safari ho – jak nečekané – nemá.

I kdyby ten JavaScript byl rychlejší než zpackaná akcelerace na GPU? Vždyť Chrome na Windows má nejpomalejší vykreslování ze všech prohlížečů.

Aha, takže ve Firefoxu vypnuté a Chrome pro Android to dostal až v poslední verzi. Takže bude trvat měsíce, než to probublá do ostatních prohlížečů.

zstd je jen jeden z dalších algoritmů komprese. Ještě řekněte, že Safari žádný nemá. Mimoto opět půlka prohlížečů na mobilech to neumí, kde to přitom má největší význam (placená data). Navíc uživatel Apple není socka a pár MB navíc nemá problém zaplatit.

Stejně tak bych mohl já vypíchávat funkce, které má Safari a Chrome ne. Umí např Chrome na desktopu obarvit vršek UI podle toho, jak definuje webová stránka? Protože např to (estetika) a delší výdrž na baterii uživatel vidí. Naopak k čemu mu je nějaká nová funkce pro webové aplikace, když ten uživatel nečekal a už 10 let na to používá dedikovanou aplikaci?

Jenže JavaScript není rychlejší než akcelerace na GPU.

Ano, za několik měsíců to budou podporovat všechny důležité prohlížeče, s výjimkou Safari.

zstd dokáže komprimovat více. Nejde o placení MB, ale o to, že to zase šetří baterku.Pořád tu píšete o šetření baterky, a pak se ukazuje, že Safari neumí jeden standard za druhým, které dokáží baterku šetřit.

U aplikací umí desktopový Chrome obarvit prostředí prohlížeče podle aplikace. U webů to nedává smysl, protože uživatel v Chrome obvykle používá záložky, takže má v jednom prohlížeči otevřeno více webů.

Podstatné je to, že těch API, které nepodporuje Safari, je podstatně víc – a pořád přibývají další. Apple prostě vývoj Safari nestíhá.

Nová funkce pro webové aplikace je proto, že to pak může používat každý web a každá webová aplikace, uživatel si nemusí kvůli jedné funkci instalovat novou aplikaci, když ani neví, že nějaká taková aplikace existuje. Po uživatele je to zkrátka mnohem pohodlnější, prostě používá webovou aplikaci a v ní má dostupné všechny funkce, které potřebuje.

> Jenže JavaScript není rychlejší než akcelerace na GPU.

Záleží na kvalitě implementace. Jak píšu, Apple navrhl svůj CPU tak, že výkon v JavaScriptu byla jedna z priorit.

> Ano, za několik měsíců to budou podporovat všechny důležité prohlížeče, s výjimkou Safari.

To dopředu nevíme. Pokud bude technologie užitečná, taky ji implementuje. Zatím ji stejně žádný web / webová aplikace nepoužívá.

> zstd dokáže komprimovat více. Nejde o placení MB, ale o to, že to zase šetří baterku.Pořád tu píšete o šetření baterky, a pak se ukazuje, že Safari neumí jeden standard za druhým, které dokáží baterku šetřit.

Samozřejmě že dokáže komprimovat více, jinak by neměl smysl. A výkon na baterii má Safari zatím stále nejlepší. Jak jsem psal předtím, premature optimization. Implementovat to má smysl - bavíme-li se o výdrže na baterii - až to bude podporované v HW (a tam je dost dlouhá doba mezi návrhem a zařízením v krámě).

> U aplikací umí desktopový Chrome obarvit prostředí prohlížeče podle aplikace. U webů to nedává smysl, protože uživatel v Chrome obvykle používá záložky, takže má v jednom prohlížeči otevřeno více webů.

Pro vás nedává smysl víc věcí, že?

> Podstatné je to, že těch API, které nepodporuje Safari, je podstatně víc – a pořád přibývají další. Apple prostě vývoj Safari nestíhá.

Většina lidí, ale i vývojářů, už přestala tohle porovnávání pindíků sledovat. Dokázal by dnešní průměrný webový vývojář vyjmenovat aspoň 3 konformační testy porovnávající funkcionalitu prohlížečů?

> Nová funkce pro webové aplikace je proto, že to pak může používat každý web a každá webová aplikace,

Může, ale nemusí. Často jde jen o to generovat činnost, a v případě Chrome ukázat "hle, v tomhle je náš prohlížeč lepší" (přitom to doteď nikdo nepotřeboval).

> uživatel si nemusí kvůli jedné funkci instalovat novou aplikaci

Ale musí, když to doteď v prohlížeči nešlo. A bude nějakou dobu trvat, než webové řešení dosáhnou feature parity se stávajícími aplikacemi.

> Po uživatele je to zkrátka mnohem pohodlnější, prostě používá webovou aplikaci a v ní má dostupné všechny funkce, které potřebuje.

Jedna webová aplikace vládne všem? Mimoto některé features jsou dostupné jen pro nativní aplikace - i v případě Chrome. Schválně sledujte, jaké další features v dalších letech přidá ("Bože, to me nenapadlo, že tohle potřebuju ve webovém prohlížeči.", "Jak jsem mohl doteď fungovat.", ...).

To dopředu nevíme. Pokud bude technologie užitečná, taky ji implementuje. Zatím ji stejně žádný web / webová aplikace nepoužívá.
Víme to ze zkušenosti. Safari spoustu užitečných věcí neimplementuje.

Spousta přednášek či článků o nových webových technologiích končí větou, že to Safari (samozřejmě) nepodporuje. Úplně stejnou větou, která se dříve psala o Internet Exploreru.Vývojáři to nemusí nijak zvlášť sledovat, protože toho si nelze nevšimnout, že pokud je s něčím problém, obvykle je někde poblíž Safari.

Do Chrome se implementují věci, po kterých je poptávka. To, že jste to nepotřeboval vy, neznamená, že to nepotřebuje nikdo.

Když něco do teď v prohlížeči nešlo, neznamená to, že si kvůli tomu uživatel instaloval aplikaci. Třeba nešlo převzít autentizační kód z SMS. Uživatel si kvůli tomu neinstaloval aplikaci – prostě ten kód do prohlížeče opsal. Je chyba, když se to uživatelům usnadnilo?

Nepsal jsem o žádné jedné aplikaci vládnoucí všem. Ale různé webové aplikace mohou využívat různé služby, různá API. Třeba e-shopu se bude hodit, když přes jeho web budete moci zaplatit, když vám bude moci poslat notifikaci, když budete moci naskenovat 1D/2D kód, když s ním dokážete otevřít výdejní schránku. To ale neznamená, že chci mít naistalovanou aplikaci každého e-shopu, kde jsem něco nakoupil. A neznamená to, že chci používat web eshopu, pak z něj odejít, nainstalovat si aplikaci pro čtení 1D/2D kódů, načíst jí kód, zkopírovat ho do webu e-shopu. Uživatelsky daleko přívětivější je, když to udělám rovnou z toho webu.

Mimoto některé features jsou dostupné jen pro nativní aplikace - i v případě Chrome.
Ta věta nedává moc smysl, že? Asi jste chtěl napsat, že některé vlastnost/funkce počítačů, telefonů či operačních systémů nejsou dostupné pro webové aplikace ani v Chromu. To je pravda. Ale postupně se do webových standardů přidávají další a další možnosti. Dříve třeba nebylo možné z webu zjišťovat souřadnice (GPS), nebylo možné reagovat na systémové téma (světlé/tmavé), nebylo možné používat drag-and-drop… Samé neužitečné věci, že?

> Safari spoustu užitečných věcí neimplementuje.

Užitečné pro koho?

> Spousta přednášek či článků o nových webových technologiích končí větou, že to Safari (samozřejmě) nepodporuje. Úplně stejnou větou, která se dříve psala o Internet Exploreru.Vývojáři to nemusí nijak zvlášť sledovat, protože toho si nelze nevšimnout, že pokud je s něčím problém, obvykle je někde poblíž Safari.

Stačilo pochopit release cycle Safari a IE.

> Do Chrome se implementují věci, po kterých je poptávka. To, že jste to nepotřeboval vy, neznamená, že to nepotřebuje nikdo.

Nevím o nikom, kdo ty funkce chtěl.

> Když něco do teď v prohlížeči nešlo, neznamená to, že si kvůli tomu uživatel instaloval aplikaci. Třeba nešlo převzít autentizační kód z SMS. Uživatel si kvůli tomu neinstaloval aplikaci – prostě ten kód do prohlížeče opsal. Je chyba, když se to uživatelům usnadnilo?

Tak jasně, že doteď nemusel používat aplikaci. Ale je chyba, že to aplikace uživatelům usnadnila?

> Třeba e-shopu se bude hodit, když přes jeho web budete moci zaplatit, když vám bude moci poslat notifikaci, když budete moci naskenovat 1D/2D kód, ...

Ani váš milovaný Chrome neumí skenovat kódy. A placení a notifikace umí i Safari.

> postupně se do webových standardů přidávají další a další možnosti.

A to mám do té doby čekat, až to bude umět aspoň Chrome?

> Dříve třeba nebylo možné z webu zjišťovat souřadnice (GPS), nebylo možné reagovat na systémové téma (světlé/tmavé), nebylo možné používat drag-and-drop… Samé neužitečné věci, že?

Hezký exkurz do historie. To vše Safari samozřejmě umí.

Užitečné pro koho?
Pro uživatele.

Stačilo pochopit release cycle Safari a IE.
To s tím vůbec nesouvisí.

Nevím o nikom, kdo ty funkce chtěl.
Což není nijak překvapivé, když se v tomto oboru nepohybujete.

Ale je chyba, že to aplikace uživatelům usnadnila?
A je chyba, když je ta aplikace webová?

Ani váš milovaný Chrome neumí skenovat kódy.
Na MacOS a ChromeOS umí. Podstatou sdělení ale bylo to, že je to další API, které podle vás nikdo nechce a uživatelé to mají řešit přes externí aplikace.

A placení a notifikace umí i Safari.
Ale jak dlouho to trvalo.

A to mám do té doby čekat, až to bude umět aspoň Chrome?
Klidně může být Safari tím prvním, kdo to naimplementuje. Každopádně pokud jde o komunikaci s něčím mimo prohlížeč, tak vám nic jiného, než počkat, až prohlížeče to API naimplementují, nezbývá.

To vše Safari samozřejmě umí.
Nejde o to, že to Safari umí. Jde o to, že jsou to další API, která prohlížeče postupně implementovaly. Ale podle vás to jsou funkce, které nikdo nechtěl, a Chrome to implementoval čistě aby mohl generovat činnost.

> Pro uživatele.

Pro jaké uživatele?

> To s tím vůbec nesouvisí.

Fakt ne?

> Což není nijak překvapivé, když se v tomto oboru nepohybujete.

Jenom se živím webovými aplikacemi 20 let. Samozřejmě spousta výpočtů i na frontendu.

> A je chyba, když je ta aplikace webová?

Doteď nemohla být.

> Na MacOS a ChromeOS umí. Podstatou sdělení ale bylo to, že je to další API, které podle vás nikdo nechce a uživatelé to mají řešit přes externí aplikace.

Takže na nejrozšířenějších OS - Windows a Android - ne?

> Ale jak dlouho to trvalo.

Bylo to tam včas pro jejich uživatele. Apple je známý tím, že technologie implementuje, až když jsou odladěné.

> Klidně může být Safari tím prvním, kdo to naimplementuje. Každopádně pokud jde o komunikaci s něčím mimo prohlížeč, tak vám nic jiného, než počkat, až prohlížeče to API naimplementují, nezbývá.

A nebo ty pro vás nenáviděné nativní aplikace ;-) (jen doplním, skrze extenze jde volat externí nativní aplikaci i v tom prohlížeči).

> Nejde o to, že to Safari umí. Jde o to, že jsou to další API, která prohlížeče postupně implementovaly. Ale podle vás to jsou funkce, které nikdo nechtěl, a Chrome to implementoval čistě aby mohl generovat činnost.

Viz výše v tomto komentáři. Apple vždy počká, až je jasné, že technologie má smysl. Nezapomeňte, jaký problém by pak bylo udržovat technologii, kterou nakonec nikdo nepoužívá, nebo ji odstranit a breaknout některé aplikace.

Jenom se živím webovými aplikacemi 20 let. Samozřejmě spousta výpočtů i na frontendu.
To, že se živíte něčím podobným, neznamená, že víte dobře, co se děje v sousedních oborech. To vaše googlení Reactu bylo dostatečně výmluvné.

Doteď nemohla být.
To je důvod, proč to nemá být ve webové aplikaci nikdy?

Takže na nejrozšířenějších OS - Windows a Android - ne?
Zatím ne.

Bylo to tam včas pro jejich uživatele.
Oni jsou jejich uživatelé nějak zpomalení?

Apple je známý tím, že technologie implementuje, až když jsou odladěné.
Aha, a několik dalších let od odladění do implementace čeká proč?

A nebude to podobné, jako když jste tvrdil, že Apple dbá na výkon a výdrž na baterii, a pak doporučujete vykreslovat celou stránku do canvasu nebo stahovat z internetu větší objem dat?

A nebo ty pro vás nenáviděné nativní aplikace ;-) (jen doplním, skrze extenze jde volat externí nativní aplikaci i v tom prohlížeči).
Nativní aplikace ovšem neběží ve webovém prohlížeči. Uživatelé si neradi k webu instalují ještě nějakou další aplikaci, aby web mohli používat. Napadá vás vůbec nějaká běžně užívaná webová stránka, která by závisela na doinstalování nativní aplikace? Navíc ty nativní aplikace pak musíte mít pro každou platformu zvlášť.

Apple vždy počká, až je jasné, že technologie má smysl.
Jo, a pak počká ještě několik let.

Nezapomeňte, jaký problém by pak bylo udržovat technologii, kterou nakonec nikdo nepoužívá, nebo ji odstranit a breaknout některé aplikace.
Je zvláštní, že Blink nebo Gecko takový problém nemají.

> To, že se živíte něčím podobným, neznamená, že víte dobře, co se děje v sousedních oborech. To vaše googlení Reactu bylo dostatečně výmluvné.

A ta vaše neznalost WebAssembly taktéž.

> To je důvod, proč to nemá být ve webové aplikaci nikdy?

Google si tam může přidat, co chce. Ale nemůže nutit ostatní, to by byla totalita.

> Oni jsou jejich uživatelé nějak zpomalení?

Je to jiný ekosystém.

> Aha, a několik dalších let od odladění do implementace čeká proč?
> Jo, a pak počká ještě několik let.

Musí se najít využití. Ne jen nějaké demo.

> A nebude to podobné, jako když jste tvrdil, že Apple dbá na výkon a výdrž na baterii, a pak doporučujete vykreslovat celou stránku do canvasu nebo stahovat z internetu větší objem dat?

Záleží, co je jak hardwarově akcelerované. Pamatujete třeba, když na starších počítačích lidé vynucovali na Youtube h264 místo vp9?

> Nativní aplikace ovšem neběží ve webovém prohlížeči. Uživatelé si neradi k webu instalují ještě nějakou další aplikaci, aby web mohli používat. Napadá vás vůbec nějaká běžně užívaná webová stránka, která by závisela na doinstalování nativní aplikace? Navíc ty nativní aplikace pak musíte mít pro každou platformu zvlášť.

Jen jsem vám ukazoval, jak lidé "přežívali", než Google přidal potřebnou funkci do prohlížeče.

> Je zvláštní, že Blink nebo Gecko takový problém nemají.

Protože tam není ta vazba na uživatele. Pro Google je Chrome cílení reklam a Firefox používá 1 % lidí, takže je vlastně jedno, jestli něco rozdrbá.

A ta vaše neznalost WebAssembly taktéž.
Já ale WebAssembly znám.

Je to jiný ekosystém.
Není, to je jen výmluva.

Musí se najít využití. Ne jen nějaké demo.
Využití je známé dřív, než ten webový standard vznikne.

Záleží, co je jak hardwarově akcelerované.
Nezáleží zdaleka jenom na tom. Když vykreslujete JavaScriptem do canvasu, kódu běžícímu v hlavním vlákně se nevyhnete. Pokud prohlížeč renderuje HTML+CSS, hlavní vlákno nijak blokované není.

Jen jsem vám ukazoval, jak lidé "přežívali", než Google přidal potřebnou funkci do prohlížeče.
To, že uživatelům nezbývá než něco přežít, to je ten jiný ekosystém Applu?

Protože tam není ta vazba na uživatele. Pro Google je Chrome cílení reklam
Jak by tam vazba na uživatele nebyla? To podle vás Google uživatele nějak donutil používat Chrome? Google díky Chrome nijak reklamy cílit nedokáže. Důvod, proč Google začal dělat Chrome, je ten, že potřeboval, aby mohly webové aplikace (které byly doménou Googlu) konkurovat nativním aplikacím (např. těm od Microsoftu).

> Já ale WebAssembly znám.

Asi ne.

> Není, to je jen výmluva.

Všichni ví o Apple ekosystému.

> Využití je známé dřív, než ten webový standard vznikne.

Konkrétní aplikace. Ne in-house tech demo v Googlu.

> Nezáleží zdaleka jenom na tom. Když vykreslujete JavaScriptem do canvasu, kódu běžícímu v hlavním vlákně se nevyhnete. Pokud prohlížeč renderuje HTML+CSS, hlavní vlákno nijak blokované není.

Proto si dělá Apple vlastní jádro, aby tohle mohl optimalizovat.

> To, že uživatelům nezbývá než něco přežít, to je ten jiný ekosystém Applu?

To se týká všech platforem.

> To podle vás Google uživatele nějak donutil používat Chrome?

Opět, tohle je známé.

> Google díky Chrome nijak reklamy cílit nedokáže.

Co třeba automatické přihlášení v prohlížeči přes jeho služby?

> Důvod, proč Google začal dělat Chrome, je ten, že potřeboval, aby mohly webové aplikace (které byly doménou Googlu) konkurovat nativním aplikacím (např. těm od Microsoftu).

To si nemyslím. V té době ve všech prohlížečích fungovaly pluginy, tj. aplikace používaly Flash, Javu a hry Unity a jely ve všech prohlížečích stejně dobře.

3. 8. 2024, 22:28 editováno autorem komentáře

Asi ne.
Nenapsal jsem o WebAssembly nic špatně. Což se nedá říct o vašich báchorkách o Reactu.

Všichni ví o Apple ekosystému.
Apple ekosystém nespočívá v tom dělat zastaralé a náročné aplikace.

Konkrétní aplikace. Ne in-house tech demo v Googlu.
Ano, konkrétní aplikace. Ne in-house tech demo v Googlu.

Proto si dělá Apple vlastní jádro, aby tohle mohl optimalizovat.
Tak proč to teda neoptimalizuje? že by proto, že to nejde a že to nikdo nechce?

To se týká všech platforem.
Čím dál víc se to týká jenom Safari.

Opět, tohle je známé.
Ano, je to známé že to neudělal ani udělat nemohl. Tak proč to píšete?

Co třeba automatické přihlášení v prohlížeči přes jeho služby?
Nic takového v Chrome není.

To si nemyslím. V té době ve všech prohlížečích fungovaly pluginy, tj. aplikace používaly Flash, Javu a hry Unity a jely ve všech prohlížečích stejně dobře.
Jo, třeba na iOS fungovaly pluginy perfektně… Google tyhle technologie nepoužíval, protože by těžko mohl konkurovat nativním aplikacím něčím, co bude mít všechny nevýhody nativních aplikací, nějaké nevýhody navíc, a žádné výhody.

> Nenapsal jsem o WebAssembly nic špatně. Což se nedá říct o vašich báchorkách o Reactu.

Já to vidím naopak.

> Apple ekosystém nespočívá v tom dělat zastaralé a náročné aplikace.

Přijde mi zbytečné vám vysvětlovat Apple ekosystém. Je to docela komplexní.

> Ano, konkrétní aplikace. Ne in-house tech demo v Googlu.

Jak může být aplikace dřív, než je funkce v prohlížeči?

> Tak proč to teda neoptimalizuje? že by proto, že to nejde a že to nikdo nechce?

Právě že to optimalizované je. A proto se tak dobře prodává, proti zasekanému Androidu a Windows. Víte ze světa x86, že optimalizace na straně hardware zrychlí i nepředělané aplikace (ne všechny dostanou update využívající novou funkci).

> Čím dál víc se to týká jenom Safari.

Můžete akorát říct, že na Safari je to později. Ale původně nebyla ta funkce na žádném prohlížeči.

> Ano, je to známé že to neudělal ani udělat nemohl. Tak proč to píšete?

Je známé, že to udělat mohl a udělal. Proč tomu nechcete uvěřit?

> Nic takového v Chrome není.

"Google secretly logs users into Chrome whenever they log into a Google site"

> Jo, třeba na iOS fungovaly pluginy perfektně

Až na to, že Safari/iOS je svobodnější než Chrome/Android, např. blokování reklam. A pluginy mobilové prohlížeče nikdy neuměly - ono tak nějak nástup mobilů byl souběžně s koncem pluginů. (Pro zajímavost, pro Android byl zabugovaný nefunkční Flash v jednu dobu, a pro iOS+Android byly etxerní služby, podobné Citrixu, které ten Flash přenášely vzdáleně do vašeho prohlížeče.)

> Google tyhle technologie nepoužíval, protože by těžko mohl konkurovat nativním aplikacím něčím, co bude mít všechny nevýhody nativních aplikací, nějaké nevýhody navíc, a žádné výhody.

Google se dost změnil, co např. odstranil slogan "don't be evil". Webové aplikace blokuje a na mobilech tlačí nativní. Když jsem měl WindowsPhone, tak jsem používal Google Docs mobilní webovou verzi. Byla úplně stejná jako nativní app, akorát (v rámci tehdejších technologií přirozeně) nefungoval offline mód. Pak to Google zařízl - mám si koupit iOS nebo Android (a použít nativní app). To Google zabil bšechny alternativní mobilní OS a vy ho tu adorujete.

Já to vidím naopak.
Za celou dobu jste neuvedl nic, co bych o WebAssembly napsal špatně.

Přijde mi zbytečné vám vysvětlovat Apple ekosystém. Je to docela komplexní.
Jo jo, Apple je znám tím, že nové věci zavádí teprve tehdy, když už se dávno osvědčily jinde a jenom kopíruje od jiných. Třeba takový iPhone.

Jak může být aplikace dřív, než je funkce v prohlížeči?
Třeba tak, že je to nejprve implementované stávajícími prostředky prohlížeče, když to jde. Nebo jsou to požadavky na funkce aplikací.

Právě že to optimalizované je. A proto se tak dobře prodává, proti zasekanému Androidu a Windows.
Bavíme se o vykreslování JavaScriptem do canvasu. A to Safari nijak extra optimalizované nemá. Například proto, že to používá jen pár aplikací, které jsou Applu úplně jedno.

Můžete akorát říct, že na Safari je to později.
Později, nebo také nikdy. A i kdyby později, to je teď uživatelům Safari na houby.

Ale původně nebyla ta funkce na žádném prohlížeči.
Původně také nebyly žádné prohlížeče. Což ale neznamená, že by to tak dnešní uživatelé chtěli.

Je známé, že to udělat mohl a udělal. Proč tomu nechcete uvěřit?
Protože to není pravda.

"Google secretly logs users into Chrome whenever they log into a Google site"
Vy jste psal ovšem o opačném směru.

Až na to, že Safari/iOS je svobodnější než Chrome/Android, např. blokování reklam.
To vůbec nesouvisí s tím, zda mobilní prohlížeče podporují či nepodporují pluginy.

A pluginy mobilové prohlížeče nikdy neuměly - ono tak nějak nástup mobilů byl souběžně s koncem pluginů.
Spíš neexistence pluginů na mobilech výrazně urychlila konec pluginů obecně. Což vám ovšem nebrání tady celou dobu pluginy vychvalovat jako dobré řešení.

Webové aplikace blokuje a na mobilech tlačí nativní.
I kdyby to byla pravda, nic to nemění na tom, že v minulosti Google potřeboval, aby webové prohlížeče uměly dost věcí na to, aby mohl konkurovat Microsoftu.

To Google zabil bšechny alternativní mobilní OS a vy ho tu adorujete.
Ne, Google žádné mobilní OS nezabil. Já jsem v celé této diskusi Google nijak neadoroval. Jenom jsem napsal o Safari to, co o něm říká i spousta jiných webových vývojářů. A vy jste začal básnit o ekosystému Apple a jak šetří baterku uživatelů tím, že se přes internet přenáší víc dat, nebo jste začal doporučovat místo běžného HTML a CSS použít vykreslování do canvasu, které by podle vás mělo mít zázračně větší výkon, než vykreslování HTML+CSS přímo prohlížečem.

> Za celou dobu jste neuvedl nic, co bych o WebAssembly napsal špatně.

Když jsem viděl, že neznáte ani základy...

> Jo jo, Apple je znám tím, že nové věci zavádí teprve tehdy, když už se dávno osvědčily jinde a jenom kopíruje od jiných. Třeba takový iPhone.

Však takhle funguje jejich business, to jsem říkal. Ne každý chce neodladěné featury s nejistou budoucností. Viz Google Cemetery. Jinak ten iPhone byl první telefon prodávaný ve velkém s kapacitním ovládáním. A pak také první s obchodem aplikací. V podstatě moderní chytré telefony definoval. Předpokládám, že se asi nemám ptát, odkud že Apple zkopíroval ten iPhone.

> Třeba tak, že je to nejprve implementované stávajícími prostředky prohlížeče, když to jde. Nebo jsou to požadavky na funkce aplikací.

Tím pádem to funguje i v Safari, dokud neodstraní starou codepath. Požadavků na prohlížeče je spousta, i Apple některé vyslyšel (třeba blokování reklam).

> Bavíme se o vykreslování JavaScriptem do canvasu. A to Safari nijak extra optimalizované nemá. Například proto, že to používá jen pár aplikací, které jsou Applu úplně jedno.

Ehm, Apple canvas vynalezl. Pro svoje aplikace.

> Později, nebo také nikdy. A i kdyby později, to je teď uživatelům Safari na houby.

Nikdy neříkej nikdy, jak se říká. A uživatelům Safari funguje vše jako předtím, než přišla nová funkce do (některých) jiných prohlížečů.

> Protože to není pravda.

"Google tlačil své aplikace na Android a dostal za to rekordní pokutu. Co se teď změní pro uživatele?"

> Vy jste psal ovšem o opačném směru.

V opačném směru to funguje i v Edge, to je ok (přihlášen v prohlížeči --> přihlásí mě v navštívené službě).

> To vůbec nesouvisí s tím, zda mobilní prohlížeče podporují či nepodporují pluginy.

Blokování reklam je původně rozšíření třetí strany.

> Spíš neexistence pluginů na mobilech výrazně urychlila konec pluginů obecně. Což vám ovšem nebrání tady celou dobu pluginy vychvalovat jako dobré řešení.

Překonání desktopů mobily trvalo dlouho a nastalo až o dost později. Můžeme akorát říct, že tohle nastavilo trend. A jestli jste to pochopil, že pluginy vychvaluju, tak to mě mrzí. Pluginy řešily to, co se "čistou cestou" podařilo implementovalo později. Tzn. není pravda, že tu ta funkčnost (pro uživatele) nebyla, což byla moje hlavní myšlenka (a i ten sandboxing tu byl, i když po dlouhou dobu jen na straně runtime pluginů).

> I kdyby to byla pravda, nic to nemění na tom, že v minulosti Google potřeboval, aby webové prohlížeče uměly dost věcí na to, aby mohl konkurovat Microsoftu.

To si neodporuje. Za ty roky se změnil nejen Google, ale i Microsoft.

> Ne, Google žádné mobilní OS nezabil.

V té době byly služby Googlu pro majoritu uživatelů "nutnost". Google aktivně blokoval např. všechny aplikace na Youtube a oddaloval dokončení HTML5 verze (např. v době WindowsPhone nefungovaly monetizovaná videa, protože si dával na čas s implementací reklam).

> Jenom jsem napsal o Safari to, co o něm říká i spousta jiných webových vývojářů.

Pohled vývojářů ale nemusí být pohled uživatelů. Na to jsem upozorňoval, když si někdo naivně myslel, že stačí např. dát banner "plná funkčnost jen v prohlížeči XY".

> vykreslování do canvasu, které by podle vás mělo mít zázračně větší výkon, než vykreslování HTML+CSS přímo prohlížečem.

Moje odpoveď se týkala toho, že chybějící funkce jde obejít, i kdyby takto "natvrdo".

Když jsem viděl, že neznáte ani základy...
Základy jsem vám už dávno vysvětlil. A už jste snad i pochopil, že WebAssembly nenahrazuje pluginy a nemůže v prohlížeči dělat nic víc, než je možné pomocí JavaScriptu. Naopak dnes pro jakékoli volání webových API potřebuje WASM JavaScript.

Ne každý chce neodladěné featury s nejistou budoucností.[…] Jinak ten iPhone byl první telefon prodávaný ve velkém s kapacitním ovládáním.
Zkuste si ty dvě vaše věty přečist ještě jednou, takhle vedle sebe. Jestli se třeba navzájem nevylučují.

Tím pádem to funguje i v Safari, dokud neodstraní starou codepath.
Jenomže jenom v té aplikaci, kde už to bylo implementováno dříve. A musí někdo tu starou codepath udržovat, jenom kvůli Safari.

A uživatelům Safari funguje vše jako předtím, než přišla nová funkce do (některých) jiných prohlížečů.
Jenom pokud si vývojáři webových aplikací dají tu právi, aby podporovali i Safari. Zatím museli, protože na iOS neměli uživatelé volbu.

Google tlačil své aplikace na Android a dostal za to rekordní pokutu. Co se teď změní pro uživatele?
Chrome se na desktopu rozšířil dávno před tím, než byl k dispozici na Androidu.

V opačném směru to funguje i v Edge, to je ok (přihlášen v prohlížeči --> přihlásí mě v navštívené službě).
Psal jste o Chrome, ne o Edge.

Blokování reklam je původně rozšíření třetí strany.
Rozšíření je něco jiného, než plugin.

Překonání desktopů mobily trvalo dlouho a nastalo až o dost později.
To je úplně jedno. Na mobily bylo nutné brát ohled mnohem dřív, než překonaly desktopy. Stejně jako je teď potřeba brát ohled na Safari, i když rozhodně nemá nadpoloviční většinu.

To si neodporuje. Za ty roky se změnil nejen Google, ale i Microsoft.
Což vůbec nerozporuje to, co jsem psal já.

V té době byly služby Googlu pro majoritu uživatelů "nutnost".
Akorát tak vyhledávač, který vždy fungoval přes web.

Pohled vývojářů ale nemusí být pohled uživatelů.
Nakonec to pohled uživatelů je. Jinak by uživatelé pořád používali Internet Explorer. Nebo Netscape Navigator.

Moje odpoveď se týkala toho, že chybějící funkce jde obejít, i kdyby takto "natvrdo".
Za prvé se to týká jen vykreslovacích funkcí, proto jsem uváděl třeba ten příklad s GPS. Za druhé pokud Apple donutí webové vývojáře takhle ty chybějící funkce obcházet, budou mít weby v Safari mizerný výkon a budou spotřebovávat baterku.

WebAssembly umožňuje to, co předtím ty pluginy - žádné "že to jinak nejde", když nechci použít JavaScript. iPhone ty featury přinesl až ve chvíli, kdy byly odladěné - proto např. ten obchod nebyl hned v první verzi. Dosavadní aplikace codepath pro tehdejší prohlížeče mají a udržovat je na nich, jestli chtějí zákazníky Apple. Nemyslím si, že se jim podaří na iOS přesvědčit větší množství pro přechod na jiné webové jádro. Vidím, že kauzu s Youtube a koncem WindowsPhone jste jaksi nepostřehl. To je to zúžené vnímání (jen Google Search? to jako fakt?). Lidi přestali používat IE a Netscape, protože jednoduše firmy přestaly tyto prohlížeče vydávat (nahradily je jinými). A funkce třeba na GPS je jednoduše API daného OS, a k tomu slouží ta glue vrstva.

4. 8. 2024, 00:28 editováno autorem komentáře

OK, vysvětlím vám to ještě jednou. Pluginy do prohlížeče jsou nativní kód na platformě, kde je spuštěn prohlížeč. Je to normální proces, který nastartuje vedle prohlížeče, a může dělat absolutně cokoli, co jakýkoli jiný uživatelský proces v systému – komunikovat s hardwarem, volat API systému apod. K tomu se právě pluginy v prohlížečích používaly – pro komunikaci s hardwarem (třeba čipové karty, čtečky čárových kódů) nebo pro volání služeb OS (třeba systémové úložiště certifikátů). Plugin navíc může komunikovat s procesem prohlížeče a může vykreslovat svůj obsah do vymezeného obdélníku na webové stránce (normálně prostředky operačního systému).

(Chrome později implementoval pro Windows jakýsi sandbox, který se snaží v uživatelském prostoru omezit proces pluginu. Smysl to mělo pro pluginy, které měly akorát něco zobrazovat v prohlížeči, neměly mít žádné jiné funkce – jako třeba Flash. Spouštět plugin komunikující s hardwarem v sandboxu by nedávalo smysl, protože to je přesně to, čemu by se ten sandbox snažil zabránit. Navíc ten sandbox rozhodně nebyl něco, čemu by se dalo stoprocentně věřit – prostě se ve Windows jeden uživatelský proces pokusil omezit jiný jím spuštěný proces. Na to Windows nikdy neměly bůhvíjaké prostředky, srovnatelné třeba alespoň s linuxovými kontejnery.)

WebAssembly není samostatný proces, není to nativní kód a nemůže přímo komunikovat s ničím mimo prohlížeč. Jediné, co bude moci do budoucna je volat webová API prohlížeče (dnes může volat akorát JavaScriptové funkce). WebAssembly vám tedy neumožní (teď ani v budoucnu) v prohlížeči nic jiného, než co vám umožňuje JavaScript v prohlížeči. Nebudete moci komunikovat s hardwarem (jinak než přes API poskytovaná prohlížečem), nebudete moci volat systémové služby (pokud je nevystavuje prohlížeč přes nějaké API).

Když je tu ten příklad s GPS. V době, kdy prohlížeče neměly Location API, jste si mohl napsat plugin, který by komunikoval třeba s nějakou externí bluetooth GPS. Nebo, když se lokační služby dostali do operačních systémů, mohl by ten plugin volat t yslužby operačního systému – ještě v době, kdy to neimplementovaly prohlížeče. S WebAssembly v prohlížeči nic takového neuděláte – nyní ani do budoucna. Jste odkázán na API poskytované prohlížečem, takže třeba na Location API nebo Web Bluetooth API – ale pokud prohlížeč takové API neposkytuje, z WebAssembly se nikam mimo prohlížeč ne dostanete.

Lidi přestali používat NN i IE dávno předtím, než je firmy přestaly vydávat.

To, čemu říkáte „glue vrstva“, jsou ve skutečnosti právě ta Web API. To jsou prostě standardy, které říkají, jaké funkce má prohlížeč v tom API poskytovat. A je to na prohlížeči, jak to zařídí. To Web API klidně může mít úplně jinou strukturu, než API operačního systému, které pro to prohlížeč použije, takže to vůbec nemusí být jednoduché lepidlo, které by propojilo JavaScript (nebo do budoucna WebAssembly) s funkcemi operačního systému. Někdy tam může být dost komplikovnaý převod.
A nemusí to být ani služby operačního systému. V době, kdy operační systémy neměly standardní rozhraní pro lokační služby mohlo být klidně Location API v prohlížeči implementováno tak, že by se prohlížeč uměl napojit na různé externí GPS (třeba přes bluetooth, sériový port nebo USB) přes jejich proprietární protokoly a knihovny. A i kdyby se ty různé externí GPS chovaly r§zně, prohlížeč by je dovnitř JavaScriptu vystavil pořád přes to jednotné Location API.

OK, vysvětlím vám to ještě jednou. Pluginy do prohlížeče jsou nejen nativní kód na platformě, kde je spuštěn prohlížeč, ale i prostředí pro kód běžící uvnitř toho pluginu. Jinými slovy, aniž bych musel řešit instalaci vlastního pluginu, měl jsem k dispozici minimálně jazyky ActionScript, Java a C#. Žádné "že to nejde", když jsem chtěl používat něco jiného než JS. A tohle WebAssembly řeší - mohu používat jazyk jaký chci, místo JS. Desetkrát jsem opakoval, že mi nejde o volání API OS vně prohlížeče, jen o nahrazení JS. Vlastně mi vyhovuje, že ty pluginy a dnes WebAssembly mají sandbox, protože v dnešní době by už uživatel nebezpečný kód nespouštěl a ani neměl.

> Lidi přestali používat NN i IE dávno předtím, než je firmy přestaly vydávat.

To není pravda, IE jádro se používá dodnes. Kvůli firmám je stále k dispozici v tom Edge postaveném na Chromiu. Neexistuje akorát GUI aplikace používající toto jádro (iexplore.exe).

> Někdy tam může být dost komplikovnaý převod.

Napíše si člověk vlastní nebo v případě např. WASM technologií od Microsoftu je už předudělaný.

Já popisuju vlastnosti pluginů a WebAssembly v prohlížeči. Vy popisujete nějaký svůj omezený způsob použití, který využíval zlomek vlastností pluginů. Že vám o něco nejde neznamená, že pluginy tu vlastnost nemají.

To není pravda, IE jádro se používá dodnes.
Teď si v tom, na co jste reagoval, zkuste najít slovo „jádro“.

Napíše si člověk vlastní nebo v případě např. WASM technologií od Microsoftu je už předudělaný.
Zase se míjíte s podstatou sdělení. A hlavně stále nechápete, že z prohlížeče (z JavaScriptu ani z WASM) nezavoláte API operačního systému. Můžete volat (zatím jen z JavaScriptu) jenom Web API, která vám poskytuje prohlížeč (a kterých je v případě Safari o dost méně).

Našel jste si svého strawmana (druhou vlastnost původních pluginů), přestože jsem opakovaně říkal, že pro mě je WebAssembly možnost použít svůj oblíbený programovací jazyk místo JavaScriptu ("Na louce se pase celý bílý kůň. Jakou má barvu?"). Proč jsem vám asi vysvětloval, že nechci volat API OS? Jen API prohlížeče. Proč jsem psal, že mne nezajímala možnost si napsat vlastní plugin, ale jen využít ty existující běžně dostupné, povolené nainstalovat?

> Teď si v tom, na co jste reagoval, zkuste najít slovo „jádro“.

Celou dobu se bavíme o jádrech prohlížečů (iOS, kde všude je použit Blink, ...).

Ptal jste se, co je WebAssembly. Tak jsem vám vysvětlil, co je WebAssembly. Porovnával jste to s pluginy, tak jsem vám vysvětlil, že pluginy jsou něco úplně jiného. Když vy jste používal z pluginů jenom nějaké jejich vlastnosti, neznamená to, že ty jiné vlastnosti nemají.

Já jsem nepopisoval žádnou druhou vlastnost pluginů, popisoval jsem jejich základní vlastnost – je to další běžný uživatelský proces v systému, akorát nastartovaný procesem prohlížeče a s procesem prohlížeče komunikující. Že může běžný uživatelský proces v systému napsat v libovolném programovacím jazyce, ve kterém lze vytvořit výstup spustitelný jako samostatný proces, je jen přirozený důsledek této základní vlastnosti.

Plácal jste nesmysly o Reactu, že se kompiluje do nativního kódu a že používá jen subset JavaScriptu. A plácal jste nesmysly o WebAssembly, že se dá použít pro volání systémových služeb, které prohlížeč nevystavuje skrze Web API. Přitom se WebAssembly zatím nedá použít ani přímo k volání Web API, i k tomu je potřeba volat z WebAssembly JavaScript.

Uživatelé přestali používat Internet Explorer a tím i jádro Trident dávno před tím, než Microsoft podporu ukončil. To, že IE dál používalo pár jedinců, nebo že se Trident v rámci Edge nuceně používá pro nějaké interní legacy systémy, neznamená, že by měl na veřejném internetu podíl, o kterém by mělo smysl se bavit.

> Ptal jste se, co je WebAssembly.

Ne, to jste se ptal vy.

> Když vy jste používal z pluginů jenom nějaké jejich vlastnosti, neznamená to, že ty jiné vlastnosti nemají.

To jsem nikde netvrdil.

> Já jsem nepopisoval žádnou druhou vlastnost pluginů, popisoval jsem jejich základní vlastnost – je to další běžný uživatelský proces v systému, akorát nastartovaný procesem prohlížeče a s procesem prohlížeče komunikující. Že může běžný uživatelský proces v systému napsat v libovolném programovacím jazyce, ve kterém lze vytvořit výstup spustitelný jako samostatný proces, je jen přirozený důsledek této základní vlastnosti

Já mluvil o nejběžnějším využití pluginů, tj. ne vlastní (obecný) plugin, ale můj (bajt)kód běžící v běžné dostupných pluginech (Flash, Java, Unity3D).

> Plácal jste nesmysly o Reactu, že se kompiluje do nativního kódu a že používá jen subset JavaScriptu

Je to přímo na jejich GitHubu, dokonce jsem dal link. (Abyste mě zas nechytal za slovíčko, je rozdíl mezi React JS a React Native. Ale oba používají ten subset HTML a JS, akorát jeden ho kompiluje do HTML+JS a druhý do nativního kódu. Tím obchází problémy s embedováním webového jádra na mobilech. Na druhé straně React JS dovoluje vložit vlastní JS, ale to by pak nešlo jednoduše zkonvertovat aplikaci v React JS do React Native.)

> plácal jste nesmysly o WebAssembly, že se dá použít pro volání systémových služeb,

To byl jen váš strawman a já vás v tom nechal plácat. Po několika marných pokusech jsem pochopil, že tohle nemá cenu.

> Uživatelé přestali používat Internet Explorer a tím i jádro Trident dávno před tím, než Microsoft podporu ukončil. To, že IE dál používalo pár jedinců, nebo že se Trident v rámci Edge nuceně používá pro nějaké interní legacy systémy, neznamená, že by měl na veřejném internetu podíl, o kterém by mělo smysl se bavit.

Co si pamatuju, tak i těsně u konce existence IE měl furt větší podíl než nástupce Edge (UWP).

Ne, to jste se ptal vy.
https://www.root.cz/zpravicky/servo-engine-uz-umi-renderovat-html-tabulky-vicevlaknove/1154243/

Já mluvil o nejběžnějším využití pluginů, tj. ne vlastní (obecný) plugin, ale můj (bajt)kód běžící v běžné dostupných pluginech (Flash, Java, Unity3D).
Když chcete psát o „nejběžnějším použití pluginů“, nepište „pluginy“. „X“ a „nejběžnější použití X“ jsou dvě různé věci. Navíc i to vaše nejběžnější použití pluginů nespočívalo v tom „můžu psát v jiném jazyce“ ale v tom, že „můžu používat technologie, které v samotném prohlížeči nejsou dostupné“.

Je to přímo na jejich GitHubu, dokonce jsem dal link.
Není, to jenom vy jste to nepochopil.

Ale oba používají ten subset HTML a JS
React JS nepoužívá žádný subset HTML a JS. React JS je normální JavaScriptová knihovna, můžete ji použít v libovolném JavaScriptovém kódu v prohlížeči.

akorát jeden ho kompiluje do HTML+JS a druhý do nativního kódu.
React JS nic nekompiluje. React Native zase nepoužívá HTML.

Na druhé straně React JS dovoluje vložit vlastní JS
Je o ppačně,i, React je normální knihovna, kterou vkládáte do svého kódu.

ale to by pak nešlo jednoduše zkonvertovat aplikaci v React JS do React Native
To taky nejde.

To byl jen váš strawman a já vás v tom nechal plácat. Po několika marných pokusech jsem pochopil, že tohle nemá cenu.
Nedokážete napsat jedinou věc, kterou bych o WebAssembly napsal špatně.

Co si pamatuju, tak i těsně u konce existence IE měl furt větší podíl než nástupce Edge (UWP).
Tak to si pamatujete špatně. Edge předběhl IE už někdy v roce 2019. V roce 2022 měl Edge na desktopu už větší podíl, než Safari (přes 10%), IE se tou dobou plácal někde pod jedním procentem. https://gs.statcounter.com/browser-market-share/desktop/worldwide/2022

4. 8. 2024, 13:41 editováno autorem komentáře

V prvním odkazu vidím jen "Já vím, co je WebAssembly. Ale radši si poslechnu vaší verzi, když se nechytáte ani s bodem výše."

> Když chcete psát o „nejběžnějším použití pluginů“, nepište „pluginy“. „X“ a „nejběžnější použití X“ jsou dvě různé věci. Navíc i to vaše nejběžnější použití pluginů nespočívalo v tom „můžu psát v jiném jazyce“ ale v tom, že „můžu používat technologie, které v samotném prohlížeči nejsou dostupné“.

Tak když napíšu Flash/Java/Unity3D, tak asi myslím můj kód běžící v těch běžně dostupných a nainstalovanch pluginech. Ne že si podle jejich vzoru budu psát vlastní plugin. Základem sdělení bylo použití jiného jazyka než JavaScript a protiargumentovat "jinak to nejde". Tamty běžné výběr rozšiřují o Javu a C# (ActionScript přímo neberu).

> Není, to jenom vy jste to nepochopil.

Tak jim napište, ať opraví svoji dokumentaci. Přitom jste sám mluvil o kompilárotu JSX.

> React JS nepoužívá žádný subset HTML a JS. React JS je normální JavaScriptová knihovna, můžete ji použít v libovolném JavaScriptovém kódu v prohlížeči.
> React JS nic nekompiluje. React Native zase nepoužívá HTML.
> Je o ppačně,i, React je normální knihovna, kterou vkládáte do svého kódu.

Však o tom jsem mluvil. Když použijete React JS, tak můžete začlenit i surový HTML a JS. Když to ale chcete převést do React Native pro build pro další platformy, tak se musíte omezit jen na ten subset jménem JSX.

> To taky nejde.

Když použiju HTML a JS nad rámec toho podporovaného subsetu v React Native, tak fakt ne.

> Nedokážete napsat jedinou věc, kterou bych o WebAssembly napsal špatně.

Třeba to, k čemu se mi hodí? Mně je úplně jedno, že s ním nemůžete přímo volat API OS. Já jen chci psát hlavní kód v něčem jiném než JS.

> Tak to si pamatujete špatně. Edge předběhl IE už někdy v roce 2019. V roce 2022 měl Edge na desktopu už větší podíl, než Safari (přes 10%), IE se tou dobou plácal někde pod jedním procentem. https://gs.statcounter.com/browser-market-share/desktop/worldwide/2022

Tak to si pamatujete špatně. Explicitně jsem mluvil o původním Edge založeném na forku enginu Trident. Edge založený na forku Chromia je late 2018, a o tom se nehádávám.

V prvním odkazu vidím jen "Já vím, co je WebAssembly. Ale radši si poslechnu vaší verzi, když se nechytáte ani s bodem výše."
Ano, takže to vy jste po mně chtěl vysvětlení, co je WebAssembly.

Tak když napíšu Flash/Java/Unity3D, tak asi myslím můj kód běžící v těch běžně dostupných a nainstalovanch pluginech.
Jenže vy jste psal „pluginy“.

Základem sdělení bylo použití jiného jazyka než JavaScript a protiargumentovat "jinak to nejde".
Ano, ten váš protiarguent byl mylný. Protože pluginy nejsou běžnou součástí webových technologií, na některých platformách ani nejsou dostupné. Za webové technologie se normálně považuje to, co je přímo dostupné ve webovém prohlížeči.

Tamty běžné výběr rozšiřují o Javu a C# (ActionScript přímo neberu).
Nerozšiřují, protože pluginy se nepoužívaly pro volání API prohlížeče (proč byste to dělal, to šlo daleko snáz s JavaScriptem). Pluginy se používaly pro implementaci věcí, které v prohlížeči nešly udělat. Třeba Flash byl tolik populární proto, že se v něm dělali animace, mnohdy interaktivní, které v té době v prohlížeči udělat, nešlo neměl na to rozumné prostředky. Java se používala pro interaktivní aplikace nebo třeba pro certifikáty a elektronické podpisy. Manipulace s DOMem (protože o moc víc API tehdejší prohlížeče neměly) se z pluginů dělala jen velmi výjimečně.

Tak jim napište, ať opraví svoji dokumentaci.
Kvůli tomu, že jste dokumentaci nepochopil, by ji měli opravovat? Chyba je ve vás, ne v té dokumentaci.

Přitom jste sám mluvil o kompilárotu JSX.
JSX není React. React se obvykle používá s JSX, ale není to technologicky nutné. Stejně tak se JSX může používat bez Reactu (a běžně se to dělá). A jak už jsem psal, JSX je jenom syntaktický cukr pro zápis volání JavaScriptových metod. Nic vám nebrání psát rovnou ten kód, který vytváří JSX transpilátor – akorát to bude o něco méně přehledné.

Však o tom jsem mluvil. Když použijete React JS, tak můžete začlenit i surový HTML a JS. Když to ale chcete převést do React Native pro build pro další platformy, tak se musíte omezit jen na ten subset jménem JSX.
To jsou bláboly. React JS je JavaScriptová knihovna. Nezačleňujete JS do Reactu, ale React do JS. JSX není žádný subset něčeho, je to syntaktický cukr pro zápis volání JavaScriptových metod.

React JS a React Native jsou dvě úplně odlišné technologie, akorát používají stejné principy. Je to jako kdybyste psal v Javě serverovou aplikaci pro web nebo aplikaci pro Android. Obojí je to Java, ale každé to používá úplně jiné technologie. Když chcete napsat aplikaci, která bude pro React JS i React Native používat stejnou codebase, musíte si vytvořit (nebo použít někým jiným vytvořené) komponenty, kterým pak pro React JS podstrčíte HTML obsah a pro React Native jim podstrčíte nativní komponenty.

Vážně vám není hloupé hádat se o Reactu s někým, kdo v něm programuje, když vy jste veškeré svoje znalosti o Reactu získal včera přečtením pár vět, které jste našel na Googlu?

Třeba to, k čemu se mi hodí?
O tom, k čemu we vám WebAssembly hodí, jsem se já nevyjadřoval.

Tak to si pamatujete špatně.
Proto jsem tam dával ten odkaz, abyste se mohl podívat, že to není co si já pamatuju nebo co si vy špatně pamatujete, ale že jsou to uznávané statistiky.

Edge založený na forku Chromia je late 2018, a o tom se nehádávám.
Psal jste o konci IE. IE skončil teprve po přechodu Edge na Blink, v roce 2022.

4. 8. 2024, 18:03 editováno autorem komentáře

> Ano, takže to vy jste po mně chtěl vysvětlení, co je WebAssembly.

A vy jste nepochopil, jak jsem to myslel.

> Jenže vy jste psal „pluginy“.

Ano, pluginy Flash/Java/Unity3D. Kolikrát to mám opakovat?

> Ano, ten váš protiarguent byl mylný. Protože pluginy nejsou běžnou součástí webových technologií, na některých platformách ani nejsou dostupné. Za webové technologie se normálně považuje to, co je přímo dostupné ve webovém prohlížeči.

Však tyto pluginy tehdy byly běžně dostupné.

> Nerozšiřují, protože pluginy se nepoužívaly pro volání API prohlížeče (proč byste to dělal, to šlo daleko snáz s JavaScriptem).

Byly i dynamické weby postavené třeba na Flashi.

> Pluginy se používaly pro implementaci věcí, které v prohlížeči nešly udělat. (...)

A nejen na to, viz výše.

> Kvůli tomu, že jste dokumentaci nepochopil, by ji měli opravovat? Chyba je ve vás, ne v té dokumentaci.
> (...)
> (...)
> (...)
> (...)

Já vám přece neberu, že ve variantě React JS jde použít i čistý HTML a JS. Jenže ten průnik s React Native není plný HTML a JS. Právě protože běh na některých platformách není přes webview.

> O tom, k čemu se vám WebAssembly hodí, jsem se já nevyjadřoval.

Ale vnucujete mi už po dvacáté, že chci použít WASM na přístup k API OS, jako to tehdy dělaly klasické pluginy (dnes už není potřeba díky obsáhlejšímu API v prohlížeči).

> Proto jsem tam dával ten odkaz, abyste se mohl podívat, že to není co si já pamatuju nebo co si vy špatně pamatujete, ale že jsou to uznávané statistiky.

Ale to jsou statistiky pro Edge (Chromium)*, ne pro Edge (UWP), který jsem explicitně zmiňoval. A to říkáte, že se živíte weby, když neznáte ani výchozí prohlížeč v nejrozšiřenějším OS (na desktopu)? Jaké pak asi budou vaše znalosti Reactu?

*) Edge (Chromium) je od late 2018, ve vašich statistikách začal útočit od 2019.

4. 8. 2024, 18:16 editováno autorem komentáře

A vy jste nepochopil, jak jsem to myslel.
Původně jsem si myslel, že si myslíte, že to nevím, a chcete mne nachytat. V průběhu diskuse jsem pochopil, že jste naopak sám nevěděl, co je WebAssembly, a takhle jste se chtěl vyhnout tomu, abyste to musel sám popsat.

Ano, pluginy Flash/Java/Unity3D. Kolikrát to mám opakovat?
To, že to budete opakovat, nezmění nic na tom, že jste zpočátku psal jen o pluginech, nenapsal jste, že myslíte jen některé. Teď zpětně to dává smysl, protože jste nevěděl, že pluginy do prohlížečů byla univerzální technologie, myslel jste si, že existovala jen ta Java, později Flash a později Silverlight.

Nic to nemění na tom, že i tyhle tři pluginy se nepoužívaly kvůli použití jiného programovacího jazyka, ale kvůli použití technologií, které tehdy prohlížeče neuměly.

Byly i dynamické weby postavené třeba na Flashi.
Jenže to byl ve Flashi udělaný celý web. Nebyla to interakce Flashe s DOMem.

A nejen na to, viz výše.
Jenom na to. NIkdo to nepoužíval pro manipulaci s DOMem místo JavaScriptu, protože by to bylo velmi neohrabané.

Já vám přece neberu, že ve variantě React JS jde použít i čistý HTML a JS. Jenže ten průnik s React Native není plný HTML a JS.
React Native není HTML. Naopak je tam plný HTML, protože tam běží plnohodnotný JavaScriptový engine.

Hlavně ale konečně přestaňte řešit React Native. Bavíme se tu o webových technologiích, takže o Reactu (nebo Reactu JS, pokud to chcete takto upřesnit). Reat Native není webová technologie.

Právě protože běh na některých platformách není přes webview.
React Native nikde neběží přes WebView. Proto je to React Native. Když chcete použít WebView, použijete uvnitř webové technologie, takže třeba React.

Ale vnucujete mi už po dvacáté, že chci použít WASM na přístup k API OS, jako to tehdy dělaly klasické pluginy (dnes už není potřeba díky obsáhlejšímu API v prohlížeči).
Protože vy jste přišel se srovnáním WebAssembly a pluginů.

Každopádně jste tvrdil, že jsem o WebAssembly napsal něco špatně. Tak se jenom ptám, co přesně jsem napsal špatně. Zatím jste nic konkrétního neuvedl.

Ale to jsou statistiky pro Edge (Chromium), ne pro Edge (UWP), který jsem explicitně zmiňoval.
Jsou to statistiky webových prohlížečů, tak, jak se používaly v jednotlivých letech. V letech, kdy neexistoval Edge, tam Edge není. V letech, kdy existoval legacy Edge a měl měřitelný podíl, je tam legacy Edge. V letech, kdy ho nahradil Edge založený na Chromiu, je tam Edge založený na Chromiu.

Psal jste o konci Internet Exploreru. Což v kontextu zbytku příspěvku dávalo větší smysl, než konec Edge (UWP). Takže jsem předpokládal, že jste se spletl v tom upřesnění verze Edge. Každopádně je to jedno, protože když končil Edge (UWP), měl větší podíl, než IE. I když to bylo na hranici měřitelnosti. Když končil Internet Explorer, měl Edge (Chromium) větší podíl, než IE. Takže to platí pro oba dva okamžiky, ať už jste myslel kterýkoli.

A to říkáte, že se živíte weby, když neznáte ani výchozí prohlížeč v nejrozšiřenějším OS (na desktopu)? Jaké pak asi budou vaše znalosti Reactu?
Jasně, celou dobu tady píšu o Edge proto, že vůbec nevím, co to je.

Každopádně já mám jednu superschopost, kterou vy nemáte. Umím si na StatCounter překliknout na jiný rok.

> V průběhu diskuse jsem pochopil, že jste naopak sám nevěděl, co je WebAssembly, a takhle jste se chtěl vyhnout tomu, abyste to musel sám popsat.

Ne, jen vy jste nedokázal pochopit (ani s polopatickým vysvětlením), k čemu se mi hodí WebAssembly.

> Teď zpětně to dává smysl, protože jste nevěděl, že pluginy do prohlížečů byla univerzální technologie, myslel jste si, že existovala jen ta Java, později Flash a později Silverlight.

No tak jste to konečně pochopil ;-)

> Nic to nemění na tom, že i tyhle tři pluginy se nepoužívaly kvůli použití jiného programovacího jazyka, ale kvůli použití technologií, které tehdy prohlížeče neuměly.

Ale tady máme ještě co dohánět.

> V letech, kdy neexistoval Edge, tam Edge není. V letech, kdy existoval legacy Edge a měl měřitelný podíl, je tam legacy Edge. V letech, kdy ho nahradil Edge založený na Chromiu, je tam Edge založený na Chromiu.
> (...)

Ale Edge překonal IE až po přechodu na Chromium. Do té doby byl IE používanější.

A ten React jsme naštěstí už taky dořešili.

Ne, jen vy jste nedokázal pochopit (ani s polopatickým vysvětlením), k čemu se mi hodí WebAssembly.
Takže když to shrnu, co je WebAssembly jste popsat nedokázal. Tvrdil jste, že jsem já napsal něco špatně o WebAssembly, ale nedokázal jste napsat, co jsem napsal špatně. Nakonec jste radši skončil u toho, k čemu se WebAssembly hodí vám (což nikoho nezajímá).

No tak jste to konečně pochopil ;-)
Ano, pochopil jsem, že když píšete o WebAssembly, nevíte, o čem píšete. Když píšete o Reactu, nevíte o čem píšete. Když píšete o webových technologiích, nevíte, o čem píšete. A nakonec se ukázalo, že i když píšete o pluginech do prohlížečů, nevíte, o čem píšete.

Ale tady máme ještě co dohánět.
Ale když napíšu, že Safari je v tom dohánění zdaleka nejhorší, začnete si vymýšlet, že to tak uživatelé Safari vlastně chtějí.

Ale Edge překonal IE až po přechodu na Chromium. Do té doby byl IE používanější.
Tak co kdybyste se konečně podíval na ty statistiky, které jsem odkazoval?

A ten React jsme naštěstí už taky dořešili.
Tak to jsem rád, že jste konečně pochopil, že od začátku blábolíte o Reactu nesmysly.

4. 8. 2024, 19:10 editováno autorem komentáře

> Nakonec jste radši skončil u toho, k čemu se WebAssembly hodí vám (což nikoho nezajímá).

Ja tím i začal. A když vás to nezajímá, proč to furt komentujete?

> Ale když napíšu, že Safari je v tom dohánění zdaleka nejhorší, začnete si vymýšlet, že to tak uživatelé Safari vlastně chtějí.

Whataboutismus.

> Tak to jsem rád, že jste konečně pochopil, že od začátku blábolíte o Reactu nesmysly.

Proč to zas otevíráte? Myslel jsem, že jste se už uklidnil.

Ja tím i začal.
Ne, nezačal. Začal jste tím, že Safari podporuje WebAssembly. Což bylo v kontextu toho, že Safari zaostává v podpoře moderních web API, zcela irelevantní.

A když vás to nezajímá, proč to furt komentujete?
Já to nekomentuju. Možná jste nepochopil, že celá tahle diskuse není o tom, co vyhovuje či nevyhovuje vám.

Proč to zas otevíráte? Myslel jsem, že jste se už uklidnil.
A já jsem si myslel, že už dokážete přiznat, že jste tu napsal o webovém vývoji spoustu nesmyslů – u Reactu, o WebAssembly, o pluginech…

> Začal jste tím, že Safari podporuje WebAssembly. Což bylo v kontextu toho, že Safari zaostává v podpoře moderních web API, zcela irelevantní.

Byl to příklad toho, že všechno se dá dnes obejít.

> Já to nekomentuju. Možná jste nepochopil, že celá tahle diskuse není o tom, co vyhovuje či nevyhovuje vám.

Tak teď už vás konečně zajímá, co vyhovuje mně?

> A já jsem si myslel, že už dokážete přiznat, že jste tu napsal o webovém vývoji spoustu nesmyslů – u Reactu, o WebAssembly, o pluginech…

Dal jsem vám možnost odejít se vztyčenou hlavou.

Byl to příklad toho, že všechno se dá dnes obejít.
Nedá. Když nemáte v prohlížeči API na nějakou externí komunikaci (třeba kdyby nějaký prohlížeč nepodporoval Location API), ve webové aplikaci (bez toho, aby si uživatel nainstaloval nějakou jinou nativní aplikaci) to neobejdete. A k tomu, co lze obejít (vykreslování) nepotřebujete WebAssembly.

Tak teď už vás konečně zajímá, co vyhovuje mně?
Vůbec.

Dal jsem vám možnost odejít se vztyčenou hlavou.
Já opravdu nepotřebuji, abyste mi dával nějaké možnosti. Doufal jsem, že se třeba poučíte pro příště a nebudete se o věcech, o kterých jste si před 10 minutami přečetl čtyři věty na Googlu, dohadovat s někým, kdo jim rozumí.

> Nedá. Když nemáte v prohlížeči API na nějakou externí komunikaci (třeba kdyby nějaký prohlížeč nepodporoval Location API), ve webové aplikaci (bez toho, aby si uživatel nainstaloval nějakou jinou nativní aplikaci) to neobejdete. A k tomu, co lze obejít (vykreslování) nepotřebujete WebAssembly.

Co máte furt s externími komunikacemi. Tam Safari problém nemá.

> Vůbec.

Ale jo. Furt si o tom povídáme.

> Já opravdu nepotřebuji, abyste mi dával nějaké možnosti. Doufal jsem, že se třeba poučíte pro příště a nebudete se o věcech, o kterých jste si před 10 minutami přečetl čtyři věty na Googlu, dohadovat s někým, kdo jim rozumí.

Čím dál míň si myslím, že rozumíte tomu, co spolu teď řešíme.

Co máte furt s externími komunikacemi. Tam Safari problém nemá.
Safari nepodporuje namátkou WebUSB, Web MIDI API, Web Bluetooth, ImageCapture API… Je úplně jedno že vy tahle API nepotřebujete. Problém je v tom, že Safari zaostává ve všem. Nejen v podpoře nových API, ale i v tom, jak zachází s dávno používanými věcmi jako local/session storage, data URL apod.

Ale jo. Furt si o tom povídáme.
Ne. Mně je to úplně jedno, co vyhovuje vám.

Čím dál míň si myslím, že rozumíte tomu, co spolu teď řešíme.
Řešíme tu webové technologie, kterým moc nerozumíte. Možná píšete něco ve WebAssembly, ale o webovém vývoji jako takovém, o tom nevíte prakticky nic – a myslíte si, že to doženete googlením.

> Safari nepodporuje namátkou WebUSB, Web MIDI API, Web Bluetooth, ImageCapture API… Je úplně jedno že vy tahle API nepotřebujete. Problém je v tom, že Safari zaostává ve všem. Nejen v podpoře nových API, ale i v tom, jak zachází s dávno používanými věcmi jako local/session storage, data URL apod.

Apple nemůže za to, že se Google zbláznil. I Mozilla jim na to už háže bobek. Např ovládání USB nikdy umět nebude.

> Ne. Mně je to úplně jedno, co vyhovuje vám.

Ale mně to takhle vyhovuje.

> Řešíme tu webové technologie, kterým moc nerozumíte. Možná píšete něco ve WebAssembly, ale o webovém vývoji jako takovém, o tom nevíte prakticky nic – a myslíte si, že to doženete googlením.

Číst tohle od místního "Brouka Pytlíka", co má 20 let zkušeností v 10 let staré technologii ;-)

4. 8. 2024, 22:46 editováno autorem komentáře

Apple nemůže za to, že se Google zbláznil. I Mozilla jim na to už háže bobek. Např ovládání USB nikdy umět nebude.
Je zajímavé, jak plynule přecházíte mezi „Safari vše podporuje nebo brzy podporovat bude, přinejhorším se to dá obejít“ a „stejně to nikdo nepotřebuje“.

Číst tohle od místního "Brouka Pytlíka", co má 20 let zkušeností v 10 let staré technologii ;-)
Web je drobátko starší, než 10 let.

Ale chápu. Myslet si o někom, že je to Brouk Pytlík, a pak neumět napsat ani jedinou věc, co napsal špatně, to člověka zamrzí. Až tak, že se uchýlí k velmi průhledné demagogii.

Nemusíte čekat, až vám někdo dá možnost odejít se vztyčenou hlavou – to je vždy jenom na vás. Stačí jenom si umět přiznat chybu.

> Je zajímavé, jak plynule přecházíte mezi „Safari vše podporuje nebo brzy podporovat bude, přinejhorším se to dá obejít“ a „stejně to nikdo nepotřebuje“.

Myslel jsem, že už jsme se shodli na tom, že Safari ne všechno umí. Nebo se pletu? Lišíme se akorát v tom, proč. Navíc permanentně ignorujete Firefox.

> Web je drobátko starší, než 10 let.

Ale ten React, který prý vyučujete, ne.

> a pak neumět napsat ani jedinou věc, co napsal špatně, to člověka zamrzí.

Já to napsal, ale vy jste si to odfiltroval. Neustále se zaměřujete a vracíte jen k vybraným věcem, i když jsem vám opakovaně vysvětloval, jak jsem to původně myslel. V normální diskuzi by se pokračovalo dál, ale vy tam na mě nic dalšího asi nemáte.

> Až tak, že se uchýlí k velmi průhledné...

Já zas odfiltrovávám urážky.

> Nemusíte čekat, až vám někdo dá možnost odejít se vztyčenou hlavou – to je vždy jenom na vás. Stačí jenom si umět přiznat chybu.

Ale já ji v tom Reactu přiznal (React JS vs React Native). Vy jste se vrátil.

Já to napsal, ale vy jste si to odfiltroval.
Já jsem se ptal, co jsem napsal špatně o WebAssembly. To znamená o WebAssembly obecně, ne o vašem vztahu k WebAssembly. Na to jste neodpověděl nic. Místo toho pořád řešíte váš vztah k WebAssembly, o kterém já jsem nenapsal ani čárku.

Ale já ji v tom Reactu přiznal (React JS vs React Native).
Naposledy, když jste psal o Reactu, jste blábolil nesmysly. To nevypadá jako přiznání, že o tom nic nevíte.

Navíc nejde jen o ten React. Psal jste nesmysly o Reactu, o WebAssembly, o pluginech, o konci IE, o webových standardech – takže je otázka, proč vlastně diskutujete o něčem, o čem nic nevíte.

Ale ten React, který prý vyučujete, ne.
Takhle to dopadá, když si nedokážete přiznat chybu. Já být na vašem místě a někdo mne upozornit, že možná váš komentář interpretuju špatně, tak si odroluju zpátky nahoru a ten komentář si znovu přečtu. Abych se přesvědčil, zda není chyba na mé straně, zda jsem si ho náhodou nezapamatoval jinak.

Takže co jsem v tom komentáři doopravdy napsal?

[…] já programuju webové aplikace přes dvacet let, React školím […]
Je to souvětí, jsou tam dvě nezávislá sdělení. První sdělení je, že webové aplikace programuju přes dvacet let. O jaké technologie se jedná tam není uvedeno – záměrně, protože ty technologie se v průběhu času proměňují. Druhé sdělení je, že React školím. Tam ale zase není uveden žádný časový údaj. Čas nebyl důležitý. Podstatné bylo to, abyste se netočil na tom, že to, že pracuji s webovými technologiemi, neznamená, že vím něco o Reactu. Což ostatně víte z vlastní zkušenosti, že možná s webem něco děláte, ale o Reactu nevíte nic.

Takže kdybyste si ten komentář dohledal a znovu si ho přečetl, musel byste zjistit, že tam není napsáno, že se Reactu věnuju dvacet let. Stejně tak když jsem vás podruhé upozornil na odkazované globální statistiky podílu prohlížečů, musel byste přijít na to, že Edge legacy podle nich měl ve závěru svého působení větší podíl, než IE. Jenže vy si prostě nepřipouštíte, že byste se mohl mýlit. A v tom je právě mezi námi rozdíl – já si věci ověřuju.

> Místo toho pořád řešíte váš vztah k WebAssembly, o kterém já jsem nenapsal ani čárku.

Já těch "čárek" vidím hodně.

> Naposledy, když jste psal o Reactu, jste blábolil nesmysly. To nevypadá jako přiznání, že o tom nic nevíte.

A co je na tom špatně? Vy jste se zmohl jen na urážení.

> Psal jste nesmysly o Reactu, o WebAssembly, o pluginech, o konci IE, o webových standardech

Všechno (kromě Reactu, který jsem přiznal) jde ověřit za 5 sekund na Googlu (pro retardované, to neznamená, že moje znalosti jsou na úrovni "5 sekund na Googlu", ale že se narozdíl od vás snažím hledat zdroje).

> takže je otázka, proč vlastně diskutujete o něčem, o čem nic nevíte.

Naopak, narozdíl od vás se nevyjadřuju ke článkům z oborů, kterým se nevěnuju.

> Takhle to dopadá, když si nedokážete přiznat chybu. Já být na vašem místě a někdo mne upozornit, že možná váš komentář interpretuju špatně, tak si odroluju zpátky nahoru a ten komentář si znovu přečtu. Abych se přesvědčil, zda není chyba na mé straně, zda jsem si ho náhodou nezapamatoval jinak.

Ale já jsem chybu přiznal. Vy ne.

> Podstatné bylo to, abyste se netočil

Točíte se tu jen vy, i když jsem uznal chybu a dal vám možnost odejít ze vztyčenou hlavou.

> musel byste přijít na to, že Edge legacy podle nich měl ve závěru svého působení větší podíl, než IE

Však jsem psal "skoro do konce", ne do úplného konce. Tohle vaše puntíčkaření (např. čárka ve větě s Reactem) vám znemožňuje se posunout dál. Tohle tady řešíme už nekolik dní.

> Jenže vy si prostě nepřipouštíte, že byste se mohl mýlit. A v tom je právě mezi námi rozdíl – já si věci ověřuju.

Já narozdíl od vás naopak umím uznat chybu a posunout se dál. Viz výše.

5. 8. 2024, 10:50 editováno autorem komentáře

Já těch "čárek" vidím hodně.
Já jsem o vašem vztahu k WebAssembly nenapsal opravdu nic. Vše, co jsem psal o WebAssembly, jsem psal obecně o WebAssembly. Jak to používáte vy je mi úplně jedno.

A co je na tom špatně? Vy jste se zmohl jen na urážení.
Psal jsem to už několikrát. Bavíme se o webu, tedy o Reactu, vy do toho mícháte React Native. Píšete, že JSX je nějaký subset něčeho. Že se React kompiluje. Že se používá JavaScript v Reactu. Nic z toho není pravda.

Všechno (kromě Reactu, který jsem přiznal) jde ověřit za 5 sekund na Googlu (pro retardované, to neznamená, že moje znalosti jsou na úrovni "5 sekund na Googlu", ale že se narozdíl od vás snažím hledat zdroje).
No a tak proč jste si to neověřil před tím, než jste ty nesmysly napsal?

Naopak, narozdíl od vás se nevyjadřuju ke článkům z oborů, kterým se nevěnuju.
To záleží na tom, jak široce si nadefinujete obor. Tady se evidentně vyjadřujete k věcem, kterým nerozumíte.

Ale já jsem chybu přiznal. Vy ne.
Ne, vy jste chybu nepřiznal. Vy jste akorát napsal, že se o tom dál nechcete bavit. A zůstala spousta dalších chyb, na kterých dál trváte.

Já jsem chybu v této diskusi nepřiznal, protože jsem tu zatím žádnou chybu neudělal. O čemž svědčí i to, že jste zatím upozornil pouze na jednu moji domnělou chybu. A to že jsem se vyjadřoval k tomu, jaký je váš vztah k WebAssembly – přičemž já jsem se k ničemu takovému nevyjadřoval, protože je mi upřímně jedno, co vám na WebAssembly vyhovuje či nevyhovuje nebo proč ho používáte.

Točíte se tu jen vy, i když jsem uznal chybu a dal vám možnost odejít ze vztyčenou hlavou.
Já od vás žádnou možnost odejít se vztyčenou hlavou nepotřebuju.

Podle vás je věta „a ten React jsme naštěstí už taky dořešili“ uznání chyby?

Však jsem psal "skoro do konce", ne do úplného konce.
Napsal jste tohle:
Co si pamatuju, tak i těsně u konce existence IE měl furt větší podíl než nástupce Edge (UWP).
Mezi koncem legacy Edge a koncem IE uběhly čtyři roky. To je podle vás „těsně“? A pokud měl IE více než čtyři roky před koncem větší podíl, než tehdejší Edge, o čem to vypovídá? Bavili jsme se původně o tom, jestli uživatelé přestali používat IE sami, nebo jestli jim ho Microsoft nějak násilně utnul. Připadá vám to, že měl IE čtyři roky před koncem podpory ze strany Microsoftu, podíl méně než jedno procento, že ho uživatelé používali?

Tohle vaše puntíčkaření (např. čárka ve větě s Reactem)
Ta čárka je tam proto, že odděluje dvě věty v souvětí. Bez čárky by to nedávalo žádný smysl. Nemůžu za to, že neumíte česky.

vám znemožňuje se posunout dál.
Já se ale nechci posouvat dál od faktů, jako vy.

Tohle tady řešíme už nekolik dní.
Ano, už několik dní tu řešíme, že plácáte nesmysly. Netušil jsem, že to, že něco nevíte a vymýšlíte si, vás posouvá dál. Mne teda dál posouvá přesný opak – že se něco nového dozvím.

Já narozdíl od vás naopak umím uznat chybu a posunout se dál.
Tak směle do toho, příležitostí jste si tu vytvořil mnoho. Naposledy to, že jsem někde měl tvrdit, že dvacet let používám technologii starou deset let. Tam se vám nějak nepodařilo chybu uznat, místo toho se vymlouváte na to, že jsem puntičkář, když trvám na tom, že to souvětí má jenom jeden možný význam a ta čárka tam není na okrasu, ale proto, že bez ní by to nedávalo žádný smysl.

> Já jsem o vašem vztahu k WebAssembly nenapsal opravdu nic. Vše, co jsem psal o WebAssembly, jsem psal obecně o WebAssembly. Jak to používáte vy je mi úplně jedno.

Jedno vám to není, když to tu musíte furt opakovat.

> Psal jsem to už několikrát. Bavíme se o webu, tedy o Reactu, vy do toho mícháte React Native. Píšete, že JSX je nějaký subset něčeho. Že se React kompiluje. Že se používá JavaScript v Reactu. Nic z toho není pravda.

Ten JSX se kompiluje/tran­spiluje. Zbytek jsem uznal, ale vy to furt otevíráte?

> No a tak proč jste si to neověřil před tím, než jste ty nesmysly napsal?

Vyjma toho Reactu to vše ale platí (kromě toho, že to jsou technologie, v kterých dělám).

> To záleží na tom, jak široce si nadefinujete obor. Tady se evidentně vyjadřujete k věcem, kterým nerozumíte.

Opět, jen ten React. Vše ostatní platí.

> Já jsem chybu v této diskusi nepřiznal, protože jsem tu zatím žádnou chybu neudělal. O čemž svědčí i to, že jste zatím upozornil pouze na jednu moji domnělou chybu. A to že jsem se vyjadřoval k tomu, jaký je váš vztah k WebAssembly – přičemž já jsem se k ničemu takovému nevyjadřoval, protože je mi upřímně jedno, co vám na WebAssembly vyhovuje či nevyhovuje nebo proč ho používáte.

Udělal jste hodně chyb, ale neuvědomujete si to.

> Já od vás žádnou možnost odejít se vztyčenou hlavou nepotřebuju.

Tak si tu plkejte dál.

> Podle vás je věta „a ten React jsme naštěstí už taky dořešili“ uznání chyby?

Ano, protože jsem neodporoval tomu, co jste napsal.

>> Však jsem psal "skoro do konce", ne do úplného konce.
> Napsal jste tohle:
>> Co si pamatuju, tak i těsně u konce existence IE měl furt větší podíl než nástupce Edge (UWP).
> Mezi koncem legacy Edge a koncem IE uběhly čtyři roky. To je podle vás „těsně“? A pokud měl IE více než čtyři roky před koncem větší podíl, než tehdejší Edge, o čem to vypovídá? Bavili jsme se původně o tom, jestli uživatelé přestali používat IE sami, nebo jestli jim ho Microsoft nějak násilně utnul. Připadá vám to, že měl IE čtyři roky před koncem podpory ze strany Microsoftu, podíl méně než jedno procento, že ho uživatelé používali?

Ano, po většinu z těch čtyr let vedl IE nad Edge (UWP). Ono taky první roky byl prakticky nepoužitelný. Spousta webů v něm byla rozbitá, nejelo tam např. Javové prihlášení do Komerční banky (Edge měl whitelistovaný jen plugin pro Flash, jiné ne) nebo embedované komentáře Disqus (ty tam nejely až do poslední verze legacy Edge).

> Ta čárka je tam proto, že odděluje dvě věty v souvětí. Bez čárky by to nedávalo žádný smysl. Nemůžu za to, že neumíte česky.

Váš problém je, že i když jsem tu chybu uznal, vy ji tu furt točíte jak zacyklená deska.

> Já se ale nechci posouvat dál od faktů, jako vy.

Proto si tu ty fakty furt vyměňujeme ;-)

> Ano, už několik dní tu řešíme, že plácáte nesmysly. Netušil jsem, že to, že něco nevíte a vymýšlíte si, vás posouvá dál. Mne teda dál posouvá přesný opak – že se něco nového dozvím.

Ano, už několik dní tu řešíme, že plácáte nesmysly. Netušil jsem, že to, že něco nevíte a vymýšlíte si, vás posouvá dál. Mne teda dál posouvá přesný opak – že se něco nového dozvím.

> Tak směle do toho, příležitostí jste si tu vytvořil mnoho. Naposledy to, že jsem někde měl tvrdit, že dvacet let používám technologii starou deset let. Tam se vám nějak nepodařilo chybu uznat, místo toho se vymlouváte na to, že jsem puntičkář, když trvám na tom, že to souvětí má jenom jeden možný význam a ta čárka tam není na okrasu, ale proto, že bez ní by to nedávalo žádný smysl.

O jakých příležitostech tu mluvíte? Zkusil jste např. napsat komentář bez urážek? Pak bych vám klidně nechal "poslední slovo", na kterém tolik lpíte :-)

Ten JSX se kompiluje/tran­spiluje.
JSX není React.

Vyjma toho Reactu to vše ale platí
Neplatí. WebAssembly se nepoužívá jako náhrada pluginů. WebAssembly neumožňuje obejít chybějící podporu standardů ze strany prohlížeče. Moderní webové frameworky se nekompilují do WebAssembly. Internet Explorer prakticky skončil na nezájem uživatelů dávno před tím, než Microsoft oficiálně ukončil jeho podporu. Ve všech případech vy jste tvrdil něco podstatně jiného.

Ano, po většinu z těch čtyr let vedl IE nad Edge (UWP).
Za prvé, po většinu z těch čtyř let byl Edge (UWP) už nahrazen Edge (Chromium). Za druhé, jak ukazuje mnou odkazovaná statistika, Edge (UWP) předběhl IE už v průběhu roku 2019. Neporovnáváte náhodou IE s Edge legacy v době, kdy už byl Edge legacy nahrazen Edge založeným na Chromiu?

Váš problém je, že i když jsem tu chybu uznal, vy ji tu furt točíte jak zacyklená deska.
Ne, vy jste tu chybu neuznal, místo toho jste se vymlouval, že jsem puntičkář, který bazíruje na čárce – aniž byste se trápil tím, že bez čárky by to nedávalo žádný smysl.

Proto si tu ty fakty furt vyměňujeme ;-)
Akorát je ta výměna poněkud jednostranná.

Ano, už několik dní tu řešíme, že plácáte nesmysly.
Škoda, že jste za celou dobu přišel s jediným mým údajně nesmyslným tvrzením, které se mělo týkat toho, proč vy používáte WebAssembly – přičemž já jsem o ničem takovém nepsal.

O jakých příležitostech tu mluvíte?
Mluvím o tom, že jste tu napsal mnoho věcí, které nejsou pravda. Například jste napsal, že jsem někde tvrdil, že mám 20 let zkušeností s technologií, která je stará 10 let. Když jsem vám to vyvrátil, reagoval jste na to takto:

Tohle vaše puntíčkaření (např. čárka ve větě s Reactem) vám znemožňuje se posunout dál.
Tomu říkáte uznání chyby?

Další věci, které nejsou pravda, jsem jmenoval už v předchozích komentářích. Chcete to i s citáty a s odkazy?

Podstatné je to, že velká část toho, co jste napsal, není pravda. Takže vaše závěry jsou k ničemu, protože po odstranění nepravd z tvrzení, ze kterých vycházíte, nezbyde skoro nic.

Zkusil jste např. napsat komentář bez urážek?
Já jsem v této diskusi nenapsal jedinou urážku. To, že blábolíte nesmysly, není urážka, je to pouhé konstatování faktu po té, co jste byl několikrát upozorněn, že je to jinak, ale vy jste na těch nesmyslech trval.

Pak bych vám klidně nechal "poslední slovo", na kterém tolik lpíte :-)
Zase jenom váš další výmysl. Mohl bych o vás napsat totéž.

> JSX není React.

Až na to, že ho vytvořil Facebook pro React.

> Neplatí. WebAssembly se nepoužívá jako náhrada pluginů. WebAssembly neumožňuje obejít chybějící podporu standardů ze strany prohlížeče. Moderní webové frameworky se nekompilují do WebAssembly.

Až na to, že jsem uvedl konkrétní příklady, např. od Microsoftu.

> Internet Explorer prakticky skončil na nezájem uživatelů dávno před tím, než Microsoft oficiálně ukončil jeho podporu. Ve všech případech vy jste tvrdil něco podstatně jiného.

Až na to, že jsem uvedl konkrétní příklady webů (bank, ...) a služeb (Disqus, ...), které nikdy v Edge (UWP) nefungovaly.

> Za prvé, po většinu z těch čtyř let byl Edge (UWP) už nahrazen Edge (Chromium). Za druhé, jak ukazuje mnou odkazovaná statistika, Edge (UWP) předběhl IE už v průběhu roku 2019. Neporovnáváte náhodou IE s Edge legacy v době, kdy už byl Edge legacy nahrazen Edge založeným na Chromiu?

Až na to, že jsem dal odkaz na Wikipedii, kde se explicitně píše, že Edge (Chromium) je late 2018. Náhoda s tím vaším rokem 2019? Nemyslím si.

> Ne, vy jste tu chybu neuznal, místo toho jste se vymlouval, že jsem puntičkář, který bazíruje na čárce – aniž byste se trápil tím, že bez čárky by to nedávalo žádný smysl.

To jsem psal až později.

> Akorát je ta výměna poněkud jednostranná.

Ditto.

> Škoda, že jste za celou dobu přišel s jediným mým údajně nesmyslným tvrzením, které se mělo týkat toho, proč vy používáte WebAssembly – přičemž já jsem o ničem takovém nepsal.

Furt o tom píšete.

> Mluvím o tom, že jste tu napsal mnoho věcí, které nejsou pravda. Například jste napsal, že jsem někde tvrdil, že mám 20 let zkušeností s technologií, která je stará 10 let. Když jsem vám to vyvrátil, reagoval jste na to takto:

Např. = jediná věc a tu jsem uznal.

> Tomu říkáte uznání chyby?

Já ji uznal už předtím, ale vy jste to jaksi přehlédl (jako vše, co sděluju).

> Další věci, které nejsou pravda, jsem jmenoval už v předchozích komentářích. Chcete to i s citáty a s odkazy?

Já citáty a odkazy na zdroje dávám.

> Podstatné je to, že velká část toho, co jste napsal, není pravda. Takže vaše závěry jsou k ničemu, protože po odstranění nepravd z tvrzení, ze kterých vycházíte, nezbyde skoro nic.

Ten React a čárku v souvětí jsem uznal. Co tam máte dál?

>> Zkusil jste např. napsat komentář bez urážek?
> Já jsem v této diskusi nenapsal jedinou urážku. To, že blábolíte nesmysly, není urážka, je to pouhé konstatování faktu po té, co jste byl několikrát upozorněn, že je to jinak, ale vy jste na těch nesmyslech trval.

Takže nezkusil.

> Zase jenom váš další výmysl. Mohl bych o vás napsat totéž.

Ale já jsem vám nabídl, že přestanu odepisovat.

Až na to, že ho vytvořil Facebook pro React.
„Vytvořil pro“ neznamená „je“. Jak už jsem vám vysvětloval, JSX se běžně používá bez Reactu a React se dá používat bez JSX. JSX je jenom syntaktický cukr.

Až na to, že jsem uvedl konkrétní příklady, např. od Microsoftu.

Uvedl jste .NET MAUI, který se používá pro vývoj mobilních a desktopových aplikací, ne webových aplikací. Kód může běžet po Android, iOS, Windows a MacOS – ale ne ve webovém prohlížeči.

Dále jste uvedl Blazer. Asi jste myslel Blazor. Ten se vskutku kompiluje do WebAssembly a JavaScriptu. A je tak závratně často používaný a oblíbený, že se v každoroční anketě o frontendových frameworcích neprobojoval ani do první dvacítky.

Až na to, že jsem uvedl konkrétní příklady webů (bank, ...) a služeb (Disqus, ...), které nikdy v Edge (UWP) nefungovaly.
A to s nezájmem uživatelů o Internet Explorer souvisí přibližně jak?

Až na to, že jsem dal odkaz na Wikipedii, kde se explicitně píše, že Edge (Chromium) je late 2018. Náhoda s tím vaším rokem 2019? Nemyslím si.
Co kdybyste se na konečně podíval na ty statistiky?

Furt o tom píšete.
Nenapsal jsem o tom ani čárku. To vy o tom píšete pořád dokola.

Já ji uznal už předtím, ale vy jste to jaksi přehlédl (jako vše, co sděluju).
Jo, a kde přesně jste to uznal? Tady (včera 23:29) jste znovu spojil Recat a 20 let. Pak následoval tento váš komentář (dnes 10:49), kde jste k tomuto tématu napsal:
Tohle vaše puntíčkaření (např. čárka ve větě s Reactem) vám znemožňuje se posunout dál. Tohle tady řešíme už nekolik dní.
Mezi těmito dvěma vašimi komentáři existuje nějaký váš komentář, kde jste tu chybu uznal? Můžete na něj dát odkaz?

Já citáty a odkazy na zdroje dávám.
Jo jo, celý jeden odkaz na zdroj v předchozím komentáři. To jste se rozšoupnul.

Takže nezkusil.
Když jsem tu nenapsal jedinou urážku, a komentáře jsem tu napsal, tak zkusil. Základy logiky. Navíc to, že jsou to bludy (což je konstatování faktu o vašem sdělení, není to urážka), jsem napsal až po té, co jsem vás upozornil na několik chyb, a vy místo abyste si to dostudoval nebo přiznal, že o tom nic nevíte, vymýšlel jste další a další nesmysly.

A nakonec tu pořád dokola opakujete, že jste to uznal, že jste psal o Reactu bludy. Tak co se vám nelíbí.

Ale já jsem vám nabídl, že přestanu odepisovat.
Kde přesně? A co takhle že byste přestal psát o věcech, kterým nerozumíte, to by nešlo?

5. 8. 2024, 17:04 editováno autorem komentáře

> „Vytvořil pro“ neznamená „je“. Jak už jsem vám vysvětloval, JSX se běžně používá bez Reactu a React se dá používat bez JSX. JSX je jenom syntaktický cukr.

Třeba kde?

> Uvedl jste .NET MAUI, který se používá pro vývoj mobilních a desktopových aplikací, ne webových aplikací. Kód může běžet po Android, iOS, Windows a MacOS – ale ne ve webovém prohlížeči.

.NET MAUI je multiplatformní řešení a vy se asi bojíte o svoji webovou platformu, když tohle šíříte.

> Dále jste uvedl Blazer. Asi jste myslel Blazor. Ten se vskutku kompiluje do WebAssembly a JavaScriptu. A je tak závratně často používaný a oblíbený, že se v každoroční anketě o frontendových frameworcích neprobojoval ani do první dvacítky.

Asi protože se stránka jmenuje "State of JavaScript 2023: Front-end Frameworks"? Jak jsme si už minule vysvětlili, ve WebAssembly řešeních je JS jen glue vrstva mezi WASM a API browseru. V případě řešební od MS často vygenerovaná v pozadí.

> A to s nezájmem uživatelů o Internet Explorer souvisí přibližně jak?

Že museli používat IE místo Edge (pokud nepoužívali něco jiného, ale to by pak neřešili Edge).

> Co kdybyste se na konečně podíval na ty statistiky?

Vy sám zmiňujete rok 2019.

> Nenapsal jsem o tom ani čárku. To vy o tom píšete pořád dokola.

Já vidím vás.

> Jo, a kde přesně jste to uznal? Tady (včera 23:29) jste znovu spojil Recat a 20 let. > (...)

Tož to já se klidně omluvím znovu, když jste to přehlédl: Omlouvám se na neznalost (sloučení) mezi React JS a React Native a pochopení čárky v jednom souvětí.

> Jo jo, celý jeden odkaz na zdroj v předchozím komentáři. To jste se rozšoupnul.

A kolik vy?

> Když jsem tu nenapsal jedinou urážku, a komentáře jsem tu napsal, tak zkusil. Základy logiky. Navíc to, že jsou to bludy (což je konstatování faktu o vašem sdělení, není to urážka), jsem napsal až po té, co jsem vás upozornil na několik chyb, a vy místo abyste si to dostudoval nebo přiznal, že o tom nic nevíte, vymýšlel jste další a další nesmysly.

Co z toho není pravda? (vyjma omluvy výše)

> A nakonec tu pořád dokola opakujete, že jste to uznal, že jste psal o Reactu bludy. Tak co se vám nelíbí.

Vyřešeno výše.

> Kde přesně? A co takhle že byste přestal psát o věcech, kterým nerozumíte, to by nešlo?

Podmínku (jedinou!) jsem uvedl.

Třeba kde?
Třeba Preact, Vue, React Native, Hono…

.NET MAUI je multiplatformní řešení a vy se asi bojíte o svoji webovou platformu, když tohle šíříte.
Když on to šíří také Microsoft: What is MAUI?

Asi protože se stránka jmenuje "State of JavaScript 2023: Front-end Frameworks"? Jak jsme si už minule vysvětlili, ve WebAssembly řešeních je JS jen glue vrstva mezi WASM a API browseru. V případě řešební od MS často vygenerovaná v pozadí.
Kdyby existoval nějaký aspoň trošku používaný webový frontendový framework, který by používal WASM, v té anketě by se objevil. Stejně jako se tam objevují backendová řešení.

Že museli používat IE místo Edge (pokud nepoužívali něco jiného, ale to by pak neřešili Edge).
Takže část z těch užití IE byla podle vás „z donucení“, takže skutečný zájem uživatelů o IE byl ještě menší.
Neměl Edge náhodou režim zpětné kompatibility, že bylo možné pro některé stránky použít jádro Trident? A neměl Edge nějaký seznam domén, na kterých by tohle aplikoval automaticky?

Vy sám zmiňujete rok 2019.
A co kdybyste se na ty statistiky> konečně podíval?

Já vidím vás.
Ale jakási záhadná síla vám brání vložit odkaz.

Tož to já se klidně omluvím znovu, když jste to přehlédl
Kde konkrétně jsem to přehlédl? Zase vám nějak vypadl odkaz.

Omlouvám se na neznalost (sloučení) mezi React JS a React Native a pochopení čárky v jednom souvětí.
Jinak o Reactu jste těch nesmyslů napsal víc. V případě toho souvětí nešlo o nepochopení čárky – bez té čárky by to nedávalo vůbec žádný smysl. Takže problém opravdu nebyl v jedné čárce, jak se snažíte tvářit.

A kolik vy?
Tři. Odkazy jsou takové ty červené podtržené části textu. Odkaz na statistiky jsem vám dával už dříve, předpokládal jsem, že si ho umíte najít. Ale asi ne, tak jsem vám ho teď znovu zopakoval.

Co z toho není pravda?
Stále to samé, co jsem psal už několikrát.

Podmínku (jedinou!) jsem uvedl.
A já jsem ji splnil ve všech svých komentářích pod tímto článkem.

> Třeba Preact, Vue, React Native, Hono...

Takže "react" dokonce 2x. Náhoda?

> Když on to šíří také Microsoft: What is MAUI?

Co si pamatuju, tak ta ukázková app Kalkulačka jela i v prohlížeči.

> Kdyby existoval nějaký aspoň trošku používaný webový frontendový framework, který by používal WASM, v té anketě by se objevil. Stejně jako se tam objevují backendová řešení

Není podezřelé , že tam není nic od Microsoftu? Když mluvíte i o backendu.

> Takže část z těch užití IE byla podle vás „z donucení“, takže skutečný zájem uživatelů o IE byl ještě menší.
Neměl Edge náhodou režim zpětné kompatibility, že bylo možné pro některé stránky použít jádro Trident? A neměl Edge nějaký seznam domén, na kterých by tohle aplikoval automaticky?

Microsoft nutil Edge (UWP), ale protože moc nefungoval, tak si to lidi přenastavovali na IE. Seznam domén pro režim IE byl jen v doméně. Pro domácí uživatele byla jednorázová volba v menu. Párkrát to člověk otevře v IE, a pak si ho nastaví jako výchozí. Mluvím o lidech, kteří nechtěli Chrome/FF/...

> A co kdybyste se na ty statistiky konečně podíval?

Já vám rok 2019 věřím. Přece byste nelhal ;-)

> Ale jakási záhadná síla vám brání vložit odkaz.

Když ono je to už asi tak 20 komentářů...

> Jinak o Reactu jste těch nesmyslů napsal víc. V případě toho souvětí nešlo o nepochopení čárky – bez té čárky by to nedávalo vůbec žádný smysl. Takže problém opravdu nebyl v jedné čárce, jak se snažíte tvářit.

Mně to smysl dávalo.

> Tři. Odkazy jsou takové ty červené podtržené části textu. Odkaz na statistiky jsem vám dával už dříve, předpokládal jsem, že si ho umíte najít. Ale asi ne, tak jsem vám ho teď znovu zopakoval.

Za těch asi 20 + 20 komentářů jsme dali odkazů přibližně stejně.

> Stále to samé, co jsem psal už několikrát.

Já vám dal konkrétní příklady takového využití, i když jste tvrdil, že to nikdo nedělá.

> A já jsem ji splnil ve všech svých komentářích pod tímto článkem.

To si každý může ověřit. Historie tu je vidět.

5. 8. 2024, 18:48 editováno autorem komentáře

Takže "react" dokonce 2x. Náhoda?
Ne, React ani jednou.

Co si pamatuju, tak ta ukázková app Kalkulačka jela i v prohlížeči.
To běžte vysvětlovat Microsoftu.

Není podezřelé , že tam není nic od Microsoftu? Když mluvíte i o backendu.
Není, protože od Microsoftu jsou jenom dvě věci, které patří do tohoto světa: TypeScript a Visual Studio Code. Ani jedno z toho pochopitelně nenajdete pod knihovnami. TypeScript najdete pod JavaScript Flavors. WASM mimochodem najdete pod Other features.

Když ono je to už asi tak 20 komentářů...
Klidně je můžeme vylučovat po jednom. Tak dejte odkaz na první komentář.

Mně to smysl dávalo.
Jasně, dva přísudky v jedné větě… Pak asi neumíte česky.

Za těch asi 20 + 20 komentářů jsme dali odkazů přibližně stejně.
Zase vám nějak vypadl odkaz na komentář, kde jste se údajně (poprvé) omluvil za tu demagogii s dvaceti lety a Reactem.

Já vám dal konkrétní příklady takového využití, i když jste tvrdil, že to nikdo nedělá.

Tvrdil jste tohle: WebAssembly je jen moderní podoba pluginů, aby to bylo nezávislé na architektuře CPU a běželo v sandboxu (pro pohodlnost v tom, který tam je už pro JS).

Přičemž vlastností pluginů bylo to, že to byly procesy nezávislé na prohlížeči, které nebyly omezené tím, co umí prohlížeč. Používaly se tedy pro implementaci věcí, které v prohlížeči udělat nešlo. Třeba interaktivní animace (prohlížeče tehdy neměly canvas) nebo práce se systémovými certifikáty.

Naproti tomu WebAssembly spuštěný v prohlížeči má k dispozici jenom API prohlížeče (Web API), nemůže dělat nic jiného, než JavaScript v prohlížeči.

Neuvedl jste žádný příklad toho, že by se pluginy používaly jenom proto, abyste mohl z pluginu volat prohlížečová API. Ono by to nedávalo žádný smysl, protože ta režie mezi pluginem a API prohlížeče byla ještě daleko větší, než mezi WebAssembly a API prohlížeče.

To si každý může ověřit. Historie tu je vidět.
Přesně tak. Jsou nějaké urážky v mém předchozím komentáři? Nejsou.

> Ne, React ani jednou.

Asi neumím počítat :-P

> To běžte vysvětlovat Microsoftu.

OMG, koukám, že Microsoft zrušil nejen podporu webu, ale i Linuxu. No tak to je ta technologie mrtvá. Soudím, že v tom mají prsty Indové, co infiltrují americké korporace.

> Není, protože od Microsoftu jsou jenom dvě věci, které patří do tohoto světa: TypeScript a Visual Studio Code. Ani jedno z toho pochopitelně nenajdete pod knihovnami. TypeScript najdete pod JavaScript Flavors. WASM mimochodem najdete pod Other features

A co ta spousta firemních webů, co jede na technologiích Microsoftu?

> Zase vám nějak vypadl odkaz na komentář, kde jste se údajně (poprvé) omluvil za tu demagogii s dvaceti lety a Reactem.

Proč by mě to mělo trápit? Omluvil jsem se podruhé.

> Přičemž vlastností pluginů bylo to, že to byly procesy nezávislé na prohlížeči, které nebyly omezené tím, co umí prohlížeč. Používaly se tedy pro implementaci věcí, které v prohlížeči udělat nešlo. Třeba interaktivní animace (prohlížeče tehdy neměly canvas) nebo práce se systémovými certifikáty.

A jsme zase na začátku. Mluvil jsem o pluginech Flash/Java/Unity3D. Vy byste takovou aplikaci asi nazval třeba applet (tak se jmenovaly v Javě). Třeba ten certifikát pro Komerčku byl Java applet. Už tehdy by si nikdo neinstaloval obecný plugin (ono i ty Java applety se později musely whitelistovat v Ovládacích panelech).

> Naproti tomu WebAssembly spuštěný v prohlížeči má k dispozici jenom API prohlížeče (Web API), nemůže dělat nic jiného, než JavaScript v prohlížeči.

Může dělat např to, co pluginy zmiňované výše. Jak např Quake 3 zkompilovaný do WebAssembly, tak "skrytý" (obfuskovaný) výpočet certifikátu.

> Neuvedl jste žádný příklad toho, že by se pluginy používaly jenom proto, abyste mohl z pluginu volat prohlížečová API. Ono by to nedávalo žádný smysl, protože ta režie mezi pluginem a API prohlížeče byla ještě daleko větší, než mezi WebAssembly a API prohlížeče.

Mluvil jsem přednostně o canvasu (a dohledal, že ani screen reader API není problém) a výše příklad výpočtu.

> Přesně tak. Jsou nějaké urážky v mém předchozím komentáři? Nejsou

To nechám na ostatních.

Asi neumím počítat :-P
Nebo spíš nechápete, že Preact ani React Native není React. Podobně jako Visual Studio Code není Visual Studio.

OMG, koukám, že Microsoft zrušil nejen podporu webu
No a vtom je právě mezi námi ten rozdíl. Já bych se na ten web Microsoftu šel podívat nejpozději po té, co byste explicitně napsal, že to WebAssembly nepodporuje. Vy ne, vy se hádáte o věcech, které jste si neověřil.

Omluvil jsem se podruhé.
Asi vážně neumíte počítat.

A jsme zase na začátku. Mluvil jsem o pluginech Flash/Java/Uni­ty3D.
Že píšete obecně „pluginy“, ale myslíte tím konkrétní tři pluginy, to z vás vylezlo až dost pozdě. Každopáně je to úplně jedno. Protože to mé tvrzení platí i v případě, když budete brát v úvahu jenom tyhle tři pluginy. Jenže vy místo toho, abyste se věnoval podstatě sdělení, jenom hledáte něco, o čem byste se mohl hádat

Může dělat např to, co pluginy zmiňované výše. Jak např Quake 3 zkompilovaný do WebAssembly, tak "skrytý" (obfuskovaný) výpočet certifikátu.
Nemůže. Pluginy (i jen ty tři vámi vyjmenované, třeba Java) mohly například číst a zapisovat do souborů na lokálním disku, zcela mimo prohlížeč. Mohly komunikovat po síti libovolným protokolem, ne jen HTTP – klidně mohly komunikovat přes UDP. Mohly nastartovat síťový server. Mohly používat certifikáty v systémovém úložišti certifikátů – třeba jimi podepisovat. To všechno WebAssembly co? Ano, správně, to všechno WebAssembly v prohlížeči nemůže. K lokálním souborům se můžete dostat přes nové API, ovšem to není vlastnost WebAssembly, to je vlastnost prohlížeče a můžete to používat i z JavaScriptu (resp. jiná možnost, než JavaScript není – i z WebAssembly se k tomu dostanete jen přes JavaScript, jako k jiným Web API).

Mluvil jsem přednostně o canvasu (a dohledal, že ani screen reader API není problém) a výše příklad výpočtu.
Jenže canvas není vlastnost WebAssembly, je to vlastnost prohlížeče. A můžete do něj kreslit pomocí JavaScriptu, žádné WebAssembly nepotřebujete.

Ty pluginy se pro kreslení nepoužívaly proto, abyste mohl použít jiný jazyk, ale proto, že nebyl canvas. Ostatně nejpoužívanější pro kreslení byl Flash používající ActionScript, který vycházel z EcmaScriptu. Takže to byste si moc nepomohl.

To nechám na ostatních.
Ostatní ale nic o urážkách nepsali. To vy. Takže zase další vaše tvrzení, které nejste schopen dokázat? Přitom by stačilo citovat z nějakého mého komentáře, to by nemělo být nic těžkého.

> Nebo spíš nechápete, že Preact ani React Native není React. Podobně jako Visual Studio Code není Visual Studio.

Kdo by to čekal? Přitom jsou funkčně tak podobné (možná i ta rozšíření jsou dnes kompatibilní).

> No a vtom je právě mezi námi ten rozdíl. Já bych se na ten web Microsoftu šel podívat nejpozději po té, co byste explicitně napsal, že to WebAssembly nepodporuje. Vy ne, vy se hádáte o věcech, které jste si neověřil.

Ale já si je ověřil. Akorát jsem nečekal ,že nejen že nová verze nepřidá nic nového, oni dokonce zruší to, co tam už fungovalo. Navíc to není chyba WebAssembly, ten samozřejmě furt funguje, ale toho .NET MAUI.

> Asi vážně neumíte počítat.

Do dvou jo.

> Že píšete obecně „pluginy“, ale myslíte tím konkrétní tři pluginy, to z vás vylezlo až dost pozdě. Každopáně je to úplně jedno. Protože to mé tvrzení platí i v případě, když budete brát v úvahu jenom tyhle tři pluginy. Jenže vy místo toho, abyste se věnoval podstatě sdělení, jenom hledáte něco, o čem byste se mohl hádat

Pozdě myslíte před 3 dny? Kolik dní to budeme muset ještě řešit, než to pochopíte? Ok, já mám čas. Každopádně moje tvrzení taky platí, i když budeme brát jen ty 3 pluginy (možnost programovat ve svém oblíbeném jazyce - tehdy spousta dnešních nebyla a C# a Java byly dost rozšířené). Jenže vy místo toho, abyste pochopil podstatu mého sdělení, jenom hledáte něco, o čem byste se mohl hádat.

> Nemůže. Pluginy (i jen ty tři vámi vyjmenované, třeba Java) mohly například číst a zapisovat do souborů na lokálním disku, zcela mimo prohlížeč. Mohly komunikovat po síti libovolným protokolem, ne jen HTTP – klidně mohly komunikovat přes UDP. Mohly nastartovat síťový server. Mohly používat certifikáty v systémovém úložišti certifikátů – třeba jimi podepisovat. To všechno WebAssembly co? Ano, správně, to všechno WebAssembly v prohlížeči nemůže. K lokálním souborům se můžete dostat přes nové API, ovšem to není vlastnost WebAssembly, to je vlastnost prohlížeče a můžete to používat i z JavaScriptu (resp. jiná možnost, než JavaScript není – i z WebAssembly se k tomu dostanete jen přes JavaScript, jako k jiným Web API).

Už před těmi 3 dny jsem psal, že věci navíc (API vně prohlížeče) mě nezajímají. A že to nejde volat přímo z WebAssembly, ale je potřeba glue vrstva v JS, to mě taky nevadí (stejně jako je glue vrstva pro neprimární jazyk(y) v Androidu, iOS, Windows, ...).

> Jenže canvas není vlastnost WebAssembly, je to vlastnost prohlížeče. A můžete do něj kreslit pomocí JavaScriptu, žádné WebAssembly nepotřebujete.

Viz výše glue vrstva. Je to rychlé dost, když to už před mnoha lety utáhlo 3D střílečku Quake 3.

> Ty pluginy se pro kreslení nepoužívaly proto, abyste mohl použít jiný jazyk, ale proto, že nebyl canvas. Ostatně nejpoužívanější pro kreslení byl Flash používající ActionScript, který vycházel z EcmaScriptu. Takže to byste si moc nepomohl.

Ale i tak jsem si mohl vybrat plugin podle jazyka, který se mi líbil víc (samozřejmě byl jsem omezen na jazyky podporované tehdejšími běžně dostupnými pluginy na počítačích uživatelů - na druhou stranu tehdy se o moc víc jazyků nepoužívalo, většina jich ještě neexistovala).

Ale já si je ověřil.
Tak jste si to ověřil špatně. Protože jediné, co jste si měl ověřit, je to, zda je možné s tím programovat webový frontend.

Navíc to po rychlém googlení nevypadá, že by .NET MAUI někdy podporoval webový frontend nebo Linux.

Do dvou jo.
Prima. Teď to ještě bude chtít doladit, abyste nenapočítal do dvou i když je počítaná věc jenom jedna.

Už před těmi 3 dny jsem psal, že věci navíc (API vně prohlížeče) mě nezajímají.
To, že vás něco nezajímá, neznamená, že to neexistuje. Celou dobu se tu bavíme o obecných vlastnostech pluginů (nebo vašich třech pluginů) a WebAssembly. Jestli vás ty vlastnosti zajímají nebo nezajímají je irelevantní.

Ale i tak jsem si mohl vybrat plugin podle jazyka, který se mi líbil víc
Ale nebyla to podstata pluginů.

To je jako kdybyste tvrdil, že osobní auto nahrazuje náklaďák, protože si v něm stejně jako v náklaďáku můžete zvolit barvu potahu na sedačku.

> Tak jste si to ověřil špatně. Protože jediné, co jste si měl ověřit, je to, zda je možné s tím programovat webový frontend.

Však to jsem udělal, dokonce vyzkoušel jejich ukázkovou aplikaci. Ale oni to v další verzi odstranili. Kdo mohl čekat, že to bude druhý GNOME, aby nová verze umělá míň než stará.

> Navíc to po rychlém googlení nevypadá, že by .NET MAUI někdy podporoval webový frontend nebo Linux.

Přechodem z hranatých rohů (UWP) na kulaté to přejmenovali na MAUI (nevím přesně, jak se to jmenovalo předtím - z UWP aplikací to bralo jen UI toolkit).

> Prima. Teď to ještě bude chtít doladit, abyste nenapočítal do dvou i když je počítaná věc jenom jedna.

Takže vám to nestačí 2x? Kolikrát se mám ještě omlouvat?

> To, že vás něco nezajímá, neznamená, že to neexistuje. Celou dobu se tu bavíme o obecných vlastnostech pluginů (nebo vašich třech pluginů) a WebAssembly. Jestli vás ty vlastnosti zajímají nebo nezajímají je irelevantní.

To, že vás něco zajímá, neznamená, že mě taky. Celou dobu se tu bavím o konkrétních vlastnostech pluginů (mých třech pluginů) a WebAssembly. Jestli vás ty vlastnosti nezajímají nebo zajímají je irelevantní.

> Ale nebyla to podstata pluginů.

Jediná správná podstata pluginů (TM)

> To je jako kdybyste tvrdil, že osobní auto nahrazuje náklaďák, protože si v něm stejně jako v náklaďáku můžete zvolit barvu potahu na sedačku.

To říkáte tady v Česku, kde se osobák volí podle velikosti kufru a podpoře tažného zařízení?

Však to jsem udělal, dokonce vyzkoušel jejich ukázkovou aplikaci. Ale oni to v další verzi odstranili.
Chcete říct, že tu verzi .NET MAUI s odstraněnou podporou WebAssembly vydal Microsoft včera? Protože tím, že jste si to měl ověřit, jsem myslel těsně před tím, než jste napsal komentář.

Tak to dělám já. Pokud si něčím nejsem jistý, ověřím si to před psaním komentáře. Pokud si něčím jsem jistý, ale někdo to v diskusi rozporuje, před psaním dalšího komentáře si to ověřím. Proto se nestává moc často, že bych napsal do diskuse něco, co by bylo fakticky špatně.

Takže vám to nestačí 2x? Kolikrát se mám ještě omlouvat?
Zase jste buď vůbec nepochopil, co jsem napsal, nebo na to reagujete demagogickým překrucováním. Tvrdíte, že jste se omluvil dvakrát, ale přitom první omluvu nedokážete citovat, neodkážete ji odkázat. Vypadá to, jako kdyby neexistovala.

Celou dobu se tu bavím o konkrétních vlastnostech pluginů (mých třech pluginů) a WebAssembly.
Celá debata se týkala obecných vlastností prohlížečů. Pokud jste si myslel, že ta zprávička o Servo Engine byla určena konkrétně vám a vývojáři Serva vám chtěli poslat e-mail s tím, co nového Servo umí, a omylem se to objevilo jako zprávička na Rootu, pak jste se spletl. Byla to obecná zprávička určená všem, rozjela se debata o genealogii jader webových prohlížečů (neřešilo se, který prohlížeč jste používal vy) a padla otázka, proč obecně Safari čím dál víc vadí webovým vývojářům.

Ano, mohlo mne varovat, že jste v prvním komentáři řešil, jaký prohlížeč jste používal vy. Ovšem v ostatních komentářích jste nepsal „já“, ale „uživatelé“, takže jsem se domníval, že píšete obecně o vlastnostech prohlížečů; o tom, co dělá většina uživatelů; o tom, co dělá většina vývojářů.

Pokud celou dobu píšete jenom o tom, co používáte vy, pak se omlouvám, že jsem se k tomu vyjadřoval – neměl jsem nikdy v úmyslu vyjadřovat se k tomu, co používáte vy. Pokud jste někdy viděl plugin, který manipuloval s webovou stránkou (pracoval s DOMem) nebo používal jakékoli jiné web API prohlížeče, zajímalo by mne, co to bylo.

> Chcete říct, že tu verzi .NET MAUI s odstraněnou podporou WebAssembly vydal Microsoft včera? Protože tím, že jste si to měl ověřit, jsem myslel těsně před tím, než jste napsal komentář.

Vy si kontrolujete update reporty každé aplikace a knihovny, když o ní mluvíte?

> Tak to dělám já. Pokud si něčím nejsem jistý, ověřím si to před psaním komentáře. Pokud si něčím jsem jistý, ale někdo to v diskusi rozporuje, před psaním dalšího komentáře si to ověřím. Proto se nestává moc často, že bych napsal do diskuse něco, co by bylo fakticky špatně.

Já si to pamatoval přesně, jako by to bylo včera.

> Zase jste buď vůbec nepochopil, co jsem napsal, nebo na to reagujete demagogickým překrucováním. Tvrdíte, že jste se omluvil dvakrát, ale přitom první omluvu nedokážete citovat, neodkážete ji odkázat. Vypadá to, jako kdyby neexistovala.

Proto jsem se pro jistotu omluvil i podruhé ;-)

> Celá debata se týkala obecných vlastností prohlížečů. Pokud jste si myslel, že ta zprávička o Servo Engine byla určena konkrétně vám a vývojáři Serva vám chtěli poslat e-mail s tím, co nového Servo umí, a omylem se to objevilo jako zprávička na Rootu, pak jste se spletl. Byla to obecná zprávička určená všem, rozjela se debata o genealogii jader webových prohlížečů (neřešilo se, který prohlížeč jste používal vy) a padla otázka, proč obecně Safari čím dál víc vadí webovým vývojářům.

Možná debata ve vaší hlavě.

> Ano, mohlo mne varovat, že jste v prvním komentáři řešil, jaký prohlížeč jste používal vy. Ovšem v ostatních komentářích jste nepsal „já“, ale „uživatelé“, takže jsem se domníval, že píšete obecně o vlastnostech prohlížečů; o tom, co dělá většina uživatelů; o tom, co dělá většina vývojářů.

Já plus minimálně jeden další, to už je množné číslo.

> Pokud celou dobu píšete jenom o tom, co používáte vy, pak se omlouvám, že jsem se k tomu vyjadřoval – neměl jsem nikdy v úmyslu vyjadřovat se k tomu, co používáte vy. Pokud jste někdy viděl plugin, který manipuloval s webovou stránkou (pracoval s DOMem) nebo používal jakékoli jiné web API prohlížeče, zajímalo by mne, co to bylo.

Omluva přijata.

Vy si kontrolujete update reporty každé aplikace a knihovny, když o ní mluvíte?
Ne, ale pokud bych tvrdil, že knihovna podporuje WebAssembly a někdo by mi tvrdil, že nepodporuje, tak si otevřu aspoň hlavní stránku té knihovny. Třeba abych zjistil, proč dotyčný nabyl dojmu, že WebAssembly nepodporuje. A protože bych na úvodní stránce uviděl velký obrázek s vyjmenovanými iOS, Android, macOS a Windows (celkem vtipné, že jsou Windows až poslední…), zbystřil bych a pátral bych dál, kam se teda podělo to WebAssembly.

Takže ano, pokud o něčem píšu a mám byť malou pochybnost (třeba proto, že tvrzení rozporuje diskusní partner), fakta si ověřuju. To je schopnost přiznat si chybu.

Já si to pamatoval přesně, jako by to bylo včera.
Pro tyto případy platí ta třetí věta: „Pokud si něčím jsem jistý, ale někdo to v diskusi rozporuje“. Jak jsem psal, schopnost přiznat si chybu, tedy vždy nejprve předpokládám chybu na mé straně. Díky tomu se jednak dozvídám správné informace, a také málokdy napíšu něco, co by bylo fakticky špatně.

Možná debata ve vaší hlavě.
Ne, debata tady na Rootu. Tahle debata, ve které je i tento komentář.

Já plus minimálně jeden další, to už je množné číslo.
Vidím, že už jste vzdal snahu předstírat, že vám jde o konstruktivní diskusi.

Mimochodem, teď jsem vyzkoušel krásnou ukázku použití WebUSB. Pro flashování firmware zařízení přes USB. Nemusíte stahovat žádný podivný flashovací program, řešit, jestli je dostupný pro vaši platformu. Prostě rovnou na stránce s aktuální verzí firmwaru ten firmware do zařízení nahrajete.

Vidím, že už si zvládnete povídat sám se sebou. Tak já jen dodám, že vedle .NET MAUI je paralelně UNO Platform a obojí je .NET / C# (/ XAML). Proto to bylo matoucí. Našel jsem i tu kalkulačku a demo, kde kód mění HTML DOM (není potřeba canvas; v tomto případě animace definovaná jen ve struktuře obsahu, ukázka žádný C# kód nepotřebuje/ne­obsahuje).

Akorát nechápu, proč galerie v Chrome/Edge spadne v inicializaci, když poslední změny v repu jsou týdny staré (chyba v konzoli odkazuje na něco, co bylo z Blink odstraněno, ale podle všeho to bylo ohlášeno s velkým předstihem). Kalkulačka a změna HTML DOM výše mi funguje i v Chrome, ale ta galerie jen ve Firefoxu. Zdá se, že WebAssembly výstup je na druhé koleji. Takže už se psychicky připravuju, jak mi to omlátíte o hlavu ;-)

PS: Jak jsem již psal, Mozilla se vyjádřila, že WebUSB nebude nikdy podporovat. Ale vy se furt navážíte do Safari a děláte, jak kdyby jedno jádro (Blink) mělo být to jediné, které smí lidi používat.

Jak jsem již psal, Mozilla se vyjádřila, že WebUSB nebude nikdy podporovat. Ale vy se furt navážíte do Safari a děláte, jak kdyby jedno jádro (Blink) mělo být to jediné, které smí lidi používat.
Hezky si protiřečíte. Já Firefox nekritizuju. Kdybych tvrdil, že jediné správné jádro je Blink, kritizoval bych Gecko i WebKit. Ale já Gecko nekritizuju.

Právě. Gecko taky nebude umět WebUSB, ale kritizujete jen Safari.

Pochopte už, že nejde o jedno konkrétní API. Až bude nějaký prohlížeč podporovat všechna webová API, bude to znamenat, že se vývoj webu zastavil. Jde o celkový přístup, kdy Apple místo aby do Safari investoval, bere si své zákazníky jako rukojmí. Naštěstí už mu to EU zatrhla. Podobně to kdysi bral Microsoft s MSIE, když si řekl „stejně všichni musí mít MSIE, tak už nemusíme do MSIE dál investovat“. Když se pak po několika letech probral a zjistil, že mu ujel vlak, začal to dohánět. Nejprve obnovil vydávání MSIE. Pak, zjistil, že s ním vlak nedožene. Tak zkusil úplně nové jádro, ale zjistil, že je tam tolik vývoje, že ani s ním by to nedohnal. Tak prostě překonal své ego, že musí mít svůj vlastní prohlížeč, zahodil i EdgeHTML a přidal se k vítězům.

Apple se z toho poučil jenom tak, že pochopil, že „všichni musí mít MSIE“ nestačí, je potřeba přitlačit víc na „nikdo nemusí mít nic jiného, než Safari“. Za pár let uvidíme, kolik uživatelů zůstane u Safari, když budou mít volbu.

A Safari nekritizuju jen já, kritizuje ho spousta webových vývojářů. Protože pokud na webu něco nefunguje, v převážné většině případů je v tom namočené Safari. Čehož si prostě dost vývojářů všimne.

Chcete aby i Mozilla "překonala své ego" a přešla na Blink? To bude pěkná totalita.

Uživatelé Apple platí premium, aby mohli být v té walled garden (která se navíc týká jen iOS a i tam to - v EU - končí, částěčně i mimo EU, když Apple povolil emulátory).

A stejně jako někteří kritizují Safari, jsou i tací, kteří kritizují Chrome. Safari je kritizován za nepřidávání funkcí, Chrome je zas první v jejich odstraňování. Žádný prohlížeč/jádro není dokonalý.

7. 8. 2024, 11:01 editováno autorem komentáře

Chcete aby i Mozilla "překonala své ego" a přešla na Blink?
Nechci. Kdybych něco takového chtěl, tak to napíšu.

To bude pěkná totalita.
Nemyslím si. Blink je na tom vlastně velmi dobře z pohledu svobodného vývoje, jenom málo projektů je na tom lépe. Je opensource, přispívat může každý (doopravdy, není to jen teorie), jsou za ním dva velcí hráči, kteří do toho dávají peníze (Google a Microsoft), vedle toho je mnoho dalších, kteří to používají a drobně přispívají (Vivaldi, Opera a další).

Uživatelé Apple platí premium, aby mohli být v té walled garden
Jestli to uživatelé doopravdy chtějí uvidíme, až se projeví opatření EU. Na MacOS, kde mají možnost volby, používá Chrome dvakrát víc uživatelů, než Safari. Takže to spíš vypadá, že si uživatelé Apple platí premium, aby mohli být zavření v kleci.

A stejně jako někteří kritizují Safari, jsou i tací, kteří kritizují Chrome.
Akorát těch kritiků Safari je násobně víc.

Žádný prohlížeč/jádro není dokonalý.
To ale nikdo netvrdil.