Názory k článku
Chrome spotřebuje 10× více paměti než Safari

1) Tak kdo teda potrebuje ty lepsi programatory? :D
2) Ty si myslis, ze napr. Mali grafiky maji na Androidu nejakou svoji vlastni pamet?

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 ....

Jenže většina těch webových aplikací by vůbec neexistovala, kdyby nebyly webové aplikace. Takže s čím to chcete porovnávat?

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é.