> Melyik tábla plugin volt ez?
Több is. Keress táblaplugineket a jQuery-hez. (Gondolom, most mindjárt megkeresed a legprimitívebbet, ami csak 30 kB...)
> Könnyű egyébként gyűjteni a kB-okat, ha mellékel saját CSS-t, meg mobilon is jól működik, meg általános használatra készül sok funkcióval.
JS kódról beszélünk, nem CSS-ről.
> A te tábla megoldásod biztos jó volt arra a pár funkcióra, amire kifejlesztetted, de nem egy általános pluginnak készült.
Minden további nélkül lehet arra használni. Ami miatt "nem általános", hogy a mezők kézzel vannak megadva benne. Pár sor kód és jöhet konfigtömbből. Próbálhatod bagatellizálni, csak felesleges. A jQuery-s táblapluginok többsége, ahogy néztem egy mezőre tudott szűrni és rendezni, nem volt multifield filter és order, pláne nem prioritizálható sorrenddel.
> Mi neked a keretrendszer? Nekem pl. Angular/React/Vue/stb.
Nekem is ezek.
> Soha nem láttam még olyat, hogy valaki egyszerre használt volna ezekből többet. Minek? Ugyanazt valósítják meg, csak máshogy.
Mert nem éltél webfejlesztésből... Az egyik funkciót ezzel a keretrendszerrel valósítják meg, mert ehhez van plugin, a másikat azzal, mert ahhoz van plugin...
> Ami egy felhasználónak is: max 1-2 mp a felső limit az első betöltésnél.
Ehhez képest baromi ritka, hogy valami 1-2 sec alatt bejöjjön. (Ld. hup-os topicok, ha már szóbahoztad a hupot.) Egyébként melyik browserből 1-2 sec? Nem csak króm van. Nem véletlen, hogy a gugli ennyire erőlteti a JS-t; a króm JS motorja a legerősebb, ha az egész átáll a JS-erőltető megoldásokra, a króm versenyelőnye fokozódni fog.
> Mi a problémád a 100% JS renderrel, azon a nyilvánvaló eseten kívül, hogy letiltott JS mellett nem megy? Van annak is jó néhány előnye és nem jelenti egyből azt, hogy lassú lesz az oldal.
Az, hogy szerver oldali rendernél a szervert terheljük vele, jóesetben egyszer, amíg a cache nem lesz invalidálva, míg kliensoldalinál minden egyes klienst, ugyanazzal a renderfeladattal, sokszor. Miért is kell ez? Egyik példa pl., hogy meg lehessen indokolni az okostelefonok gyors erkölcsi avulását.
> A többi felsorolt problémához nincs közük nyilván.
Ehhez képest szépen leragadtunk a JS/Electron körben, pedig mint mondtam, csak egy közülük.
> Van még ilyen egyáltalán? Pláne böngészőbe ágyazott.
ie-only oldalak is vannak még, a pénzügyi szektor nehezen mozdul.
> És hogy készítsen asztali változatot a webes szolgáltatásából egy fejlesztő anélkül, hogy 0-ról újraírja a GUI-t?
Qt-hoz van saját stylesheet (QSS), lehet a CSS-t konvertálni, de egyébként színes-szagos, seggkinyalós GUI buildere is van.
> Powered by lesajnált webes technológiák. :D
Mert ugye itt a Drupal 8-ra való átállással is sokkal jobb lett minden.
> Egyébként minek foglalkozol akkor még mindig vele, ha 15 év alatt se találtál egy neked tetsző webes stack-et?
Azzal foglalkozom, amit megfizetnek. Ha van más, azt csinálom.
> Felsorolni se lehet hányféle megoldás van,
A többségük szar, max. egy-két specifikus célra létrehozott cucc van, ami azt tényleg jól tudja, amire kitalálták.
> és sajátot is létrehozhattál volna ennyi idő alatt.
Szerinted nem csináltam, többször is, a különféle cégeknek? Ott örültek, hogy milyen gyors, aztán annyi.
> Közel pixel pontos megjelenés mindenhol és ne kelljen azzal törődni, hogy melyik platformon milyen feature támogatott, hanem egy egységes API legyen. Az Electron pont azért készült, mert a natív webview komponensek platformonként eltértek render végeredményben és elérhető funkciókban is. Amíg ezt nem oldják meg, addig marad az Electron.
Pedig pont erre törekednek és elég nagy százalékban ugyanaz is jelenik meg, a maradék meg a default CSS-en múlik, de épp ezért vannak ilyen reset CSS-ek is. Egyébként hogyan is szabadulunk meg a webes technológiától, ha a browserek eljutnak oda, ahova te mondod?
Egyébként, ahhoz képest, hogy állításod szerint a véleményem érdekelt, már elkezdted bagatellizálni amiket csináltam és már kezded a véleményemet is karikírozni; már próbálod rámhúzni a csörgősipkát. Megmondtam, hogy magasról teszel a véleményemre, te már eldöntötted az elején, hogy mit akarsz hinni.