ugrás a tartalomhoz

fejlesztési módszer pro kontra

blabla · 2018. Már. 23. (P), 09.59
Sziasztok

A kérdésem pusztán elméleti.
Melyik a jobb megoldás : ha a kliens gépet dolgoztatom vagy ha a szerver oldali php scriptet? Józan (nem programozó végzettségű :) ) ésszel azt mondanám az első a jobb, de valóban így van?

Konkrét dolog:
Lekérsz adatokat a szerverről (mondjuk AJAXszal).
Mi a jobb megoldás?
Ha a szerverre beérkező kérés során nem csak az adatokat adjuk vissza hanem a megjelenítési formát is (magyarán a kész HTML kódot), vagy ha csak az adatokat adom vissza és hagyom hogy a kliens oldali javascript létrehozza a megjelenítéshez szükséges html formát?
‹ URL dekódolás Egyetlen, egysoros sztringgé alakítás ›
 ■
1

Attol fugg

janoszen · 2018. Már. 23. (P), 10.45
A valasz, mint oly sok esetben az, hogy "attol fugg". Ha kliens oldalon dolgozol, azt a keresogepek nehezen tudjak felnyalni. (Az elso paint-ig futtatnak JS-t elvileg.) Raadasul a JS single process / single thread cooperative multitaskingon alapul, eleg konnyu CPU hoggal megolni az egeszet.

Cserebe viszont a vastagklienses fejlesztes sokkal konnyebben karbantarthato, mert eles elvalasztas van a backend logika es a frontend logika kozott (API-val elvalasztva).
6

Karbantartás

Hidvégi Gábor · 2018. Már. 26. (H), 12.14
Cserebe viszont a vastagklienses fejlesztes sokkal konnyebben karbantarthato, mert eles elvalasztas van a backend logika es a frontend logika kozott (API-val elvalasztva).
Biztos?

Nézzük a szükséges lépéseket:
  • bejövő adatok feldolgozása
  • válaszhoz szükséges adatok összeállítása
  • a válasz "kinyomtatása"

Ebből az utolsó pont a lényeges, ahol a kérés típusától függően a vastagkliens esetében mondjuk JSON-t küldünk ki, egyébként meg HTML-t.

Szóval a hagyományos kliens esetében is tökéletesen el lehet választani a programlogikát a sablonozástól, így a karbantartásra nincs igazán hátránnyal ez a megközelítés.

Ha arra gondoltál, hogy itt kényszerűen szét van választva a két oldal, és emiatt nem lesz spagettikód, ez megvalósulhat, de például a múltkori Google Drive-os elemzésemben rámutattam, hogy ettől függetlenül magában a frontend kódban keveredtek a sablonok és az alkalmazáslogika.

Ez a szétválasztás abból a szempontból hasznos, hogy az adatok kérvényezője el tudja dönteni, hogyan dolgozza fel azokat.
7

Szerintem János

Pepita · 2018. Már. 26. (H), 18.01
nem a "kinyomtatásra" gondolt (pedig tetszik a kifejezés):

backend logika es a frontend logika kozott


hanem arra, hogy ha már egyre több logikát viszünk ki a FE-re (kényelmi / használhatósági okokból), akkor minél élesebben van elválasztva, annál kevesebb a kvázi kódduplikáció.
Ha mindig html-t küldünk, akkor sanszos, hogy sok olyan apró-cseprő ellenőrzést viszünk ki FE-re is, amiknek meg kell lennie BE-n, de könnyen megvalósítható FE-n és gyorsabbá és / vagy kényelmesebbé teszi a használatot, ha normál esetben már FE-n kiderül, hogy ott még matatni kell a usernek.

API-t hívogatva pedig van egy kötött (adat)struktúrád, a FE eldönti, hogy hogyan állítja elő a requestet, BE meg dob egy k.. nagy errort, ha nem volt jó. Státuszkódokkal még külön lehet csoportosítani a hibákat.
Tisztább, szárazabb érzés.
8

Raadasul a JS single process

inf · 2018. Már. 27. (K), 11.12
Raadasul a JS single process / single thread cooperative multitaskingon alapul, eleg konnyu CPU hoggal megolni az egeszet.


Olyan 2010 óta lehet WebWorker, mostanra már elég széles a támogatottsága.
11

Igen

janoszen · 2018. Már. 27. (K), 20.17
Igen, kulon kell vele erolkodni, nem fersz hozza a DOM fahoz, stb. A mai napig a frontend fejlesztok tobbsege nem tudja hasznalni ertelmesen.
24

Hát biztosan vicces hibákhoz

inf · 2018. Már. 28. (Sze), 12.11
Hát biztosan vicces hibákhoz vezetne, ha több szálról lehetne írni ugyanazt a DOM fát, de szerintem jobb, ha nem megyünk el ilyen irányba. Szerintem teljesen jó a mostani rendszer, hogy a számításigényes dolgokat ki lehet vinni külön szálba, pl grafikon készítésre vagy bármi hasonlóra. Leginkább szerintem 3d alkalmazások veszik hasznát, más téren lényegi javulást nem hiszem, hogy adna, hacsak nem hatalmas adatsorokat próbál kliens oldalon feldolgozni valaki (de azt meg én az esetek többségében a szerverre tenném).
12

Többszálúság

Hidvégi Gábor · 2018. Már. 28. (Sze), 07.20
Szerintem a többszálúság bevezetése minden szempontból visszalépés.

A böngészők a dinamikus típusosság és egyebek miatt eleve jóval erőforrásigényesebbek, mint egy natív program, ha több szálat használnak és ezeket programozni is lehet WebWorkerekkel, akkor még rosszabb lesz a helyzet. Így egy rosszul megírt webes alkalmazás miatt nem csak egy magot, hanem mindet meg tudja ölni, vagy például kiválóan lehet így bányászni.

A legtöbb lassú weboldal és webes alkalmazás egyszerűen csak rosszul van megírva, és optimalizálással csodákat lehet művelni, de ehelyett egyszerűbb és csábítóbb áttenni bizonyos műveleteket más szálakra.

Az erőforrások korlátozottsága miatt születnek mindig a nagy ötletek.
13

Ez nem böngészős programokra

BlaZe · 2018. Már. 28. (Sze), 07.59
Ez nem böngészős programokra akkor miért nem igaz? Hol jó akkor egy többszálú program? Egy rosszul megírt többszálú program nem böngészőben is tud galibát okozni. Sőt, még inkább tud pl egy shared állapottéren operáló program, ahol az erőforrások nem optimális kihasználása mellett az inkorrekt állapotok is be tudnak jönni, valamint deadlockok, egyéb liveness, visibility, ordering issuek stb.

Vannak feladatok, amiket jól lehet offloadolni worker szálakra. Ennek támogatása nem hiszem, hogy visszalépés.
14

Más

Hidvégi Gábor · 2018. Már. 28. (Sze), 08.41
A webnek az a lényege, hogy az erőforrások/adatok egy része a szerveren van, például üzleti szempontból, ezért a böngésző mint egy ablak vagy rajzvászon vesz részt a folyamatban. A legtöbb webes alkalmazás végtelenül primitív a működését tekintve, lásd Facebook vagy Google Drive, az előbbi például előre generált HTML-eket küld, de mégis mindkettő nagyon lassú, mert rosszul vannak megírva.

A nem webes alkalmazásoknál mások a kritériumok. És biztosan vannak a weben is olyan feladatok, ahol érdemes használni a WebWorkereket.
19

Rengeteg dolgot nem tudsz megoldani szerveroldalon

BlaZe · 2018. Már. 28. (Sze), 09.44
Rengeteg dolgot nem tudsz megoldani szerveroldalon generált tartalommal. Pl egy interaktív grafikonhoz nagyon kell a kliens oldali JS, és ez elég erőforrásigényes is tud lenni nagyobb adatmennyiségnél. Tehát ez valójában előrelépés, nem visszalépés.

Én ha már definiálni akarjuk a böngészőt, akkor azt mondanám, hogy a UX van ott, nem a megjelenítés. Van különbség a kettő között (validáció stb).

Én Facebookot mondjuk egyáltalán nem használok, viszont elég sokat használom a Google Drive-ot. Rengeteg doksit, táblázatot és prezentációt készítettem vele és a MS OneDrive-val is, napi szinten használom. Soha nem éreztem még lassúnak egyiket sem. A 6 éves laptopomon sem, az év elején vásárolton meg pláne nem. Őskövületeken, vagy a mai szoftverekhez nagyon alultervezett hardware-en nyilván lassú lehet. De egy pár éves gép elég jól viszi, márpedig arra kell méretezni.
23

Szerintem egyáltalán nem

inf · 2018. Már. 28. (Sze), 11.50
Szerintem egyáltalán nem visszalépés, pl a notifications-t ez hozta el. Annál is amennyire én tudom worker fut a háttérben és az küldi az értesítéseket, ha valami történt az adott oldalon.

Abban teljes mértékben egyetértek, hogy a többség átgondolatlanul vagy rosszul használja ezeket az eszközöket, de ez nem az eszközök hibája. Én a képzésben látom a megoldást ahelyett, hogy korlátoznánk az elérhető eszközök számát. Azt hiszem ez általánosságban igaz az általunk lefolytatott viták szinte mindegyikénél.

A háttérben történő workeres cryptocurrency bányászat valóban elterjedt pl pornó oldalakon.
25

Képzés

Hidvégi Gábor · 2018. Már. 28. (Sze), 12.16
Igazad van, csak nagyon nehéz a megoldása, mert az internet decentralizált, az MDN-ről például csak az alapokat lehet megtanulni, de komplexebb feladatok megoldását már nem.

Nehezíti a helyzetet, ha az ember keretrendszerekkel dolgozik, mert azok bizonyos problémákat elfednek, viszont, ha kiderül, hogy ezek bármelyikénél szűk keresztmetszet, nem is lesz az egyszeri webfejlesztőnek eszköze, elképzelése arra, hogyan lehet jól megcsinálni, sőt, ha nem moduláris, akkor még lecserélni sem tudja.
27

Persze, de ez sem a

inf · 2018. Már. 28. (Sze), 12.28
Persze, de ez sem a keretrendszerek hibája, mindegyik valamilyen absztrakciót használ, ami sosem nyújt minden esetben tökéletes megoldást, ismerni kell a korlátaikat. Ha odáig jut egy projekt, hogy a keretrendszer a szűk keresztmetszet, akkor muszáj lesz vagy belefejleszteni a keretrendszerbe, vagy kidobni a szűk keresztmetszetet tartalmazó részen a keretrendszerre épülő kódot, és megcsinálni valamilyen alacsonyabb szintű kóddal. Szerintem az esetek döntő többségében nem muszáj ehhez nulláról újraírni a teljes alkalmazást. Abban igazad van, hogy az egyszeri fejlesztő nem feltétlen képes ilyen módosításokra, ha nem tudja, hogy alacsony szinten hogyan működik az aktuális keretrendszer, és hogy mi okozza a szűk keresztmetszetet, amin változtatni kéne. A keretrendszerek egyébként nagyon hasznosak, rengeteg időt lehet spórolni velük, az áruk meg ez, amit te is írsz, hogy az absztrakció elfedi a működésüket.
2

Nem egyértelmű

Pepita · 2018. Már. 23. (P), 10.46
Az első kérdésedre nem lehet egyértelműen kimondani, hogy melyik a jobb, mert egyrészt feladatfüggő (van amit szerveren jobb / kell megoldani, van aimt nem), másrészt nagyban függ a kliens teljesítményétől, amit viszont gyakorlatilag nem tudsz, legfeljebb sejtesz vagy elvársz (pl nem támogatunk "régi" böngészőt => ha van ilyen böngésző, az feltételez valamennyi vasat is).

Lekérsz adatokat a szerverről (mondjuk AJAXszal)
Ilyenkor is feladatfüggő, de többnyire inkább csak az adatokat küldjük ki, és FE intézi a megjelenítést.
3

Értem..

blabla · 2018. Már. 23. (P), 11.01
Köszönöm. Nos az adatok amiket használok sima mérési adatok, melyek nem szenzitívek, azaz public domain. Ezért gondoltam arra hogy szerver oldalon csak feldolgozom a kérést ellenőrzéssel és a nyers adatokat töltöm vissza, és majd a kérésnek megfelelően (pl az adatok mely részére kíváncsi a user, vagy milyen csoportosításban/formában szeretné látni) jelenítem meg őket ahelyett hogy szerver oldalon hoznám létre a teljes html-t és azt küldeném vissza.
4

Attól függ...

Pepita · 2018. Már. 23. (P), 17.42
Csak hogy ne legyél olyan biztos a dolgodban (bocsi :) ), nézzük csak meg egy picit ezt:
az adatok mely részére kíváncsi a user, vagy milyen csoportosításban/formában szeretné látni
Ez máris egy határmezsgye...

- Ha van 10 M adatod a db-ben és a user csak 100 k-t akar megnézni, ne küldd el mind a 10 M-t.
- Csoportosítás / sorba rendezés szintén sokkal könnyebb db lekérdezés során, esetleges mapping stb pedig php-ban.
- Fenti kettő viszont még mindig az adatokra vonatkozik, nem kell hozzá html.

A lényeg kb az, hogy minél pontosabb legyen az ajax request, a visszakapott adatokkal már ne kelljen a kliensen manipulálni, de a kiíratás lehet nyugodtan a kliens dolga.

Inkább olyankor fordulhat elő, hogy érdemes html-t válaszolni, amikor pár adatból bonyolult logika szerint bonyolult html-rész keletkezik. Ha viszont "nyers adat" van sok, de egyszerű kiírni, akkor ne szorozzuk az adatforgalmat x-el a html miatt.
15

Értem

blabla · 2018. Már. 28. (Sze), 09.07
De mi van akkor ha a user a 100 k-t akar megjeleníteni, azonban egy selectet átállít és máris a 10 M másik 100 k-ját szeretné látni?
Akkor a select esemény ismét ajaxszozzon? Nem elég egyszer áttolni a 10 M-t és akkor a user úgy válogat ahogy szeretne? A szerver "békénhagyása" mellett?

A lekérdezés, sorba rendezés valóban gyorsabb ha az adatbázis csinálja, de kérdés ha van a következő szitució amit fentebb említettem, akkor a select onchange ajax kérés ideje + megjelenítés majd újabb select onchange + megjelenítés vajon tényleg gyorsabb-e mintha egyszer átmegy a 10 M és utána a kliens gépe dolgozik?
16

Ez már pláne attól függ. :)

Pepita · 2018. Már. 28. (Sze), 09.24
Azért én 10 M adatot szerintem még sose küldtem kliensre, de néha előfordul igen, hogy pl a lapozást kliens oldja meg. De vigyázni kell, mert túl sok rekorddal js-ből is le tudod fektetni a klienst.
Szóval egészséges határokat érdemes tartani.
Én alapvetően backend-párti vagyok ha valami matekot igényel, mert azt a vasat könnyebben tudom növelni (ha kell), mint a userét... Utóbbiról nem is tudod, hogy behalt, "csak" buktál egy látogatót.
18

Jó, most utánanéztem

blabla · 2018. Már. 28. (Sze), 09.35
én korántsem dolgozok 10Mb adattal:)))
Még 1 MB sincs.
21

Méretek

Hidvégi Gábor · 2018. Már. 28. (Sze), 09.58
Száz kilobájtba rengeteg minden belefér, ennyit át tud látni egy ember egyszerre? Mi is többezres listákkal dolgozunk, de ha húsz sornyi adat fér ki a képernyőre, akkor miért küldenénk ki mindent?
10

Ha grafikonokat akarsz, akkor

inf · 2018. Már. 27. (K), 11.57
Ha grafikonokat akarsz, akkor svg vagy canvas jó lehet neked valamilyen keretrendszerrel, pl d3.js-el. A csoportosítást, rendezést, clusterezést, ilyesmiket inkább bízd a szerverre. Bőven elég erre a célra, ha JSON-ban küldöd át, aztán összegányolod a megjelenítő kódot, ha nem túl változékony az adat. Érdemes mindenképp olyan keretrendszert választani, ami újrahasznosítja a meglévő DOM element-eket, ahelyett, hogy mindenre újat hozna létre. Ez nagy mértékben gyorsítja majd a frissítést. Elvileg a d3 ilyen grafikonokhoz. Ha valami hosszú listát/táblázatot akarsz scrollozni, akkor is lehet gyorsítani rajta, ha tényleges görgetés helyett a meglévő DOM element-eket frissíted rajta, és ahelyett, hogy pl 10.000 DOM element-et renderelnél le egyszerre, mondjuk renderelsz 20-at, ami egy oldalra kifér.
5

Nehéz

Hidvégi Gábor · 2018. Már. 26. (H), 10.00
AJAX-os oldalt könnyű készíteni, jó AJAX-os oldalt nagyon nehéz, általában nem is sikerül még a legnagyobbaknak sem. Nem is érdemes addig foglalkozni a témával, amíg az ember meg nem érti teljesen a HTML-t és a böngészők működését. Az AJAX-os weboldalak túlnyomó többségén használhatósági (usability) problémák vannak, vagy lassúak, vagy a keresők nem tudják őket rendesen indexelni, vagy túl bonyolultak, vagy ezek kombinációja.


Vastag kliens

Ha kliensoldalon állítod elő a tartalmat, akkor külön figyelmet kell szentelni a keresőknek, ha ez fontos számodra. Tehát szerveroldalon is el kell készíteni ilyenkor a HTML-t, és választhatsz, hogy ezt ugyancsak javascriptben végzed el, de akkor node.js-t kell használnod, és akkor nem kell kétszer dolgoznod. Vagy ha PHP-val állítod elő, akkor az kétszer annyi munkát fog jelenteni, kétszer annyi hibázási lehetőséggel és kétszer annyi fejlesztési és karbantartási idővel. Emellett a kliensprogram is bonyolultabb lesz némileg a következő bekezdésben leírtakhoz képest.


Vékony kliens

Ha csak szerveroldalon állítod elő a HTML-t, minimális kliensre lesz szükséged, mert annak csak annyi dolga lesz, hogy a megfelelő helyen lecseréli a HTML kódot. A szerveroldalon ehhez úgy kell elkészíteni a logikát, hogy tudni kell, az adott kérésnél melyik blokk változik, azaz az oldalt több ilyen részre kell bontani, például menü, tartalom, fejléc. Amikor normál kérés jön, például keresőből, akkor az összes blokk HTML kódját le kell generálni, ha AJAX, akkor pedig csak a szükségeset.


Hogyan?

Egy ilyen programot előképzettség nélkül nem egyszerű elkészíteni, még a vékony klienset sem. Én ezért azt ajánlanám, hogy először javascript nélkül, kvázi statikus oldalként, szerveroldalon előállított HTML-lel készítsd el az egészet, hagyományos űrlapokkal. Ez a biztos, ez mindenhol és mindenkinél működni fog, és legegyszerűbb az elkészítése. Emellett szerveroldalon megvalósítasz minden funkciót, azaz a bejövő adatok feldolgozását, valamint a kimenő HTML előállítását.

Ha tökéletesen működik, akkor érdemes utánaolvasni a Progressive Enhancement nevű dolognak, amivel "feldíszítheted" a már működő oldalt javascript segítségével.

Mondok egy példát: az adataidat táblázatosan jeleníted meg, és van egy szűrő, aminek a segítségével különböző feltételek szerint részhalmazokat jeleníthetsz meg. Tegyük fel, hogy ez működik a hagyományos módon, űrlapokkal, GET vagy POST metódussal. Ekkor javascriptben írhatsz hozzá egy nagyon egyszerű függvényt, hogy a Szűrés gombra AJAX-szal küldje el az űrlap elemeinek az értékét, és a visszakapott HTML-lel cserélje a meglévő táblázatot.

Így minimálisan kellett kiegészítened a meglévő kódbázist, a böngészőkben talán picivel gyorsabb lesz a működés, de a keresők is fel tudják dolgozni.

Nehezen találok érveket a vastag kliens mellett, de annál könnyebben ellene. A vastag klienst mindig újra le kell tölteni, ha változik az alkalmazáslogika, ha pedig a sablonok nincsenek különválasztva, akkor azokat is. A vékony kliensnél ezzel szemben elég, ha a szerveroldalon megváltoztatod a sablont, és az AJAX kéréskor azonnal már az fog kimenni.

Végeztem egy mérést is, a gépemen találtam egy adatfájlt (XML és JSON formátumban), és a belőle előállított HTML-t. A számok bájtban:
A kimeneti HTML mérete: 27 869
A bemenő XML mérete: 15 714
A bemenő JSON mérete: 14 911

Gzip-pel tömörítve pedig:
HTML: 1 438
XML: 1 148
JSON: 1 059

Ebből látszik, hogy mindenképp érdemes tömöríteni (ob_start('ob_gzhandler');), és hogy igazán nagy különbség a méretek között nincs.

Ha viszont kliensoldalon állítjuk elő a HTML-t, akkor nem szabad elfelejtkezni az overhead-ről, azaz a bejövő adatokat mindig át kell transzformálni. Ennek a sebessége függ a kliens hardverétől és a böngészőtől, amire nincs ráhatásunk. Lehet, hogy pár bájtot megspórolhatunk a nyers adatok küldésével, viszont mobil eszközökön jobban merítjük az akkumulátort.

Ha mindent a kliensoldalon állítasz elő, előfordulhat az, ami a World of Warcraft játéknál, ahol privát szerverekkel is működik a kliens, azaz elég volt elkészíteni a szerveroldali funkciókat.

Emellett bizonyos programrészeket a kliensen és a szerveroldalon is párhuzamosan el kell készíteni, például a klienstől érkező adatok ellenőrzését. Ez is negatív hatással van a fejlesztési és karbantartási időre.

A vastag kliens előnye lehet, hogy az adatokat nyers formában küldi, ezért nem csak böngészőben lehet feldolgozni, hanem akár mobilos alkalmazást is lehet hozzá írni. De egy jól megválasztott sablonozó rendszer (XML + XSLT) segítségével ez könnyen megoldható vékony klienssel is.


Összegzés

Vastag kliens:
  • ha a kliens változik, újra kell tölteni,
  • ahhoz, hogy a keresők indexelhessék, plusz erőfeszítéseket kell tenni,
  • a klienst bárki lemásolhatja, felhasználhatja
  • nagyobb az erőforrásigénye, lassabb.
Vékony kliens:
  • némileg nagyobb az adatforgalom
17

Köszönöm

blabla · 2018. Már. 28. (Sze), 09.32
a kimerítő választ. Nem vagyok kezdő de profi sem. Csak elbizonytalanodom mindig, mert nem vagyok biztos magamban, értsd nem tudom teljesen 100%-san megindokolni miért úgy csinálom ahogy, de ez már emberi dolog. Számomra a fontosabb a szerver minél nagyobb kímélete, és a gyorsaság.

Valóban, arra nem gondoltam, hogyha kliensen oldok meg dolgokat, akkor ha változik pl a javascript akkor a user amíg nem tölti le újra a teljes js-t addig nem fog megfelelően menni az oldal. És tényleg kétszer kell ellenőrizni a kérés adatait, egyiket a kliens oldalon kényelmi szempontból és egyszer a szerveren biztonsági okok miatt, persze kicsit máshogy.

A keresők nem érdekelnek, ez nem olyan weboldal, hogy minél nagyobb nézettséget produkáljon, célközönségnek szól akik tudják hol az oldal.

Mondok egy példát: az adataidat táblázatosan jeleníted meg, és van egy szűrő, aminek a segítségével különböző feltételek szerint részhalmazokat jeleníthetsz meg. Tegyük fel, hogy ez működik a hagyományos módon, űrlapokkal, GET vagy POST metódussal. Ekkor javascriptben írhatsz hozzá egy nagyon egyszerű függvényt, hogy a Szűrés gombra AJAX-szal küldje el az űrlap elemeinek az értékét, és a visszakapott HTML-lel cserélje a meglévő táblázatot.


Erre én azt kérdezem vissza, miért nem szűrhet a kliens? Miért kell újra "hátramenni" a szerverhez a szűrt adatokért? Egyszer átadom a teljes táblázat adatait, majd ha a user a szűrésre kattint, akkor mindenféle szerver kommunikáció nélkül ott a kliens gépen végrehajtja a szűrést. Az ajax kérés ideje valóban kisebb lesz mintha a kliens végzi el pl js-ben a szűrést (persze ehhez hozzátartozik az adattömb megfelelő struktúrája)? Az ajax kérésnél mindig ott van a hálózat akadozás lehetősége, míg a második esetben csak olyan vis major dolgok jöhetnek közbe ami csak és kizárólag a kliens gépe miatt következik be.
20

nem tudom teljesen 100%-san

Hidvégi Gábor · 2018. Már. 28. (Sze), 09.55
nem tudom teljesen 100%-san megindokolni miért úgy csinálom ahogy
Ezzel semmi gond nincs, amíg nem érted pontosan, hogy mi hogyan működik. Én sem értek sokmindent, ezért szoktam folyamatosan a dokumentációkat olvasni, valamint mérni, kísérletezni, összehasonlítani.

Erre én azt kérdezem vissza, miért nem szűrhet a kliens? Miért kell újra "hátramenni" a szerverhez a szűrt adatokért?
A web egyik alapszabálya, hogy a kliens undefined, azaz semmi biztosat nem tudsz róla. Nem tudod, hogy milyen teljesítményű eszközt használ, nem ismered a memória méretét, nem tudod, hogy milyen böngészője van. Ha viszonylag kevés adatod van, nyugodtan kiküldheted a kliensre, és lehet ott szűrni, nem fog problémát okozni. De ha az adatok száma nőhet az idők során, akkor előbb-utóbb valakinél negatívan fogja befolyásolni a működést, például elfogy a memóriája, és azt veszi észre, hogy amikor tabot vált, az mindig újratöltődik.

Itt is csak mérni kell. Mit nyersz azzal, ha minden lenn van a kliensen? És mit nyersz azzal, ha a listát mindig szerveroldalon generálod? Például jóval egyszerűbb lesz a program, könnyebb lesz a karbantartása és a fejlesztés.

Egyébként én már úgy dolgozom, hogy nem nagyon gondolkodok előre, hanem megírom úgy a programot, ahogyan jólesik, így gyorsan elkészül. Aztán ahogy használják, folyamatosan figyelem, és annak megfelelően csiszolok rajta.
22

Igen, az adatmennyiség

blabla · 2018. Már. 28. (Sze), 10.23
sok minden befolyásol. Most így elolvasva a hozzászólásokat, az jött le, hogy a kétféle megoldási mód közötti választás jelentősége többek között attól is függ mennyi adatot ráncigálok a kliens és a szerver között.
28

Nem tervezel?

Pepita · 2018. Már. 28. (Sze), 12.29
nem nagyon gondolkodok előre
Elég vadnak tűnik tervezés nélkül fejleszteni, hacsak nem valami szögegyszerű pici alkalmazás.
26

Pedig kéne

Pepita · 2018. Már. 28. (Sze), 12.27
nem tudom teljesen 100%-san megindokolni miért úgy csinálom ahogy
Odáig OK, hogy minden megoldásnál van jobb és rosszabb is, de azért valami alapján meghoztad a döntést, hogy miért úgy csinálod. Nem ritkán a megrendelő is kíváncsi rá.. (Erre mondjuk mindig ott a menekülőút: "mert így hamarabb kész és olcsóbb" :) )

Egyszer átadom a teljes táblázat adatait, majd ha a user a szűrésre kattint...
Ha meg is tudja jeleníteni az összes adatot, akkor is van némi plusz teljesítményigény, hogy miket kell közülük eldugni. Mondjuk egy max 100 soros táblázatnál még nem gond, de amit Gábor is említett: a kliens undefined.
Ezzel együtt persze ki lehet mondani (és kell is), hogy az oldal csak az x.y.z verziónál újabb böngészőket támogatja, de ez még nem jelenti önmagában azt, hogy mekkora RAM / CPU van a vasban.
9

Ahogy fentebb is írták, sok

inf · 2018. Már. 27. (K), 11.48
Ahogy fentebb is írták, sok szempont van ezzel kapcsolatban:

- Mekkora a számítási igény a megjelenítésnél (pl adatok rendezése, svg készítés, stb.)?
- A számítási igényt elbírja-e egy átlag gép a célközönségedben minden erőlködés nélkül?
- Mennyire elavult az átlag böngésző a célközönségedben?
- Mennyire szokott gondot okozni az oldal karbantartása?

Talán még ezen felül is vannak szempontok, nekem most nem jut több eszembe. Talán annyi a lényeg, hogyha a klienst nagyon megdolgoztatod, akkor belassul az oldal, és rontani fogja a felhasználói élményt. Ha viszont erős a kliens és naprakész a böngésző, akkor a szervert tehermentesítheted, ha nagy a forgalom, és nehezen bírja.

Technikailag nagyon sokféle megoldás van.
Lehet HTML-t küldeni, ahogy írod, lehet JSON-al valami adatot küldeni, amit aztán átalakít HTML-re egy arra specifikus js kód, pl berakja egy sablonba. Itt az adat szempontjából van olyan módszer, hogy a model-nek megfelelő adatot küldöd el, és pl a sorba rendezés ilyesmi is a kliensen történik, vagy van olyan, hogy a viewmodel-t küldöd el, és a kliens tényleg csak annyit tesz, hogy sablonba illeszti. Lehet hypermedia-t is küldeni pl JSON-LD-vel, amit egy általános js kód alakít át HTML-re, amihez nem feltétlenül kell hozzányúlni, ha módosítasz valamit az adaton szemben az előző változattal.
Lehet websocket-et is használni AJAX helyett vagy mellett, hogyha realtime közeli kapcsolat kell, pl chatnél. Lehet webworker-t használni ha külön szálra akarsz tenni valami számításigényes dolgot, és nem akarod, hogy belassítsa az eredeti oldalt.
Vannak single page appok, amiknél az egész oldalt js kód hozza létre, van progressive enhancement, aminél js nélkül is megy az alap oldal simán HTML-el, a js csak extra funkciókat ad hozzá. Ilyesmik.
Mindennek van valamekkora előnye, és hátránya is, és érdemes a feladathoz eszközt választani. Ha pl csak annyi a szempont, hogy egy kis szeletét az oldalnak frissítsd újratöltés nélkül, akkor bőven elég a HTML fragmentet elküldeni.