Vývojář prohlížeče pro macOS Floato Morten Just otestoval spotřebu paměti webvými prohlížeči v macOS. V testu se dvěma otevřenými stránkami Chrome zabere 730 MB RAM a Safari jen 73 MB. Flotato pak ještě méně a to 63 MB.
Při testu s 54 otevřenými stránkami Chrome zabere 15,3 GB a Safari jen 0,6 GB. Pokud používáte jen prohlížeč, tak velká spotřeba RAM patrně není problém. Autor také podezřívá, že systémový nástroj psrecord nezachytí všechny procesy Safari.
(zdroj: slashdot)
Google už začíná poslední dobou štvát docela dost i mě. Jako prohlížeč používám tradičně Firefox, na telefonu jsem objevil alternativního klienta pro Google Play - Aurora Store. Jen Google Fotky budou hodně bolet. To pořád nevím kam od nich.
Docela by mne zajímalo i porovnání s FF (a Chromium).
Syn používá pro "distančku" starší notebook (2 core, 4 GB RAM, Ubuntu 20.04) a Chromium sežere obě jádra při první záložce a víc než 5 lidí na Google Meet reálně nefunguje; Firefox vydrží až někam ke dvacítce (víc jich tam nebejvá).
Na to, že FF nemá "ty akcelerace" apod. to funguje lépe.
mam v ff kolem 1000 zalozek (jsem bordelar a uklizim parkrat do roka), sice to pak torchu nenazrane - podle toho kolik je jich aktivnich i 6GB RAM. Tuhle jsem ze zvedavosti zkusil refresh all, cca po 15 minutach ff spadnul, nic nedelo. Jak se znova spsustil zalozky byla zpet. Btw tento vrlky pocet nerni nijak extremne zpomalujici start ff (ale asi mi sezere ssd)
Přijde mi to jako nonsese. Když si vezmu, že Epiphany, které má stejné vykreslovací jádro jako Safari a troufl bych si tvrdit, že jinak bude ještě úspornější, po načtení jedné prosté stránky (duckduckgo.com) v paměti bere přes 200 MB... Ano, samotný proces Epiphany má krásně pod 100 MB, ale pak si člověk musí přičíst další procesy WebKitu, které to startuje.
Spousta optimalizací je vně webového jádra. Např. sdílení procesu a RAM cache mezi kartami, odswapování na disk viz komentář níže nebo komprese RAM (např. stránka stáhne JPG, dekomprimuje na bitmapu, kterou pak kreslí při každém překreslení obsahu stránky - pokud by bitmapa v RAM byla komprimovaná rychlým algoritmem zlib, tak je to technicky PNG - ve skutečnosti je bitmapa ne v systémové RAM, ale ve video RAM /GPU akcelerované kreslení stránky/, a tady má Apple výhodu vlastního hardware: HSA architektura umožňuje CPU a GPU pracovat se stejnými daty ve sdílené RAM, tj. není třeba je duplikovat /data ve VRAM se obecně berou jako dočasná, takže se drží kopie v RAM a do VRAM průběžně nahrává jen ty nejčastěji používané/ a není pro něj problém implementovat stejný kompresní algoritmus i pro svoje GPU, takže pro překreslení stránky není třeba bitmapu dekomprimovat /GPU mají komprese textur už dávno, ale nevim o žádné lossless/).
Prostě tady PC a Android světu ujíždí vlak. Sdílená GPU na PC a Android nejsou HSA, takže je třeba bitmapy kopírovat sem a tam a zabírají víc místa. Podobně např většina mobilů má pruhy v gradientech na OLED displeji, protože výrobci mobilů nedokážou upravit hw GPU, driver GPU nebo vykreslovací kód OS (i když je Android opensource, tak na tohle by potřebovali lepší programátory než jen na vlastní launcher), aby obešli nedostatky OLED v tmavých odstínech. Jediná výhoda je, že Apple si říká o pořádnou marži (proč ne, když nemá konkurenci), takže PC/Android ho dotahává hrubou silou (za cenu menší výdrže na baterii při zátěži, ale cenově to i tak může být levnější než Apple).
To je sice pěkné, že jste si dal takovou práci přijít na to, čím by to mohlo být, že Safari žere tak zázračně málo RAM, ale ušetřil byste si čas, kdybyste se podíval na tu odkazovanou diskusi na Ycombinatoru.
Tam byste se dočetl, že autor k takovým číslům došel, protože opravdu nezapočetl všechny renderovací procesy, protože ten nástroj, který používá, to neumí. Když tam někdo použil nástroj, který to seskupení všech procesů Safari umí, dostal se na 750-850 MB při dvou otevřených stránkách. Tedy zhruba na úrovni toho, co je reportované u Chrome. Senzace se nekoná.
1) Čím složitější řešení, tím lepší potřebuješ inženýry a programátory. Proto taky AMD architekturu HSA opustilo. Bez spolupráce od OS a vývojářů aplikací by přínos nebyl takový, aby ospravedlnil tu makačku. Neříkám, že je to špatně - akorát uznávám práci Apple, že se snaží vyždímat každý skrytý kousek výkonu, aby byl konkurenceschopný (koneckonců Zen 3 je i jako CPU obecné architektury výkonnější než M1; ale takhle Apple překonal Zen 2 a Intel, což pro přechod na vlastní CPU není vůbec špatný).
2) Sdílená paměť neznamená HSA. VRAM na Android SoC, Rhapsbery Pi a Intel/AMD iGPU se chová jako samostatná (logická) RAM, jen je fyzicky namapovaná do prostoru systémové fyzické RAM (jde ale měnit její velikost za běhu). U primitivnějších řešení se data do ní musí kopírovat, tj. načtu z disku JPG, dekomprimuju na bitmapu, zkopíruju její bajty do VRAM (fyzicky na další místo ve fyzické RAM). U lepších řešení se označí paměťové stránky dekomprimované bitmapy jako grafická paměť, tj. zero-copy (myslím, že to takhle má nějakej rok AMD; nejde to použít vždy - někdy si aplikace chce ponechat bitmapu pro další práci). Nicméně ani u toho lepšího řešení nemůže s bajty bitmapy ve VRAM pracovat současně CPU a GPU (stránky paměti jsou buď RAM, nebo VRAM - ne obojí).
Tohle řeší HSA (Heterogeneous System Architecture): ačkoli s daty pracuje současně CPU (načtení bajtů JPG z disku), ISP (image signal processor; dekomprese JPG na bitmapu) a GPU (použití bitmapy ve vykreslení stránky), tak bitmapa je ve fyzické RAM jen 1x (a současně na ní mohou přistupovat všechny procesory a koprocesory, včetně funkčnosti cache).
Ani 2 jadra CPU bez synchronizace nemuzou pracovat se stejnymi daty soucasne. Pro svuj argument potrebujes lepsi priklad, nez dekompromaci obrazku. Idealne neco, kde CPU a GPU potrebuje spolupracovat soucasne a nejlepe pouzit nejake atomicke operace. Pokud jenom predavas buffer mezi koprocesory, tak to bohate staci zero-copy.
Když program na 2 CPU jádrech pracuje s jedním kusem paměti současně, tak je pro něj cache transparentní. Nemusí v kódu programu řešit nějaké zamykání paměti a synchronizaci. Tohle je u CPU jader implementováno všude. U iGPU to má Intel - tam se iGPU chová jako další jádro CPU (proto třeba na chromebookách odpadne jedno kopírování obrazu webové stránky). Nevím, jak dnes, ale když AMD opustilo HSA, tak iGPU sice bylo zero-copy (např. nahrávání textur do "VRAM"), ale CPU musel počkat na iGPU, aby s ním dohodl změnu paměťové stránky, že bude patřící pro GPU.
Přístup více jader CPU je cache transparentní ale stejně se synchronizaci nevyhneš jinak se dostaneš do dirty read nebo dirty write situace.
Stejně tak je synchronizace nutná u HSA. CPU nemůže měnit bitmapu textury, ktrou GPU zrovna používá k rasterizaci.
RTX 3080 má paměťovou propustnost 760GB/s... jaká by asi musela být konfigurace RAM HSA řešení, aby nebrzdila takovou GPU když současné ddr4 v čtyřkanálovém zapojení mají propustnos řádově nižší?
Když říkám, že není potřeba synchronizace na aplikační úrovni (např CPU čekající na iGPU, aby mohl dohodnout zero-copy), tak to znamená, že je tam nějaká automatická low-level (takovou, jakou známe u vícejádrových CPU).
GPU stačí porovnávat s podobným výkonem (iGPU x dGPU), tam vyjde iGPU jako efektivnější (dosáhne daného výkonu s menší propustností RAM). Mimochodem Apple si pomáhá větším počtem užších kanálů, takže různá jádra CPU a GPU mohou současné šahat do RAM (latence), i když součet rychlostí do RAM je stejný jako 2kanalálové klasické zapojení.
:D no uz jsem to skoro vzdal, protoze Ladislav Zima na jednoduche problemy odpovida zdlouhavym vysvetlovanim :) ....
on ti na to zase muze rict, ze ty ten JPG musis nejdrive nacist pomoci CPU do RAM a pak to presunout na GPU, na coz mu reknes zase ty, ze se to udela pomoci DMA takovou a takovou rychlosti, na to ti rekne, ale to tam stejne musis mit 2 kopie jednoho obrazku a pak to zabira zbytecne misto, na to my ty reknes, kolik GB pameti ma to GPU a jak velky by ten obrazek musel byt, aby to melo nejaky vyznam a na to on ti zase odpovi, ze ne vsechny zarizeni maji takove parametry a muzou volne rozdavat pamet a na to ty mu reknes, ze zrovna ten Apple m1 ma nejmene 8 GB a to uz kdyz si teda koupis Apple, tak je to vylozene zebracka varianta, ktera i tak vyjde na brutalni prachy
Tak to muzeme takto zkratit a jit dal ....
Mac OS v poslední verzi (a Safari) s ním začaly masivně využívat swap a disk. Nevím, která varianta je lepší, jestli snižovat životnost disku nebo používat operační paměť.
Chrome jsem kvůli jeho způsobu využití paměti přestal používat, způsob, kdy každý web je vlastním procesu dělá výrazný DoS útok na OS. Nelze jednoduše omezit celkové využití paměti a hlavně cpu pro chrome, prostě to jede silou.
Ten swap na disk ale neopotřebovává SSD, protože 1) stránka se uloží zamrzlá (obsah na SSD se opakovaně nepřepisuje) a 2) SSD v Macách je o třídu lepší než ve většině PC (zvládnou více přepisů - ale o to je taky dražší, spousta lidí by upřednostnila méně kvalitní, ale větší SSD). SSD bylo poprvé v Apple v nějakém Air, 64 GB a 4 GB RAM - kvůli malé RAM to furt swapovalo, ale disk stejně bez problému přežil... kolik, 10 let?
Myslel jsem to tak, že je jiná kvalita SSD v notebooku za 15-20 tisíc a v notebooku/macbooku za 30-80 tisíc. Spousta lidí, co se setká s po čase pomalým SSD to zná právě z těch levných notebooků, které Apple ani nevyrábí. Podobně je to s Androidem za 2-5 tisíc verzus Android/iPhone za 20-30 tisíc. Opět, Apple nedělá lowend, takže i roky data generace iPhone z bazaru je kvalitněji udělaná než nový Android za 2,5 tisíce (kde se šetří na každé součástce).
Zjednodušeně :-) Ale časem ho konkurence vždy dožene. Takže zákazník má na výběr lepší, ale dražší teď / levnější a horší teď / stejně dobrý a levnější, ale rok si počkat. Např. se běžně uvádí, že v singlethread výkonu CPU je Qualcomm rok a půl za Apple. Podobně nahrávání videa je u konkurence slabší (např. na posledním Google Pixel 5 se při nahrávání ve 4K telefon přehřeje a aplikace spadne). Jinými slovy, leader musí jít furt vpřed, nesmí se zastavit (a když ho někdo brzdí, tak změna - např. přechod z PowerPC na Intel a teď z Intelu na vlastní). Apple je ve výhodě, že vystartoval první (první smartphone v moderním smyslu, např. ovládaný prsty a jednoduchá instalace aplikací - bez připojování kabelu k PC). Takže stejně jako ve Formuli 1 mu stačí neriskovat a nedělat chyby.
1) stránky jsou ale dynamické, pořád se mění a pořád je potřeba zapsat nová data
2) nikterak nutně ;), dříve se používali pouze SLC disky, ty jsou skoro věčné, bohužel i Apple dnes už používá klasické TLC (a snad i QLC), ty věčné nejsou
Problémů s opotřebením ssd u nových maců je docela dost, namátkou koukám na "mac os ssd wear level" a ten problém existuje.
"Ten swap na disk ale neopotřebovává SSD, protože 1) stránka se uloží zamrzlá..."
Takže ona se tam uloží, ale SSD se tím neopotřebuje? Nějaký zázračný způsob zápisu?
A že dříve existovaly jiné SSD (SLC), které vydržely o jeden dva řády zápisů více, to opravdu není jen záležitost Applu. A tak jako tenkrát, i dnes tam má Apple běžný HW, který koupíte i jinde. Jen prostě někteří když je to v Applu, tak nad tím vidí snad svatozář...
Tak jde o bezpečnostní funkci nebo snad chcete, aby jeden tab měl šanci přistoupit do paměti druhého? To asi ne. Přidělit CPU a paměť samozřejmě jde, ale nedokážu si představit situaci, kdy by to bylo potřeba. K čemu by mi bylo, že bude crashovat nějaký tab, protože nemá k dispozici dostatek paměti.
Před pár lety jsem se staral o tlupu počítačů, Pentia Pro na 133 MHz, 37 MB RAM.
Byly tam tehdá Win 98, odlehčená a říznutá pár knihovnama z Win 95.
Běželo na to >200 výukových programů, prohlížeč, editory všeho možného, stovky vybraných her,...
Asi i proto se mi nelíbí, jak jsou prohlížeče nenažrané a kolik dokáží spotřebovat zdrojů k činnostem, které svou užitnou hodnotou rozhodně nemají 100x vyšší, zatímco 100x vyšší spotřeba zdrojů je jim tolerována.
Jasně je to zkratka. Ve skutečnosti nejde jen o prohlížeče, ale celý ekosystém a programátorskou kulturu této oblasti.
Abych jen nenegoušil, za to "multiplaformní" prostředí, které tu díky prohlížečům máme, jsem rád.
Vy ale neberete v úvahu, jak se od té doby změnila interaktivita aplikací. Že s nimi uživatel ve výsledku pracuje mnohem rychleji, protože za prvé musí mnohem méně čekat, a za druhé má od aplikací mnohem lepší zpětnou vazbu, takže si je při jejich používání mnohem jistější, tudíž pracuje rychleji a dělá méně chyb. Myslím, že ve skutečnosti hodnota aplikací roste rychleji, než jejich spotřeba zdrojů.
IMHO: Bude velký rozdíl, pokud máte počítač vybavený novějším procesorem, s dostatkem RAM, SSD disk,... To řada lidí nemá. Běžné jsou počítače 5 a více let staré. Běžně mají lidí v mém okolí 10 a více let starými notebooky. Pak se i ten uživatelský komfort rapidně klesá, včetně toho čekání, až aplikace něco udělá. Mnohem lepší zpětnou vazbu? Např.?
V rámci pomoci rodinám s domácí výukou jsem zprovoznil desítky počítačů s 1GB RAM a našly se i takové co měly 256MB RAM. Např. pro staré výukové programy, v pohodě dostačující, pro online výuku, nepoužitelné.
Co se interaktivity aplikací týče, pokud se bavíme třeba o aplikacích v prohlížečích, za bonusy v interaktivitě nepovažuji automatické přehrávaní videí v HTML5, ani záplavy trasovacích JavaScriptů a pod.
Srovnám-li Google Docs nebo Office 365, tak nedosahují ani poloviny funkčnosti editoru Ami Pro z před 20 lety. Takže nevím, co máte konkrétně na mysli.
To co to má navíc a jsem za to rád, je např. hromadný přístup k jedné verzi a souběžná editace mnoha uživateli, to ano.
Pokud máte na mysli jiné aplikace než prohlížeče a jejich interakci. Ano, třeba vývojářská IDEčka jsou jistě dál, ale ne zase tak dramaticky dál než třeba Borladní IDE pro Turbo Pascal, které svižně běhalo na počítačích se 4 MB RAM.
Ne, opravdu si nemyslím, že by užitnost aplikací rostla stejným tempem jako jejich nároky na HW.
I na těch 5 let starých počítačích je odezva počítačů výrazně rychlejší, než bylo v době Windows 95. Google Docs nebo Office 365 nedosahují ani poloviny funkčnosti Ami Pro, pokud se zaměříte na sazbu nebo „programátorské“ ovládání. Ami Pro se zase ani nesnilo o možnostech dnešních editorů co se týče možností vkládání dalšího obsahu, napojení na další zdroje dat, práce s jazykem (slovníky, kontrola pravopisu a gramatiky). A vývojářská IDE? Ta dnešní jsou úplně jiná kategorie oproti Turbo Pascalu. To je jako kdybyste porovnával F-16 a Čmeláka.
Re: I na těch 5 let starých počítačích je odezva počítačů výrazně rychlejší, než bylo v době Windows 95.:
S tím tedy nesouhlasím. Samozřejmě, na některé věci se chvíli čekalo, ale běžná interakce, byla svižná, pokud jste neměl rozsáhlé dokumenty.
Nevím co v těch editorech dnes všechno vkládáte. Já si vystačím s texty a obrázky. Výjimečně osnova, seznam literatury, seznam obrázků, poznámky pod čarou, hlavička patička. A to jsou samé oldies goldies.
Na složitější věci raději LaTeX.
S tím Spell Checkerem se pletete. Ten mělo už AmiPro v roce 1988 a obsahoval cca 130tis slov. Sice jen v angličtině, ale nebyl problém mu podstrčit jiné slovníky.
Kontrola gramatiky tu byla už roku 2005 ve Wordu 2003 a doteď jsem v editorech nenarazil na takovou, kterou by mi za to stálo ji používat.
IDEčka, podobně jako třeba některé 3D editory a řada dalších aplikací udělaly skutečně velký posun. Problém "nenažranosti" vidím především u webových aplikací, ale najde se i řada Offline věcí (o Elektronu nemluvě), které jsou, na to co umí, také značně rozežrané.
PS: "hospodářský" stroj a vojenskou stíhačku bych nesrovnával. To že je ta stíhačka našláplá špičkovými technologiemi neříká nic moc o tom, nakolik je ten který typ letadla ve své oblasti efektivní. Také se obě ta letadla vyráběla souběžně ve stejné době.
Tak nevím. Evidentně máme na věc rozdílný názor. Dokážu s tím žít.
Vývoj aplikací by se bez téhle role webového prohlížeče jistě nezastavil.
Takže ty aplikace by byly.
Jen možná nikdo neměl odvahu to vzít pěkně od podlahy, navrhnout a zrealizovat lepší background pro to, co dnes dělají prohlížeče.
Jen se podívejte na ty mraky změn a optimalizací, které mají za cíl ten novodobý OS trochu zefektivnit (QUIC / SPDY, ..), na ty tisíce aplikací, které nějakým způsobem přelepují nedostatky prohlížečů (jen transkompilátorů do JS jsou stovky).
Porovnával jsem to, subjektivně, přes aplikace které existují i v offline verzi.
Např. 1 stránka Gmailu (což je jedna z top aplikací v tomto zvěřinci) zabere cca 500MB RAM.
Když si vezmu, že do toho množství by se mi před 20 lety vešlo 15 operačních systémů a v každém by běžel poštovní klient, který by mi umožnil minimálně 80% funkčnosti, které využívám v Gmailu, tak je to pro mě znechucující.
Přitom Gmail není žádný 3D CAD ani IDEčko. Pracuje se s texty a cachovat někam do paměti má smysl akorát tak přílohy několika nejnovějších zpráv. Nebo tam mít optimalizaci, která se bude umět učit, jak s poštou pracuje ten který uživatel a podle toho si nakešuje pravděpodobné data.
Před pár lety mi tohle téma jeden agenturní frontenďák Googlu říkal svůj pohled: že JavaScript velmi snadno požírá RAM, stačí málo a už ji velmi nesnadno uvolňuje, že mnozí weboví vývojáři, jsa vybaveni našlápnutými vývojářskými mašinami a bez zkušenosti s nižšími programovacími jazyky, nemají cit pro alokaci paměti, ekosystém kolem JavaScriptu že je solidní divočina, best practices se mění, podle toho, kam se který interpret JS pohne a DOM je pomalý moloch.
Vývoj aplikací by se bez téhle role webového prohlížeče jistě nezastavil.
Takže ty aplikace by byly.
To vychází z chybného předpokladu, že vývoj aplikací buď je, nebo není, a pokud je, aplikace se vyvíjejí konstantním tempem. Jenže nic není vzdálenějšího realitě. Množství aplikací totiž závisí na rychlosti vývoje a na množství vývojářů, kteří se mu mohou věnovat. Přičemž v obojím prohlížeče vývoj dost urychlily. Což je dost paradoxní, protože HTML+CSS je dost nevhodný nástroj pro tvorbu GUI a JavaScript je dost nevhodný jazyk pro začátečníky.
Jen se podívejte na ty mraky změn a optimalizací, které mají za cíl ten novodobý OS trochu zefektivnit (QUIC / SPDY, ..)
Zrovna tyhle optimalizace jsou důležitější pro klasické webové stránky než pro webové aplikace. A desktopová aplikace komunikující s HTTP serverem z těch optimalizací těží úplně stejně, jako webová aplikace.
Např. 1 stránka Gmailu (což je jedna z top aplikací v tomto zvěřinci) zabere cca 500MB RAM.
Když si vezmu, že do toho množství by se mi před 20 lety vešlo 15 operačních systémů a v každém by běžel poštovní klient, který by mi umožnil minimálně 80% funkčnosti, které využívám v Gmailu, tak je to pro mě znechucující.
Jenže těch 500 MB zabere i jakákoli jiná aplikace spuštěná v prohlížeči. A těch je mnohem víc, než kolik jich bylo před 20 lety. Navíc ty dnešní aplikace mají mnohem víc možností – u vás to dělá 20 %, jenže u jiného uživatele to bude dělat jiných 20 %, takže ta aplikace toho nakonec umí třeba o 200 % víc.
Před pár lety mi tohle téma jeden agenturní frontenďák Googlu říkal svůj pohled: že JavaScript velmi snadno požírá RAM, stačí málo a už ji velmi nesnadno uvolňuje, že mnozí weboví vývojáři, jsa vybaveni našlápnutými vývojářskými mašinami a bez zkušenosti s nižšími programovacími jazyky, nemají cit pro alokaci paměti, ekosystém kolem JavaScriptu že je solidní divočina, best practices se mění, podle toho, kam se který interpret JS pohne a DOM je pomalý moloch.
To všichni vědí. Jenže i přes tyhle nedostatky je to dnes zdaleka nejefektivnější platforma pro vývoj frontendu. Je to smutné, ale je to tak. Cosi velmi nelichotivého to vypovídá o ostatních platformách.
Vývoj aplikací bez prohlížečů.
Na to mám jiný pohled. Množství aplikací závisí samozřejmě na množství vývojářů a pak na mnoha dalších faktorech. Dostupnosti IT vzdělání, rozšíření HW, vývoj programovacích jazyků, ale jedním z hlavním motorů bych viděl poptávku po aplikacích, a ta by podle mě vzrůstala, tak jak vzrůstala již před nástupem Internetu a prohlížečů. Nepopírám, že multiplaformnost a snadná distribuce, které přišly s prohlížeči tomu napomohly, ale nemyslím si, že bez prohlížečů bychom k tomu stejnému nepřišli jinou cestou.
Zmínil jsem: QUIC / SPDY ale měl jsem na mysli stovky dalších technologií, jako WebAssembly / Ajax / CORBA / WebDAV / ActiveX / Silverlight / Flash / Java Applety / a desítky dalších, které rozšiřují funkčnost webových prohlížečů a snaží se jejich funkčnost přiohnout pro běh webových aplikací. Myslím, že při vhodném návrhu nástroje, který by byl orientovaný na multiplatformní webové aplikace by třeba nikoho nenapadlo, že by byla vhodná bezstavovost relací a desítky dalších aspektů, ze kterých se vycházelo, když byl WWW prohlížeč skutečně jen prohlížeč.
Ne, těch 500MB je údaj o množství paměti, které zabere stránka Gmailu. Údaj beru z Integrovaného správce úloh v Google Chrome.
S povděkem koukám, že aktuálně to už není 500MB jako v roce 2018 ale jen 350MB. Paměť zabranou samotným prohlížečem uvádí cca 300MB + Proces GPU cca 250 MB, + síťařina +50 MB + několik procesů k vykreslování + cca 250MB [TfujTajxl]
Pro srovnání stránka Seznamu žere >500MB, Root 100MB, jednoduchá stránka s pár texty a obrázky, ve které má souhrnný obsah (html + css + grafika) velikost cca 1MB zabere > 30MB, slovy, třicetinásobek, a to mi přijde dost.
<i>Navíc ty dnešní aplikace mají mnohem víc možností.</i>
Ne, to si nemyslím. Můj pohled na věc je že většina uživatelů používá základní funkce a pak je malá skupina těch, kteří tam potřebují nějaké spešl fičůry.
<i>Jenže i přes tyhle nedostatky je to dnes zdaleka nejefektivnější platforma pro vývoj frontendu.</i>
Zde se shodneme a tvrdil jsem to už před 20 lety, že je to jediné skutečně multiplatformní prostředí pro běh aplikací (tehdy jsa znechucen HW nároky Javy).
Ale o tom to právě jde. Nespokojit se s tím, jak fungují prohlížeče a jak se tam postupně snažíme dolepit funkčnost, na kterou nebyly navržené, ale hledat cestu k lepšímu návrhu webové platformy pěkně na čisto se zohledněním toho co o potřebách webových aplikací víme teď.
Nemyslím si, že by poptávka nějak dramaticky rostla. Ten růst je podle mne daný především zlevňováním na straně nabídky, tím pádem se posouváme po poptávkové křivce.
Zmínil jsem: QUIC / SPDY ale měl jsem na mysli stovky dalších technologií, jako WebAssembly / Ajax / CORBA / WebDAV / ActiveX / Silverlight / Flash / Java Applety / a desítky dalších, které rozšiřují funkčnost webových prohlížečů a snaží se jejich funkčnost přiohnout pro běh webových aplikací.
Tohle je taková směska mrtvých technologií, technologií které nesouvisí s webovými aplikacemi, technologií, které existují desítky let… Nevypovídá vůbec o ničem.
Myslím, že při vhodném návrhu nástroje, který by byl orientovaný na multiplatformní webové aplikace by třeba nikoho nenapadlo, že by byla vhodná bezstavovost relací a desítky dalších aspektů, ze kterých se vycházelo, když byl WWW prohlížeč skutečně jen prohlížeč.
Bohužel, Java, Qt, MFC a další neodhadli trend a pro frontend se prosadil web. Protože má velmi nízký vstupní práh pro vývojáře – resp. základ, kterým je HTML+CSS, se za vývoj ani nepovažuje.
Mimochodem, bezestavovost byla původní vlastnost webu, pak přišly webové aplikace založené na CGI, a tenkrát se bezestavovost opustila. Což přetrvalo až do doby SPA, a k bezestavovosti jsme se vrátili až na popud serverových technologií – protože se tak daleko snáz zajišťuje dostupnost. Frontendové technologie se tomu teprve dodatečně přizpůsobovaly.
Ne, těch 500MB je údaj o množství paměti, které zabere stránka Gmailu. Údaj beru z Integrovaného správce úloh v Google Chrome.
Ale integrovaný správce úloh zobrazuje jen paměť celého procesu, podrobnější dělení neumí. Ty další údaje, o kterých píšete, jsou další procesy, které zabezpečují běh prohlížeče.
to mi přijde dost
DOM, navíc reprezentovaný tak, aby se s ním dalo snadno manipulovat, není zrovna efektivní způsob reprezentace UI. Jiné technologie sice byly technicky lepší, ale nákladnější na vývoj (alespoň na počátku).
Můj pohled na věc je že většina uživatelů používá základní funkce a pak je malá skupina těch, kteří tam potřebují nějaké spešl fičůry.
Ale ono nejde o nějaké expertní funkce, to je spíš okrajová věc. Spíš se zefektivňují a prohlubují ty základní funkce.
Zde se shodneme a tvrdil jsem to už před 20 lety, že je to jediné skutečně multiplatformní prostředí pro běh aplikací (tehdy jsa znechucen HW nároky Javy).
Vysoké HW nároky ale bude mít jakákoli životaschopná technologie. Technologie je totiž mnohem levnější, než programátoři, kteří by to psali v assembleru.
Ale o tom to právě jde. Nespokojit se s tím, jak fungují prohlížeče a jak se tam postupně snažíme dolepit funkčnost, na kterou nebyly navržené, ale hledat cestu k lepšímu návrhu webové platformy pěkně na čisto se zohledněním toho co o potřebách webových aplikací víme teď.
Není reálné vystavět cíleně na zelené louce novou platformu nahrazující webové aplikace. Jediná reálná možnost je, že vyroste nějaká technologie, která bude původně určená k něčemu jinému. Úplně stejně, jako z webu vyrostly webové aplikace.
[i]Tohle je taková směska mrtvých technologií, technologií které nesouvisí s webovými aplikacemi, technologií, které existují desítky let… Nevypovídá vůbec o ničem.[/i]
Podle mě vypovídají o tom, že vývoj prohlížečů se hrnul/hrne různými cestami, místy nekoncepčně, aby se rozšířila funkčnost, která mohla být dávno a čistěji, implementována v základech.
[i]Obsazená RAM.[/i]
Pokud by to ten správce nedovedl rozlišit, tak by i malá stránka zobrazovala výrazně více obsazené RAM než než velká. Z toho odvozuji, že to co integrovaný správce zobrazuje je údaj, kolik RAM daná stránka ke svému zobrazení potřebuje. Je zřejmé, že jsou do toho započítány i některé sdílené podprocesy, jinak by souhrn záhy převyšoval mou fyzickou RAM i se swapem.
[i]manipulace s DOMem není efektivní[/i]
Což je problém, pokud ta webová aplikace potřebuje s DOMem aktivně manipulovat. Např. na mém starém noťásku čekám v Google Docs na přepnutí z jedné záložky sešitu a druhou cca 6 sekund. Přitom v té záložce je jen 40 řádků údajů. Stejná operace se záložkou kde je tisíce řádků trvá v LibreOffice zlomek sekundy.
[i]Vysoké HW nároky ale bude mít jakákoli životaschopná technologie. [/i]
Opět nesouhlasím.
Jsem ochoten připustit "neadekvátní" HW nároky nějakým startupovým aplikacím ve fázi rozjezdu, ale top aplikace, za kerými jsou jedny z nejbohatších firem světa by měly mít zdroje na to, aby byly naprogramovány optimalizovaně a nemusí jít rovnou o assembler.
[i]Není reálné vystavět cíleně na zelené louce novou platformu nahrazující webové aplikace. Jediná reálná možnost je, že vyroste nějaká technologie, která bude původně určená k něčemu jinému. Úplně stejně, jako z webu vyrostly webové aplikace.[/i]
Ani zde se neshodneme. Mě to smysluplné a reálné přijde, třeba i za tu cenu, že by tohle prostředí ze začátku spolupracovalo s prohlížečem.
Ono už se to v podstatě děje. Když spouštíte aplikace pro Zoom / Teamsy / Slack (zde tedy Electron což od browseru není tak daleko) / ... tak se skrz prohlížeč spustí lokální aplikace a pak už si jede po svém.
Akorát má představa o tom, jak by to mělo být není o tom, že si každý postaví vlastní aplikaci od píky, ale o tom, že bude jednotná multiplatformní platforma k tomu určená, na které to půjde stavět. Aktuálně se pálí obrovské množství úsilí programátorů na tom, aby ty aplikace zefektivnily, kdyby mohli rovnou stavět na optimalizovaném prostředí, tak by to bylo řádově efektivnější, jak na úrovni lidských zdrojů, tak na úrovni HW nároků.
Viz třeba zrovna ten Slack, kde dva roky makali na optimalizaci a zlepšili výkon o 33% a ušetřili 50% RAM
https://www.theverge.com/2019/7/22/20703458/slack-desktop-app-performance-improvements-windows-mac-features-download
Co by to výrobci aplikace přineslo, kdyby investoval do toho, aby aplikace efektivněji využívala hardware?
Takže si z prohlížeče spustíte aplikaci, která si spustí vlastní jádro webového prohlížeče a uvnitř máte zase webovou aplikaci. Nějak tam nevidím tu výhodu oproti webové aplikaci, když je to webová aplikace, jenom s vlastním jádrem (takže nemůže používat sdílené prostředky toho hlavního prohlížeče, je tam nějaká starší verze jádra).
Multiplatformní platforma byla třeba Java. Uměla startovat z prohlížeče (Java Web Start), uměla dokonce s prohlížečem spolupracovat (Java Applet). Ale na frontendu ji převálcovalo HTML5.
Ne ne, nemám na mysli směr, kterým se ubírá Elektron, na jeho příkladu ukazuji, současný stav, který není ideální, ani nečekám, že jedna firma takové běhové prostředí udělá a dá ho k dispozici ostatním.
S Javou Web Start jsem se potkal. Kromě oblasti instalace a aktualizace aplikací na ní asi nebylo nic moc užitečného. Neujala se. Obecně byla/je Java na desktopech overkill který baštil hodně prostředků.
Z webového prohlížeče se stal dominantní nástroj naší společnosti.
Adekvátně k jeho významu by měla být ustavena skupina odborníků podobně jako fungují ISOC, IAB, IETF, IRTF, IEEE, ... která se otázkou nové platformy bude zabývat.
Po pečlivém návrhu platformy by se mohlo začít s Open Source vývojem, který by byl financován z darů lidí, firem, státních grantů,... (v zájmu všech zmiňovaných je platforma, která bude pracovat efektivněji a umožní jednodušší vývoj )
A po přechodnou dobu, než taková platforma bude vytvořena a bude schopna plně nahradit současné web browsery by se propojení se současným webovým prostředím mohlo realizovat na úrovni spouštění aplikace z webového prohlížeče.
Několik směrů, kterými by se návrh takové platformy měl ubírat:
Jednotná autentizace, ochrana dat a soukromí, efektivita předávání dat ze serveru a zpět, efektivní přístup k HW prostředkům klienta, rychlá a nenáročná manipulace grafickým prostředím, snadná tvorba aplikací, snadnější integrace do prostředí konkrétních OS, široká a jednotná podpora HW platforem, ...
Varianta postupného přiohýbání webových prohlížečů sice vede k postupným dílčím zlepšením, ale zadrátovanost starých a překonaných konceptů je při tom vývoji jako zeměkoule na noze.
Kdy se reálně stalo to, že by byla ustavena skupina odborníků, která by od zeleného stolu navrhla platformu, na kterou by mělo přejít prakticky celé jedno odvětví? Podle mne je to zajímavá idea, ale v praxi nic takového nenastane, protože nikdo nemá důvod něco takového financovat, a je velmi nepravděpodobné, že by se to povedlo. Proto je lepší evoluce, protože se postupuje po malých krocích a chyba se snadno opraví.
K té Javě, co vyžadovala hodně prostředků – no, tak teď místo Javy máme aplikace v prohlížečích, které těch prostředků vyžadují ještě podstatně víc. Holt je potřeba se smířit s tím, že HW prostředky jsou levné a to, co rozhoduje, je to, jak jednoduše se do té technologie dá nastoupit. A v tomhle kritériu holt HTML všechno ostatní převálcovalo.
Re. <b> Kdy se reálně stalo to, že by byla ustavena skupina odborníků, která by od zeleného stolu navrhla platformu, na kterou by mělo přejít prakticky celé jedno odvětví? </b>
To je argumentační wrestling? Nikdy se nic nestalo dřív, než se to stalo.
Takže možná je na čase, aby se to stalo.
Re. <b>postupuje po malých krocích a chyba se snadno opraví.</b>:
Ano, to je jiný přístup k řešení. V praxi vidíme jak to jde.
Re. <b>Holt je potřeba se smířit s tím, že HW prostředky jsou levné</b>
Zde se opět se neshodneme. Podle mě jsou HW prostředky mnohem dražší, než to na první pohled vypadá:
https://www.bloomberg.com/news/articles/2019-05-29/the-rich-world-s-electronic-waste-dumped-in-ghana
V této vysoké hře je oblast webových browserů jen jeden díl. Ovšem velmi významný díl. Podle mých zkušeností je web browser hlavní aplikací kvůli, které HW prostředky nestačí a proč jsou počítače nahrazovány novými.
Například, ve většině her si můžete snadno upravit náročnost grafického zobrazení. V prohlížeči některé možnosti máte taky, ale zdaleka nejsou tak dostupné pro uživatele a zdaleka nemají takový efekt na snížení náročnosti. Navíc při těchto úpravách riskujete, že vám to někde přestane fungovat.
To je argumentační wrestling? Nikdy se nic nestalo dřív, než se to stalo.
Takže možná je na čase, aby se to stalo.
Ne, to je normální dotaz. Průmysl tu máme přes dvě stě let, příležitostí pro takovouhle změnu odvětví navrženou od stolu bylo nespočet. Vlastně jediný reálný pokus, který mne napadá, byl komunismus – a nedopadlo to dobře. Ono se totiž ukazuje, že domyslet rovnou všechny souvislosti je nemožné.
Ano, to je jiný přístup k řešení. V praxi vidíme jak to jde.
Ano, v praxi vidíme, že to jde. Na rozdíl od všech ostatních způsobů.
Podle mě jsou HW prostředky mnohem dražší, než to na první pohled vypadá
To pořád neznamená, že nejsou výrazně levnější, než velmi kvalifikovaní programátoři.
Podle mých zkušeností je web browser hlavní aplikací kvůli, které HW prostředky nestačí a proč jsou počítače nahrazovány novými.
On už je totiž webový prohlížeč často jedinou aplikací, kterou uživatel používá.
Pořád to nic nemění na tom, že k jinému řešení se musíme dostat evolucí ze současného stavu. A že to jiné řešení musí být z hlediska vývoje alespoň tak nízkoprahové, jako současné webové technologie.
Komunismus bych do toho netahal, to už raději meritokracii.
[b]Pořád to nic nemění na tom, že k jinému řešení se musíme dostat evolucí ze současného stavu.[/b]
Můj názor, a historie mi snad dává za pravdu, je, že nemusíme posouvat jen evolucí.
Ale klidně, aby byl uspokojen i váš názor, ať to klidně vznikne evolucí z webbrowserů. Je mi jedno jak se k tomu dopracujeme a jak to označíme.
Přál bych si, aby prohlížeče a mnohé webové technologie kolem byly méně nenažrané na HW prostředky, a k tomu měly další pozitivní atributy, které jsem zmiňoval v některé z předchozích reakcí. Toť celé.
Souhlasím. Mě se ten koncept prohlížeče jako "novodobého OS" nikdy nelíbil.
K tomu, aby se z nich stal nový OS prohlížeče nebyly určeny, ale rozšířily se.
Stejně tak JavaScript nebyl určen k tomu, aby se v něm stavěly komplexnější aplikace, natož, aby něco dělal na server-side.
Roky snažení ty technologie přiohnout, aby dělaly to co bychom od nich potřebovaly, nás dostaly do stavu, ve kterém jsme teď. I když se spoustu věcí podařilo posunout, tak to rozhodně není to žádné Hi-Fi.
Aplikace umožňující spolupráci více uživatelů v jednom prostředí, tady samozřejmě máme. Že to jde i bez prohlížečů ukazuje např. kdejaká, i třeba 20 let stará multiplayer hra.
ČLÁNKY DO MAILU