Stav odstranění XUL a XBL z Firefoxu

Martin Klíma napsal(a) 2. 9. 2019 v 9:23:

„postupem času se stalo výhodnější přejít na moderní HTML a JavaScript s potřebnými API“
A v čem spočívá ona výhodnost? HTML a JavaScript jsou jazyky určené původně pro tvorbu webových stránek (HTML), jejich rozšíření o dynamické prvky (JavaScript) a svými vlastnostmi jsou pro psaní na klientu běžícíh aplikací naprosto nevhodné. V základu totiž neobsahují žádné možnosti přístupu k operačnímu systému ani jiným binárním API, tyto funkce je pak nutné doplňovat všemožnými rozšiřujícími frameworky, což v důsledku znamená extrémně vysokou režii paměti a výpočetního výkonu. Výborně je toto pozoravtelné na doplňcích pro Firefox, kdy u všech doplňků majících nějaké uživatelské rozhraní došlo po přechodu na API WebExtensions k nárustu nároků na systémové prostředky (skutečnost, že pouhé přepnutí z jedné karty na druhou v menu trvá na stroji s 8GB RAM a 4jádrovým CPU přes sekundu, a to ještě s akustickou signalizací pomocí ventilátoru, opravdu není v pořádku) a omezení funkcionality kvůli chybějícím funkcím (pardon, bezpečnostním hrozbám), jako třeba těm pro přístup k souborům, v novém API.
Shrnuto, přechodem na „moderní“ webové technologie došlo ke zvýšení hradwarových nároků a omezení funkcionality doplňků. Jedinou „výhodu“ tedy vidím v tom, že došlo k přizpůsobení se módnímu trendu, ač nesmyslnému. Ví-li však někdo o praktických výhodách onoho přechodu, budu velmi rád, když je zde sdělí.

1. Michal Stanke napsal(a) 2. 9. 2019 v 9:52:

   Je potřeba rozlišovat použití XUL/XBL pro Firefox jako takový a pak jako „vrstva“ pro doplňky.

   Z pohledu rozhraní samotného Firefoxu poslouží HTML úplně stejně dobře jako XUL. Obojí je variace na XML a popravdě velká část implementace XULu byla nahrazena pomocí Custom Elements. Binding kód v XBL se může taky portovat rovnou do custom elementu, něco by možná šlo nahradit dokonce obyčejnými posluchači (event listener). Když se podíváte na příklad XBL, vlastně to je jen JavaScript s přístupem k internímu API, a na tom se přepisem do skutečného JavaScriptu nic měnit nemusí.

   A pak je tu jedna netechnická výhoda, a to že UI Firefoxu bude rozumět a moci do něj příspívat kdokoliv se znalostí HTML, JS a případně přístupem k dokumentaci interního API, nic víc. A samozřejmě se může jádro zbavit speciálního kódu, který existuje jenom kvůli XULu, který nikdo jiný nepoužívá.

   V případě doplňků je to trochu jiné. XUL/XBL a hlavně přístup k oněm interním API dávaly doplňkům opravdovou moc udělat úplně cokoliv. Je nutné ale podotknout, že nic z toho nebylo stabilní a mohlo se kdykoliv změnit. A jakákoliv malá změna mohla buď rozbít doplněk, nebo naopak po ní doplněk rozbít Firefox. Ten interní přístup neposkytoval žádné skutečné API, žádné definované rozhraní, na které by se mohly obě strany spolehnout. Bylo to i bezpečnostní riziko a třeba něco jako Fission (principialní ochrana před útoky typu Meltdown a Spectre) je s tím nemyslitelná.

   Každopádně pokud máte takový problém s přepínáním panelů, dovolím si odkázat na podporu. Jako první bych klidně rovnou zkusit provést obnovu.

   1. Michal Stanke napsal(a) 2. 9. 2019 v 9:54:

      Jenom doplním, že nejsem vývojář Firefoxu, jenom ho sleduji. A před zavedením WebExtensions API jsem ani žádný doplněk nevyvíjel. Živím se ale jako softwarový inženýr a musím říct, že s WebExtensions API se mi pár doplňků psalo docela dobře.

   2. Martin Klíma napsal(a) 2. 9. 2019 v 18:53:

      Problém nebyl s přepínáním panelů, nýbrž s rychlostí vykreslování uživatelského rozhraní doplňků, oním přepínáním karet jsem myslel ovládací prvky doplňku, nikoliv prohlížeče.

      Jinak celý komentář jsem směřoval spíše k opuštění XUL u doplňků, nicméně ten problém platí obecně. „Webové“ jazyky nebyly nikdy určeny k programování desktopových aplikací a jejich užití pro tento účel s sebou nese mnohá úskalí, ať již nutnost doplnění dodatečných funkcí a vizuálních prvků či pomalejší zpracování rozsáhlého kódu. XUL sice byl derivát XML, tedy HTML syntaxí podobný (mimochodem, HTML není odvozeninou XML, nýbrž SGML), avšak byl od začátku určen pro definici uživatelského rozhraní aplikací, což umožnilo lepší optimalizaci jak jazyka, tak jeho interpreteru.
      Nevím, jestli je to způsobeno přímo užitím HTML a JS, či špatnou implementací API (XUL používá nativní vizuální prvky OS), nicméně i u prohlížeče samotného si lze všimnout výrazného nárůstu vytížení CPU při vykreslování (uživ. rozhraní, ne zobrazovaných stránek). Velmi dobře lze „rychlost“ XUL a HTML porovnat v prohížeči SeaMonkey, který vychází ze starší verze Firefoxu a má většinu rozhraní kompletně v XUL. Práce s tímto rozhraním příliš CPU nevytěžuje, reakce jsou okamžité, nicméně například v okně „nástroje pro vývojáře“, jehož rozhraní je již psáno „novým“ způsobem, jsou reakce ovládacích prvků výrazně pomalejší (i když nejsou zobrazena žádná data).

      K dostatečnosti znalosti HTML pro vývoj – Předpokládám, že když se někdo chce podílet na vývoji určitého projektu, nemá problém naučit se pracovat s techologíí v tomto projektu užívanou. Smysl tohoto argumentu mi tudíž zůstává záhadný.

      K bezpečnostní hrozbě – Ta nastává až v okamžiku, kdy si uživatel „nebezpečný“ doplněk nainstaluje, což však činí vědomně a není tedy problém, aby bral v potaz rizika s instalací spojená.

      Bohužel, celý vývoj Firefoxu se poslední dobou vydává směrem upřednostňování poplatnosti moderním trendům nad praktickými vlastnostmi, prosazování vyšší bezpečnosti za každou cenu (i na úkor funkčnosti) a vnucování představy vývojáře uživateli jako jediné správné možnosti (zrušení možností přizpůsobení UI – uživatelské skiny, úpravy rozložení prvků, znemožnění přidání výjimky pro instalaci nepodepsaných doplňků, kdysi uvažované znemožnění užití nešifrovaného HTTP – nastěstí nerealizované, umělé omezení NPAPI pouze pro Flash). Paradoxní je, že se přitom vývojáři ohání pojmy jako „svobodný prohlížeč“ (Ano, znamená to možnost šíření a úprav kódu, nicméně podobná vyjádření působí zavádějícím dojmem, a uživatel pak očekává, že nad takovým programem bude mít kontrolu, což se nekoná).