To jen ukazuje, jak jsou technologie kolem webu rozbité. Specifikace jsou rozsáhlé a nejasné. Nikdo je nedokáže implementovat správně a ani bezpečně. Už aby se uchytilo něco jiného, co víc slouží uživatelům a neobtěžuje je to reklamami, šmírováním, těžbou kryptoměn apod.
Ideálně pak, aby to bylo spojeno s jednoduššími protokoly, kde poslední verzi specifikace jde najít v jendom dokumentu a člověk nehledá informace po mnoha různých RFC.
Tak zrovna tohle je spíš chyba, jak je to naprogramované, za normální situace by v normálním systému za posledních 30 let fakt nemělo vadit, že jeden proces vyžírá CPU čímkoli...
Špatně je tohle, a to fakt není specifikací:
...and during this injection attempt, it saturates the main thread, disrupting the event loop and causing the interface to collapse...
Moc velké vůči čemu? Drtivá většina věcí, co je ve Web API, je užitečná pro nějakou aplikaci nebo web.
Není pravda, že by se specifikace měnily několikrát za týden. Když je specifikace daného API schválená, tak se už nemění (kromě oprav chyb). Maximálně může za nějakou dobu vzniknout nová verze, která přidává nové možnosti.
> Není pravda, že by se specifikace měnily několikrát za týden.
Zrovna u HTML to bývá 3x za týden. Specifikace jsou tzv Living Standard. Např. následující části byly aktualizovány za poslední 2 dny (30. a 31. října):
DOM: https://dom.spec.whatwg.org/
HTML: https://html.spec.whatwg.org/multipage/
URL: https://url.spec.whatwg.org/
> Maximálně může za nějakou dobu vzniknout nová verze, která přidává nové možnosti.
To není pravda. Občas se to mění tak, že se specifikace změní podle skutečné implementace. Tj. specifikace něco říkala, ale Chrome to implementoval jinak, tak se specifikace změní podle Chrome.
Pokud za změnu specifikace považujete to, že se pro formátování klíčového slova ve specifikaci použije místo elementu var element i, pak se skutečně specifikace mění takto často.
Akorát že to nijak nesouvisí s implementací v prohlížečích.
Občas se to mění tak, že se specifikace změní podle skutečné implementace.
To je záměr. Aby specifikace nebyla teorie odtržená od reality, ale aby to bylo ve specifikaci popsané tak přesně, že každá další implementace se bude chovat stejně. Dokonce je požadováno, aby to bylo v široce používaném prohlížeči implementováno dřív, než dojde ke schválení specifikace.
> Pokud za změnu specifikace považujete to, že se pro formátování klíčového slova ve specifikaci použije místo elementu var element i, pak se skutečně specifikace mění takto často.
To ani nemusím. I bez těch "Editorial: Fix markup + wording" commitů se mění takhle často. Za poslední týden se změnila 31. října, 29. října a 28. října. A pokaždé to byly změny, co s implementací souvisí, protože mění nebo upřesňují chování.
> To je záměr. Aby specifikace nebyla teorie odtržená od reality, ale aby to bylo ve specifikaci popsané tak přesně, že každá další implementace se bude chovat stejně. Dokonce je požadováno, aby to bylo v široce používaném prohlížeči implementováno dřív, než dojde ke schválení specifikace.
To je možné, ale pak se to mění tak, že nové chování není zpětně kompatibilní se starým. Třeba se stane, že Firefox a Safari to naimplementují podle specifikace, Chrome nikoliv, ale pak se specifikace změní podle Chrome, takže nakonec to mají blbě minoritní prohlížeče.
A pokaždé to byly změny, co s implementací souvisí, protože mění nebo upřesňují chování.
Kdybyste se na ty commity podíval, jedno je změna formátování, jedno je upřesnění (které nesouvisí s implementací) a jenom jedno je upřesnění, které by se čistě teoreticky mohlo v implementaci projevit.
Třeba se stane, že Firefox a Safari to naimplementují podle specifikace, Chrome nikoliv, ale pak se specifikace změní podle Chrome, takže nakonec to mají blbě minoritní prohlížeče.
Abych vám to věřil, chtěl bych vidět příklad takového „třeba se stane“.
> To by nebylo moc praktické, zahodit všechny současné weby i s tím, že obsah je přístupný i pro jiné formy konzumace, než je zobrazení, a nahradit to vykreslováním přes WebGPU.
Já bych to nezahodil úplně - aplikace by to mohly normálně používat, akorát by to nebylo přímo v prohlížeči ale třeba v nějaké JS nebo WebAssembly knihovně. Tím by se značně zjednodušila implementace prohlížeče a aplikace by mohla říct, jakou verzi očekává, takže by se s updatem prohlížeče nemusely rozbít stránky, které dříve fungovaly. Nebo naopak, nové CSS vlasnosti by mohly fungovat napříč prohlížeči a ne jenom v Google Chrome, který je implementoval jako jediný.
Já bych to nezahodil úplně - aplikace by to mohly normálně používat, akorát by to nebylo přímo v prohlížeči ale třeba v nějaké JS nebo WebAssembly knihovně.
Takže věci, které se optimalizují až na dřeň, by se nově implementovaly v JavaScriptu nebo WebAssembly, aby se to pořádně zpomalilo a zabíralo ještě víc paměti.
Tím by se značně zjednodušila implementace prohlížeče
Akorát byste to, co je složité na implementaci prohlížeče, přesunul do implementace toho JavaScriptu.
takže by se s updatem prohlížeče nemusely rozbít stránky, které dříve fungovaly.
Což se reálně neděje ani teď, takže je zbytečné to řešit.
Nebo naopak, nové CSS vlasnosti by mohly fungovat napříč prohlížeči a ne jenom v Google Chrome, který je implementoval jako jediný.
Podle mne je důležité, že existuje víc vykreslovacích jader prohlížečů – a bylo by lepší, kdyby Blink dominoval méně.
Implementovat jedno vykreslovací jádro, které by používali všichni, a ještě v JavaScriptu, by byla pozoruhodná kombinace několika naprosto nesouvisejících špatných rozhodnutí. Můžu si taky něco přihodit? Já bych doporučil, aby takové jádro mělo dokumentaci a názvy proměnných, funkcí a objektů v Katalánštině.
> Takže věci, které se optimalizují až na dřeň, by se nově implementovaly v JavaScriptu nebo WebAssembly, aby se to pořádně zpomalilo a zabíralo ještě víc paměti.
To nemusí být pravda. Tím, že by ten kód byl v aplikaci, tak by se mohl lépe specializovat pro konkrétní aplikaci.
> Což se reálně neděje ani teď, takže je zbytečné to řešit.
To se děje, protože se nedrží zpětná kompatibilita.
> Akorát byste to, co je složité na implementaci prohlížeče, přesunul do implementace toho JavaScriptu.
Nebo WebAssembly. Tím by ubylo bezpečnostních problémů a nekompatibilit.
Tím, že by ten kód byl v aplikaci, tak by se mohl lépe specializovat pro konkrétní aplikaci.
Takže by dokonce každá webová stránka měla své vlastní vykreslovací jádro prohlížeče napsané v JavaScriptu. Už předchozí váš komentář byl hodně dada, ale vidím, že jste se ještě překonal.
To se děje, protože se nedrží zpětná kompatibilita.
Nesmysl. Jestli jste něco takového zaslechl od webových vývojářů, tak se bavili o době před dvaceti lety. A nešlo o zpětnou komaptibilitu.
Nebo WebAssembly. Tím by ubylo bezpečnostních problémů a nekompatibilit.
Budu optimista a budu předpokládat, že ten úbytek bezpečnostních problémů by byl po přepisu vykreslovacího jádra z C/C++/Rustu do JavaScriptu/WebAssembly. A ne že by ze bezpečnostní problémy a nekompatibility zlepšily přechodem z JavaScriptu na WebAssembly.
Každopádně třeba takové Servo se vyvíjí už několik let, a pořád z toho není kompletně hotové vykreslovací jádro prohlížeče. A vy byste chtěl vytvořit úplně nové jádro webového prohlížeče, a to ještě pro platformu WebAssembly. Jak dlouho by to asi trvalo?
Navíc nekompatibilita vykreslovacích jader je váš virtuální problém. V praxi takový problém neexistuje. Co se řeší v praxi je nepodpora nebo částečná podpora různých Web API. Nejblíž tomu vašemu virtuálnímu světu by byla chybějící podpora některých CSS funkcionalit, to je to jediné, co by to vaše nové vykreslovací teoreticky mohlo řešit. Akorát že to málokdy opravdu vadí, obvykle to znamená jen to, že v nepodporovaném prohlížeči je něco o něco ošklivější.
> Nesmysl. Jestli jste něco takového zaslechl od webových vývojářů, tak se bavili o době před dvaceti lety. A nešlo o zpětnou komaptibilitu.
Haha. Děje se to dost často, protože ta specifikace se mění často. Už i upřesnění může znamenat ztrátu zpětné kompatibility. Příkladů za pár posledních let je hromada - třeba Chrome odebral Mutation events, nebo vlastnosti selectionStart a selectionEnd přestaly existovat na některých inputech.
> Budu optimista a budu předpokládat, že ten úbytek bezpečnostních problémů by byl po přepisu vykreslovacího jádra z C/C++/Rustu do JavaScriptu/WebAssembly. A ne že by ze bezpečnostní problémy a nekompatibility zlepšily přechodem z JavaScriptu na WebAssembly.
O přepis vůbec nejde. Jde o to, že by to běželo v sandboxu na úrovni aplikace. Teď to běží na úrovni prohlížeče.
> A vy byste chtěl vytvořit úplně nové jádro webového prohlížeče, a to ještě pro platformu WebAssembly.
Neřekl jsem úplně nové. Stačí upravit existující, aby používalo WebGPU API (+ nějaké API pro přístupnost) a přeložit ho pomocí Emscripten.
Takže věci, které se optimalizují až na dřeň, by se nově implementovaly v JavaScriptu nebo WebAssembly, aby se to pořádně zpomalilo a zabíralo ještě víc paměti.
Byl bych mnohem radši, kdyby nebyly tak optimalisované - třeba by vedlo k jejich méně častému používání.
Vyloženě mi vadí, že k zobrazení informací ve stylu text a obrázky
občas potřebuji vysoce optimalisované knihovny pro přehrávání videa, zvuky, složité efekty, apod.
I API o 2 metodách jde naimplementovat dobře a blbě, a naopak otevřené API s miliony pluginů jde udělat stabilně a bezpečně (v krajním případě přes forknutí subprocesu - což ostatně dnes všechny browsery dělají anyway).
Tohle je typický design flaw (a i naznačený rate limiting je jen mitigace debilně udělaného designu, ne řešení)
To máte pravdu. Teď už je to tak složité, že už to nikdo správně nenaimplementuje. Je potřeba to celé zahodit a začít znovu. S tím, že ty původní aplikace by nad novým API mohly běžet tím způsobem, co jsem popsal.
Navíc hodně aplikací vlastně vůbec nezajímá přímo HTML nebo DOM - používají nějakou knihovnu (třeba React), která to nějak použije za ně. Tudíž těmto lidem by bylo jedno, zda ten React bude pracovat s DOMem nebo s něčím efektivnějším.
může to být na úrovni Reactu
React ovšem pracuje s DOMem.
Point je, že to nad SDL 3 API snadno implementujete.
To, co ovšem stále nechápete, je to, že nad SDL 3 API se snadno implementuje drobná část vykreslovacího jádra prohlížeče, kterou už ovšem mají prohlížeče dávno vyřešenou. Takže přepisem byste vůbec nic nezískal.
> To, co ovšem stále nechápete, je to, že nad SDL 3 API se snadno implementuje drobná část vykreslovacího jádra prohlížeče, kterou už ovšem mají prohlížeče dávno vyřešenou. Takže přepisem byste vůbec nic nezískal.
Já bych tam implementoval prakticky všechno - od parsování HTML, CSS, přes DOM a layout engine až po vykreslování. To znamená velkou část. A získal bych menší prohlížeč, kde je menší prostor pro bezpečnostní chyby a je jednodušší jej implementovat.
Krom toho to vyřešené stále nemají, protože jsou v tom stále chyby nebo se to stále mění.
Nezískal byste menší prohlížeč, který je jednodušší implementovat. Tím, že napíšete nový prohlížeč s pomocí jiné technologie, nedocílíte toho, že by byl prohlížeč menší nebo jednodušší na implementaci.
Chyby jsou ve všem a mění se to tak, že se přidávají nové funkce – protože je po nich poptávka. Z prohlížečů se holt stal systém pro spouštění aplikací, takže je poptávka po rozšiřování funkcionality pro ty aplikace.
> Z prohlížečů se holt stal systém pro spouštění aplikací, takže je poptávka po rozšiřování funkcionality pro ty aplikace.
Ano, souhlasím. Klasické HTML pak může být jedna z těch aplikací, už nemusí být součástí prohlížeče. Konkrétně třeba u Chrome by se mohl odstranit celý Blink a Skia - čímž by se Chrome zjednodušil a zmenšil o několik milionů řádků kódu.
Navíc Skia pro WebAssembly už existuje, teď se přepisuje pro WebGPU - pro použití ve Flutteru, který by běžel v prohlížeči. Takže část té práce je už hotová.