Hogy manapság már tök fölösleges a jQuery, abban egyetértünk. 10-15 évvel ezelőtt még egy fontos szerepet töltött be, mára azonban a böngészők megoldották azt a problémát, ami miatt a jQuery született. A 8 kB-os megoldásod feltételezem nem támogatta IE9-et, mint a jQuery, szóval annyira nem fer az összehasonlítás. :)
ie9-em hirtelen nem volt, de volt itt egy kimustrált virtuális xp ie8-cal, azaz egyel korábbival. Kíváncsiságból kinyitottam benne (nem meglepő módon nem ment) és elkezdtem fixálni a funkciókat. Kifixáltam az AJAX-ot, a tábla megjelenítését, a keresést, sorrendezést, szerkesztést (már 95+%-os funkcionalitásnál járunk), aztán belefutottam valami cacheing mizériába és meguntam. De még mindig csak 7.5 kB-nál járok; egy-két sort kellett hozzáadni per funkt. Remélem nem azt akartad megmagyarázni, hogy a jQuery ie-kompatibilitási rétegre épülő tábla plugin többszáz kilója az ie-kompatibilitás miatt többszáz kiló, ha azt már a jQuery megoldotta. És nem, még az ie kompatibilitás sem csinál többszáz kB-nyi plusz kódot.
A fejlesztők többsége azért használ egy library-t, mert nem akar egy korábban megoldott problémát újra megoldani, hanem a saját dolgaival akar inkább foglalkozni. Én nem állnék neki írni egy n+1. táblázatkezelő libet, ha van már olyan, ami a céljaimnak megfelel.
Úgy tényleg nincs értelme a vitának, ha nem arra válaszolsz, amit írtam. Nem egy db. konkrét célú JS libről van szó, hanem komplett keretrendszerekről, ráadásul többről, egyszerre.
Egyesével megnézed, vagy miként tűnik ez fel?
Felbőgnek a ventilátorok, megugrik a load, aztán JS tilt és hirtelen minden megint csendes.
a Google is bünteti a lassú oldalakat.
Mi számít a google-nek lassúnak? Ha a krómban kipróbált kód még ma betölt krómban? És a többi browser? Egyébként, ha a legtöbb oldal ilyen trágya, akkor nem számít a google büntetése, mert mindet büntetni fogja.
Ez valamilyen szinten megakadályozza a több száz kB-os JS-t futtató blogokat, mert senki sem fogja őket olvasni.
A fenét. A júzereket még a cryptomining sem zavarja. Fel sem tűnik nekik, hogy az egész olyan, mint a csiga.
Ha leterheli a CPU-t a fölösleges JS, akkor is bezárom az oldalt.
Az se rossz, de én inkább tiltom a JS-t.
A Youtube tök más tészta. Nem a hozzá nem értés miatt ilyen, hanem ez a termékük szerves része. Azért így oldották meg, hogy minél nehezebb legyen lelopni a tartalmat róla, mert az nekik nettó veszteség a kieső reklámbevétel miatt.
Kár volt belinkelni az URL védelmet, mert így teljesen ignoráltad az első felét: a 100% JS-rendernek nincs köze a tartalom lelopásához. A hozzáértésről meg ennyit: http://www.commitstrip.com/en/2016/07/04/pre-roll-video/ (Igen, én is tudom, hogy ez vicc, de van benne igazság.)
Egyébként meg a statikus oldalgenerátorok épp reneszánszukat élik. Van közöttük JS alapú is, de a legtöbb sima HTML-t generál. A Netlify és társai ezt a hullámot meglovagolva nőttek óriásira.
Hogy jön ez ahhoz, hogy a webet elárasztotta a JS? Vagy a bankok Java appjaihoz, vagy a dotnet cuccait blikkre berángató alkalmazásokhoz? Vagy ahhoz, hogy a windows 10-ben ötvenszer tárolják le ugyanazt a kódot/adatot redundánsan és még a debug infókat sem strippelik a libekből? Ha vannak ezek a statikus generátorok, akkor a többi nincs?
Miért ne? Miért töltse egy fejlesztő azzal az idejét, hogy az x. platform y. keretrendszerét is megtanulja, hogy abban is lekódolja ugyanazt a GUI-t, amit már z db másik platformon lekódolt?
Szalmabáb érvelés. Nem azt mondtam, hogy kódoljon le mindent nulláról, hanem azt mondtam, hogy az Electront kerülje el. Miért? Mert így sokkal több erőforrást zabál a szemete. Ez csak a hardwaregyártóknak jó, senki másnak.
A webes technológiák elég jók ahhoz, hogy egy minimál multiplatform GUI-t össze lehessen rakni velük.
Több, mint másfél évtized webfejlesztés után azt hiszem megalapozottan mondhatom, hogy a webes taknyológiák semmire se jók. (Kis túlzással.)
Mint mondtam, az oprendszerek gyártóinak kellene egy konzisztens HTML render motort gyárilag leszállítani és akkor nem kéne Electront használni.
Milyen szempontból konzisztens? A vizuális végeredményből? Hát abból a szempontból nagyjából konzisztensek a létező motorok, amit a HTML kód leír, az közel azonosan néz ki mindegyikben, ami eltérés akadhat is, az a default CSS beállításokból ered. (Mínusz a HTML5 még nem támogatott elemei az adott motorban.) Mire gondoltál?
A natív programok is eszik a memóriát, kérdés, hogy mennyi a különbség.
Programfüggő, mint mondtam, egy igazi lamer bármilyen nyelven tud jávaszkript kódot írni; de azért nem a C++ szokott lassú lenni. Hovatovább, az Electron még mindig csak egy példa volt.