Weblabor

Egy múltkori fórumtéma kapcsán többen is a manapság népszerűnek tartott React-et és Angulart javasolták kezdőknek, ebben az írásomban bemutatom részletesen, hogy mi a probléma ezekkel.

Bizonytalanság

Ezek a keretrendszerek alapból kliensoldali sablonozást valósítanak meg, ami egy annyira abszurd ötlet, hogy gyakorlatilag ezen bukik el az egész, minden más csak hab a tortán.

A működési elvük a következő: általában nyers adatforrásokkal (json) dolgoznak, amiket a kliens aktuális állapota alapján olvasnak be, majd átadják a sablonoknak, amikből végül HTML-t generálnak. A kulcs itt az, hogy az aktuális állapot (az esetek túlnyomó többségében) a kliensen van, amivel legalább két probléma van. Az egyik, hogy egy áramszünet vagy a böngésző bezárása/a lap újratöltése után ez az állapot elveszik. A másik, hogy nem veszik figyelembe az internet alaptörvényét.

Ezt az alaptörvényt Peter-Paul Koch, az egyik legismertebb frontendes így emeli ki:Azaz lényegében fogalmunk sincs, hogy a kliensoldalon mi van, csak feltételezések. Nem tudhatjuk, hogy az a legújabb i7-es nyolc maggal, tizenhat szállal, hatvannégy gigabájt memóriával, vagy egy ötéves, 4.0-s Androidos telefon 512 megabájt RAM-mal. Mert a felhasználónak lehetősége van mindkettőt választani, ha az igényeit kielégíti.

Node egy Androidos böngésző ugyanolyan jó, mint a legújabb Chrome vagy Firefox? Ugyanúgy fog repeszteni? Ha a felhasználó számára lassú lesz az oldal, és emiatt otthagyja, az az ő baja, vagy a fejlesztő hibája? Ha utóbbi, akkor vállalja-e a felelősséget, és megtéríti-e a megrendelő kárát?
Nagyon jó példa erre a React 15.0 változási napló, melyben így fogalmaznak:A fejlesztők teljes dilettanciáról tesznek bizonyítékot, amikor azt feltételezik, hogy mindenki a legújabb böngészőket használja.

De ha a cél környezet undefined, akkor miért tárolunk ott állapotot? Ennél elborultabb ötlettel nem igazán jöhettek volna elő a kedves készítők.

Verziók

A React és Angular verziózása sem vetít előre semmi jót.

A React a kisebb kaliberű, de bőven alkalmas az ember elbizonytalanítására. Kezdetben 0.x verziószámokat használtak, ami a konvenciók alapján azt jelenti, hogy ez egy béta minőségű szoftver, és várhatóan az 1.0-ban vált stabillá. Ehhez képest a 0.14.7 után 15.0-ra váltottak, ami ezer kérdést hoz maga után, például hogy akkor már a 0.14 is stabil volt? Vagy csak a 15.0 stabil? A 15.0 ungyanolyan stabil, mint a 0.14? Ekkora változás van a 0.14 és a 15.0 között? Van jelentősége a verziójuknak, vagy inkább csak azt méregetik, melyiküké hosszabb, az Angularé vagy a Reacté? Marketing az egész?

Az Angular 1.x és 2.0 közötti váltásról mindenki hallott már, aki foglalkozik a témával, röviden annyi, hogy az új verzióban mindent újraírtak, visszafele nem kompatibilis.

Ezek után nem lehet tudni, hogy mikor játsszák meg ugyanezt, mikor dobhatja ki a kukába az aktuális fejlesztését az adott cég, aki Angularra épít, mert ez utóbbi készítői rájönnek, hogy nagyon elrontottak valamit, és megint újraírják.

Aki az Angulart választja ezek után, az egészen biztosan ostoba.

Node...

Ezen keretrendszerek azt igérik, hogy segítségükkel felgyorsul a fejlesztés és akarbantartás. Viszont nem minden megrendelő webes alkalmazást szeretne, hanem egy átlag weboldalt, aminél fontos szempont, hogy a keresőkben jó helyezést érjenek el, amihez fontos, hogy legyen statikus HTML kimenet (is). Mivel ezeket a keretrendszereket javascriptben írták, szerveroldalon jelenleg csak node.js segítségével lehet ezt megvalósítani.

Bár a javascript nagyon népszerű, a node.js-nél elcseszettebb programozási környezetet akarva sem lehet készíteni. Gyakorlatilag az első perctől azzal küzdenek, hogy a javascript nem arra lett kitalálva, amire ők használni szeretnék, lásd callback hell, amire máig n darab megoldás született, szabványt is módosítottak miatta, de mindegyik kompromisszumra készíti a fejlesztőt. Sokat elmond az egészről, hogy Ryan Dahl, a node.js megalkotója már a konkurens Go nyelvvel dolgozik.

A node.js stabilitásáról mindent elmond, hogy 2014-ben kettévált a fejlesztése, amelyek nem voltak teljesen kompatibilisek egymással. Bár egy év múlva egyesültek, nem tudhatjuk, mikor fog megtörténni ez az eset még egyszer. Innentől kezdve node.js-re építeni olyan, mintha valaki trágyadombra tervezne egy várat.

Mivel a webet a legtöbben php-ban programozzák, a node.js használatát is meg kell tanulniuk a fejlesztőknek. Nehezíti a dolgot, hogy még nem sok tárhelyszolgáltatónál van erre lehetőség, vagy pedig többet kell érte fizetni.

Így projektünkben egy függőséggel több lesz, ami a kiszolgáltatottságot növeli, nem beszélve arról, hogy ha magát az oldalt is javascriptben készítik el szerveroldalon.

Kavarodás

2004-2005 tájékán, amikor elkezdett elterjedni az XHTML, egy furcsa divat kezdte felütni magát, amit a weboldalakat táblázatok segítségével előállító munkások először nem értettek: a HTML-ben csak HTML legyen, a kinézetet a CSS fájlokban definiáljuk, míg a viselkedést a javascriptben. Például felejtsük el az onclick="" attribútumokat, a <b></b> tag-eket stb.

Ehhez képest, ha megnézünk egy Angular vagy React példát, az eseménykezelők szépen visszacsúsztak, ismét keveredik a HTML és a viselkedés (mindkét linket a rendszerek saját tutorialjából vettem, azaz ez az alap működésük, nincs más választásunk).

Ez sok kérdést vet fel, például mennyire kell ezek után komolyan venni a szétválasztás elvét? Ha igazából nem is olyan fontos, akkor mi alapján lehet megitélni, hogy egy webfejlesztői elv mennyire komolyan veendő? Az épp aktuális divatirányzatok felülírhatnak bármit? Mennyire stabil ez a szakma ezek után?

HTML

Teljesen mindegy, mennyit bűvészkedünk, a végén, mivel böngészőben vagyunk, úgyis HTML-t kell írnunk, ha szeretnénk, hogy bármi megjelenjen a képernyőn.

Ebből következik, hogy mindig léteznie kell egy adatszetnek, amiből sablonozással a képernyőn megjelenő tartalomhoz szükséges HTML kódot elő lehet állítani – ezt hívják állapotnak.

Az állapot részei a kiírt adatok, de például az is, hogy ha van egy listám – amihez nem a natív <select> elemet használom, hanem HTML-ben valósítottam meg –, és azt mondjuk lenyitom.

Ezt az állapotot a szerveren is tarthatom, így jóval megbízhatóbb lesz, mivel egy komoly bizonytalansági faktort egy kontrollált környezetbe tettem át. A szerverről pontosan tudom, hogyan működik, milyen szoftverek futnak rajta, tudom mérni a terhelését, bővíthetem, az egyes (szoftver) komponenseket lecserélhetem hatékonyabbra stb.

Működés

Egy webes alkalmazás/weboldal működése végtelenül primitív.

• Első lépésben a felhasználótól kapunk egy inputot: például kattint, beír egy szöveget, simogat.
• A második lépésben ezt feldolgozzuk, ami alapján változik az állapot.
• A harmadik lépésben ezen állapot alapján előállítjuk a HTML-t.

A harmadik a sablonozás, amikor az adatokat egy sablon szerint transzformáljuk. Ezt megtehetjük szerveroldalon, sokan elfelejtkeznek például arról, hogy a PHP egy sablonnyelv, de használhatunk külső rutinkönyvtárakat is, mint a mustache vagy az XSLT.

Egy ilyen egyszerű sablonozó rendszert pártíz kilobájtból össze lehet hozni, a mustache például 19 kilobájtos.

Ha mondjuk egyoldalas alkalmazást készítünk, akkor tipikusan annyi feladatunk van, hogy a DOM fát frissítjük (törlünk belőle, hozzáadunk elemeket, meglevőket átírjuk).

Ha az alkalmazás működéséből kivesszük a sablonozást, az eseménykezelést és a DOM fa frissítését a megfelelő adatokkal meg lehet oldani nagyjából öt-tíz kilobájt javascript kóddal.

Menő

janoszen a következőt fogalmazta meg arra a kérdésre, hogy kezdőként mivel érdemes foglalkozni:Ez a mondat azért csodálatos, mert benne van az önmaga cáfolata.

A kulcs az általam kiemelt "az most menő": egyrészt csak most menő, másrészt, ha belegondolunk, hogyan működik a divat, olyan, mint a tavaszi szellő, most itt van, egy év múlva más lesz a helyén.

Ebből következik, hogy erre építeni felelőtlenség. Ráadásul szerinte négy komponens használatát szükséges ahhoz megtanulni, hogy használható tudásunk legyen, ami rengeteg idő, amit a következő "menő" keretrendszer megjelenésénél dobhatunk a szemétbe.

Megrendelő

BlaZe a fenti fórumtémában a következőket állította:Ha a Működés fejezetben és a korábban leírtakból indulunk ki, akkor az, amit BlaZe ír, szakmailag megalapozatlan és rossz tanács, hisz akár öt-tíz kilobájtból ki lehet hozni egy teljes, szabványos sablonozó rendszert eseménykezeléssel és dinamikus frissítéssel. Ezt elég egyszer megírni, és utána nem kell hozzányúlni, ha szerveroldalon kezeljük az állapotot.

Szóval felmerül a kérdés, hogy a megrendelő érdeke, hogy az aktuális divatirányzatnak megfelelő rendszert választok? És ha két év múlva teljesen átírják? És ha jövőre egészen más lesz a menő?

Fán

Amikor utánaolvastam a fenti keretrendszereknek, több helyen is belebotlottam abba, hogy kifejlesztésüknél fontos szempont volt az őket használó programozó kényelme, hogy fun legyen velük dolgozni.

Innentől kezdve ez az egész gyanús. Tisztelettel feltenném a kérdést, hogy a megrendelő abból él, hogy a weboldalának a fejlesztője élvezkedik, vagy pedig a produktumot használó felhasználók által közvetve vagy közvetlenül fizetett pénzből? Mert ha az utóbbi, akkor talán inkább az a legfontosabb, hogy minden felhasználóhoz, aki pénzt hoz, eljusson a tartalom és tudjon fizetni. Ha ez maradéktalanul teljesül, és a fentebb elmített legutolsó Androidos telefont használó sem fog továbbállni, mert az oldal gyors és nála is működik, akkor foglalkozhatunk azzal, hogy a fejlesztőknek is jó legyen. A webes programozás így is egy absztrakcióhalom teteje, amikor csak végtelenül egyszerű API-kat kell hívogatni, és nem kell foglalkozni azzal, hogy milyen bonyolult is valójában a helyzet.

Összegzés

A React és társainak választása minden szempontból hibás döntés, helyettük célszerűbb megismerni a böngészők működését, megtanulni a HTML, a CSS és a javascript használatát.

Pontosabban egy valamiben azért jobb a helyzet, mint korábban: a fejlesztők már adatokban gondolkodnak.