ugrás a tartalomhoz

A frontend állapota 2017-ben

Hidvégi Gábor · Júl. 6. (Cs), 11.19
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:
The target environment is undefined. In most programming problems we start with with a well defined target environment (or at least the language semantics are well defined and we quickly learn where the platform-specific hacks are). In web programming each of the browsers is slightly different in about a hundred different ways.
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:
We are now using document.createElement instead of setting innerHTML when mounting components. This allows us to get rid of the data-reactid attribute on every node and make the DOM lighter. Using document.createElement is also faster in modern browsers
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:
Ha én Te lennék, akkor most megpróbálnék egy React, Redux, React Router és webpack stacket összerakni és azzal munkát szerezni, az most menő.
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:
Fizetést azért kapunk, mert értéket teremtünk a megrendelőnek, és azért kapunk magas fizetést, mert ezt hatékonyan (a pénzével optimálisan gazdálkodva) tesszük. Leveszem a polcról és használom a kb standardet, ezzel garantálom, hogy az utódom is érteni fog hozzá: ha lelépek, a megrendelőm/munkáltatóm minimális hiccuppal (elvárhatóan alacsony betanulási költség mellett) tud pótolni. VS saját hegesztett valami, amit csak te ismersz.
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.
 
1

Ha mar

janoszen · Júl. 6. (Cs), 11.56
Ha mar szemelyesen emlitettel es a szovegkornyezetbol kiragadt mondatommal probalod alatamasztani a mondanivalodat, had pontositsak egy kicsit: az illeto azt kerdezte, hogy mit tanuljon. Most, ha a piacon vagy, akkor rovid tavon eladhato dolgokat kell tanulnod. Mert azzal kapsz olyan allast, amivel tovabbi tanulasi lehetosegeknek elebe nezel.

Ami a React es tarsait illeti, fontos kulonbseget tenni akozott hogy mit szeretnel. Ha egy komplex alkalmazast keszitesz tobb szaz gombbal, tobb ezer beviteli mezovel, akkor kenytelen vagy egy react-szeru rendszert hasznalni, vagy sajatot kesziteni a szabvanyositas jegyeben. Ha mindenhol kezzel kezelsz mindent raw JS-ben, akkor az egy karbantarthatatlan katyvasz lesz. Ugyanakkor ha valaki egy bloghoz Reactot hasznal, akkor ott erosen megkerdojeleznem a dontesi kepessegeit.
2

Tévedsz

Hidvégi Gábor · Júl. 6. (Cs), 13.51
1, Ezt fejtettem ki fentebb, de nem reagáltál: a divat jön-megy. Ha rövid távon gondolkozol, megtanulod mondjuk a React-et, belejössz pár év alatt, aztán jön egy másik aktuális őrület, és kitörölheted a feneked a React-es tudásoddal, mert egészen máshogy fog működni. Lásd jQuery -> React közötti különbségek.

Ezzel szemben, ha van egy stabil JS tudásod, azzal tizenöt éve is el tudtál helyezkedni, meg ma is.

2, Nincs különbség egy többezer elemből álló alkalmazás és egy blog között. Semmi. Pontosan ugyanannyi meló egy tízezer elemből álló űrlapon frissíteni véletlenszerűen tízet, százat vagy ezret, mint egy darabot. Csak egy ötlet kell hozzá, és maga az algoritmus kevesebb, mint egy kilobájtos. Az Angular meg a React nagyjából egy megabájtos mérete az nem más, mint mellébeszélés.
3

Igy van

janoszen · Júl. 6. (Cs), 14.21
1. ez igy van, de ha pont most kezdesz bele, akkor elegge nagy kuzdelem bekerulni egy olyan ceghez ahol tanulhatsz ertelmes dolgokat. Plane ha semmi nincs az oneletrajzodban. At kell verekedned magad a HR-esen, aki csak a buzzwordoket ismeri.

2. De van kulonbseg. Ha 5-10 urlapot kezelsz, teljesen mas strategiat fogsz valasztani az alkalmazasodra mint frontenden, mint backenden, mint 1000 urlapra. 1000 urlapnak sokkal jobban fogsz szabvanyositani mint 10 eseten. 10 eseten ugyanis eroforras pocsekolas, tok jol mukodi a dzsekverivel osszekokanyoljuk oszt jonapot megoldas. 1000-nel nem.

Es azt tessek megerteni, hogy itt nem a reactrol van szo, hanem arrol, hogy a domturkalast kell kiszervezni ha bonyolult a frontend logika. Tok mindegy mivel, de valamivel meg fogod csinalni.
4

Tévedsz

Hidvégi Gábor · Júl. 6. (Cs), 16.03
1, Ha React/Angular vonalon mozogsz, azaz klasszikus webalkalmazást/-oldalt készítesz, akkor igazából a frontend az végtelenül primitív, és semmit sem változott 1991 óta. Ha ismered a HTML-t és a CSS-t, bármilyen kinézetet el tudsz készíteni, javascripttel pedig fel tudod dísziteni, élővé tudod tenni. De ez korábban is így volt, az alapok ugyanazok.

Ha Canvas-szel vagy SVG-vel játszol, az más tészta, és a téma szempontjából irreleváns.

2, Nincs különbség.

a, A legegyszerűbb weboldal is áll egy menüből és az aktuális menüponthoz tartozó tartalomból. Ha kapsz egy kérést, akkor át kell színezned az aktuális menüpontot, meg a tartalmat le kell cserélni. Azaz a belső állapotod egy darab mutató, méghozzá az aktuális menüpont azonosítója.

b, Ha egy ezerötszáz elemből álló űrlapon elvégzel egy műveletet, akkor változik mondjuk a kijelölt sor, a kijelölt elem, az aktuális sor tartalmát meg mondjuk újratöltöd. Itt a belső állapotot jelenti az űrlap, valamint a kijelölt sor és elem, esetleg a lista pozíciója.

Ha a belső állapotot ismered, bármikor újra tudod rajzolni az egészet. Innentől kezdve vissza van vezetve a feladat az a, pontra, tehát mindegy, hogy hány elem van a képernyőn és az állapot hány részből áll.

A kulcs a felbontásban van, hogy mekkora a legkisebb adategység, amit frissítesz. React-ben például alapból minden elemet frissít a rendszer, de ha azt szeretnéd, hogy csak a megváltozott elemek tartalma íródjon felül, neked kell a shouldComponentUpdate paramétert egyesével beállítani.

Amíg állapotban gondolkodsz, nincs bonyolult frontend logika.
99

Most, ha a piacon vagy, akkor

Hidvégi Gábor · Júl. 16. (V), 20.57
Most, ha a piacon vagy, akkor rovid tavon eladhato dolgokat kell tanulnod. Mert azzal kapsz olyan allast, amivel tovabbi tanulasi lehetosegeknek elebe nezel.
Ez oximoron. Mármint ha keretrendszereket ajánlasz, mint az Angular vagy a React és társaik, amelyek keretet adnak a munkádnak, akkor pontosan annyit tudsz a későbbiekben fejlődni, tanulni, amennyit ezek a keretek engednek.

Mivel ezek a teljes renderelési folyamatot lefedik, használójuknak nincs más dolga, mint javascript objektumokat manipulálni és API hívásokat indítani. Így elég hamar el lehet érni a határokat.

Az más kérdés, hogy ezzel most pénzt lehet keresni, mert akkora igény van rá. De az ilyen jellegű munkákat fogják a leghamarabb a mesterséges intelligenciával pótolni.
5

Egy bekezdésedre szeretnék

smokey · Júl. 6. (Cs), 22.09
Egy bekezdésedre szeretnék reagálni:

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.


Problémának érzem sok más ember esetében is, hogy attól mert van egy menő , piacképes technológia, akkor mindenre azt kell használni. Az angular-t, react-ot, stb-t nem biztos, hogy keresőoptimalizációt igénylő oldalak fejlesztésére kell használni, mert preprenderelni kell, hogy legyen találat a kereséséi listákban, amit meg tudsz oldani nem csak node.js-el, de nem ez a lényeg.

Ezeket a keretrendszereket nyugodtan lehet használni WEBALKALMAZÁS és nem feltétlen WEBOLDAL fejlesztésre. Miért? Mert mélységekig dokumentálva, optimálisan és kellő támogatással rakja alád az összes olyan feature-t, amit te magad is lefejlesztesz, mert ELENGEDHETETLENÜL szükséges. Egy vállalati folyamatokat támogató webalkalmazást, amit 10-20 fő fejleszt és 10000 másik használ, szerintem manapság kész öngyilkosság bármiféle hasonló technológia nélkül készíteni, az ilyenre tök jó pl az angular is. Rengeteg időt és hiba lehetőséget spórolsz meg.

AJAX, nem AJAX... 21. században szerintem egy webalkalmazás ne menjen el a szerverhez HTML kódért. Miért az üzleti réteget terheljem HTML kód generálással?

+ 1
Vitatkoznék, hogy ki ér többet manapság: egy jó angular fejlesztő, vagy egy profi, aki érti, hogy működik a böngésző. Ha az angulart olyanok írták, akik értenek a böngészőkhöz (feltételezem, hogy igen), és egy fejlesztő az angulart úgy használja, ahogy kell, akkor az is úgy fog viselkedni, ahogy kell. Ettől függetlenül azért néhány dologgal természetesen minden frontendes legyen tisztában; de ha desktop .net appokat fejlesztenék sem érdekelne, hogy az operációs rendszer hogyan kezeli az egymásra dobált ablakokat.
8

Egy vállalati folyamatokat

Hidvégi Gábor · Júl. 7. (P), 09.00
Egy vállalati folyamatokat támogató webalkalmazást, amit 10-20 fő fejleszt és 10000 másik használ, szerintem manapság kész öngyilkosság bármiféle hasonló technológia nélkül készíteni, az ilyenre tök jó pl az angular is. Rengeteg időt és hiba lehetőséget spórolsz meg.
Mint fentebb kifejtettem, ez az egész sablonozós sztori végtelenül primitív, ha belegondolsz. Egy darab kulcsot kell megtalálni, és rájössz, hogy mennyire feleslegesek ezek a frontend keretrendszerek, mert csak lassítják és bonyolítják a munkát. Egyébként meg leírtam minden szükséges információt a kereséshez.

AJAX, nem AJAX... 21. században szerintem egy webalkalmazás ne menjen el a szerverhez HTML kódért. Miért az üzleti réteget terheljem HTML kód generálással?
Egy szóval sem mondtam, hogy ne legyen AJAX. Sőt, a végeredmény az is lehet, hogy kikapcsolt javascripttel is pontosan ugyanúgy működik az oldal, lásd hidvegi.net, mint AJAX-szal.

Vitatkoznék, hogy ki ér többet manapság: egy jó angular fejlesztő, vagy egy profi, aki érti, hogy működik a böngésző.
Ott van janoszen és BlaZe, vitatkozz velük : )
9

Mint fentebb kifejtettem, ez

smokey · Júl. 7. (P), 10.02
Mint fentebb kifejtettem, ez az egész sablonozós sztori végtelenül primitív, ha belegondolsz. Egy darab kulcsot kell megtalálni, és rájössz, hogy mennyire feleslegesek ezek a frontend keretrendszerek, mert csak lassítják és bonyolítják a munkát


Nem csak a sablonozásról szól a React vagy Angular használata.

Egy szóval sem mondtam, hogy ne legyen AJAX. Sőt, a végeredmény az is lehet, hogy kikapcsolt javascripttel is pontosan ugyanúgy működik az oldal, lásd hidvegi.net, mint AJAX-szal.


Hát, én nem szeretem szivatni saját magam :) Általában JS nélkül működni szerintem már rég nem elvárás, nem is igény, de nem is lehetőség.

Ott van janoszen és BlaZe, vitatkozz velük


Nem lenne egy hosszadalmas vita :)
10

Nem csak a sablonozásról szól

Hidvégi Gábor · Júl. 7. (P), 10.57
Nem csak a sablonozásról szól a React vagy Angular használata.
Hanem?

React
A JavaScript library for building user interfaces


AngularJS is built on the belief that declarative programming should be used to create user interfaces
Wikipedia

Hát, én nem szeretem szivatni saját magam :) Általában JS nélkül működni szerintem már rég nem elvárás, nem is igény, de nem is lehetőség.
Olvasd el még egyszer, amit írtam. Van ott egy lényeges szó: is
14

Szerintem sablon != UI.

smokey · Júl. 7. (P), 11.57
Szerintem sablon != UI.
16

Tényleg

Hidvégi Gábor · Júl. 7. (P), 12.07
Ezt ki állította? Mindkét rendszer azzal hirdeti magát, hogy segítségével felhasználói felületeket lehet készíteni. Nyilván statikus elemekből is össze lehet dobni bármit, de arra ki használna keretrendszert? Tulajdonképpen ezzel most mit akartál mondani?
18

2 idézet tőled

smokey · Júl. 7. (P), 14.27
Ezzel kezded a cikket:

Ezek a keretrendszerek alapból kliensoldali sablonozást valósítanak meg


Aztán idézel:

A JavaScript library for building user interfaces


Majd jövök én:

Szerintem sablon != UI.


És végül kérdezel:

Ezt ki állította? Mindkét rendszer azzal hirdeti magát, hogy segítségével felhasználói felületeket lehet készíteni.


Itt irod: "felhasználói felület" = UI; UI készítésre nyújtanak megoldást, de fent a sablonok problémájáról beszélsz, ami csak egy része az egésznek.
19

Pontosabban?

Hidvégi Gábor · Júl. 7. (P), 14.51
Kifejtenéd, hogy mire gondolsz? A felhasználói felületek adatokat megjelenítő komponensekből állnak, ezeket más néven sablonoknak hívjuk. Mi mást tudnak még?
21

Véleményem szerint a sablon

smokey · Júl. 7. (P), 15.32
Véleményem szerint a sablon csak megjelenít, a UI pedig összeköt az alkalmazással, kezeli a felhasználói interakciót is, továbbítja az igényeket a core felé.
24

Input

Hidvégi Gábor · Júl. 7. (P), 16.36
Ezt hívják szép magyar szóval inputnak, ami lehet például billentyűleütés, egérkattintás, simogatás. Ez, akárhogy is nézem, nem bonyolult, hisz nagyon kevés változó van.

Mi ebben a kihívás?
31

Elkezdtem válaszolni a

smokey · Júl. 7. (P), 21.28
Elkezdtem válaszolni a kérdésre, de igazából nem tudtam mit, mert nem tudom mire irányul a kérdés. Feltennéd másként a kérdést?
35

Felhasználói felület

Hidvégi Gábor · Júl. 10. (H), 12.09
Ezeknek a keretrendszerenek az egyik legfontosabb feladata a sablonozás. Ezen felül még kettőt sorolsz fel, az input kezelését, valamint az alkalmazás és a felhasználói felület összekötését.

Erre írtam azt, hogy az input kezelése végtelenül egyszerű, mert nagyon kevés választási lehetőség van (kattintás, billentyűzés, valamint egy-két absztraktabb, mint a görgetés simogatással, ami visszavezethető a kattintásra), ráadásul az ember egyszerre csak egy helyre tud figyelni, egy diszkrét időpillanatban csak egy inputot tud adni.

Kérdés az, hogy a háttérben lévő alkalmazást és a felületet hogyan kell összekötni. Én azon az állásponton vagyok, hogy nem, és célszerűbb a böngészőt mint egy monitort felfogni, aminek semmi más dolga nincs, mint kirajzolni adatokat, de az összefüggéseket nem kell "fejben tartania".

Mi ezen az elven dolgozunk, és az általunk fejlesztett vállalatirányítási rendszerben például úgy cseréltük le a teljes raktár modult, hogy a klienshez nem kellett nyúlni, mivel az a lehető legbutább, és öt éve nem változott a kódja.

Ezért kérdeztem azt, hogy mi a kihívás egy ilyen keretrendszer elkészítésében, ha ennyire leegyszerűsítjük a dolgokat.

Ezzel szemben van az, hogy ha bizonyos állapotok kezelését áttesszük a kliensre, azonnal kiszámíthatatlanabbul kezd el viselkedni a rendszer, mert a cél környezet undefined. Tudod-e garantálni például, hogy a böngésző kihasználja a videokártya gyorsító képességeit?
37

Nem igazán jött le nekem,

inf3rno · Júl. 10. (H), 13.28
Nem igazán jött le nekem, hogy mit akarsz ezzel mondani, vagy hogy hogyan jön a video kártya a szerver oldali fejlesztéshez. Azzal egyetértek, hogyha nincs rá kimondottan szükség (az esetek többségében nincs), akkor érdemesebb nem megbonyolítani, és hagyományos webalkalmazást írni kliens oldali javascript nélkül.
40

undefined

Hidvégi Gábor · Júl. 10. (H), 21.14
A videokártyával arra szerettem volna rámutatni, hogy nem tudod, mi van a kliensoldalon, azaz a környezet undefined. Ezért célszerű mindent szerveroldalon megoldani, amit csak lehet, mert ott a te kezedben van az irányítás.
39

Ha van egy millio inputod,

smokey · Júl. 10. (H), 15.51
Ha van egy millio inputod, akkor nem lesz kedved kliens oldalon egyesével manuálisan bindolgatni. Ugyanez igaz visszafelé is.

Igen tudom.. lehet iterálni, mert csak kulcs érték, stb, ugyanaz, mint 10 éve, de akkor is hibalehetőséget csökkentesz és rengeteg időt megspórolsz ezzel.

Kérdés az, hogy a háttérben lévő alkalmazást és a felületet hogyan kell összekötni. Én azon az állásponton vagyok, hogy nem, és célszerűbb a böngészőt mint egy monitort felfogni, aminek semmi más dolga nincs, mint kirajzolni adatokat, de az összefüggéseket nem kell "fejben tartania".


Végre valami, amiben egyet értünk.

Ezért kérdeztem azt, hogy mi a kihívás egy ilyen keretrendszer elkészítésében, ha ennyire leegyszerűsítjük a dolgokat.


Ez egy kiragadott szitu, de nem csak backend újraírásról szól minden fejlesztés. Elég durva kliens oldali funkciókat kell megvalósítani, pl. fanci felhasználói funkciók, ahol az az ominozus data binding is hatalmas help és tényleg rengeteg időt ment meg.

Tudod-e garantálni például, hogy a böngésző kihasználja a videokártya gyorsító képességeit?


Nem. Nem is akarom.
41

Elég durva kliens oldali

Hidvégi Gábor · Júl. 10. (H), 21.16
Elég durva kliens oldali funkciókat kell megvalósítani, pl. fanci felhasználói funkciók, ahol az az ominozus data binding is hatalmas help és tényleg rengeteg időt ment meg.
Tudsz ilyen fanci funkciókat mutatni/leírni? Csak hogy legyen valami konkrétum is.

A data binding szerintem túl van dimenzionálva, de erről majd később.
47

Tegyük fel, hogy van egy 1

smokey · Júl. 11. (K), 08.07
Tegyük fel, hogy van egy 1 millió felhasználós rendszered, ahol, van egy szerver alkalmazásod (mindegy milyen nyelven és technológiával készült), és van egy rakat kliensed (böngészős webalkalmazás, ios kliens, android kliens, valamiféle reporting tool, meg mondjuk IOT-s kütyük). A scope annyi, hogy a IO kliensek realtime adatot szinkronizálnak fel, amit a mobil és web kliensek backend oldali adattranszformáció után hasznos információ formájában megjelenítenek, a reporting tool meg vezetői kimutatásokt csinál.

Ez egy olyan rendszer, ahol sablon generálásnak backend oldalon semmi keresni valója nincs. A backend semmi mást nem kér és ad, mint JSON adatokat, amiket a frontend különböző dimenziókban és aspektusokban jelenít meg (táblázat, chart, lista, stb). A kliens oldali folyamat:
- szűrés beállít - egymástól függő dropdownok, megjelenő, eltűnő mezők, akár több lépésben anélkül, hogy elmennék a szerverig (2 mb az angular appom? már többet spóroltam vele, mintha 11-szer behúznám a 200kbos saját cuccot), pláne hogy a megjelenítésről gondoskodik az angular is angular komponensben tárolt állapot alapján - szerintem felhsználóbarát, gyorsan fut, gyorsan elkésztettem, hát nem nagyszerű? de
- GET kérés a szervernek - angularos http service, fain módon működik, jah, és nincs extra meló a filter objektum összeépítésével, hiszen ott van a komponensemben; ua. az objektum (optimálisabb esetben egy klónja a referenciák miatt), ami a felületre van rá bindolva, hát nem nagyszerű? de.
- JSON adat visszaküld - átadom egy megjelenítésért felelős komponesnek az objektumot, és már ott is van az adat a felületen
- Felhasználó nézetet váltogat - más nézetbe kerül át ugyanaz az adat, oldal újratöltés nélkül, nem írom le mégegyszer a fenti előnyöket, hát nem nagyszerű? de

Az üzleti folyamat backend oldalon van, a megjelenítés nem (mert nem oda való). A mai napon pedig tudom mi van kliens oldalon. Egy olyan böngésző (minden böngésző; ie8+), amivel normálisan működik az angular 1.x. Mégsem fut az oldal. Pech, tölts le egy új böngészőt. 1millió vs 100 felhasználó miatt nem szeretnék 10 évre visszamenőleg backward kompatibilis lenni. Miért? Mert nem éri meg. Saját keretrendszerrel is üzemelne így az oldal, csak épp 100ezer felhasználóval. Miért? Mert nem lenne kész annyi funkció, mint most.

Backendhez annyi infó: nincs session, JWT authentikáció van, a rendszer egy skálázható körnezetben fut, continious delivery működik.

A data binding szerintem túl van dimenzionálva, de erről majd később.


Hát, nincs. Hogyan kell túl dimezionálni? Lenti példa, az igény: oldal újratöltés nélkül történjen bármi. Angularos példakód, nem teszteltem, de kéne működnie. Akuális állapot mindig ugyanaz lesz, mint ami az inputban van, a mentett állapot pedig egy clone, ami gombnyomásra állítodik be. Nah, ezt képzeld egy 20-szor ilyen bonyolult felületen, ahol függ egymástól minden.

app.controller('appController', function(){
    //Mindegy is, hogy ideteszem, vagy sem, ha a felületen van rá hivatkozás, akkor létrejön
    //Azért szoktam definiálni előre, hogy lássam, mit használ egy controller funkció
    this.data = {
        name: ''
    };
    
    //Megy prototyppal is
    this.doSomething = function(){
        console.log(this.data);
        this.dataClone = angular.copy(this.data);
    }.bind(this);
});

<div ng-controller="appController as appCtrl">
    <input type="text" ng-model="appCtrl.data.name" />
    <button ng-click="appCtrl.doSomething()">Do something</button>
    <span>Aktuális állapot: {{appCtrl.data.name || 'n/a'}}</span>
    <span>Mentett állapot: {{appCtrl.dataClone.name || 'n/a'}}</span>
</div>
Ha megteszed a fenti funkcionalitást megvalósítanád úgy, ahogy te gondolod? Kíváncsi volnék a te oldaladra is.
50

Amit írsz, az több kérdést is

Hidvégi Gábor · Júl. 11. (K), 11.18
Amit írsz, az több kérdést is felvet, de előbb linkelem a saját demó oldalam, ahol
  • tisztán adatokkal (XML) kommunikál a szerver és a kliens, ha a kliens képes erre
  • ha nem (pl. kereső), akkor HTML-t küld
  • a transzformáció ebből adódóan történhet bármelyik oldalon
  • nincs állapot a kliensen
  • minden logika a sablonokban van
  • kikapcsolt javascripttel is ugyanúgy működik
  • bekapcsolt javascriptnél automatikusan oldalújratöltés nélkül, csak a megváltozott részek cserélődnek
  • IE 5.5-ig kompatibilis
  • mivel végtelenül egyszerű a javascript, villámgyors a működés
52

tisztán adatokkal (XML)

smokey · Júl. 11. (K), 12.48
tisztán adatokkal (XML) kommunikál a szerver és a kliens, ha a kliens képes erre
ha nem (pl. kereső), akkor HTML-t küld
a transzformáció ebből adódóan történhet bármelyik oldalon


Már több "if"-et látok, mint amennyi valóban indokolt volna.

nincs állapot a kliensen


Én viszont ott tartom, mert így tudok skálázódni.

minden logika a sablonokban van


Csak a megjelenítésé.

kikapcsolt javascripttel is ugyanúgy működik


Úgy nézem ez egy fétis (bocs :)), viccet félre téve. Eszem ágában nincs kikapcsolni. Miért tenném? Kit szivatnék? Magam..

bekapcsolt javascriptnél automatikusan oldalújratöltés nélkül, csak a megváltozott részek cserélődnek


Itt már megint/még mindig két irányba mehet a dolog.

IE 5.5-ig kompatibilis


Ez mondjuk érv 2017-ben :)

mivel végtelenül egyszerű a javascript, villámgyors a működés


Mi sem panaszkodhatunk.

Nézd, részemről már többször elhangzott, nem ugyanarról a problémáról beszélünk, tök mást kezelsz te és tök mást kezelek én. Ha megoldod úgy, ahogy eddig, akkor hajrá, senki nem állít meg, csináld úgy, ahogy jónak látod, lehet felesleges is volna esetedben bármi hasonló. Ettől függetlenül rajtam segített már rengeteget az angular és a react is. Sarkítok: két tutorial video kevés ahhoz, hogy közösség ellőtt kampányolj valami ellen, aminek az igazi értékeit nem is biztos, hogy ismered, mert nem használtad hosszú távon.

Ezt a képet még hadd linkeljem be :)..

Kép
55

Ugyanaz

Hidvégi Gábor · Júl. 11. (K), 13.42
Ugyanarról a problémáról beszélünk, csak én, úgy látszik, képtelen vagyok elmagyarázni úgy, hogy megértsd.

Például értetlenül állsz a kikapcsolt JS előtt, hiába írtam le már sokszor, hogy a keresők tipikusan így működnek. Ha alkalmazást fejlesztesz, ez nyilván nem feltétlenül érdekes, de ha van olyan része, amelyet be kell indexelni, máris aktuális a dolog. Ha Angularra vagy React-re (stb.) épül a projekted, akkor nincs választás, a szerverre node.js-t kell telepíteni, míg az én megoldásom gyakorlatilag bármelyik programnyelvvel megvalósítható.
61

Ő a jobb skálázódásról beszél

inf3rno · Júl. 11. (K), 15.45
Ő a jobb skálázódásról beszél állapotmentes kommunikációnál, te meg a böngésző kompatibilitásról állapottal terhelt kommunikációnál. Nem igazán értem szerinted a kettő miért ugyanaz.
64

Az elején valahol azzal

smokey · Júl. 11. (K), 15.52
Az elején valahol azzal kezdtem (mint janoszen, amit később vettem észre), hogy nagyon nem mindegy mire használod az angulart. Blogot, hírportált, seo heavy oldalt csinálni angularral nem biztos, hogy jó választás, nem arra való. Arra ott van a WP, vagy Moto, vagy bármi.

Telepített node.js-en kívül megoldja más is egyébként a prerenderelést.
53

Kliens

Hidvégi Gábor · Júl. 11. (K), 13.07
böngészős webalkalmazás, ios kliens, android kliens
Miért van szükség Android és iOS kliensre?
54

:D Mert natív appot kért az

smokey · Júl. 11. (K), 13.32
:D

Mert natív appot kért az ügyfél. Így férünk hozzá mobilos erőforrásokhoz. BLE-n kommunikál az IO eszközökkel, és fogadja a push üzeneteket.
56

Aha

Hidvégi Gábor · Júl. 11. (K), 13.47
Értem, mondjuk ilyen alkalmazásba lehet integrálni böngészőt, azaz csak az erőforrásokkal való kommunikációt kell leprogramozni bennünk, a többi lehet ugyanaz, mint a weben.
57

Nah, ezt a választ vártam

smokey · Júl. 11. (K), 14.17
Nah, ezt a választ vártam ;).

Megint scope-ot váltunk. A mobil appba integrált webviews megoldásokkal mindaddig nincs gond, amíg gyakorlatilag egy webappot duplikálsz. Az egy dolog, hogy komolytalan látszatot keltenek, mert azért nah.. Ha valaki normális minőségű termékkel nyomul, amibe milliókat fektet, akkor jogos a natív app igénye.

Megint ugyanaz a kérdés: attól mert rendelkezésre áll egy technológia, nem azt jelenti, hogy onnantól kezdve csak azzal szükségszerű megoldani mindent. Lehet mobilappba webview-t tenni, de ez az én esetemben nem kielégítő, és nem jó választás.

A "sárácok, kéne egy eszköznyílvántartó alkalmazás az operatív osztálynak és egy mobil app a kollégáknak, hogy lássák milyen eszközöket használtak fel" jellegű kérésre eszembe nem jutna más kombó, mint egy frankó RESTful backend, és pl egy angular/react + cordova + ionic (vagy hasonló) kombó. Adatot tartok karban, és listát kérdezek le illetve jelenítem meg mobil appban.

Már látom magam előtt, ahogy beindulnak a fogaskerekek: "minek ehhez mobil app, stb..". Ezt még az egyel korábbihoz:

Miért van szükség Android és iOS kliensre?


Nem az a lényeg... kérlek ne forgasd ki a szavaim szükségtelen kérdésekkel, példát hoztam fel ismét, de nem is értem miért próbálom megértetni, hogy van más is, ha egyszer nem szeretnéd befogadni a másik véleményét. Ha komolyan szeretnéd megérteni és megismerni mások álláspontját és/vagy érdeklődsz és legalább veszem a fáradságot, hogy ezen segítsek, akkor legalább releváns kérdéseket tegyél fel, ne out of scope baromságokat. (bocs...)

Jót beszélgettünk, köszönöm!
59

mindaddig nincs gond, amíg

Hidvégi Gábor · Júl. 11. (K), 15.20
mindaddig nincs gond, amíg gyakorlatilag egy webappot duplikálsz. Az egy dolog, hogy komolytalan látszatot keltenek, mert azért nah.. Ha valaki normális minőségű termékkel nyomul, amibe milliókat fektet, akkor jogos a natív app igénye
Ne hülyéskedj! Ha egy általános platformon megoldott egy program működése, akkor miért fájdítsa az ember a fejét azzal, hogy "natív" alkalmazást fejlesszen még azon felül? Hisz mindenhol ugyanazt kell tudnia, csak kiegészül olyan funkciókkal, amit az adott operációs rendszer nyújt.

Erre tökéletes a beágyazott webes kliens. Ráadásul, mivel vastag kliens elven dolgoztok, ezért ugyanazt a funkcionalitást le kell fejleszteni n darab platformra, itt összesen háromra, azaz a frontend háromszor annyiba kerül a megrendelőnek.

"jogos a natív app igénye" - miért? Őszintén örülnék egy szakmailag alátámasztott válasznak, mert én eddig még nem láttam ilyet.

kérlek ne forgasd ki a szavaim szükségtelen kérdésekkel
Nem forgattam ki a szavaidat. Minden kérdés szükséges, és igen, kíváncsi vagyok a natív alkalmazások üzleti okára. Miért éri meg beleölni annyi pénzt?
63

Erre tökéletes a beágyazott

inf3rno · Júl. 11. (K), 15.49
Erre tökéletes a beágyazott webes kliens. Ráadásul, mivel vastag kliens elven dolgoztok, ezért ugyanazt a funkcionalitást le kell fejleszteni n darab platformra, itt összesen háromra, azaz a frontend háromszor annyiba kerül a megrendelőnek.


Érdekelne, hogy ezt honnan veszed, hogy egy mobil/tablet kliensnek ugyanúgy kell kinéznie és ugyanúgy kell működnie, mint egy asztalinak?
62

A NativeScript-et

inf3rno · Júl. 11. (K), 15.46
A NativeScript-et próbáltátok?
65

Még nem, React Native-vel

smokey · Júl. 11. (K), 15.55
Még nem, React Native-vel kezdtünk el foglalkozni pár hónapja. Éles projectet még nem indítottunk vele.
67

Más trendeket kell követnie

smokey · Júl. 11. (K), 16.05
Más trendeket kell követnie egy modern webalkalmazásnak, egy modern android appnak és egy ios appnak is. microsoftéknál nem tudom mi a helyzet, de gondolom ott is vannak irányok. Hogy reflektáljak egy korábbi hozzászólásodra: egy natív android app kihasználja a a hrdver adta lehetőségeket (pl. videokártya erőforrások), míg egy webviewban működő HTML + JS oldal nem.

A mobil app hasonló, de mégis más igényspecifikációval rendelkezik. Itt van az a pont, hogy hiába angular, a túl komplex és nagy mértékű frontend oldali elágazások növelik a komplexitást, ezzel a hibalehetőségek számát, meg minden mást is.. nem segítenek, hanem kell egy másik módszert választani, amivel hatékonyabban és jobb minőségben ki lehet vitelezni egy fejlesztést.

Ha agyon animált mobilapp kell az ügyfélnek, akkor megint nem jó választás egy kvázi hardveres gyorsítás nélküli megoldás. Igen, tudom, a canvas mobilon is az (ha egyáltalán a canvas kielégítő), de akkor is távolabb van a core-tól, mint egy androidos view.
11

Vitatkoznék, hogy ki ér

Hidvégi Gábor · Júl. 7. (P), 11.13
Vitatkoznék, hogy ki ér többet manapság: egy jó angular fejlesztő, vagy egy profi, aki érti, hogy működik a böngésző. Ha az angulart olyanok írták, akik értenek a böngészőkhöz (feltételezem, hogy igen), és egy fejlesztő az angulart úgy használja, ahogy kell, akkor az is úgy fog viselkedni, ahogy kell.
Oké, ezt a részt félreértettem.

Tessék, itt a lehetőség, vitatkozz! Mi alapján feltételezed, hogy az Angulart olyanok írták, akik értenek a böngészőhöz? Miért volt szükség a teljes újraírásra az 1.x és a 2.0 között? Mi garantálja, hogy bármelyik következő verzióban nem írják újra megint az alapoktól?

Az Angular dokumentációja szerint
Angular is built on the latest standards of the web platform.
Tehát azok, akik nem tudják frissíteni a böngészőjüket, ki vannak zárva. Hogyan adod el azt egy megrendelőnek, hogy a TE választásod miatt a látogatók egy része nem fog látni semmit, ezáltal nem tud tőle vásárolni?

Ha megnézzük az Angular kezdőlapját, van rajta pár kép, pár szöveg, pár link. Ezek teljesen átlagos elemek, mégsem jelenik meg az oldal Opera 12 vagy Firefox 29 alatt, pedig ezek a böngészők ismerik a diveket meg a link tag-eket.

Tehát a kérdés az, hogy az Angular készítői valóban értenek a böngészőkhöz?
13

Fentebb írtam, hogy attól

smokey · Júl. 7. (P), 11.54
Fentebb írtam, hogy attól mert van Angular vagy React, vagy bármi, nem kell mindenre azt használni. Én nem az Angulart adom el, hanem megoldom az ügyfél problémáját. Ha jó rá az angular, akkor azzal, ha nem, akkor nem azzal. Blogot nem fogok angularral megvalósítani, úgy mint adminiszrációs alkalmazást sem WordPressel.

Haladni kell a korral. Ez egy ilyen szakma.

Az angular fejlesztők biztosan értenek a dolgukhoz, úgy, mint Te is ahhoz, amit csinálsz. Köztünk és Google között az a különbség, hogy mi követjük a trendet, ők meg diktálják!
15

Kérdések

Hidvégi Gábor · Júl. 7. (P), 12.01
Tudnál a feltett kérdésekre konkrétan válaszolni?

Blogot nem fogok angularral megvalósítani, úgy mint adminiszrációs alkalmazást sem WordPressel.
Ha abból az állításomból indulunk ki, hogy "bárhogy bűvészkedünk, a végén úgyis HTML-t kell írnunk", tulajdonképpen mi a különbség egy blog és egy adminisztrációs alkalmazás között?

Haladni kell a korral. Ez egy ilyen szakma.
Tehát az a korral való haladás, hogy div, section, header, footer stb. elemekből álló oldal megjelenítésekor js hibával elszáll a böngésző? Ez a fejlődés? Mi lett jobb?

Az angular fejlesztők biztosan értenek a dolgukhoz
Biztos? Ezt mi alapján állítod? Hogy volt azokkal a verziókkal (1.x és 2.0-re célzok).
17

Ha abból az állításomból

smokey · Júl. 7. (P), 14.18
Ha abból az állításomból indulunk ki, hogy "bárhogy bűvészkedünk, a végén úgyis HTML-t kell írnunk", tulajdonképpen mi a különbség egy blog és egy adminisztrációs alkalmazás között?


Mert bloghoz ott a WordPress, egy custom admin alkalmazáshoz meg ott egy rakat angularos komponens, amiből töredék idő alatt lehet virítani, mint nulláról kódolni az egészet.

Tehát az a korral való haladás, hogy div, section, header, footer stb. elemekből álló oldal megjelenítésekor js hibával elszáll a böngésző? Ez a fejlődés? Mi lett jobb?


Azt jelenti, hogy nem ragadok le a múlt évtizednél, hanem hajlandó vagyok ádozatot hozni azért, hogy saját magamon segítsek.

Biztos? Ezt mi alapján állítod? Hogy volt azokkal a verziókkal (1.x és 2.0-re célzok).


Ők is haladtak a korral. Megcsinálták az 1.x-et. Rájöttek, hogy mit lehetett volna jobban, tanultak a hibáikból, és csináltak egy 2.0.
20

Mert bloghoz ott a WordPress,

Hidvégi Gábor · Júl. 7. (P), 14.56
Mert bloghoz ott a WordPress, egy custom admin alkalmazáshoz meg ott egy rakat angularos komponens, amiből töredék idő alatt lehet virítani, mint nulláról kódolni az egészet.
Nem ezt kérdeztem.

Azt jelenti, hogy nem ragadok le a múlt évtizednél, hanem hajlandó vagyok ádozatot hozni azért, hogy saját magamon segítsek.
Miben segítettél magadon? Van egy rakat angularos komponensed? Az elmúlt évtizedben, amíg nem Angularral dolgoztál, miből építkeztél? Mindig újraírtál mindent?

Ők is haladtak a korral. Megcsinálták az 1.x-et. Rájöttek, hogy mit lehetett volna jobban, tanultak a hibáikból, és csináltak egy 2.0.
És mi biztosítja, hogy a mostani vonal az elég jó? Mi biztosítja, hogy ezt nem írják át ugyanígy, és a mostani vonalra épített alkalmazásod megy a levesbe, mert már nem lesz hozzá olyan támogatás, új komponensek stb.? Mert amíg még az 1.x-et fejlesztették, akkor is úgy gondolták, hogy az a tuti, amit épp csinálnak. Aztán kuka lett az egész. Mi biztosítja, hogy nem ismétlik meg magukat?
22

Kérdezek, mielőtt válaszolnék

smokey · Júl. 7. (P), 15.34
Kérdezek, mielőtt válaszolnék ismét: egyedül, vagy csapatban dolgozol? Ha csapatban, akkor mekkora csapatban?
25

Mind

Hidvégi Gábor · Júl. 7. (P), 16.37
Egyedül is, csapatban is, kisebben-nagyobban, de leginkább kis csapatban.
30

Milyen formában adod át a

smokey · Júl. 7. (P), 21.17
Milyen formában adod át a tudást egy másik fejlesztőnek, aki rákerül a projectre, és azt a keretet viszi tovább, ami mögé te raktál mindent? Nem az 1-2 hónapos fejlesztésre gondolok, hanem egy űrhajó funkcionalitásával vetekedő rendszerre, ami mögé kell egy stabil keret, mert máskép nem megy, és kvázi ugyanazt valósítja meg, mint egy menő angular vagy react?
36

Elmondom azt, amit a

Hidvégi Gábor · Júl. 10. (H), 12.13
Elmondom azt, amit a témaindító írásban lejegyeztem, ez pár perc. A kliensünk pár kilobájtos, az állapotot szerveroldalon kezeljük, az állapotnak megfelelő adatmegjelenítést pedig a sablonokban. Az esetek 99%-ában egy deka javascript kódot sem kell írni a fejlesztés során.
38

Hány felhasználós

inf3rno · Júl. 10. (H), 13.33
Hány felhasználós rendszerekről van szó? Már kifejtettem párszor, de talán jobb újra elismételni, hogyha a kliens állapotát a szerveren tárolod, akkor amint több gépre kell skáláznod gondban leszel, mert a session-öket szinkronizálni kell a szerver gépek között. Ezért nagyobb rendszereknél a kliens állapotát a kliensen kell tárolni, kisebb rendszereknél meg érdemesebb ilyen irányba optimalizálni, ha kezdi kinőni a szervert az alkalmazás.

Vannak persze kivételek, ha pl szinkronizálni akarod a webshop kosarat két kliens gép között, amelyek ugyanahhoz a felhasználóhoz tartoznak. Viszont ilyen esetben már üzleti logikáról beszélünk, nem kliens állapotról.
42

Állapot a szerveren

Hidvégi Gábor · Júl. 10. (H), 21.21
Egy webalkalmazás esetében az állapotok legfeljebb párszáz bájtnyi adatot jelenthetnek.

Ha viszont kliensoldalon tárolod, ami definíció szerint undefined, akkor jelentősen nő az adatvesztés esélye.

A szinkronizáció bármilyen szolgáltatásnál fontos lehet, akár webshop esetében, akár pénzügyi műveleteknél. Minimális tárolandó adatmennyiségről van szó, de ez annál fontosabb, hogy ne veszhessen el.

A kevés adat miatt a szerver oldali overhead is elhanyagolható.
43

Minimális tárolandó

inf3rno · Júl. 10. (H), 21.43
Minimális tárolandó adatmennyiségről van szó, de ez annál fontosabb, hogy ne veszhessen el.


Mi annyira fontos a kliens állapotában, ami nem veszhet el? Egyébként ha a sok közül elszáll egy szerver gép, akkor ugrott egy rakás kliens munkamenete.

A kevés adat miatt a szerver oldali overhead is elhanyagolható.


Ez felhasználó szám függő. Sok felhasználós rendszereknél nem működik az, amit írsz. Minél több a felhasználó, annál kevésbé működik.
46

Mi annyira fontos a kliens

Hidvégi Gábor · Júl. 11. (K), 07.20
Mi annyira fontos a kliens állapotában, ami nem veszhet el?
Te szeretsz bármit is kétszer begépelni? Mi a megbízhatóbb munka szempontjából: az otthoni géped, vagy egy szerver?

Egyébként ha a sok közül elszáll egy szerver gép, akkor ugrott egy rakás kliens munkamenete.
Ennek a megoldása az üzemeltetés feladata.

Sok felhasználós rendszereknél nem működik az, amit írsz. Minél több a felhasználó, annál kevésbé működik.
Mennyi az a sok?
66

Te szeretsz bármit is kétszer

inf3rno · Júl. 11. (K), 15.59
Te szeretsz bármit is kétszer begépelni? Mi a megbízhatóbb munka szempontjából: az otthoni géped, vagy egy szerver?


Legtöbbször nekem sima HTML alapú fórumoknál volt ilyen, hogy kétszer kellett valamit begépelnem, azt hiszem iwiw-nél. Egy js kliens simán megoldja, hogy szerver hiba esetén újraküldi, ha meg van bármilyen tárolási mód kliens oldalon, akkor elmentheti a böngészőbe, esetleg ha az üzleti logika része a piszkozat készítés, akkor meg el lehet menteni a szerverre írás közben 5 percenként. Innentől nem sokat ér az érved.

Ennek a megoldása az üzemeltetés feladata.


Az üzemeltetés nem biztos, hogy mindig meg tudja oldani. Nagyobb kockázat valamit egy gépre rakni, mint szétosztani sok ezer gép között (single point of failure).

Mennyi az a sok?


Az szerver és munkamenet méret függő. Próbáld ki szimulált felhasználókkal a kódod, aztán kiderül, hogy nálad mennyi. Lehet, hogy 1M, lehet, hogy 10k. Blaze tudna erre komolyabban válaszolni (ha akarna), ő már tesztelt ilyet. Igazából ha kis szerver gépekből csinálsz clustert, akkor már jelentkezik, tehát nem kell valami egetverően magas felhasználó szám. Ezért gondolom a legtöbben inkább vertikálisan skáláznak és erősebb gépet vesznek, hogy ne fussanak bele ilyenbe. Az egy gépes rendszerekre lennék kíváncsi, hogy azoknál mikor jelentkezik, azt nem tudom.
72

Én csak a válaszidő grafikon

BlaZe · Júl. 12. (Sze), 00.26
Én csak a válaszidő grafikon miatt hoztam a saját példát. Nem web amin dolgozunk, és ott még a klasszikus értelemben véve több kliens sincs. Úgyhogy sajnos érdemben erre nem tudok válaszolni. De amúgy is nagyon attól függ, ez minden rendszerben egyedi, hogy hol kezdi már nem tolerálni a loadot. Ami biztos, hogy egy distributed lock segíteni nem fog.
73

Azt esetleg meg tudnád

inf3rno · Júl. 12. (Sze), 01.08
Azt esetleg meg tudnád válaszolni, hogy ez a probléma jelentkezik akkor is, ha egy gépről beszélünk, nem clusterről és stateful a kommunikáció a kliensekkel?
83

Gépen belül is létezik shared

BlaZe · Júl. 13. (Cs), 01.28
Gépen belül is létezik shared resource (CPU, memória, disk etc), úgyhogy elméletben jelentkezik, de egy elosztott rendszerhez képest mivel nem kell senki mással lefocizni a dolgokat, az erőforráshoz való hozzáférés kevésbé jelentős a kiszolgáló kód futásához képest. *

Lockolni (emlékeim szerint) azért lockol a PHP session default implementációja egy gép esetén is (flock), tehát a lockon egy találkozás mindenképpen negatív hatású a vesztes request(ek) kiszolgálására. Ha ez gyakran történik (pl sok AJAX call), akkor annak lehet akár egy komolyabb impactja. De önmagában egy flocktól én nem várnám, hogy dominálja egy átlagos PHP script lefutását. Ha kíváncsi vagy, egy JMeterrel pl neki lehet egyszerűen szaladni a problémának.

* Finomhangolt többszálú programoknál ez viszont nagyon is fókuszban van: léteznek rendszerek, ahol gyakorlatilag a lockolás tiltott még heapben lévő referencián is. Near realtime rendszerek tipikusan ilyenek (pl trading rendszerek fastpath-a).
84

Köszi!A real time vagy

inf3rno · Júl. 13. (Cs), 01.44
Köszi!

A real time vagy ahhoz közeli alkalmazások fejlesztésével még nem foglalkoztam. Nézegettem real time Linux disztrókat, de egyelőre most nem cél, hogy ebbe is beletanuljak. Később esetleg hobbi szinten drón irányításra, ilyesmire elszórakoznék vele, de nem valószínű, hogy komolyabban kelleni fog valaha is.
85

RT kernel más téma kicsit.

BlaZe · Júl. 13. (Cs), 11.02
RT kernel más téma kicsit. Ezek jellemzően sima kernellel mennek, csak nagy figyelemmel és hozzáértéssel van megoldva a szálak közötti kommunikáció, memória hozzáférés, kernel tuning stb. A lényeg, hogy a lockolás by design egy bizonytalansági faktor: nem tudhatod, hogy mikor fog folytatódni a programod futása, ha egyáltalán. Ezért nem fér bele ilyen rendszerekben a lockolás, mert amellett extra nagy latencyre lehet készülni jobb esetben is (sok millisec). Distributed locknál ez még hatványozottabban igaz, és ott már akár az általános teljesítményigényű alkalmazásokat is térdre tudja kényszeríteni.
74

(...) Innentől nem sokat ér

Hidvégi Gábor · Júl. 12. (Sze), 06.28
(...) Innentől nem sokat ér az érved.
Nyilván azért fizetnek a cégek akár többször árat szerverekért, a dupla betápért, RAID-ért, minőségi alkatrészekért, mert a gazdaság pörgetésében érdekeltek, ugye? Ugyanazt a feladatot egy normál PC is ellátja Vargáné táppal, mi?

Az üzemeltetés nem biztos, hogy mindig meg tudja oldani. Nagyobb kockázat valamit egy gépre rakni, mint szétosztani sok ezer gép között (single point of failure).
Hogy akarod te egy darab számla felvitelét szétosztani ezer gép között? Amikor gépel valaki az általad fejlesztett alkalmazásban, azt elküldöd a többieknek?

Mi az, hogy az üzemeltetés nem tudja megoldani az adatok biztonságos tárolását? Hisz az a dolga.

Ezzel a hozzászólásoddal most eléggé alacsonyra tetted a mércét.
75

Mi az, hogy az üzemeltetés

BlaZe · Júl. 12. (Sze), 11.57
Mi az, hogy az üzemeltetés nem tudja megoldani az adatok biztonságos tárolását? Hisz az a dolga.
Az üzemeltetés dolga, hogy a fejlesztő csapat által készített rendszert üzemeltesse a megadott specifikáció alapján. Semennyire nem dolga kitalálni az architektúrát és a HA-t. Márpedig azon múlik az adatbiztonság, nem a vason, üzemeltetésen. A legjobb vason a legjobb üzemeltetés is adatvesztésbe fut bele, ha nem jól van kitalálva az egész.
76

Absztrakció

Hidvégi Gábor · Júl. 12. (Sze), 12.10
Akkor majd megoldja az, akinek ez a dolga. Ha nem tudja, akkor alkalmatlan a feladatra.
77

És akkor visszakanyarodtunk

BlaZe · Júl. 12. (Sze), 12.34
És akkor visszakanyarodtunk oda, hogy olcsóbb, egyszerűbb pl angularos fejlesztőt találni, mint olyat, aki tudja hogy kell shared állapotot jól kezelni, meg milyen problémák léphetnek fel.
78

Fejlődés

Hidvégi Gábor · Júl. 12. (Sze), 13.41
Ha úgy gondolkodunk, mint te, akkor abszolút igazad van, és ez az egyetlen út. De vajon kizárt, hogy létezzen más megoldás a backend problémájára? Jó architektúrával, mint például a korábban említett szilánkolással, egész sokáig el lehet evickélni, és biztos vagyok benne, hogy a legtöbb cégnek ez kielégítő megoldást ad.

De ha a te utadon járunk (amit csak lehet, toljunk a kliensre), akkor sosem oldjuk meg a helyzetet, és nem fejlődünk.
79

Szerintem ebben a szálban nem

BlaZe · Júl. 12. (Sze), 14.37
Szerintem ebben a szálban nem én vagyok a fejlődés ellen, és nem én vitatkozom olyan dolgok ellen, amikre kb 10 éve éve válaszolt már a szakma.

Én nem mondtam, hogy mindent. Sőt, azt se mondtam, hogy mindig a kliensen kell tárolni a session infót. Te vagy, aki azt mondja, hogy ez nem elfogadható. Itt mindenki csak azt cáfolta, amit állítasz, mégpedig jó okkal.

A particionálás jó dolog, de nem silver bullet. Pl probáltál már joinolni shardok között?
80

Modern

Hidvégi Gábor · Júl. 12. (Sze), 15.11
Ami újabb, az egyértelműen jobb? Lásd a Volkswagen dízel botrányát.

Felsoroltam az ellenérveimet a React-tel és társaival kapcsolatban (erőforrásigényes, lassú, speciális tudást ad, a böngészők szűkebb körén működik, mint egy natív megoldás, nagyobb az adatvesztés lehetősége, instabil verziózás), azok közül egyiket sem cáfolta meg senki.

Nem próbáltam még shardok között joinolni, mert nálunk erre nincs szükség. Nyilván van, ahol ez probléma, de ez egy szűk kisebbség, hisz nem mindenki milliós ügyfélszámmal dolgozik.
81

sosem oldjuk meg a helyzetet,

BlaZe · Júl. 12. (Sze), 16.06
sosem oldjuk meg a helyzetet, és nem fejlődünk.

[...]

Ami újabb, az egyértelműen jobb?
?

Felsoroltam az ellenérveimet a React-tel és társaival kapcsolatban [...] azok közül egyiket sem cáfolta meg senki.
Hát...de :) Más kérdés, hogy nyitott vagy-e mások érveire. Esetleg tapasztalatára - olyanban, amit te még nem csináltál esetleg - ha azok szembe mennek a nézeteiddel.
82

Nyilván azért fizetnek a

inf3rno · Júl. 12. (Sze), 23.24
Nyilván azért fizetnek a cégek akár többször árat szerverekért, a dupla betápért, RAID-ért, minőségi alkatrészekért, mert a gazdaság pörgetésében érdekeltek, ugye?


nem

Ugyanazt a feladatot egy normál PC is ellátja Vargáné táppal, mi?


nem

Hogy akarod te egy darab számla felvitelét szétosztani ezer gép között?


sosem írtam ilyet

Mi az, hogy az üzemeltetés nem tudja megoldani az adatok biztonságos tárolását? Hisz az a dolga.


Előfordul, hogy elszáll a RAID és nem sikerül rebuild-elni. A munkamenetek meg tipikusan nem olyan jellegű adatok, amikről 10 percenként backup készül. Jó esetben egyáltalán nem készül róluk backup, mert senkit nem érdekel hosszú távon, ha elveszik egy munkamenet. Szemben ha a kliensen tárolod őket, akkor nincs ilyen probléma, mert csak a kliens gép elszállása, ami miatt elveszik egy munkamenet, a többi kliens meg boldog, mert nem veszik el a munkamenetük a session-ök tárolását végző gép(ek) hibája miatt, és a HTTP szerver is boldog, hogy nem kell stateful request-eket teljesítenie, és kikerestetni a több millió munkamenet közül, hogy melyik a felhasználójé, mert megkapja a kérés kiszolgálásához szükséges adatokat a klienstől a kéréssel együtt. A másik előnye ennek a megközelítésnek (amiről már szó volt), hogy nem kell erőforrásokat lockolni, hogy beírj egy munkamenetbe, és így növekvő munkamenet szám mellett sincs olyan probléma, hogy a lockok miatt lassulna a kiszolgálás, esetleg megrogyna a szerver túl sok kliens esetén. De tulajdonképp teljesen mindegy, hogy milyen érveket írunk, amikor write only módban vagy.

Ezzel a hozzászólásoddal most eléggé alacsonyra tetted a mércét.


A mércét sajnos nem én tettem alacsonyra, hanem Ádám, amikor nem bannolt ki már 10 éve, amikor elkezdted széttrollkodni ezt az oldalt.
86

+1

bamegakapa · Júl. 13. (Cs), 18.17
10 éve egy dolog, de azóta se. Mostanra meg csak ő maradt gyakorlatilag :). Leszámítva azt a néhány hazajáró lelket, mint mi, akik csak kísérteni jönnek.
87

Nekem vannak ötleteim

inf3rno · Júl. 13. (Cs), 20.56
Nekem vannak ötleteim közösség által moderált oldalra, akár még abban is benne lennék, hogy githubon közösen összeszórnánk egy új oldalt, ezt meg hagynánk a fenébe. Talán az egyedüli probléma, hogy az itteni tartalmat nem lehet átemelni, és kár lenne, ha a cikkek elvesznének.

szerk:
Közben eszembe jutott, hogy nem lehet lemondani a szerzői jogról, tehát jogilag semmi akadálya az innen történő importálásnak amennyiben a cikk szerzője ehhez hozzájárul.
88

Közösség

Hidvégi Gábor · Júl. 13. (Cs), 21.44
A közösségi moderálás nem működik, mert a tömeg intelligenciája alacsony, ezt használták ki például Hitlerék. Érdemes megfigyelni a prohardver vagy a mobilaréna hozzászólásait, az emberek véleménye szinte kivétel nélkül a cikkíróét tükrözi, úgy, hogy sosem használták az adott terméket, és semmilyen kézzelfogható tapasztalatuk nincs róla.

A közösség az aktuális divatirányzatoknak megfelelően moderál. Ha mindig csak a magad igazát szeretnéd hallgatni, akkor egyszerűbb, ha alapítasz egy vallást, és megteszed magad főpapnak.

Minden más helyen találkozhatsz olyan véleményekkel, amik nem egyeznek a tieddel. Kitiltani internetes fórumról bárkit is nem túl hatékony döntés, hisz úgyis bármikor visszamegy.

Egy időben divat volt például személyreszabott tartalmat vagy reklámot adni az embereknek, csak aztán rájöttek, hogy ez nem túl hatékony, mert egysíkúvá válik a gondolkodás. Szóval szerintem érdemes meghallgatni a más véleményeket is, mert tanulhatunk belőle.
89

Felnevettem, mikor ezt

smokey · Júl. 13. (Cs), 23.29
Felnevettem, mikor ezt olvastam tőled :D.

Ha mindig csak a magad igazát szeretnéd hallgatni, akkor egyszerűbb, ha alapítasz egy vallást, és megteszed magad főpapnak.


az emberek véleménye szinte kivétel nélkül a cikkíróét tükrözi, úgy, hogy sosem használták az adott terméket, és semmilyen kézzelfogható tapasztalatuk nincs róla


Bocs, nem bántani akarlak, tényleg, csak simán vicces :D.
90

Tényleg az. :D

inf3rno · Júl. 14. (P), 02.26
Tényleg az. :D
92

Nemtom eldönteni hogy sírjak

bamegakapa · Júl. 14. (P), 07.35
Nemtom eldönteni hogy sírjak vagy nevessek...
91

A projekt érdekesen hangzik.

bamegakapa · Júl. 14. (P), 07.33
A projekt érdekesen hangzik. Vagy megvárjuk amíg HG megcsinálja a saját oldalát aztán valahogy feltámasztani ezt. Bár gondolom Ádám nem hagyná.
94

Én nem sietek, ha 10 évig

inf3rno · Júl. 15. (Szo), 02.12
Én nem sietek, ha 10 évig ráért. :D

Nagyjából belenéztem a várható látogatottságba, üzemeltetési költségbe, reklámbevételbe, és csak úgy tudnám bevállalni a közös fejlesztést, hogy karitatív alapon megy mindenkitől. A fejlesztési költségek valószínűleg egyébként sosem térülnének meg, kivéve talán, ha valamit egy CMS-ben 1 nap alatt tákolnánk össze. Igazából nem is a fejlesztés a neheze a dolognak, mert azzal boldogulok egyedül is, ha muszáj. Inkább azt kéne átbeszélni egy arra való felületen, hogy mi miatt csődölt be a mostani oldal, és mik a megoldások ezekre a problémákra. A válaszokból nagyjából lejönne, hogy milyen feature-ök kellenek az oldalra, és az alapján már lehet fejleszteni. Erre mi lenne a legalkalmasabb felület szerinted? Lehetne google groups-ot csinálni és email-ben megvitatni, vagy még az jutott eszembe, hogy a feature-öknek csinálok egy git repo-t, a hozzá való gitter-en, esetleg issues-ban meg lehet vitatkozni a feature-ökről. Nekem egyébként az utóbbi szimpatikusabb, nem bírom a levél özönt...
95

A levélözönre én se vágyom.

bamegakapa · Júl. 15. (Szo), 09.49
A levélözönre én se vágyom. Issues jó ötlet. Alaposan át kéne beszélni, mit akarunk pontosan építeni, ha egyáltalán valamit.
96

Egyelőre csináltam neki egy

inf3rno · Júl. 15. (Szo), 19.58
Egyelőre csináltam neki egy repo-t, domain nevet még nem találtam ki, szinte minden foglalt. weblabor-issues Nyitottam már pár issue-t, igyekeztem nem kész tervekkel előállni, hanem inkább ötletelni. Várom az ötleteket, észrevételeket, újabb issue-kat.

Személy szerint a következő hónapban kezdek el összerakni egy hasonló taggelős keresős rendszert itthoni használatra. Az jó kiindulási alap, ha elkészül, és úgyis kell néhány hónap, mire átbeszéljük, hogy pontosan mit is akarunk, van e egyáltalán értelme, stb.
97

Bár nem vagyok címeres tag,

smokey · Júl. 16. (V), 13.40
Bár nem vagyok címeres tag, javasolnék egy számomra jól bevált technikát:

- Lean canvas
- Business Model Canvas

Röviden, tömören

Amiért nekem tetszik: Minden héten legalább kétszer kitalálom a világ megváltó ötletet, és mielőtt bármibe is belefognék, csinálok egy canvast (az ötlettől függően a kettő közül a relevánsabbikat választom). A canvas készítése közben, ami adot esetben egy kevés kutató munkát is iégnyel:
- általában letisztul az elképzelésem
- összeszedem minden gondolatom
- kiderül, hogy 60 ugyanilyen megoldás létezik már
- semmi értelme az ötletnek
- nem is létezik a probléma
- nincs célközönség

stb, stb. Ha nem sikerül egy épkézláb canvast összerakni, akkor nem is érdemes beszélni következő lépésről.
98

Köszi, ránézek.

inf3rno · Júl. 16. (V), 14.14
Köszi, ránézek.
100

Hát ez el fog tartani egy

inf3rno · Júl. 21. (P), 22.36
Hát ez el fog tartani egy darabig, amíg átrágom magam a könyvön. Érdemes esetleg valami gyorstalpalót végigolvasni, vagy megéri a 200 oldal?
101

Én nem olvastam el semmi

smokey · hétfő, 15.08
Én nem olvastam el semmi terjedelmes írást, inkább megpróbáltam magam értelmezni. Kipróbáltam pár általam jól ismert projectre ráhúzni a canvasokat, így viszonlag gyorsan tiszta képet kaptam az értelmükről.
93

Gyere

Pepita · Júl. 14. (P), 10.17
44

Állapot vs skálázódás

BlaZe · Júl. 11. (K), 00.11
A kevés adat miatt a szerver oldali overhead is elhanyagolható.
Egy rendszer tejlesítményét extrém kivételektől eltekintve mindig az IO műveletek (azok befejeztére való várakozás egészen pontosan) határozzák meg. A szinkronizációval egy olyan extra IO műveletet raksz a rendszerbe, amin megjelenhet egyéb teljesen független szálak, processek, node-ok okozta késleltetés is, hiszen a shared állapotot kénytelen leszel lelockolni valamilyen módon. Gyakorlatilag könnyen olyan helyzetben találod magad, hogy a lockok kérése fogja dominálni a kiszolgálási időt. Az ilyen központi bottleneckeknél van egy pont, mint a repülőknél az átesési sebesség. Ha azt eléred, akkor a rendszered gyakorlatilag beleáll a földbe: konstans válaszidő növekedéssel lehet számolni, adott esetben exponenciális növekedéssel. A stressz tesztjeinken nagyon jól szokott az ilyen kinézni: kb mint a gyökfüggvény, csak épp logaritmikus skálán...

A gyakorlatban ez globális szolgáltatáskiesést jelent. Vagyis az egyes történelem előtti eszközöket használó kliensek (de mindenképpen egy kisebbség) számára tapasztalható kellemetlenségeket átkonvertáltad egy globális, mindenkit érintő kockázattá, és problémává.

Léteznek módszerek ennek a problémának a kezelésére - pl particionálás -, de egyrészt minden problémát jobb elkerülni, mint kezelni, másrészt azok költsége (hardware, fejlesztői bér és üzemeltetés) és komplexitása messze lekörözi a kliens állapot kliensen történő menedzselésének költségét és kockázatát. Ezt kell megérteni. Hogy a kliens állapotot normálisan kezelni nem képes böngészőt használó felhasználók kedvéért alternatív megoldásokat szükséges-e kialakítani, az egy üzleti döntés, nem pedig IT.

Nagyon érintőlegesen kapcsolódó téma, de jól érzékelteti mennyire kritikus a skálázódási képesség, illetve az informatikai háttérrendszer cégműködésre való hatása: 2018-tól a szabályozók előírják a befektetési cégeknek (bankok, egyéb piacon jelenlévő cégek), hogy a megrendeléseket kezelő rendszereik a mindenkor rögzített legnagyobb másodpercenkénti loadjuk kétszeresét képesek kell legyenek kezelni rendszerleállás, data corruption, adatvesztés stb nélkül. Aki ezt nem tudja, kb lehúzhatja a rolót. Nincs ez másként egy egységsugarú webshopnál sem, csak nincs rajtuk akkora szabályozói nyomás ebben a tekintetben, mint a befektetési szolgáltató cégeken. Úgyhogy ez a "nincs még akkora a terhelésem, hogy ilyenekkel kelljen foglalkoznom" eléggé megkérdőjelezhető megközelítés. Nem kell egyből geo redundáns rendszerekben gondolkodni, de a skálázódási képesség benne kell legyen képletben. A skálázódási képesség a kulcsa egy cég növekedésének. Egy informatikai rendszerekből élő cégnél ez pedig egyértelműen az IT skálázódás képessége. Az IT skálázódás pedig a konkurensen hozzáférhető shared állapot lehetőség szerinti elkerüléséről, és minél inkább a stateless service-ek irányába tolódásáról szól (amennyire lehet). Weben erre egy kézenfekvő megoldás a kliens állapotát a kliensen tartani a szerveroldal helyett.

Hogy hány byte, amit mozgatni kell a gépek között, az már egy következő kérdés. Fontosabb, hogy kell-e, ha nem muszáj.
45

Teljes mértékben egyetértek,

inf3rno · Júl. 11. (K), 03.58
Teljes mértékben egyetértek, itt a lényegi kérdés szerintem is az, hogy egy kis terhelésű rendszernél, pl egy kis forgalmú webshopnál van e értelme foglalkozni ilyesmivel, vagy jobb mindent beszórni mondjuk php session-be és megspórolni a ráfordított fejlesztési időt? A méréseitek alapján mennyi párhuzamos felhasználó körül lehet nagyságrendileg a kritikus pont, ami felett már muszáj foglalkozni a kérdéssel? Az olyan rendszereknél, amiknél elég egy gép a kiszolgálásra is felmerülhet ez a lock probléma?
48

Skála

Hidvégi Gábor · Júl. 11. (K), 08.40
Értem, tehát azért, mert nagyvállalatok milliós számú ügyféllel, gigantikus eszközpark mellett ilyen problémákkal küzdenek, ezért tárolja mindenki kliensoldalon az állapotot?

Ez engem erősen az amatőr programozó első tipikus hibájára, az előre optimalizálásra emlékeztet.

  • Minden cég akkora lesz, mint az általad üzemeltetett?
  • Egy kisebb cégnél van-e erőforrás/kapacitás/tudás, amivel ki tudják számítani, melyik megoldás az olcsóbb?
  • Melyik rendszert olcsóbb elkészíteni (figyelembe véve az átlagos programozó képességeit/tudását)?
  • Egy kezdő cég, amelyik még nem termelte vissza a befektetett összeget vagy még nem stabilan nyereséges, megengedheti-e a vastag kliens miatt történt adatvesztést?
  • Hogyan oldható meg a kliensoldali skálázódás problémája (egy watt TDP versus 140)?
49

Értem, tehát azért, mert

BlaZe · Júl. 11. (K), 09.17
Értem, tehát azért, mert nagyvállalatok milliós számú ügyféllel, gigantikus eszközpark mellett ilyen problémákkal küzdenek, ezért tárolja mindenki kliensoldalon az állapotot?
Abban tévedsz, hogy milliós látogató szám kell ehhez a problémához. Amint több gép szolgál ki, megvan ez a probléma. Együtt is dolgoztunk olyan rendszeren, aminek 4 gépből állt a backendje, tizenévvel ezelőtt :)

Ez engem erősen az amatőr programozó első tipikus hibájára, az előre optimalizálásra emlékeztet.
Tehát akkor eljutottunk oda, hogy ez nagyon is valós igény :)

1) Nem, és nem is kell akkorák legyenek. BTW nálunk ez nem egy sokszáz gépből álló webes clusterben jön elő, hanem JMS brókerre publikálásnál.

2-3) Ezekre kitértem az előző hozzászólásomban. Pl angulart ismerő frontendest találsz sokat. Olyat, aki fel tud építeni egy masszívan skálázódó backendet már nehezebben, drágábban. Nem beszélve a fent említett egyéb költségekről.

4) Melyik az a bármilyen evolúciós állapotban lévő cég, amelyik megengedhet magának egy globális szolgáltatáskiesést, vagy összes felhasználót érintő belassulást? Jobb az, mint egy egy klienst érintő esetleges adatvesztés?

5) Kliensen nem kell skálázódni, pont ez a lényeg. Vannak erősebb, meg gyengébb gépek. De egy JS oldal kiszolgálásához nem kell 140W TDP-s i7 :) Nekem eldöcögnek simán az atom procis tabletemen, 5 éves telefonomon is.
51

Szilánk

Hidvégi Gábor · Júl. 11. (K), 11.43
A shardolás ma már nagyon egyszerűen megoldható például PHP-FPM-mel, a webszerveren (pl. nginx) könnyen szét lehet osztani a feladatokat n backend között, amelyek m adatbázishoz vagy egyéb szolgáltatáshoz kapcsolódnak, és emiatt nem kell a szerveroldalhoz nyúlni egyáltalán.
58

Valóban, ezt írtam is

BlaZe · Júl. 11. (K), 14.49
Valóban, ezt írtam is korábban. De egyrészt a shardolás sem csak úgy magától működik, mégha van is rá támogatás, másrészt a lockolás problémája attól még fennáll, csak épp a shardokon belül.

Az van, hogy a lockolás egy sorosító művelet az ugyanazon erőforráshoz hozzáférni kívánó rendszerek számára, illetve egy queuen keresztül idegen processek késleltetésének költségét kell megfizetni akkor is, ha különböző erőforrást szeretnének az egyes processek lockolni, de ugyanazon a lock manageren. Tévedés, hogy ez mindent megold varázsütésre.
60

Annyira nem bonyolult

Hidvégi Gábor · Júl. 11. (K), 15.25
Nálunk csak a webszerver konfigurációs fájlját kell módosítani, valamint az előfizetők beállításait a support rendszerben, és azonnal egy saját szilánkon megy a kiszolgálásuk. Nem igazán volt kihívás megvalósítani.

Szóval nekünk sikerült, és ezt megosztom, hátha más is profitálhat belőle.
69

Gondolom majd ha beüt egy

inf3rno · Júl. 11. (K), 16.12
Gondolom majd ha beüt egy ddos és leül a szerver, mert nem foglalkoztatok a fent említett erőforrás lockolási problémával, akkor majd néztek bután. :D
71

Ez nem elosztott rendszer,

Pepita · Júl. 11. (K), 16.56
Ez nem elosztott rendszer, hanem kód- és vas - duplikálás. Tartsd karban, amikor a 20-at hoztad létre. :)
68

Szerintem nem kell teljesen

inf3rno · Júl. 11. (K), 16.08
Szerintem nem kell teljesen elvetni azt, amit Gábor írt. Üzleti döntés, hogy szükség van e HTML-es oldalra az olyan klienseknek, amik nem támogatják a js-t vagy túl régi verziót támogatnak. Pl a google-nél is van js nélküli megoldás. Mondjuk 1% a felhasználók közül ilyen, a kérdés az, hogy akarsz e foglalkozni velük, vagy kiírod a kezdőlapra, hogy bocs, de gyenge a böngésződ, tegyél fel másikat vagy nézd egy normális gépről az oldalt. Emiatt nyilván pár felhasználó lelép, aminek anyagi vonzata van. Ezt kell szembeállítani a fejlesztési költségekkel, hogy kiderüljön megéri e. Szerintem legtöbbször nem, de nagy cégeknél az 1% vagy 1 ezrelék is több millió felhasználót jelenthet, ami már komoly pénz.

Ilyenkor persze a szerver oldalra teszik át a klienst és ugyanazzal a REST API-val fog kommunikálni, mint a JS-es kliens azzal szemben, amit Gábor ír. Az ő változata tipikusan 1 szerveres rendszerekre működőképes.
23

Miben segítettél magadon? Van

smokey · Júl. 7. (P), 15.43
Miben segítettél magadon? Van egy rakat angularos komponensed? Az elmúlt évtizedben, amíg nem Angularral dolgoztál, miből építkeztél? Mindig újraírtál mindent?


Tanultam. Rengeteget. Kész komponensekből dolgoztam, és mindig kerestem a jobbat. Nem állok neki lefejleszteni azt, ami már kész. Rengeteg időt spóroltam, így a végtermék tökéletesítésére tudtam mindig fordítani az időt, ahelyett datepickert írnék.

És mi biztosítja, hogy a mostani vonal az elég jó? Mi biztosítja, hogy ezt nem írják át ugyanígy, és a mostani vonalra épített alkalmazásod megy a levesbe, mert már nem lesz hozzá olyan támogatás, új komponensek stb.? Mert amíg még az 1.x-et fejlesztették, akkor is úgy gondolták, hogy az a tuti, amit épp csinálnak. Aztán kuka lett az egész. Mi biztosítja, hogy nem ismétlik meg magukat?


Semmi. És elég szomorú lenne, ha megelégedetten állnék 3 év után is a munkám előtt. Ez részemről azt jelenti, hogy nem fejelődök semmit. Mindig az újat és a jobbat keresem, nem elégszem meg azzal, ami rég volt. Így tesznek ők is (mármint az angularosok). Van jobb ötlet és koncepció a jelnleginél? Igen? Akkor hajrá!
26

Provokatív kérdések

Hidvégi Gábor · Júl. 7. (P), 16.58
»Miben segítettél magadon? Van egy rakat angularos komponensed? Az elmúlt évtizedben, amíg nem Angularral dolgoztál, miből építkeztél? Mindig újraírtál mindent?«

Tanultam. Rengeteget. Kész komponensekből dolgoztam, és mindig kerestem a jobbat. Nem állok neki lefejleszteni azt, ami már kész. Rengeteg időt spóroltam, így a végtermék tökéletesítésére tudtam mindig fordítani az időt, ahelyett datepickert írnék.
Értem, tehát volt egy komponenskészleted már az Angular előtt, amit eldobtál, hisz nem kompatibilis vele, és valószínűleg sokkal bonyolultabb/kevésbé jól kezelhető/rugalmatlanabb volt, mint most, különben nem cserélted volna le. Így volt? Akkor tulajdonképpen mit tanultál?

»És mi biztosítja, hogy a mostani vonal az elég jó? Mi biztosítja, hogy ezt nem írják át ugyanígy, és a mostani vonalra épített alkalmazásod megy a levesbe, mert már nem lesz hozzá olyan támogatás, új komponensek stb.? Mert amíg még az 1.x-et fejlesztették, akkor is úgy gondolták, hogy az a tuti, amit épp csinálnak. Aztán kuka lett az egész. Mi biztosítja, hogy nem ismétlik meg magukat?«

Semmi. És elég szomorú lenne, ha megelégedetten állnék 3 év után is a munkám előtt. Ez részemről azt jelenti, hogy nem fejelődök semmit. Mindig az újat és a jobbat keresem, nem elégszem meg azzal, ami rég volt. Így tesznek ők is (mármint az angularosok). Van jobb ötlet és koncepció a jelnleginél? Igen? Akkor hajrá!
Látod, ez a különbség köztünk. Én előveszem bármelyik tízéves PHP vagy JS projektem, és gond nélkül futnak ma is a futtatókörnyezetükben. De erre még jobb példa a Java, elvileg az 1.0-ban írt kód ma is lefordul és fut.

Szóval értem én, hogy tanultál, de az utóbbi tíz évben egy csomó időd elment az Angularra, hónapok, akár évek, amíg megtanultad, hogyan kell kezelni, mik a buktatók stb. Közben kénytelen voltál kidobni a korábbi komponenseket.

Ez idő alatt én például a meglevőket tudtam csiszolni. Ha úgy vesszük, minimum annyi előnyöm van, az a pár hónap vagy év, amit te az Angularra szántál. Miben jobb az, amit most te csinálsz? Hatékonyabb? Gyorsabb?

Tehát mit tanultál és miben lettél jobb?
29

Értem, tehát volt egy

smokey · Júl. 7. (P), 21.13
Értem, tehát volt egy komponenskészleted már az Angular előtt, amit eldobtál, hisz nem kompatibilis vele, és valószínűleg sokkal bonyolultabb/kevésbé jól kezelhető/rugalmatlanabb volt, mint most, különben nem cserélted volna le. Így volt? Akkor tulajdonképpen mit tanultál?


Ezen a szinten saját komponens készletem soha nem volt. Minek is kellett volna, mikor ott volt a rengeteg bejáratott cucc, közösséggel a háta mögött. Tehát, nem dobtam el semmit az angular miatt. Megtanultam hatékonyan használni az újdonságokat, amivel mérhető mennyiségű időt, pénzt és energiát spóroltam meg, nem csak magamnak.

Látod, ez a különbség köztünk. Én előveszem bármelyik tízéves PHP vagy JS projektem, és gond nélkül futnak ma is a futtatókörnyezetükben. De erre még jobb példa a Java, elvileg az 1.0-ban írt kód ma is lefordul és fut.


Én nem az egyetlen sajátomat használom, hanem kategóriájában az X darab komponens közül kipróbálok párat - ha nincs egy mindig használatos, jól bevált valami, és a relevánsabbat integrálom, ha kell felülethez igazítom. Bower és/vagy npm package már van mindenhez, így még a verziókezelésről sem kell gondoskodnom.

Szóval értem én, hogy tanultál, de az utóbbi tíz évben egy csomó időd elment az Angularra, hónapok, akár évek, amíg megtanultad, hogyan kell kezelni, mik a buktatók stb. Közben kénytelen voltál kidobni a korábbi komponenseket.


A szép az egészben az, hogy nem kellenek hónapok, évek, hogy megtanuld használni, elég hozzá pár hét max 1-2 hónap egy projecten.

Ez idő alatt én például a meglevőket tudtam csiszolni. Ha úgy vesszük, minimum annyi előnyöm van, az a pár hónap vagy év, amit te az Angularra szántál. Miben jobb az, amit most te csinálsz? Hatékonyabb? Gyorsabb?


- plusz egy sor a CV-ben
- mérhetően gyorsabban és profibban lehet dolgozni angularral, mint saját kóddal, ha csak a data binding funkciója lenne az egyedüli, már megérte volna használni
- milyen kontextusban gyorsabb? Gyorsabban lehet vele haladni; nem biztos, hogy gyorsabb, de az sem, hogy lassabb egy nem angularos/reactos alkalmazáshoz képest
- reguláris és publikus a működése, ezáltal olyan lehetőségeket ad, amit saját rendszerrel nem bizots, hogy megoldasz (pl.: react native; közös core-t tudsz csinálni a web alkalmazásodnak, és a mobil alkalmazásodnak)
- új csapattag esetén nem kell oktatást tartanom a saját rendszerről

Szumma szumma, én sírva fakadok a tavaly előtti kódomtól is, és két év múlva is sírva fogok fakadni a mostani megoldásaimon. Miért? Mert mindig lehet jobban csinálni!
6

Az alábbi tények közül most

BlaZe · Júl. 7. (P), 00.00
Az alábbi tények közül most melyiket is vitatod?

1) A mindenkori legkeresettebb framework-ök technológiák
1/a) ismerete növeli a fejlesztő piaci értékét
1/b) alkalmazása nagyban megkönnyíti egy projecten a kieső erőforrás pótlását
2) Saját cucc lefejlesztése, tesztelése, javítása, továbbfejlesztése, betanítása nagyságrendileg több ideig tart, mint polcról levenni egy mindenki által ismert megoldást
3) Nagyságrendileg több idő nagyságrendileg több pénzébe kerül a megrendelőnek
4) Belső framework betanítása minden egyes new joinernél növeli a ramp-up idejét, ezzel költségét
5) Belső framework tudást a programozó nem tud továbbvinni következő munkahelyére, ezért az nem igazán javítja a munkaerőpiaci pozícióját
6) Az a project, ami nem javítja a munkaerőpiaci pozíciót
6/a) kevésbé keresett a fejlesztők részéről, ezért nehezebb, költségesebb a staffing (nem kicsit)
6/b) magas fluktuációval kénytelen számolni

A hatos ponthoz hozzátenném, hogy egy alkalmazott pótlásának költsége átlagosan a 7-8 havi munkabérével egyezik meg. Az erőforráshiány okozta költség adott esetben pedig minden hónapban a hiányzó kolléga bérének többszöröse.

Ezek egyike se az én személyes véleményem, hanem tények. Továbbá vedd észre, hogy ebben egy betű technikai tartalom sincs. Ha már szakmailag megalapozatlan az a pár mondat, amit idéztél tőlem :)

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
Mégis milyen más indíttatásból fejleszt valaki keretrendszert?

Állapot a szerveren: dolgoztál már elosztott, konkurens rendszereken? Tudod, hogy a webes alkalmazások többsége ilyen (skálázás, load balancing, HA, redundancia)? És hogy a szerveroldali állapotot irtani próbálja mindenki, mert akkora probléma?

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

A demagógia eszközei: mind pipa :)
7

Érvek?

Hidvégi Gábor · Júl. 7. (P), 08.48
Először is tisztázni kell, hogy olvastad-e az írást, legfőképp a címét, mert nem általában a keretrendszerekről, hanem a frontendről szól.

Akkor nézzük tételesen:

1, Ha elolvasod és átgondolod a "HTML" és "Működés" fejezeteket, akkor nyilvánvaló lesz, hogy a webes fejlesztést framework-ök nélkül az esetek 99%-ában el lehet végezni.

2, 3, 4, 5, 6, Ugyancsak a "Működés"-ben fejtem ki, hogy a kész sablonok alapján (a sablonozáshoz vannak kész eszközök, ezeket is felsoroltam) a megfelelő DOM részek cseréje pár kilobájtnyi kódból megoldható. Ennyi kód elkészítése, karbantartása és betanítása gyakorlatilag nulla egy cég életében.

Továbbá vedd észre, hogy ebben egy betű technikai tartalom sincs. Ha már szakmailag megalapozatlan az a pár mondat, amit idéztél tőlem :)
Aki ismeri a böngészők működését, a HTML-t és társait, és átgondolja, az bőven elég. Ha nem értesz valamit, előtted a lehetőség, hogy kérdezz. Mi nem világos?

Amit írsz, nem csak szakmailag, hanem üzletileg is megalapozatlan, az alatta lévő bekezdésben kifejtettek miatt. A frontend nem a megrendelőnek dolgozik, hanem a felhasználóknak. Az, hogy ebből a megrendelő profitál, a munka következmény, de nem oka.

Mégis milyen más indíttatásból fejleszt valaki keretrendszert?
Alatta kifejtettem, de valószínűleg elkerülte a figyelmed, hogy alapvetően a felhasználóknak dolgozunk. Ha egy eszköz – esetünkben egy keretrendszer – a felhasználó kárára válik, mert a kívánt tartalmat nem, vagy jóval lassabban tudja elérni, azaz a fejlesztő kényelmét előbbre helyezték, mint a felhasználó érdekeit, akkor az az eszköz rossz, és nem szabad használni.

Állapot a szerveren: dolgoztál már elosztott, konkurens rendszereken? Tudod, hogy a webes alkalmazások többsége ilyen (skálázás, load balancing, HA, redundancia)? És hogy a szerveroldali állapotot irtani próbálja mindenki, mert akkora probléma?
Bonyolult a programozás és az üzemeltetés? De ha valakinek nem megy, akkor miért választja ezt a területet?

Inkább toljunk mindent a kliensre, ami definíció szerint undefined? Azaz fogalmunk sincs, mi van ott, egy teljesen kontrollálatlan környezet. Már a backend is ekkora bajban van?

A demagógia eszközei: mind pipa
Tudnál esetleg személyeskedés nélkül is érvelni? Meg tudod mondani az eddigiek alapján, hogy az Angular következő verziója az visszafele kompatibilis lesz-e a mostaniakkal, vagy pedig újraírják, mint az 1.x és a 2.0 között?
32

HG, az az igazság, hogy

BlaZe · Júl. 7. (P), 21.55
HG, az az igazság, hogy nagyon nehéz figyelmesen végigolvasni, amit írtál. Borzasztóan demagóg (tényleg az összes eszközt felhasználtad a listáról), szakmai érveket szinte teljesen nélkülöz. Tudom, hogy a szándékod nem ez, és nem is így gondolod, de gyakorlatilag így van. Lázít, fröcsög, lehülyézi az olvasót. Ennek a stílusnak semmi létjogosultsága nincs egy szakmai oldalon, és semmi szakmai tartalmat nem hordoz. Gyakorlatilag azt írtad, hogy az angulart a sorosgyuri pénzeli a szakma ellen :)

Szakmailag akkor vagy vitaképes technológiák összehasonlításában, ha mindkettő mellett és ellen is képes vagy érvelni, ismered mindkettő előnyeit és hatrányait, ha tudsz értelmes példákat hozni rá mikor melyiket használnád. Lásd janoszen válaszát példának. Ez nálad teljesen hiányzik, kizárólag valami ellen vagy hajlandó véleményt formálni.

Konkrétan a kontextusából kiragadtad, amit janoszen és én is írtunk, majd közölted, hogy azok hülyeségek. És amikor az ember visszarakja kontextusba a saját irományát, akkor közlöd, hogy nem arra kaptál választ, amit írtál. Hát sorry, akkor nem kellett volna más kontextusban idézni, és hülyeségnek beállítani.

Amiket pontokba szedve írtam, azokkal is vitatkozol. Holott aki valamennyire is rálát a munkaerőpiacra, azok számára ezek alighanem alapvetések. Én csak idén két olyan jelöltet interjúztam, akik azért hagyták ott az egyik legjobban fizető, és legnevesebb itthoni céget, mert csak ott használható technológiákat kell megtanulni, és úgy érzik csökkent a job market pozíciójuk. Volt is benne valami.

A backend állapottal kapcsolatban meg ajánlom olvass kicsit a software architektúrákról.
12

A Weblabor állapota 2017-ben

bamegakapa · Júl. 7. (P), 11.49
A Weblabor állapota 2017-ben :(
70

Sajnos. :D Nem is értem miért

inf3rno · Júl. 11. (K), 16.20
Sajnos. :D Nem is értem miért írok most ebbe a topicba, amikor évekkel ezelőtt megfogadtam, hogy nem vitatkozom Gáborral, mert csak időelbaszás. Őt nem lehet meggyőzni, mindenki más meg ugyanazt írja, mint én.
27

Kamikaze

Pepita · Júl. 7. (P), 18.42
Gábor, ismét egy ragyogó "szembe megyek a világgal" írást közöltél, én tiszteletben tartom a véleményed, ezért "cserébe" annyit kérek, hogy Te is tartsd tiszteletben másokét... Megjegyzem, hogy minél keményebben harcolsz a modern technológiák ellen (és ezt elég nagy bullshit szó szerinti divatnak nevezni), annál kisebb az esélyed, ha esetleg neked kell új állás után nézni.

A React és társainak választása minden szempontból hibás döntés,...


Ezzel a tagmondattal nálunk egyenesen lehülyézted a teljes cégvezetést és az összes fejlesztőt, úgyhogy ne küldj önéletrajzot. :-D
Viccet félretéve: ha egy cég megfinanszírozza, hogy egy nagyon komplex webalkalmazás teljes frontendjét kb 6 fejlesztő kb 1 év(!) alatt újraírja React alatt, akkor csak nem olyan rossz az a cucc.. És elég sok ilyen van, nem mi egyedül.

Nyilván a Manyika néni őstermelőt bemutató 3 statikus html-ből álló weboldalt kár lenne React v Angular FE - el ellátni. De nem csak ilyen oldalak vannak.
28

Tisztelet

Hidvégi Gábor · Júl. 7. (P), 20.10
én tiszteletben tartom a véleményed, ezért "cserébe" annyit kérek, hogy Te is tartsd tiszteletben másokét
Én maximálisan tiszteletben tartom mindenki véleményét, de ez egyrészt nem jelenti azt, hogy azzal egyet is értek, és ha már ez egy szabad fórum, akkor hadd mondhassam el a véleményem. Lehet ellenérveket hozni! Eddig még nem igazán sikerült cáfolni az állításaimat.

»A React és társainak választása minden szempontból hibás döntés,...«

Ezzel a tagmondattal nálunk egyenesen lehülyézted a teljes cégvezetést és az összes fejlesztőt, úgyhogy ne küldj önéletrajzot
Arra a cégvezetésre célzol, aki, mit is mondtál, hány frontend technológia párhuzamos használatát hagyta jóvá? Nem szeretnék most senkit sem kellemetlen helyzetbe hozni.

Az egyébként törvényszerű, hogy van egy cégvezetés meg egy rakás frontend kollega, és ők mindig jó döntéseket hoznak?

Viccet félretéve: ha egy cég megfinanszírozza, hogy egy nagyon komplex webalkalmazás teljes frontendjét kb 6 fejlesztő kb 1 év(!) alatt újraírja React alatt, akkor csak nem olyan rossz az a cucc..
Biztos?
34

cáfolni..

Pepita · Júl. 9. (V), 02.02
Én maximálisan tiszteletben tartom mindenki véleményét
Ne haragudj, de ez telefonon sem úgy tűnt.

Eddig még nem igazán sikerült cáfolni az állításaimat.
1. Milyen a "sikeres" cáfolat? Rengeteg érv hangzott el, de nemigazán érted ezeket, emiatt - számodra - nem sikeres.
2. Nem nekünk / bárkinek kell cáfolni a Te állításaid, hanem neked kéne kellően alátámasztani, mert Te állítasz olyanokat, amivel eddig senki sem ért egyet.

Nem szeretnék most senkit sem kellemetlen helyzetbe hozni.
Ne is, és ennyire se kéne belemenni abba, amit szóban mondok el.
Egyébként saját magad hozod kellemetlen helyzetbe, ha mindent így próbálsz kifordítani. Szó sem volt "párhuzamos" jóváhagyásról. :)
Vagy esetleg Te egy előfizetős szolgáltatást, amit jópár előfizető használ és sok pénzt keres vele, beszüntetnél 1 évre azért, mert új frontend technológiára váltasz? :-D
Ha nem, akkor bizony előfordul, hogy "van még a régiből, míg készül az új".

Az egyébként törvényszerű, hogy van egy cégvezetés meg egy rakás frontend kollega, és ők mindig jó döntéseket hoznak?
Nem, nem törvényszerű.
De egyrészt, ha a cégvezető(k) tulajdonos is, akkor marha egyszerűen úgy is lehet közelíteni a kérdéshez, hogy "az ő pénze, ha azt akarja, akkor még egy statikus oldal is react-es lesz". Nálunk mondjuk ez nem így van, több ember egyetértése volt ez a döntés (is).
Másrészt amíg sok (legtöbb) technológiai és üzleti tényt egyszerűen divatnak nevezel és köpködsz rá, hogy "fúj de ördögtől való", addig semmi értelme veled erről vitatkozni. Nem is akarod érteni, hogy az a döntés miért lehet jó.

Biztos?
Igen.
33

Az egyik, hogy egy áramszünet

inf3rno · Júl. 9. (V), 01.48
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.


Nem feltétlen ha localstorage-be mentik. Alapvetően az nem gond, ha a munkamenetet a kliensre viszik át, sőt nagy oldalaknál egyenesen kötelező a jobb skálázódás miatt. Azzal lehet probléma, ha túl sok ideig nem történik szinkronizálás a szerverrel, és így egy 10 perces írás elveszik, vagy hasonlók.

Ha a felhasználó számára lassú lesz az oldal, és emiatt otthagyja, az az ő baja, vagy a fejlesztő hibája?


Ezt nem hiszem, hogy a fejlesztő dolga lenne eldönteni. A megrendelőnek persze fel lehet ajánlani, hogy mobilra meg ie6-ra is optimalizálod az oldalt felárért.

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.


Ez bármilyen szoftverre igaz, felesleges ezen rugózni. A kliens oldalon nem hiszem, hogy annyira számítana, hogy hányas verzióval csinálták meg a GUI-t, a szoftver frissítés biztonsági javításoknál kötelező jellegű csak.

máig n darab megoldás született, szabványt is módosítottak miatta, de mindegyik kompromisszumra készíti a fejlesztőt


Senki sem mondta, hogy aszinkron kódot fejleszteni nem jár kompromisszumokkal. Egyébként a szabvány módosításokkal részemről megoldódott a probléma, elég jól használható, én sem tákolom tovább a saját megoldásomat a témában. Szerintem inkább a közösség erősségét mutatja, hogy félre tudták tenni a nézeteltéréseiket és újra egyesült a két projekt. Nyilván sosem lesz egy java, de nem is az a cél ezzel a nyelvvel. Egyébként hogy jön ez a kliens oldalhoz?

Így projektünkben egy függőséggel több lesz, ami a kiszolgáltatottságot növeli


Nem vagy te egy kicsit paranoiás, hogy minden külső függőségtől meg akarsz szabadulni? Persze projekttől függően érdemes mérlegelni, hogy mi az, ami belefér, és mi az, ami nem, de a legtöbb projekt nem az a szint, aminél ne lehetne bármelyik komolyabb keretrendszert vagy programnyelvet használni. Nem banki vagy nemzetbiztonsági szoftvert fejlesztünk.

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


Ezt én sem feltétlenül tartom jónak.

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.


Ha ez kritikus az üzlet szempontjából (pl statisztikát készítesz róla), akkor persze lehet a szerveren tárolni az állapotnak ezt a részét, de tipikusan ez a kliensre tartozik, és semmi köze a szervernek ahhoz, hogy egy listában ki hogyan próbál éppen választani. Egy bizonyos látogató szám felett pedig a szervert kinyírja az ebből fakadó többlet terhelés.

Ahogy nézem még mindig az XSLT-re pörögtél rá. Ha jól skálázódó oldalt akarsz vele, akkor tárold cookie-ban a kliens állapotát, ahonnan a szerver is ki tudja olvasni, és bele tudja írni az adat modelbe, ami alapján sablonozol. A másik megoldás, hogy rejtett űrlap mezőkbe teszed minden űrlapnál ezeket az adatokat. A lényeg, hogy nem tárolhatod szerveren, hanem minden kéréssel el kell mennie a szervernek amire szüksége van belőle.


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.


Nem feltétlenül 1 év múlva, de 2-3 év alatt azért megfordulhat a világ. Egy komoly fejlesztő alkalmazkodni szokott ehhez, és megtanulja az új dolgok használatát. Én komolytalannak számítok, mert a react és az angular is hidegen hagynak és sikítva menekülök ha kliens oldali fejlesztésről van szó. Egyszerűen elegem lett abból, hogy a 20 év alatt, amióta követem a kliens oldali dolgokat nem sikerült megoldani, hogy egy-egy feature ugyanúgy működjön minden böngészőben. Ennek persze részben az is az oka, hogy a böngésző fejlesztők versenyeznek egymással, és új feature-öket alkotnak, néha ugyanazt egymással párhuzamosan, a szabványosítók meg sok évvel mögöttük kullognak. Szerintem sosem fog változni a helyzet, nem látok megoldást erre a problémára.

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.


Az új keretrendszereknél lehet mérlegelni, hogy kell e ez neked, nem muszáj felülni a hype vonatra. Ha nem látod semmi előnyét és a réginél megmaradt a support, javítják a hibákat, akkor nyugodtan lehet maradni a réginél.

Ezt elég egyszer megírni, és utána nem kell hozzányúlni, ha szerveroldalon kezeljük az állapotot.


Ha vanilla js-ben jó, akkor írd meg abban, de ha sokféle böngészőt akarsz támogatni, akkor előbb utóbb ott kötsz ki, hogy egy saját keretrendszert írsz, tehát újra feltalálod a kereket és egy csomó időt és pénzt áldozol arra, amit elég lenne letölteni a githubról és használni. Persze, ha neked ez a hobbid, hogy keretrendszereket írj (nekem pl az volt egy ideig), akkor csináld nyugodtan, csak ezt nem szabad összekeverni az üzletnek azon részével, ami arról szól, hogy gyorsan összeszórsz valamit kész keretrendszerekkel, ami kielégíti az ügyfél igényeit. Az esetek 99.9%-a ilyen fejlesztés, a maradékot, ahol nem lehet külső függőség, mert kockázatot jelent, azt meg úgyis haverék cégére bízzák.

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ő?


Amit addig tanultál nem felejted el addig, nyugodtan fejlesztheted tovább az extra feature-ökkel az oldalt a régi keretrendszerrel. Egy időt után meg úgyis jön az arculatváltás, mert az újabb a jobb a vásárlók szerint is, azt meg már csinálhatod az új keretrendszerrel.


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.


Én úgy gondolom, hogy első a HTML, CSS és vanilla JS legalább alap szinten. Ha már az alapokkal tisztában vannak, akkor lehet elgondolkodni azon, hogy van e értelme egyik vagy másik keretrendszer használatának, és hogy könnyebbé teszi e a munkájukat. Sok esetben igen, más esetben felesleges az általuk nyújtott absztrakció, és csak overengineering feeling-je van a dolognak. Kell valamekkora tapasztalat, hogy fel tudja mérni az ember, mire van szüksége a fejlesztéshez.

Én személy szerint ha megjelenik egy agyonhypeolt új technológia, akkor mindig megnézem, hogy nekem erre szükségem van e, vagy hogy miben könnyítené meg a munkámat, és az alapján döntök, nem amiatt választok egy keretrendszert egy projekthez, mert valaki azt mondja, hogy most éppen ez a divat. A dolog másik oldala, hogy az éppen divatos rendszerekre van a legtöbb munka, szóval ha állást keresel vagy nem te mondod meg, hogy mit használsz, hanem a főnököd a cégnél, akkor jobb ismerni őket. Nem minden esetben te vezeted a projektet, vagy tudod meggyőzni a projekt vezetőjét arról, ami szerinted a legjobb lenne, és ha alkalmazott vagy, esetleg éppen állást keresel, akkor vagy alkalmazkodsz, vagy kénytelen leszel másik szakmát választani.



Én itt részemről befejeztem a flame wart, inkább másra fordítom az energiákat, amit erre pazarolnék.