...a milionkrát užitečnější, než špatně udělaný grid...
Jasně. Tvoje řešení je nejlepší, protože bude udělané dobře, zatímco ostatní to udělaj blbě. Tomu říkám argument.
Já jsem nepsal nic o tom, jestli je něco moje řešení nebo řešení někoho jiného. Tomu, co jste ředvedl, se říká slaměný panák.
Existuje x JS webových aplikací, které takový problém zvládají dobře.
Zvládají to technicky dobře, ne dobře z hlediska UX. Bohužel pro vás tohle tvrzení není v rozporu s ničím, co jsem napsal, takže vaše teorie o tom, že s tím nemám zkušenosti, jsou jen další vaše demagogie.
To, co tvrdíš - že optimalizace znepřehledňuje kód - je sice teoreticky pravda, ale pouze od určité úrovně. Naopak do určité úrovně správně napsaný a tedy rychlý kód je přehlednější a použitelnější, než "bastl".
Děkuji za potvrzení mého tvrzení, že optimalizace znamená, že správně napsaný a přehledný kód v zájmu vyšší rychlosti nebo menší paměťové náročnosti přepíšu a bohužel ho při tom musím znepřehlednit. Pokud je nějaký kód napsaný špatně a já ho přepíšu, aby byl srozumitelný, a přitom se ten kód jako vedlejší efekt i zrychlí, není to optimalizace, ale obyčejná oprava špatně napsaného kódu.
A to, co řeší tazatel, se ani náhodou neblíží k limitu, kdy by to dobře napsaná webgui aplikace nezvládla.
Tazatele zřejmě řešení nezajímá, takže jsme se nedozvěděli, jak přesně ta tabulka vypadá. Je možné, že v těch tisíci řádcích opravdu je spousta interaktivních komponent – sice to z hlediska UX nedává žádný smysl, ale to nedává ani těch 1000 řádků. Výpis takové tabulky by samozřejmě trval dlouho, klidně je možné i se správným kódem se dostat na ty časy, které uváděl tazatel. Takovou tabulku (se zachováním funkčnosti) ovem moc optimalizovat nejde. Jediné, kde se ten problém dá řešit, je UX. Takže stále platí to, co jsem psal na začátku. Pokud se ten problém má opravdu vyřešit, je potřeba se zaměřit na UX. Až se vyřeší UX, technický problém nejspíš zmizí.
A navíc je to právě naopak, dobře napsaná JS aplikace má ty limity v některých ohledech podstatně dál, než aplikace která tahá ze serveru vygenerované html snapshoty. Z mnoha důvodů, např. že podstatně snáz se tam dělá cache a znovupoužití dotažených záznamů ze serveru.
Preo vás je možná limitem to, co se dělá snadno. Já mám limity dál a klidně se pustím i do věcí, které jsou obtížné.
Tvoje rada je podobnej nesmysl, jako svého času byly na webu zaručené rady, že používat JOINY je špatně, protože jsou pomalé.
Další slaměný panák.
Takže ještě budeš kombinovat dvě různé technologie a lepit je na sebe - a jako myslíš si, že tím vznikne rychlejší a nebo přehlednější kód. Hele, sorry, fakt je vidět, že mluvíš o věci, o který sis možná někdy něco přečet, ale zkušenosti s tím nemáš....
Optimalizace se nedělá proto, aby vznikl přehlednější kód. Právě naopak, optimalizace znamená, že se obětuje přehlednost v zájmu vyšší efektivity kódu. Zkuste to pochopit.
Jinak pro vaši informaci, parsování HTML prohlížečem do DOMu je podstatně rychlejší, než když parsujete JSON a pak z něj v JavaScriptu vyrábíte DOM. Proto jsou poslední dobou tak v oblibě generátory statických webů postavené na frontendových technologiích jako Gatsby, Next.js, Gridsome, Sapper apod. Ale můžete všem, kteří to používají kvůli rychlosti výsledného webu, vysvětlit, že vy jste ten odborník, a že to všichni dělají špatně, je to pro uživatele pomalé, a navíc se jim to bude strašně špatně vyvíjet, nemohou používat cache…