Raccoon Attack - támadás a TLS ellen

1. A "desktopszerű dinamikus működés" csak egyes részeit érinti a weblapoknak; miért kell az egészet így csinálni?
2. A "desktopszerű dinamikus működés" nem feltétlenül igényli, hogy a különféle részeket node-onként hozd létre és fűzd össze interpreterből; egyidős a JS-sel az innerHTML property, ha felül akarok írni valamit és kb. a bronzkor óta létezik az insertAdjacentHTML() függvény a beszúrkálásokhoz, hozzáfűzésekhez. A direkt node-os cseszegetésre kb. akkor van szükség, amikor helyben állítasz valamilyen node szerkezetet össze, amin egy raklap egyéb attribútumot is be kell állítani, viszont maga a szerkezet totál egyszerű, pl. input-ok hozzáfűzése egy listához, vagy whatever.
3. A "desktopszerű dinamikus működés" megvalósításához pár sor JS is elég, mi a túrónak hozzá hatvannyolcezer féle JS keretrendszer. 4 teh lulz?

A HTMLt mindenképp ugyanannyiszor rakod össze függetlenül attól, hogy kliens oldal-on van a HTML "generálva", vagy szerver oldalon. (A renderelést a böngésző végzi a HTML-ből, azt ne keverjük ide, az mindenképp ugyanúgy történik bármelyik oldalon is áll elő maga a HTML.) Persze előfordulhat olyan eset, hogy a HTML-t cache-elni lehet, és akkor elég a cacheből visszaadni, de a mai weboldalak töredéke lehet ilyen, többnyire teljesen egyedi oldal jelenik meg minden letöltéskor.

Ezt szépen meg is válaszoltad magadnak: cache. Hogy nem mindenütt használják, az egy dolog, de a lehetőség megvan rá.

Másrészt egyáltalán nem egyértelmű, hogy nem hatékonyabb ha a kliens oldalon építed a HTML-t, ugyanis így tényleg csak annyi adatmozgás történik a kliens és a szerver között, ami feltétlenül szükséges, míg a hagyományos JS nélküli HTML esetében minden egyes kattintásra a teljes oldalt újra kell tölteni függetlenül attól, hogy épp mekkora része változatlan az oldalnak.

Ez hatalmas tévedés. Olvasd el még egyszer, amit mondtam; kulcsszavak: AJAX, innerHTML, insertAdjacentHTML().

A felhasználói élményről nem is beszélve.

Éppen a felhasználói élmény az, amit a lassúság és az erőforrászabálás kinyír.

Persze ez minden oldalnál egyedi, hogy épp melyik éri meg jobban, mondjuk egy híroldalnál jól tud működni a hagyományos HTML, de minél inkább elmozdulunk webalkalmazás irányba ez annál kevésbé lesz így.

Ld. a kettővel előbbi bekezdést. Én asszem, hogy te valamit nagyon félreértettél, én nem a dinamikusan betöltött tartalomról beszéltem, hanem a JS-ből történő nodetree-buildingről.

És azt akkor meg sem említettem, hogy gyakorlatilag ma már nem létezik olyan oldal, amiben ne lenne valamennyi JS.

Ööö...és?

Azért ez így elég félrevezető, úgy érzem pár réteget minta lehagytál volna, de a valóság azért jóval bonyolutabb:

A levezetés céljából irreleváns vagy nem létező réteget. Kit érdekel, hogy honnan jön az adat? Egyáltalán, miért kéne feltétlenül DB-ből jönnie? Nem ez volt a lényeg. Hovatovább, te viszont kihagytál egy lépést a második esetből, nevezetesen az adatszerkezet összeállítását. A JSON-t talán nem kell összeállítani, mint a HTML-t? A te második eseted így kéne, hogy kinézzen:

DB -> server / repository layer (-> server / service layer - egyszerűbb esetben ez kimaradhat) -> server / controller layer -> server / json (vagy egyéb struktúra) generálás -> browser / html generálás JS-ből -> browser / HTML megjelenítés

Így aztán ugyanott tartunk, mint az én leegyszerűsített sémámnál: a kettes esetben a szerveroldalon így is van struktúragenerálás, a kliensoldalon meg manuális nodetree-building és így is egyel több lépés a kettes eset.

És a meglepetés az, hogy igazából mindkét esetben ugyanannyi lépés / réteg van, gyakorlatilag tényleg csak annyi a különbség, hogy melyik oldalon áll elő a controllerből kijövő adatből a HTML. Persze nem mondom, hogy minden websitenak ilyen a felépítése (de azért az esetek túlnyomó többsége ilyen, az elmúlt 10+ évben gyakorlatilag ez az architektúra egyeduralkodó volt), de ahol nincsennek ilyen szépen meg a rétegek, ott is tipikusan ezek a lépések történnek.

Kivéve, hogy nem ugyanannyi réteg a két megoldás, mert a kettesből kifelejtettél egy fontos réteget; ld. egyel feljebb. A te sémádnál a szerveroldali "kontroller" és a browser között egy nagy semmi volt, mintha az adat varázslatosan csak átkerült volna az egyikből a másikba. Az adatszerkezet összeállítását a szerveroldalon nem lehet megspórolni. Cachelni persze a kapott JSON-t is lehet, ahogy a HTML-t is, de ettől még a túloldalon marad a manuális nodetree-building, a lépések száma nem változik.

Annak pedig a fejlesztési oldalon nagyon nagy előnyei vannak (fejlesztésnél, tesztelésnél és deploymentnél is), ha a kliens és a szerver oldal architekturálisan is el tud különülni ez az egyik fő oka annak, hogy mára ez az irány dominál.

A szerver és a kliens "architektúrálisan" mindenképpen elkülönül, semmi szükség erre a pocsékoló felállásra. Egyáltalán nem ez az oka, hogy ez az irány dominál. Azért dominál ez az irány, mert ez a trend. A divat.