Doporučte rychlý WWW widget pro view SQL tabulky

Kit

  • *****
  • 596
    • Zobrazit profil
    • E-mail
Re:Doporučte rychlý WWW widget pro view SQL tabulky
« Odpověď #30 kdy: 20. 05. 2021, 19:33:11 »
Docela výrazně - generování JSON spotřebuje asi jednu desetinu výkonu oproti HTML.
Jo, ty špičaté závorky se v tom procesoru zasekávají, složené projdou mnohem líp… Na tohle se fakt nedá nic jiného napsat…

Nejde jen o špičaté závorky. Data musí být patřičně ošetřena - přitom json_encode() to již má v sobě.

Navíc je zbytečné renderovat HTML i na klientovi, takže klient ho nemusí ani parsovat.
Nějak mi uniká, co jste touhle větou chtěl říct.

že Javascript to umí zapisovat přímo do DOM a umí do něj doplnit i potřebnou bižuterii, kterou není nutné přenášet. Mezičlánek HTML je tedy možné vypustit.


M_D

  • ***
  • 177
    • Zobrazit profil
    • E-mail
Re:Doporučte rychlý WWW widget pro view SQL tabulky
« Odpověď #31 kdy: 20. 05. 2021, 19:45:16 »
Uff, jak bych byl rád, kdyby uživatelé po nás chtěli jen tabulku o jednom tisíci řádků. Ty junioři analyzátoři chtějí tabulku o 4 až 5000 řádků. Jejich plesnivej šéf tabulku o 50.000 řádcích. Žádné filtrování, žádné stránkování, to zdržuje, vyhoď do prohlížeče tabulku, já chytnu posuvník a projedu ji za cca 30 sekund odshora dolů a vím jak zkouška dopadla, voko totiž není <pííp> a vidí.... A nemusím čekat, až oddělení výpočtů a analýz to vedle přechroupá za 5 hodin a vypadne z nich je OK/není OK. :-)
Pár sloupců - název relátka/spínáče, čas posledního sepnutí na milisekundy, stav, doba přepnutí.... Pozice řádků je pevná, takže vyhledávání na řádek dělá tak, že najede posuvníkem na naučenou pozici, zkrátka to zná po paměti (jen když dostane nový monitor a myš, tak chvíli trvá, než se přeučí na aktuální geometrii). A ten poloslepej plesnivec se nesplete. Když neměl prohlížeč v PC, tak před 30-ti lety to vyhodnocoval tak, že mu to ADT4500 vytisklo na balík papíru, který si protočil přes mandl a měl výsledek také (na tom ADT to pak analyzovali cca týden, co on na tom mandlu z traktorového papíru sjel okometricky za pár minut).
Nu, a když nezkoumá zrovna zkoušku, tak v si tabulku zobrazí pro radost a řádky se v ní ještě živě aktualizují, cca desítky-stovky řádku/sec (a dost se ukazuje, že posílat data k aktualizaci přes MQTT embedované ve websocketu jako JSON zprávy je dost omyl, prohlížeč je z toho na prášky).

Pixe

Re:Doporučte rychlý WWW widget pro view SQL tabulky
« Odpověď #32 kdy: 20. 05. 2021, 19:45:59 »
Jakou má prosím souvislost json_encode() s Java aplikací?

Nejde jen o špičaté závorky. Data musí být patřičně ošetřena - přitom json_encode() to již má v sobě.

Re:Doporučte rychlý WWW widget pro view SQL tabulky
« Odpověď #33 kdy: 20. 05. 2021, 19:49:14 »
Nejde jen o špičaté závorky. Data musí být patřičně ošetřena - přitom json_encode() to již má v sobě.
:D

že Javascript to umí zapisovat přímo do DOM a umí do něj doplnit i potřebnou bižuterii, kterou není nutné přenášet. Mezičlánek HTML je tedy možné vypustit.
Výše jsem vysvětloval, že nativní implementace HTML → DOM je výrazně rychlejší, než parsování JSONu a následná manipulace s DOMem pomocí JavaScriptu.

Logik

  • *****
  • 934
    • Zobrazit profil
    • E-mail
Re:Doporučte rychlý WWW widget pro view SQL tabulky
« Odpověď #34 kdy: 20. 05. 2021, 21:13:05 »
Citace
Výše jsem vysvětloval, že nativní implementace HTML → DOM je výrazně rychlejší, než parsování JSONu a následná manipulace s DOMem pomocí JavaScriptu.
Generování DOM pomocí JS je - pokud se to dělá dobře - i v mnohatisíciřádkové tabulce naprosto dostatečně rychlé. Takže to není problém. (A pokud někdo tvrdí, že to problém je a že ten problém jde vyřešit jen složitým špatně čitelným kódem, tak prostě netuší, jaké jsou dnes možnosti vývoje webových aplikací).

Co problém je, je rychlost UI v "HTML only" aplikaci - protože v takové aplikaci musím dělat drtivou většinu věcí na serveru (např. jak mám filtrovat data, když přišli jako HTML snippet a "nevidím dovnitř"). Proto je JS implementace UI ve výsledku podstatně rychlejší, neboť odpadne pro uživatele vždy znatelný lag komunikace se serverem - stejně jako hromada problémů tohoto modelu vývoje (např. nutnost přenášet stav aplikace po bezstavovém protokolu, nebo implementace stavu pomocí cookies, jejíž problémy lze vidět např. na problémech tohoto fóra).

Samozřejmě, pak je také možnost si posílat HTML, to na klientu parsovat a získávat z něj dále zpracovávatelná data pro filtrování a agregace a..... - ale nevím, proč bych takovou pitomost dělal, když si můžu rovnou poslat JSON, a odpadne mi jak kódování na serveru (místo psaní šablon zavolám jednu funkci) i na klientu.


Re:Doporučte rychlý WWW widget pro view SQL tabulky
« Odpověď #35 kdy: 20. 05. 2021, 21:33:38 »
Generování DOM pomocí JS je - pokud se to dělá dobře - i v mnohatisíciřádkové tabulce naprosto dostatečně rychlé. Takže to není problém. (A pokud někdo tvrdí, že to problém je a že ten problém jde vyřešit jen složitým špatně čitelným kódem, tak prostě netuší, jaké jsou dnes možnosti vývoje webových aplikací).
Když se váš komentář tváří jako polemika, měl by se texte vztahovat k tomu, co citujete. Polemizovat s něčím, co nikdo nenapsal, je zbytečné.

Co problém je, je rychlost UI v "HTML only" aplikaci - protože v takové aplikaci musím dělat drtivou většinu věcí na serveru (např. jak mám filtrovat data, když přišli jako HTML snippet a "nevidím dovnitř"). Proto je JS implementace UI ve výsledku podstatně rychlejší, neboť odpadne pro uživatele vždy znatelný lag komunikace se serverem - stejně jako hromada problémů tohoto modelu vývoje (např. nutnost přenášet stav aplikace po bezstavovém protokolu, nebo implementace stavu pomocí cookies, jejíž problémy lze vidět např. na problémech tohoto fóra).
U stránkovací tabulky není nic lepšího, než filtrovat na klientovi… „Na této stránce odpovídají filtru 4 záznamy. Ale zkuste se podívat také na další stránky, třeba tam objevíte nějaké další.“ Nebo stáhnete do pohlížeče celou databázi?

Samozřejmě, pak je také možnost si posílat HTML, to na klientu parsovat a získávat z něj dále zpracovávatelná data pro filtrování a agregace a..... - ale nevím, proč bych takovou pitomost dělal, když si můžu rovnou poslat JSON, a odpadne mi jak kódování na serveru (místo psaní šablon zavolám jednu funkci) i na klientu.
To, že do prohlížeče pošlete první stránku už kompletně vygenerovanou a teprve pak na to napojíte JavaScript, se normálně dělá. První stránka se zobrazí rychle, dobře funguje SEO, a teprve následující požadavky se řeší přes JSON.

Logik

  • *****
  • 934
    • Zobrazit profil
    • E-mail
Re:Doporučte rychlý WWW widget pro view SQL tabulky
« Odpověď #36 kdy: 20. 05. 2021, 22:54:33 »
Citace
Polemizovat s něčím, co nikdo nenapsal, je zbytečné.
Psal jsi: "Výše jsem vysvětloval, že nativní implementace HTML → DOM je výrazně rychlejší"
Jsou dvě možnosti. Buďto tvrdíš rychlejší ve smyslu CPU času. Pak je Tvůj argument mimo, protože CPU čas na klientovi při úloze tohoto rozsahu není problém (pokud se to napíše rozumně). Že ho tazatel řeší není zvolenou technologií (jak tu celou dobu implicitně tvrdíš), ale pouze nekvalitou zvoleného widgetu.
Anebo jsi myslel rychlejší ve smyslu rychlejší vývoj (což je dnes většinou poměrně podstatné kritérium)- a pak se prostě mýlíš, je to přesně naopak.

Citace
U stránkovací tabulky není nic lepšího, než filtrovat na klientovi… „Na této stránce odpovídají filtru 4 záznamy.
Nikoli. Bude tam "z dosud načtených záznamů vyhovují tyto"....a zatím tahám další. Takže uživatel vidí a může zpracovávat aspoň něco, než request doběhne, takže ho to tolik nezdržuje. Evidentně netušíš, jak se taková aplikace dá napsat (včetně prefetchingu atd...). A navíc, ta data nahrávám jednou, ne že uživatel čeká po každém kliku. Což je při analýze dat (kdy delší dobu pracuji s jednou sadou dat) velká výhoda.


Citace
To, že do prohlížeče pošlete první stránku už kompletně vygenerovanou a teprve pak na to napojíte JavaScript, se normálně dělá.
Ano, existuje více možností, jak napsat webapp: kde má každý svojí silnou a slabou stránku. Správně jsi vystihl, že sliná stránka tohoto řešení je SEO (i když dneska dobré boty - např. google interpretují i JS, takže to už není tak nutné jako dřívé). A slabá stránka tohoto řešení je, že nějakým způsobem buďťo píšeš ty stránky defakto dvakrát (pokud tedy nepoužíváš např. nodejs, kde to může renderovat stejný kód na obou stranách, nebo nepoužíváš nějakej framework, kterej ti tu serverside stranu vygeneruje z clientside javascriptu sám), anebo se jiným způsobem drbeš se sešíváním HTML a JS části aplikace.

Tedy tato technologie tedy může bejt vhodná např. pro eshop, kde Ti jde o SEO v první řadě, a UI nedosahuje velké složitosti. Ale nevím, proč bych měl tuto technologii používat pro stránku s reportama, kde mne SEO nezajímá, a tedy nemám důvod psát tu stránku dvakrát, když jde napsat jednou. Obzvlášť, když se dá čekat, že tam bude složité UI, což ještě zvýrazní nevýhody Tebou navržené technologie.

Re:Doporučte rychlý WWW widget pro view SQL tabulky
« Odpověď #37 kdy: 21. 05. 2021, 08:42:23 »
Jsou dvě možnosti. Buďto tvrdíš rychlejší ve smyslu CPU času. Pak je Tvůj argument mimo, protože CPU čas na klientovi při úloze tohoto rozsahu není problém (pokud se to napíše rozumně). Že ho tazatel řeší není zvolenou technologií (jak tu celou dobu implicitně tvrdíš), ale pouze nekvalitou zvoleného widgetu.
Anebo jsi myslel rychlejší ve smyslu rychlejší vývoj (což je dnes většinou poměrně podstatné kritérium)- a pak se prostě mýlíš, je to přesně naopak.
Nebo je ještě třetí možnost, ta nejlogičtější – jde o dobu, kdy se uživateli stránka zobrazí. To je totiž to, co se na webu řeší. Jestli uživatel pět vteřin kouká na bílou stránku a teprve pak se něco zobrazí, nebo jestli se mu něco zobrazí za 1 sekundu. Měří se to metrikami jako First Meaningful Paint nebo Time to Interactive, abych vybral ty dvě nejdůležitější.


Evidentně netušíš, jak se taková aplikace dá napsat
Ale vím. Přičemž to vaše filtrování na klientovi i na serveru je ta úplně nejhorší možnost, mnohem horší a koplikovanější, než kus stránky posílat ze serveru jako HTML.

Správně jsi vystihl, že sliná stránka tohoto řešení je SEO
A také pomalost, která je podle mne větší problém, než SEO – právě proto že vyhledávače si už s JS docela obstojně poradí.

A slabá stránka tohoto řešení je, že nějakým způsobem buďťo píšeš ty stránky defakto dvakrát (pokud tedy nepoužíváš např. nodejs, kde to může renderovat stejný kód na obou stranách, nebo nepoužíváš nějakej framework, kterej ti tu serverside stranu vygeneruje z clientside javascriptu sám), anebo se jiným způsobem drbeš se sešíváním HTML a JS části aplikace.
To platilo před několika lety, dnes už to není pravda.

Logik

  • *****
  • 934
    • Zobrazit profil
    • E-mail
Re:Doporučte rychlý WWW widget pro view SQL tabulky
« Odpověď #38 kdy: 21. 05. 2021, 11:37:16 »
Citace
Ale vím,... filtrování na klientovi i na serveru je ta úplně nejhorší možnost, mnohem horší a koplikovanější, než kus stránky
posílat ze serveru jako HTML.
Nevíš. Protože
a) tento přístup jde zrovna pro záznamy typu logy, kde člověka zpravidla zajímá blízká budoucnost, dobře a funkčně implementovat s filtrováním jen na klientovi. A to máš s dobrým widgetem v podstatě zadarmo, popř. musíš napsat jeden malej JS helper apod. Takže Ti to naopak často práci ušetří
b) a i když je dat tolik a usecase je takové, že je potřeba součinnost filtrování na klientu a serveru, tak ta námitka je úplně mimo, protože doplnit do serverového api filtrování je práce tak asi na čtvrt hodiny. Takže za malej kus práce získáš svižnější aplikaci (nemusí si v mnoha případech říkat serveru o data)

(samozřejmě, tento přístup přestane bejt vhodnej v okmažiku, kdy bude tad tolik, že budou k rozumné práci potřeba indexy).

Citace
právě proto že vyhledávače si už s JS docela obstojně poradí.
JS only page je pro crawlery furt poněkud problematická a nedoporučuje se. Viz např.https://www.searchenginejournal.com/seo-javascript-good-bad-uncertainty/346708/
Citace
To platilo před několika lety, dnes už to není pravda.
To, o čem mluvíš teď je serverside prerendering JS-only aplikací. Tedy rozumná (či spíše velmi dobrá) technologie (kterou jsem btw. ze svých tvrzení explicitně vylučoval, kdybys dobře četl...), která ovše s Tebou původně navrhovanou technologií, kterou jsme kritizovali:
Citace
Tak evidentně je to pro některé novinka, že se může do prohlížeče poslat jen HTML fragment a vyměnit jen část stránky
....nemá společného vůbec nic. A protože jsme se opět dostali do fáze, kdy místo technických věcí řešíme to, že děláš z černé bílou, tak se z další debaty na toto téma omlouvám.

Re:Doporučte rychlý WWW widget pro view SQL tabulky
« Odpověď #39 kdy: 21. 05. 2021, 12:34:45 »
tento přístup jde zrovna pro záznamy typu logy, kde člověka zpravidla zajímá blízká budoucnost, dobře a funkčně implementovat s filtrováním jen na klientovi. A to máš s dobrým widgetem v podstatě zadarmo, popř. musíš napsat jeden malej JS helper apod. Takže Ti to naopak často práci ušetří
Vidím, že načíst si celou tabulku do paměti a pak záznamy filtrovat a řadit na serveru v PHP, už není v módě. Teď se celá ta tabulka rovnou přestěhuje až na klienta.

i když je dat tolik a usecase je takové, že je potřeba součinnost filtrování na klientu a serveru, tak ta námitka je úplně mimo, protože doplnit do serverového api filtrování je práce tak asi na čtvrt hodiny. Takže za malej kus práce získáš svižnější aplikaci (nemusí si v mnoha případech říkat serveru o data)

(samozřejmě, tento přístup přestane bejt vhodnej v okmažiku, kdy bude tad tolik, že budou k rozumné práci potřeba indexy).
Ony existují i aplikace, které zpracovávají větší objem dat, než je nějaký blogísek. Filtrovací logika může být dost komplikovaná, např. se do SQL dotazu připojují další tabulky, které tam nejsou, když příslušný filtr není použit. Když to budete chtít řešit na klientovi, nebudete k němu po síti stěhovat jen celou tabulku, ale rovnou celou databázi.

To, o čem mluvíš teď je serverside prerendering JS-only aplikací.
To je druhá možnost. Já jsem ovšem psal o staticky generovaných webech (SSG). Což byste věděl, kdybyste četl komentáře, na které reagujete. Technologie za tím je stejná, jako SSR, nicméně když chcete rychlost zobrazení stránky, používá se právě to generování – protože se stránky vytvoří už v době buildu a jediné, co musí udělat server, je poslat už hotový soubor do prohlížeče. Což se krásně deleguje na hloupou edge cache, která nemusí umět zpracovávat žádný JavaScript, jenom odesílá soubory.

kterou jsem btw. ze svých tvrzení explicitně vylučoval, kdybys dobře četl...
To je právě váš problém. Nečtete komentáře, reagujete na své domněnky – a pak za to ještě vynadáte ostatním, že se drží tématu a ne vašich výmyslů.

která ovše s Tebou původně navrhovanou technologií, kterou jsme kritizovali:
Citace
Tak evidentně je to pro některé novinka, že se může do prohlížeče poslat jen HTML fragment a vyměnit jen část stránky
....nemá společného vůbec nic.
Řeč byla o tom, zda se rychleji zobrazí HTML → nativní HTML parser → DOM, nebo JSON → nativní JSON parser → JavaScript → DOM. Na tomto příkladu je to dobře vidět, protože ta komplikace se SSG a SSR se dělá právě proto, že první cesta je pro zobrazení výrazně rychlejší. No a princip je úplně stejný, jako s tím mým příkladem – z hlediska rychlosti je prohlížeči jedno, zda parsuje celé HTML, nebo jen HTML fragment.

A protože jsme se opět dostali do fáze, kdy místo technických věcí řešíme to, že děláš z černé bílou, tak se z další debaty na toto téma omlouvám.
Přesněji řečeno jsme se opět dostali do fáze, kdy vy polemizujete s vlastními výmysly, které vás napadají volnými asociacemi nad některými slovy z mých komentářů. To, že se omlouváte z debaty, je tedy eufemismus – vy jste se jí doopravdy nikdy nezúčastnil.

Kit

  • *****
  • 596
    • Zobrazit profil
    • E-mail
Re:Doporučte rychlý WWW widget pro view SQL tabulky
« Odpověď #40 kdy: 21. 05. 2021, 12:49:05 »
tento přístup jde zrovna pro záznamy typu logy, kde člověka zpravidla zajímá blízká budoucnost, dobře a funkčně implementovat s filtrováním jen na klientovi. A to máš s dobrým widgetem v podstatě zadarmo, popř. musíš napsat jeden malej JS helper apod. Takže Ti to naopak často práci ušetří
Vidím, že načíst si celou tabulku do paměti a pak záznamy filtrovat a řadit na serveru v PHP, už není v módě. Teď se celá ta tabulka rovnou přestěhuje až na klienta.

Někdy bylo v módě načítat celou tabulku do paměti a pak teprve zpracovávat v PHP? No fuj!

i když je dat tolik a usecase je takové, že je potřeba součinnost filtrování na klientu a serveru, tak ta námitka je úplně mimo, protože doplnit do serverového api filtrování je práce tak asi na čtvrt hodiny. Takže za malej kus práce získáš svižnější aplikaci (nemusí si v mnoha případech říkat serveru o data)

(samozřejmě, tento přístup přestane bejt vhodnej v okmažiku, kdy bude tad tolik, že budou k rozumné práci potřeba indexy).
Ony existují i aplikace, které zpracovávají větší objem dat, než je nějaký blogísek. Filtrovací logika může být dost komplikovaná, např. se do SQL dotazu připojují další tabulky, které tam nejsou, když příslušný filtr není použit. Když to budete chtít řešit na klientovi, nebudete k němu po síti stěhovat jen celou tabulku, ale rovnou celou databázi.

Stačí klientovi poskytnout view.
která ovše s Tebou původně navrhovanou technologií, kterou jsme kritizovali:
Citace
Tak evidentně je to pro některé novinka, že se může do prohlížeče poslat jen HTML fragment a vyměnit jen část stránky
....nemá společného vůbec nic.
Řeč byla o tom, zda se rychleji zobrazí HTML → nativní HTML parser → DOM, nebo JSON → nativní JSON parser → JavaScript → DOM. Na tomto příkladu je to dobře vidět, protože ta komplikace se SSG a SSR se dělá právě proto, že první cesta je pro zobrazení výrazně rychlejší. No a princip je úplně stejný, jako s tím mým příkladem – z hlediska rychlosti je prohlížeči jedno, zda parsuje celé HTML, nebo jen HTML fragment.

Správně, nenechme se zmást benchmarky, které tvrdí opak.

Logik

  • *****
  • 934
    • Zobrazit profil
    • E-mail
Re:Doporučte rychlý WWW widget pro view SQL tabulky
« Odpověď #41 kdy: 21. 05. 2021, 15:40:06 »
Filipe:
Na JS-only aplikacích není pomalé samotné JS generování DOMU. To se koneckonců přeloží na stejné volání interní funkcí browseru na vybudování DOMU, jako bude volat parsing HTML (jo, před patnácti lety to opravdu pomalejší bylo, ale jaksi je rok 2021). To, proč se používá SSG či prerendering je nutnost nahrát celý JS a inicializovat aplikaci a celý JS framework před tím, než se něco zobrazí. Tedy to, že se používá SSG a prerendering řeší úplně jiný problém, než rychlost vytváření DOM pomocí JS - a tedy celé Tvoje teorie, které sis kolem toho vybudoval a tady razíš, jsou nesmyslné.
Debata začala od toho, že jsi to navrhoval konkrétní problémřešit pomocí dohrávání HTML snippetů. A u této technologie -- která už je léta považovaná za antipattern, byť se pořád používá: ze setrvačnosti nebo proto, že frameworky nepodporují modernější a praktičtější možnosti -- se (přinejemenším obvykle i v tomto konkrétním případě) prostě žádná podstatná výhoda SSR se neprojeví, zatímco nevýhody ano.

Promiň, ale z toho co píšeš, je naprosto evidentní, že web nevyvíjíš, praxi v tom nemáš (teda doufám, to by tomu dalo nový rozměr hrůzy :-) ) - a jen sis o tom občas někde něco přečet, a myslíš si, že rychle vygooglenejma věcma někoho uzemníš.

Citace
Někdy bylo v módě načítat celou tabulku do paměti
Jsou případy, kdy je vhodné tahat data na klienta (především pokud je předpoklad, že většinu z nich bude klient stejně chtít zobrazit) a jsou případy, kdy je to špatně. Tazatel popisoval případ, kdy na klientu ta data zobrazovat chce, tedy je rozumné si je tam dotáhnout a ne je tahat furt dokolečka znova.
Takže tato Tvá snaha o zesměšnění je jen demagogie.




Re:Doporučte rychlý WWW widget pro view SQL tabulky
« Odpověď #42 kdy: 21. 05. 2021, 21:51:22 »
Na JS-only aplikacích není pomalé samotné JS generování DOMU. To se koneckonců přeloží na stejné volání interní funkcí browseru na vybudování DOMU, jako bude volat parsing HTML
Ne, ta cesta je jiná. Při parsování HTML se může prohlížeč spolehnout na to, že je parser jediný, kdo má k vznikajícímu DOMu přístup. Když DOM staví skript, jsou už to živé objekty, ke kterým se podle toho musí chovat, např. je zamykat. Proto vznikají věci jako Shadow DOM, které umožňují vyhnout se pomalé práci s živým DOMem. To, že je DOM řádově rychlejší, než před lety, neznamená, že už je stejně rychlý, jako HTML parser. Rozdíly tam pořád jsou a dají se změřit a změřit.

Debata začala od toho, že jsi to navrhoval konkrétní problémřešit pomocí dohrávání HTML snippetů.
Ne, já jsem navrhoval ten problém řešit tím, že se někdo začne zabývat UX aplikace. HTML snippety jsem uvedl jako příklad maximální rychlosti, které lze docílit – aby si tazatel mohl vyzkoušet, co je maximum možného, a např. mohl usoudit, že je to stále pomalé a je potřeba opravdu řešit UX. Nebo, v horším případě,  aby měl aspoň s čím srovnávat a věděl, zda už se dostal na 90 % maxima, nebo se stále plácá někde kolem 5 %.

Tazatel popisoval případ, kdy na klientu ta data zobrazovat chce
Tazatel popisoval příklad, kdy data na klientovi chce programátor. Uživatel je tam nechce.

Re:Doporučte rychlý WWW widget pro view SQL tabulky
« Odpověď #43 kdy: 21. 05. 2021, 23:04:05 »
Ok, tak teď když si tazatel otestoval maximum možného, je vše v pořádku a může přeskočit celou diskuzi a věnovat se opravě toho svého řešení, kde nejspíš stačí opravit nějaký přehmat :)

Logik

  • *****
  • 934
    • Zobrazit profil
    • E-mail
Re:Doporučte rychlý WWW widget pro view SQL tabulky
« Odpověď #44 kdy: 22. 05. 2021, 19:16:20 »
Citace
Rozdíly tam pořád jsou a dají se změřit a změřit.
Cože???? To fakt myslíš vážně????

 První odkaz měří např. FF 3.x - 13 let starej browser (a to je ještě z těch novějších v testovací sadě). To fakt se snažíš "svoji pravdu" dokazovat takovým podvodem a myslíš si, že Ti na to nepřijdem? Nebo jen nejsi schopen si všimnout ani tak základního problému odkazovaného?
 Druhej odkaz pak neporovnává totéž, anžto je napsanej blbě (psal jsi ho Ty? nebo jen si vygooglil první blbost, která podporuje "Tvoji pravdu" a nejsi schopen ji ani zkontrolovat?)? Když ten odkaz opravím tak, aby fungoval stejně (tzn. aby druhá možnost nedělala s každou iterací větší a větší dokument, a zahrnu čas i na sestavení toho HTML, které někde sestaveno být musí), tak mi vyjde rychlost 72 ku 78 - čili manipulace HTML vyjde dokonce pomaleji.

https://measurethat.net/Benchmarks/Show/13130/0/corrected-dom-manipulation-vs-innerhtml
(Pokud nezahrnu sestavování HTML tak je HTML o cca 10% rychlejší, což je pořád zanedbatelné - a také to ukazuje, že manipulace s DOM není natolik drahá operace, aby mělo smysl dělat takovéto fine-grade optimalizace). Takže sorry, prostě tu sebejistě prohlašuješ nesmysly.

Citace
Při parsování HTML se může prohlížeč spolehnout na to, že je parser jediný, kdo má k vznikajícímu DOMu přístup.
Když DOM staví skript, jsou už to živé objekty, ke kterým se podle toho musí chovat, např. je zamykat.
Když stavím dom "mimo dokument" a pak ho tam jedním appendChild přivěsím, zamykat musím úplně stejně jako když ho tam zavěsím pomocí innerHTML. Javacript v browseru je multithreadový pouze pomocí Worker threadů, které nemají přístup k DOMu. Žádnej problém navíc s race conditions tam prostě není. Takže pohádky si vymejšlíš hezké, ale to je tak vše....

Citace
HTML snippety jsem uvedl jako příklad maximální rychlosti, které lze docílit – aby si tazatel mohl vyzkoušet, co je maximum možného, a např. mohl usoudit, že je to stále pomal
Ano, a právě proto tvrdím, že navrhuješ kravinu. Použití HTML snippetů by žádnou podstatnou rychlost navíc nepřineslo. Problém tady  vůbec není v tom, že by použitá technologie byla znatelně pomalejší než snippety,ale čistě v tom, že uživatel použil špatně napsanej grid, kterej je zbastlenej a nezvládá větší objemy dat. Proto se tazatel zcela korektně ptá, kterej jinej - lépe napsanej grid použít. Jednoduchá otázka s jednoduchou odpovědí.

A ty, místo toho, co bys tazateli poradil na co se ptá (a pokud nevíš, tak mlčel), tak na základě zastaralejch znalostí, které už dávno neplatí, tady radíš kraviny a chceš po něm, aby místo jednoduché výměny gridu, kterou jde zvládnout za pár hodin, začal experimentovat s předpotopní technologií, řešení zcela překopal a tím zbytečně spálil hodin desítky, a jsi ve svý aroganci přesvědčenej, že víš líp než tazatel sám, co vlastně řeší za problém a co tazatel potřebuje, čímžs ten dotaz úplně zabil. Sorry.

A když Tě ostatní upozorní, že tvrdíš nesmysly, že problém není tam, kde ho hledáš, tak místo toho, aby sis pořádně svá tvrzení ověřil, nebo dokonce třeba se dokonce nechal poučit od lidí, kteří danou věc umějí a mají s ní reálné zkušenosti, tak tu celej thread zničíš tím, že dokolečka opakuješ nesmysly, který se snažíš obhájit dalšíma nesmyslama vycucanejma z prstu a prasecky napsanejma testama, který jestli něco dokazujou, tak to, že nedokážeš pochopit, co ve skutečnosti udělá párřádkovej JS kód. Sorry  za otevřenost.