BGAFC Vendégkönyv

Σ: 1 post

TCH (statz)

#1, Főfasz (10443)

7194 | #5216 | ^ | Idézet | Tue, 12 Jan 2021 12:55:10 +01

178.164.*.*

*.pool.digikabel.hu

@Ádám:
Lehet ezeket a megálmodott mindenféle effekteket meg animációkat nem erőforrászabáló módon is kivitelezni?
Ezeket mind dzsuvaszkriptben írják, az meg önmagában lassú és erőforrászabáló, nemde?

Hogymongyammagának... A dzsuvaszkript az egy nyelv. Egy szar, inkonzisztens, logikátlan és minden épeszű koncepciót nélkülöző nyelv, de csak egy nyelv, nem más.
Az, ami önmagában is lassú és erőforrászabáló lehet, az a VM implementáció, ami majd a JS-t fogja futtatni. Ha azt annyira szarul írják meg, akkor a gép bele fog szakadni egy alert('kecske');-be is. Namármost, alapvetően, mivel a JS nem CPU utasításokra fordul, hanem bytecode utasításokra, amit nem a CPU, hanem a VM interpretál és futtat, ez már önmagában is lassabb lesz, mint egy "natív" nyelv, de a lassabb nem ekvivalens a lassú-val. Az tény, hogy az összes JS VM tele van bugokkal és nem kevés memóriát zabál még alapjáraton is, de a VM-ek interpreterjeinek optimalizációjának szempontjából el kell ismerni, hogy irdatlan munka van mindegyik motorban, mondjuk nem is csoda, mert a webkettő ezt kikényszerítette, ld. mindjárt.
Képbe jön még a JIT is, azaz a Just-In-Time, azaz, amikor a bytecode egyes részeit a browser futásidő alatt leforgatja magának az adott CPU architektúra utasításaira és tkp. utána átadja neki a vezérlést és ez is tovább gyorsít még rajta és ezt sem tegnap találták ki, hanem elég régen.

Mit jelent mindez a gyakorlatban? Azt, hogy egy egyszerű JS kód nem lesz lassú. Lassabb lesz, mint ha valami natív nyelvben írták volna, de mint mondtam a lassúság relatív, az, hogy lassabb, mint ha C-ben írták volna, még nem jelenti azt, hogy lassú is lesz. A C-ből fordított kód sem lesz gyors, csak azért, mert C-ben írták: nézd meg a GTK3-at, azt C-ben írták, oszt' olyan lassú, mint a picsa...

Tehát a sok rizsa után megválaszolva a kérdésedet: igen, meg lehetne JS-ből írni ezeket a funkciókat úgy, hogy ne legyen lassú és ne legyen - annyira - erőforrászabáló. A webkettes webappok (OMG) azért olyan szájbabaszott lassúak, mert húsz féle JS keretrendszer fut bennük párhuzamosan és olyan elkúrt, konvulens módon valósítanak meg benne minden szart, hogy megszakad alatta a böngésző. A feladat csak annyi volt, hogy egy kattintást küldjön el a szervernek, aztán a kapott eredményt köpje ki valahova, de mindezt több megányi JS-sel oldották meg.

A webkettő developereknek nincs kultúrájuk, sem eszük (tisztelet a kevés számú kivételnek), a webkettőt vallásként kezelik és a JS benne a szent grál, szent és sérthetetlen...

https://www.commitstrip.com/wp-content/uploads/2019/04/Strip-Trop-de-JS-dans-le-web-650-finalenglish.jpg
https://www.commitstrip.com/wp-content/uploads/2020/09/Strip-Réduis-tes-ko-650-finalenglish.jpg

Mutatok egy példát. Nemrégiben Prometheus révén jelentkeztem egy céghez és kaptam próbafeladatot. A szerveroldali rész itt nem érdekes, fókuszáljunk a kliensoldalra. A feladat az volt, hogy

Kliens oldalon JQuery segítségével jeleníts meg egy táblázatot a kapott adatokkal.

azaz explicit megkövetelték a jQuery használatát, bár helyesen leírni a nevét nem sikerült nekik... Ennek formálisan eleget tettem, mert az AJAX-ot a jQuery intézi (kemény egy db $.get()), tehát a segítségével jelenítem meg a táblát, de minden mást saját kútfőből oldottam meg.
Namármost, a jQuery v3.5.1, amit én használtam, az 89476 byte méretű, tehát közel száz kByte-ról indulunk alapból. A jQuery-s táblaplugin-ek általában többszáz kByte-osak. Ha megnézünk belőlük egy párat, akkor látni fogjuk, hogy a tudásuk változó, de körülbelül kimerül az egy oszlopra rendezésben, lapozásban és egymezős keresésben (azaz ugyanazt keresi minden kereshető mezőben), adatot módosítani meg vagy tudnak, vagy nem.
Ehhez képest az, amit én csináltam az a kommentekkel együtt is kevesebbet foglal, mint 7 kbyte és ezek után nem egyszerűen tud több oszlopra rendezni, hanem prioritizáltan (azaz te döntöd el az egyes oszlopok fontossági sorrendjét), nem egy mezővel tud keresni az összes oszlopban, hanem minden oszlopnak saját keresőmezője van és minden mezőt lehet szerkeszteni, továbbá lehet törölni is, akár csoportosan is (checkbox a sor elején). Pusztán a kísérletezés kedvéért, kipróbáltam, hogy az AJAX-ot mennyiből tudom kihozni; így született meg a Yoctoajax, ami a maga 240 byte-os méretével (kommentek nélkül, minifizálva) talán a legkisebb létező AJAX library, ami GET-et és POST-ot is tud. (Nyilván, ha csak az egyiket tudná, akkor még kevesebb is lehetne, de akkor nem lenne teljes értékű.) Vagyis, még ha az AJAX-ot is én csinálom, akkor is 7 kB körül marad a végeredmény.
A Yoctoajaxos verziót feltettem ide, az adatbázist alá így tudod beimportálni (nyilván felkonfigolt MySQL kell hozzá):

git clone https://github.com/datacharmer/test_db
cd test_db
mysql -t < employees.sql -p

De ha nem akarsz ezzel vacakolni, itt egy képernyőfotó, ezen minden látszik, kivéve a sebességet, de kb. arról van szó, hogy a szerver válaszidejét leszámítva itt instant történik minden. (Egyébként a MySQL teszt adatbázis egy nagy fos, elkúrt struktúra és indexek, minek következtében pármillió rekordban is több másodpercet vett igénybe a keresés, ami elfogadhatatlan, nem véletlenül van lent az a két gomb; a Correct indexes a normalizált táblákon hajtja végre az indexstruktúrák korrekcióját (egyébként nem segít túl sokat, de valamennyit igen), a Denormalize table, meg csinál egy denormalizált nézetet, na azzal tényleg minden <1s alatt jön vissza a szerverről... Csak mivel nem tudtam, hogy megengedett-e, ezért opcionálissá tettem.)

Felteszem akkor a kérdést, hogy miért sikerült nekem 7 kByte-ból egy sokkal többet tudó és mégis sokkal gyorsabb táblagenerátort kihoznom, mint ezeknek jQuery+plugin felállással többszáz kByte-ból? Trécéhá, a retardált kecske, ekkora májer lenne? Nem. Ezek ekkora balfaszok. Über-balfaszok. Mint mondtam, a JS-t szent grálként kezelik; öncélúan vernek telibe vele mindent, minden cél és értelem nélkül. Ezért lassú az összes webkettes fos. Mert tőből leszarják, hogy mennyi funkcionalitást kell megvalósítani, a lényeg, hogy a kedvenc JS keretrendszereket használni kell.

@Ádám:
Az, de a mai mezőnyben egy WP-ben normálisan összerakott weblap bőven elmegy (sajnos).

Elhiszem, de a mélyén fos marad.

@Ádám:
Nem, azt a trészisztem gányolta össze. Ilyen szart csak ők tudnak :D
(webarchívba' szerintem láthatod, hogy milyen vót az, amire gondolok, működött, de lassú volt meg eléggé bugzódott)

Meg a mikrofos tud még ilyeneket. :P

@Ádám:
(Gondolom, adatvédelmileg ez se a legjobb, de a guglikróm és társai meg már nagyon fosok)

Igazából majdnem ugyanott vagy velük.