ugrás a tartalomhoz

A frontend állapota 2017-ben

Hidvégi Gábor · 2017. 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 · 2017. 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 · 2017. 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 · 2017. 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 · 2017. 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 · 2017. 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 · 2017. 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 · 2017. 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 · 2017. 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 · 2017. 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 · 2017. Júl. 7. (P), 11.57
Szerintem sablon != UI.
16

Tényleg

Hidvégi Gábor · 2017. 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 · 2017. 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 · 2017. 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 · 2017. 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 · 2017. 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 · 2017. 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 · 2017. 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,

inf · 2017. 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 · 2017. 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 · 2017. 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 · 2017. 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 · 2017. 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 · 2017. 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 · 2017. 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 · 2017. 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

inf · 2017. 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 · 2017. 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 · 2017. 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 · 2017. 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 · 2017. 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 · 2017. 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 · 2017. 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

inf · 2017. 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

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

Még nem, React Native-vel

smokey · 2017. 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 · 2017. 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 · 2017. 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 · 2017. 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 · 2017. 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 · 2017. 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 · 2017. 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 · 2017. 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 · 2017. 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 · 2017. 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 · 2017. 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

inf · 2017. 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 · 2017. 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ó

inf · 2017. 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 · 2017. 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

inf · 2017. 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 · 2017. 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

inf · 2017. 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 · 2017. 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

inf · 2017. 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 · 2017. 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 · 2017. 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 · 2017. 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 · 2017. 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 · 2017. 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 · 2017. 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 · 2017. 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 · 2017. 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 · 2017. 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

inf · 2017. 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 · 2017. 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

inf · 2017. 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 · 2017. 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 · 2017. 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

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

Nemtom eldönteni hogy sírjak

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

A projekt érdekesen hangzik.

bamegakapa · 2017. 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

inf · 2017. 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 · 2017. 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

inf · 2017. 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 · 2017. 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.

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

Hát ez el fog tartani egy

inf · 2017. 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 · 2017. Júl. 24. (H), 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.
102

Én már elkezdtem olvasni a

inf · 2017. Júl. 29. (Szo), 20.44
Én már elkezdtem olvasni a könyvet nyaraláson. Nem rossz, van benne pár új ötlet/info.
93

Gyere

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

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

BlaZe · 2017. 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,

inf · 2017. 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 · 2017. 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 · 2017. 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 · 2017. 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 · 2017. 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 · 2017. 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

inf · 2017. 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 · 2017. 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

inf · 2017. 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 · 2017. 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 · 2017. 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 · 2017. 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 · 2017. 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 · 2017. 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 · 2017. 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 · 2017. Júl. 7. (P), 11.49
A Weblabor állapota 2017-ben :(
70

Sajnos. :D Nem is értem miért

inf · 2017. 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 · 2017. 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 · 2017. 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 · 2017. 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

inf · 2017. 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.
103

Dolgozol azt veszel

Iamzozo · 2017. Aug. 7. (H), 17.28
Bizonytalanság: a stateless állapotnak elég sok esetben van előnye. Ha az kell, hogy ne vesszen el a szöveg amit írunk, akkor autosave, nem egy nagy mágia és stb.

Verziók: Az angular 2 igazából 4-es verizó :D
2.4 után ugrottak feljebb megintcsak minorról majorra. Ez a lifecyclek rövidítése miatt történik, ígéretek szerintem sokkal nagyobb major verzió updatek lesznek ritkábban. Legalábbis angular ezzel indokolt, így gondolom nem lesz React 37 decemberre.

Node: Ezt a szerveres js motiváció hozta, aztán lehetetett a fájlokkal manipulálni, így egy rakás korábbi vergődős lib-et leváltották a build toolok. Ha már a szimpla sarki fűszeres website, akkor is jobban szeretek sass-al dolgozni, mert nem kell annyit pötyögni. Az pedig nem volt egy nagy élmény mikor licencelhettük a compass-t erre... Aztán hogy ez deploy-ra már csak sima css megy ki, rendben van, nem kötelező szerveren buildelni.

Kavarodás: Némileg félreérthető, de itt az onClick nem a klasszikus html onclick. "Unlike browser DOM elements, React elements are plain objects". Vue-nál pl @click, angularnál (click) stb...

Menő: Ezt szerintem félreérted a hozzászólásból, meg nyilván a neve miatt pukkasztó jelző. A menő itt azt jelenti hogy a cégek ezzel foglalkoznak, azaz a dolgozóik is. Tehát ha vki jelentkezik egy állásra, azzal nem sokra megy ha fejből felmondja a w3c-t. Aktív futó projektek vannak, jön a kolléga és örülünk ha minél gyorsabban bele tud kezdeni az angularos/react/vue stb. projektbe. Jó dolog a jquery meg a vanilla js, de egy agyvérzés esélyes ha azzal próbálkoznánk a legtöbb esetben. Mint írtad, a termék leszállítása a cél, időre. Ezek a toolok pedig ebben segítenek.

Összeségében:
Értem én mire gondolsz és jobb (vagy legalábbis egyszerűbb) hely volt a web. Az hogy új dolgok jönnek ki, új eszközök nem egyenértékű hogy át kell állni, meg hogy újra kell írni, csak azért mert fun. Vannak akik üldözik a hype-ot, és mindent minden héten újra akarnak írni, új tool, új language stb. Ők a legtöbb esetben kevésbé produktívak, de ismeretük széles.

De ami elterjedt fejlesztő cégeknél, azzal egy elhelyezkedni kívánó embernek ajánlott foglalkoznia, tanulnia. Így kap munkát, megélhetést.
104

Köszönöm a választ

Hidvégi Gábor · 2017. Aug. 8. (K), 12.07
Állapot: felhasználói szempontból ez egy fontos paraméter, ugyanis egy összetett alkalmazás vagy űrlap bizonyos állapotához esetleg csak több, egymásra épülő lépésből lehet eljutni (ide kattint, erre szűr stb.).

Fejlesztői szempontból okozhat problémát, lásd fentiek, de szerintem ez hozzáállás kérdése, és aki akarja, meg tudja oldani.

Angular: kettes vagy négyes, teljesen mindegy. Igérhetnek bármit, de sosem tudod, hogy mikor lesz akkora váltás, mint az egyes és a kettes között. Egyszer megcsinálták, ez előfordulhat akármikor. Innentől kezdve erre építeni hazárdjáték, és egy normális cégvezető sem engedi meg, ha normálisan van tájékoztatva.

CSS: nekem sosem volt szükségem semmilyen külső eszközre a CSS-eim elkészítéséhez, pedig vettem már rész jópár nagy projektben. A kulcs, hogy az ember a lehető legegyszerűbb kódot írja meg. Így a definícióim nagyon rövidek, az egyes elemek megjelenítését legfeljebb két-három definíció határozza meg. Azt vettem észre, hogy ha valaki ennél bonyolultabban oldja meg, az általában nem ért hozzá.

Kavarodás: tudom, hogy nem klasszikus onclick, de akkor is a viselkedés és a markup keveredik. Ráadásul nem tudom, mennyire jó ötlet beleépíteni egy komponensbe az eseménykezelőjét, ugyanis ez csökkentheti a későbbi felhasználási lehetőségeit, mert előre megmondja, hogyan kell viselkednie.

Menő: A kulcs a divat. Most menő valami, két év múlva nem lesz az. Ha egy cég üzemszerűleg X keretrendszerrel dolgozik, akkor két év múlva nehezebben fog átállni Y-ra, mert televan monomániás X fejlesztőkkel. Amit én javaslok, az ennél rugalmasabb.
105

Angular: kettes vagy négyes,

Poetro · 2017. Aug. 8. (K), 13.25
Angular: kettes vagy négyes, teljesen mindegy. Igérhetnek bármit, de sosem tudod, hogy mikor lesz akkora váltás, mint az egyes és a kettes között. Egyszer megcsinálták, ez előfordulhat akármikor. Innentől kezdve erre építeni hazárdjáték, és egy normális cégvezető sem engedi meg, ha normálisan van tájékoztatva.

Szerintem a tájékoztatás megfelelő volt, már hónapokkal korábbról. És még ma is simán építhetsz korábbi változatokra, javítások még jó ideig érkeznek az 1-eshez is.
Egyébként a verziókra teljesen felesleges hivatkozni. Több programozási nyelvben előfordult a verzióváltás, lásd PHP 5-6?-7 esetén, de volt Python 2-3, és a sort folytathatnánk. Ezen nem érdemes rugózni. Azért van verzióváltás mert szükségessé vált a fejlesztők szerint.
Menő: A kulcs a divat. Most menő valami, két év múlva nem lesz az. Ha egy cég üzemszerűleg X keretrendszerrel dolgozik, akkor két év múlva nehezebben fog átállni Y-ra, mert televan monomániás X fejlesztőkkel. Amit én javaslok, az ennél rugalmasabb.

Azt már megbeszéltük, szerintem elégszer, miért hasznos keretrendszerekkel dolgozni. Gyors fejlesztés, költséghatékony, könnyű rá új embert felvenni, ad egy struktúrát a kódodnak, nem kell feltalálni dolgokat, nem kell a keretrendszer fejlesztésére embert felvenni, azt karbantartani, mert a keretrendszer fejlesztői ezt megteszik.
106

Szerintem a tájékoztatás

Hidvégi Gábor · 2017. Aug. 8. (K), 16.50
Szerintem a tájékoztatás megfelelő volt, már hónapokkal korábbról. És még ma is simán építhetsz korábbi változatokra, javítások még jó ideig érkeznek az 1-eshez is.
1, Az idők során az API-k fejlődnek, és ha valaki elkezd egyet használni, jogosan várja el, hogy az arra épülő alkalmazását minimális mértékben kelljen módosítania, ahogy az API maga is fejlődik.

Az Angular 1.x-ről 2-re váltásnál gyakorlatilag egy új terméket kaptak a felhasználók, és a régi kódjaik az újjal egyáltalán nem működtek.

2, Ha az 1.x esetében rájöttek a fejlesztők, hogy valamit annyira elrontottak, hogy teljesen újra kell írni, az nem feltétlenül a profizmusukat mutatja. Mi garantálja, hogy a következő verzióknál nem fognak hasonló döntésre jutni?

Egyébként a verziókra teljesen felesleges hivatkozni. Több programozási nyelvben előfordult a verzióváltás, lásd PHP 5-6?-7 esetén, de volt Python 2-3, és a sort folytathatnánk. Ezen nem érdemes rugózni. Azért van verzióváltás mert szükségessé vált a fejlesztők szerint.
Nem felesleges. PHP esetében az alapok nem változtak, a legtöbb esetben csak bővült a nyelv. Ad absurdum egy 4.0-ban jól megírt algoritmus ma is működik. Ugyanez nem igaz egy Angular 1.x felhasználásával megírt alkalmazásra magasabb verziókon.

Azt már megbeszéltük, szerintem elégszer, miért hasznos keretrendszerekkel dolgozni.
Egy általános tudással egyrészt akár bármilyen keretrendszerrel tudsz dolgozni, míg, ha specializálod magad X-re, akkor a többivel nehézségeid lesznek.

Másrészt a fórumtéma HTML és a Működés bekezdésében leírtak alapján ma már bármilyen kliensoldali keretrendszer használata ódivatú, kontraproduktív és felesleges. Azt annyival egészíteném ki, hogy nem muszáj persze az állapotot szerveroldalon tárolni, lehet kliensen is, csak nem célszerű.

De ha valaki mindig csak keretekben gondolkodik, erre sosem jön rá, mert a keretek megölik az innovációt.

Egyébként abszolút igazad van, ha gyárad van, és valamit nagy tételben állítasz elő, akkor a keretrendszerek használata nagyon fontos. Csak épp a robotok mindig azt tudják elkészíteni, amire kiképezték őket. Ha egy gyárban Audi Quattrot gyártanak, akkor ott sosem fog készülni Mercedes. Rugalmatlan.

Míg azok a cégek, akik az innovációban hisznek, lehet, hogy nem fognak akkora mennyiséget előállítani, viszont, amit készítenek, az akár minden tekintetben jobb lehet a tömegtermelt példányoknál. Ez is egy valós üzleti stratégia.
107

Minden major verzió váltásban

inf · 2017. Aug. 8. (K), 17.43
Minden major verzió váltásban benne van, hogy visszafele nem kompatibilis. Lehet választani, hogy vagy átírod a kódot vagy maradsz a régi verziónál. Pár évig még azzal is simán el lehet lenni. Általában azért az új verziók ajánlanak olyan feature-öket, hogy sokszor megéri váltani.

Egy általános tudással egyrészt akár bármilyen keretrendszerrel tudsz dolgozni, míg, ha specializálod magad X-re, akkor a többivel nehézségeid lesznek.


Ezzel egyetértek.

Másrészt a fórumtéma HTML és a Működés bekezdésében leírtak alapján ma már bármilyen kliensoldali keretrendszer használata ódivatú, kontraproduktív és felesleges. Azt annyival egészíteném ki, hogy nem muszáj persze az állapotot szerveroldalon tárolni, lehet kliensen is, csak nem célszerű.


Ezzel meg nem.
110

Minden major verzió váltásban

Hidvégi Gábor · 2017. Aug. 8. (K), 22.51
Minden major verzió váltásban benne van, hogy visszafele nem kompatibilis.
Ez nincs így, mivel a weben a verziók a legtöbb esetben elvesztették jelentésüket, és ma már csak marketingszerepük van. Pont erre jó példa a React, ami a 0.14 után mindjárt 15-re ugrott, de az Angular is a 2.0 után egész verziókat lépked. Ha ránézel egy verzióra, sosem fogod biztosan tudni, hogy hoz-e nagy változást vagy sem.

»Másrészt a fórumtéma HTML és a Működés bekezdésében leírtak alapján ma már bármilyen kliensoldali keretrendszer használata ódivatú, kontraproduktív és felesleges. Azt annyival egészíteném ki, hogy nem muszáj persze az állapotot szerveroldalon tárolni, lehet kliensen is, csak nem célszerű.«

Ezzel meg nem.
Két dolgot is állítottam, melyikkel nem? Esetleg kifejthetnéd, hogy miért nem értesz egyet vele, hogy legyen súlya is annak, amit mondtál.

Az állításom első részére itt van a bizonyíték előttem: a megjelenítés másfél kilobájt, az eseménykezelés öt, az inicializáció ugyancsak másfél. Nyolc kilobájt a teljes kód, és ezzel bármilyen interaktív webalkalmazást el lehet készíteni, animációkkal, minden kutyafülével együtt. Emellé teszünk egy végtelen görgetőt, az három kilobájt, és mindenki boldog lehet. Ezen felül egy deka javascriptet sem kell írni.

Természetesen adat alapú az egész, az adatok származhatnak egyesével külső forrásból, és az oldalnak csak az a része frissül, ahol változott bármi is.

Ez az igazi webkettő : )
112

Attól, hogy néhányan nem

inf · 2017. Aug. 9. (Sze), 00.19
Attól, hogy néhányan nem követik az ajánlást ezzel kapcsolatban még nagyon is így van.

Egyikkel sem. Nincs kedvem most kifejteni, majd talán máskor.

Amikor valahol már gigabites internet van, akkor nem hiszem, hogy lenne bármi értelme kb-okat számolni. Vannak erre külön versenyek, ha ezt érzed fontosnak, akkor nevezz be!

A web 2 egész mást jelent. link Persze abban egyetértek, hogy hasznos szétválasztani az adatot és a megjelenést.
108

PHP esetében az alapok nem

Poetro · 2017. Aug. 8. (K), 18.14
PHP esetében az alapok nem változtak, a legtöbb esetben csak bővült a nyelv. Ad absurdum egy 4.0-ban jól megírt algoritmus ma is működik.

Backward incompatible changes Nem olvastam el, mert nem foglalkozok PHP-val, de nekem hosszúnak tűnt a lista.
De ugyan ez igaz Python 2 vs 3 esetén is. Van ami működik, van ami nem.
109

Változások

Hidvégi Gábor · 2017. Aug. 8. (K), 22.37
Tudni kell használni. A mi teljes kódunkban egy sort sem kellett a PHP7-re való átálláskor megváltoztatni. Nyaralás után megnézem, szerintem még 4-es alatt is működik a rendszerünk. Az újabb verziókban a sebességelőnyön kívül nem sok minden volt, amiért érdemes az ember agytekervényeit megmozgatni.
113

Nyilván aki nem használ egy

inf · 2017. Aug. 9. (Sze), 00.20
Nyilván aki nem használ egy deka objektum orientált kódot csak függvényeket meg változókat, annak a kódjára nem sok hatással volt az elmúlt 3 verzió váltás.
111

Te nem (saját) framework-öt

BlaZe · 2017. Aug. 8. (K), 23.56
Te nem (saját) framework-öt használsz? Ha feltesszük, hogy igaz, amit írtál, a te frameworködre nem igaz pont ugyanez? Ha nem, miért nem? Ha a tiédre nem igaz, nem lehet, hogy másikra sem? Startupok nem innoválnak? Ha innoválnak, nem használnak Angulart, meg ilyeneket UI frameworknek? Nem lehet, hogy semmi köze a UI frameworknek az innovációhoz?

Tudom, ti nem használtok semmit PHP-ból, ami 4.x feletti feature. Tegyük fel, hogy ez erény. Ettől még a PHP se nem backward kompatibilis, se nem konzisztens. Még Javanál is sikerült 1-2 furcsaságba beleszaladni (pl tört számok kerekítése), pedig ott aztán nagyon figyelnek a backward compatibilityre. Úgyhogy olyan nincs, hogy nem számítunk semmire verzióváltásnál (és többek között ezért is kell a sok automata teszt, hogy a verzióváltás realitás legyen)...
115

Úgyhogy olyan nincs, hogy nem

inf · 2017. Aug. 9. (Sze), 00.32
Úgyhogy olyan nincs, hogy nem számítunk semmire verzióváltásnál (és többek között ezért is kell a sok automata teszt, hogy a verzióváltás realitás legyen)...


+1, ha valami nagyon komoly kódot írsz, akkor esetleg még a nyelvet is érdemes lehet tesztelni. Én legalábbis js-nél és php-nál is belefutottam már apróbb nyelvi hibákba, pl "+0 <> -0", stb. Meg persze a kliens oldali js-nél rémálom a vanilla js-t közös nevezőre hozni, mert mindegyik böngésző máshogy implementál dolgokat. A w3c szabványosítás valamit javított a helyzeten, de szerintem ez örök probléma lesz, vagy megáll a böngészők fejlődése.
117

Állapot

Hidvégi Gábor · 2017. Aug. 9. (Sze), 07.45
Kliensoldalon eljutottunk oda az évek során, hogy nem használunk semmit, shimek nélkül nyolc kilobájt a teljes kód. Minek ennél több, ha ezzel mindent el tudunk intézni, és ráhúzható a weboldalak és -szolgáltatások több mint kilencven százalékára?

Az átlag weboldal/-szolgáltatás elképesztő mennyiségű javascript kóddal dolgozik, amelynek jórészt az a szerepe, hogy az állapotot menedzselje: például kirajzol egy lenyíló menüt kattintásra, lekér adatokat a szervertől, amivel itt-ott frissíti a tartalmat stb. Egyrészt ezek a különböző rendszerekben különféleképp vannak megvalósítva, hol egyszerűbben, hol bonyolultabban, másrészt a fejlesztők tudása is tág határok között változik, a végeredmény pedig általában egy nagy kuszaság, ami ráadásul lassú is. Ezt nehezíti, hogy (ha használnak) az objektumorientáltság miatt a fő állapot egyes alállapotai nem látnak egymásra, azaz a fő állapot nem rekonstruálható egy lépésből, hanem az egyes alállapotokat kezelő objektumok megfelelő paraméterekkel meghívott láncolataként.

Minek ez a sok varázslás?

Hehe, sajnos most idő hiányában nincs időm tovább fejtegetni, majd nyaralás után.
118

Ezt nekem akartad írni? Nem

BlaZe · 2017. Aug. 9. (Sze), 08.06
Ezt nekem akartad írni? Nem látom a kapcsolatot a hozzászólások között.

Jó nyaralást :)
119

Ha js-t akarsz használni,

inf · 2017. Aug. 9. (Sze), 15.49
Ha js-t akarsz használni, akkor nincs más választásod. Talán 1 éve foglalkoztam egy ideig a hibakezeléssel, és még az sincs megoldva egységesen az elterjedt asztali böngészőkre. Fogalmam sincs, hogy a mobil böngészőknél, Linuxos böngészőknél mekkora lehet a káosz... Én utálom a kliens oldali js-t úgy, ahogy van, viszont azt érdemes belátni, hogyha egy cégnek fejlesztesz belsős oldalt, akkor azért lehet tudni, hogy milyen böngészők vannak a cég gépein, mi az, amit használni fognak. Egy CRUD+JSON API-val, amit általában REST-nek hív a nagy többség hibásan, elég jól el lehet látni ilyen js klienseket adattal, és így a kliens oldali cucc fejlesztője is kap egy API-t magának, ami alapján dolgozhat. Nagyjából ez az előnye a dolognak.

Ha nem belsős oldalt írsz egy cégnek, hanem mondjuk webshopot, ilyesmit, amihez széleskörű böngésző támogatás kell, akkor én is jobb szeretek a HTML-nél maradni, mert egyszerűbb vele dolgozni. Persze ha van keretrendszered, ezer shimmel, akkor ugyanúgy js-ben is megoldható a dolog.

Az állapot kliensen tartása attól függ, hogy mit kell tudnia az oldalnak. Ha nagy terhelésre kell felkészíteni a rendszert, akkor jobban skálázódó oldalt lehet írni így. Ha szükség van arra, hogy több gépről belépve szinkronizálva ugyanazt lássa az ügyfél, pl online játékoknál, akkor nyilván a szerveren kell tartani az állapotot valamilyen formában. Egy szimpla webshopnál egyikre sincs szükség általában, annál ha js-el oldod meg, akkor simán maradhat a kliensen mondjuk cookie-ban, localstorage-ben, stb., hogy miket pakolt be az illető a kosárba, amit még nem küldött el. Statisztikai célból persze erről is lehet infot adni a szervernek, de nem életbevágó ott tárolni a kosarakat.
121

Talán 1 éve foglalkoztam egy

smokey · 2017. Aug. 10. (Cs), 11.32
Talán 1 éve foglalkoztam egy ideig a hibakezeléssel, és még az sincs megoldva egységesen az elterjedt asztali böngészőkre. Fogalmam sincs, hogy a mobil böngészőknél, Linuxos böngészőknél mekkora lehet a káosz


Egyébként a kliens oldali keretrendszerek egyik feladata az is, hogy a böngészők közti különbségeket elfedjék. Elég jól megoldják az "if (MSIE)" jellegű problémákat.
122

A hibakezelésre sajnos nem

inf · 2017. Aug. 10. (Cs), 12.41
A hibakezelésre sajnos nem találtam semmi olyan standalone lib-et, ami egységesítette volna.
123

Mielőtt beljebb mennénk:

smokey · 2017. Aug. 10. (Cs), 14.34
Mielőtt beljebb mennénk: milyen hibakezelésről beszélünk?
124

https://blog.sentry.io/2016/0

MadBence · 2017. Aug. 10. (Cs), 16.25
https://blog.sentry.io/2016/01/04/client-javascript-reporting-window-onerror.html szerintem ez elég jól leírja a helyzetet. Amit tudok ajánlani a window.onerror helyett: kapd el a hibákat ott, ahol le akarod kezelni őket.
125

Csináltam egy V8 Error API

inf · 2017. Aug. 11. (P), 02.21
Csináltam egy V8 Error API polyfill-t annak idején, amivel többféle környezetben tudtam debuggolni. https://github.com/inf3rno/error-polyfill Kiegészítettem ezen kívül saját Error osztályokkal is https://github.com/inf3rno/e3. Még bőven lenne mit dolgozni rajta, csak annyira csináltam meg, amennyire nekem kellett Firefox-hoz. Az onerror már nem emlékszem, hogy benne van e, de terveztem hogy egységesítem azt a részét is. Sajnos nem minden böngészőben lehet elkérni magát az objektumot, úgy meg a stack sem elkérhető, ami nélkül nem a legjobb debuggolni.

Most hogy így szóba került, azt hiszem csinálom majd egy pár napig ezt a hibakezelős projektet. Úgyis át akartam írni ES6-os osztályokra, meg jó lenne, ha a nagyobb böngészőket tudná parsolni.
120

Kliensoldalon eljutottunk oda

smokey · 2017. Aug. 10. (Cs), 11.29
Kliensoldalon eljutottunk oda az évek során, hogy nem használunk semmit, shimek nélkül nyolc kilobájt a teljes kód. Minek ennél több, ha ezzel mindent el tudunk intézni, és ráhúzható a weboldalak és -szolgáltatások több mint kilencven százalékára?


Így végülis a szerver lehet több terhelést kap a HTML előállításától, mint az egyéb üzleti folyamatok támogatásától.

Az átlag weboldal/-szolgáltatás elképesztő mennyiségű javascript kóddal dolgozik, amelynek jórészt az a szerepe, hogy az állapotot menedzselje: például kirajzol egy lenyíló menüt kattintásra, lekér adatokat a szervertől, amivel itt-ott frissíti a tartalmat stb


Ezzel szemben a te megoldásod kitesz minden listát a kliensre, habár lehet nem is használod.

Ezt nehezíti, hogy (ha használnak) az objektumorientáltság miatt a fő állapot egyes alállapotai nem látnak egymásra, azaz a fő állapot nem rekonstruálható egy lépésből, hanem az egyes alállapotokat kezelő objektumok megfelelő paraméterekkel meghívott láncolataként.


Nehogymár kiderüljön, hogy az OOP is mehet a francba! Ha nehezen tudnak kommunikálni az egységek, akkor az rosszul van megtervezve. Te hogy rekonstruálsz egy lépésből? Sok funkcióval kiolvasod a $_SESSION ből a - tegyük fel - jól szervezett adatstruktúrát úgy, hogy belepakolod global változókba?
127

Így végülis a szerver lehet

Hidvégi Gábor · 2017. Aug. 14. (H), 10.07
Így végülis a szerver lehet több terhelést kap a HTML előállításától, mint az egyéb üzleti folyamatok támogatásától.
A nyolc kilobájtban természetesen benne van a HTML generálása is. Korábban írtam, hogy a buta kliensek esetében állítjuk csak elő szerveroldalon.

Ezzel szemben a te megoldásod kitesz minden listát a kliensre, habár lehet nem is használod.
Nem, csak azt a listát tesszük ki kliensre, amit a felhasználó meg akar nézni. Ha van egy oldal, amin látszik száz listbox, de a felhasználó egyikre sem kattint, egynek a listájával sem foglalkozunk.

Nehogymár kiderüljön, hogy az OOP is mehet a francba!
Pedig kliensoldalon inkább hátrány, mint előny. A React is funkcionális-szerű – nem véletlenül.
129

Pedig kliensoldalon inkább

smokey · 2017. Aug. 14. (H), 23.05
Pedig kliensoldalon inkább hátrány, mint előny. A React is funkcionális-szerű – nem véletlenül.


Ezzel a válaszoddal egy kiragadott mondatra reagálsz, az azt követő a lényeg:

Ha nehezen tudnak kommunikálni az egységek, akkor az rosszul van megtervezve


Mindegy, hogy objektum, komponens, bármi, a lényeg az egységbezáráson és az SRP-n van. Ha egy alkalmazás egyégei nem tudnak megfelelően kommunikálni, akkor az nincs jól kitalálva. A megfelelő szónak ebben az esetben elég sok jelentése lehet:
- Egy view szerepkörrel ellátott egység ne kérjen adatot semmilyen szerviztől
- Egy szerviz metódus ne használjon render funkciókat
- Bárhonnan ne érjek el bármit

Ha a két React komponensem nem tud kommunikálni, akkor felteszem a kérdést:
- Jó egyáltalán, ha ők kommunikálnak?
- Ha logikailag kommunikálhatnának, de nem tudnak, akkor az React hibája, vagy az enyém?

Az az overhead, amit a komponensek közti kommunikáció megvalósítása okoz, az normális keretek között az alkalmazás felépítésének a minőségét erősítheti. Nem varázslásról van szó, hanem rákényszerülsz arra, hogy a window.get('valami') alkalmazás szinten bármilyen formában bárhonnan elérhető metódusod helyett találd meg mindennek a helyét.

Ellenkező esetben a spagettit eheted csőtésztával, zöld paradicsommal és óriás, mócsingos húsgolyókkal. Jól laksz tőle, de nem finom...
131

Kommunikáció

Hidvégi Gábor · 2017. Aug. 15. (K), 07.48
Én épp azt kérdőjelezem meg, hogy a megjelenítésért felelős komponenseknek miért kell egymással kommunikálniuk? Miért kell nekik tudniuk, mi a többi elem állapota? Egy ceruza számára is irreleváns, hogy autót rajzol vagy házat. Ha papírdarabokból ragasztgatsz össze alakzatokat, a sárga kört sem érdekli, hogy napocska lesz vagy egy bicikli kereke.
132

Azért kell kommunikálniuk,

smokey · 2017. Aug. 15. (K), 09.05
Azért kell kommunikálniuk, mert egy komponens valamilyen tulajdonsága befolyásolhatja egy másik komponens viselkedését. És nem, nem akarom oldal újratöltéssel megoldani, mert nem célom.
133

Újratöltés

Hidvégi Gábor · 2017. Aug. 15. (K), 09.16
Mi köze van az oldal újratöltéséhez az egyes komponensek viselkedésének? Miért kéne az oldalt újratölteni, ha bármelyik is megváltozik?
136

Mit csinálsz abban az

smokey · 2017. Aug. 15. (K), 17.18
Mit csinálsz abban az esetben, ha egy legördülőben kiválasztott érték befolyásolja másik 3 legördülő listaelemeit úgy, hogy közben mérési eredményként elmented a felhasználói interakciót is?
138

?

Hidvégi Gábor · 2017. Aug. 15. (K), 20.33
Frissítem az érintett elemeket.
139

Hogyan?

smokey · 2017. Aug. 15. (K), 21.12
Hogyan?
140

Így

Hidvégi Gábor · 2017. Aug. 15. (K), 21.46
Amikor megváltozik az első listbox értéke, az állapotmenedzser összeállítja az érintett elemek listáját és a szükséges adatokat, ezt átadom a sablonkezelőnek, ami elkészíti a szükséges HTML-t, és a megfelelő helyre illeszti.
142

Tehát ugyanazt csinálod mint

smokey · 2017. Aug. 15. (K), 22.59
Tehát ugyanazt csinálod mint bárki más, ugyanazt valósítod meg. 10 év alatt sikerült úgy kipofozni a kódodat, hogy 8kb lett. Ennek az az oka, mert 10 éve nem volt Angular meg React, meg bootstrap meg stb. Nekiálltál szépen, és fáj kidobni.
143

Miként

Hidvégi Gábor · 2017. Aug. 16. (Sze), 07.59
Igen, azt csinálom, mint más: ezt írtam le párszor, hogy a végén ígyis-úgyis a DOM fát kell írni – csak nem mindegy, hogyan. Az én kódom nyolc kilobájt, a gépemen lévő React hétszáz, az Angular egy mega.
145

Igen, de szerintem 692kb difi

smokey · 2017. Aug. 16. (Sze), 09.41
Igen, de szerintem 692kb difi megér annyit, hogy nem szívtam vele 10 évet, plusz kaptam hozzá egy rakat más feature-t a DOM fa manipulálásán kívül. Azt értsd meg, amiről szintén volt szó párszor, hogy egy API vezérelt szolgáltatás backendjétől nem várhatok HTML kódot, sem oldalak közti navigációt, sem állapotkezelést, sem egyéb sok más dolgot.

Kezdettől fogva olyan problémára próbálod ráhúzni a Reactot és társait, amire neked nem jó, ennek lehet több oka:
- már csak azért sem akarod, hogy jó legyen
- nem éri meg lecserélni
- nem ismered eléggé

Fogalmam sincs mennyi időt szántál rá, de sanszos, hogy annyit, mint a Silexes topicra, amiből az derült ki, hogy egy semmire való callbackhell agyonhypolt featureökkel.

A helyzet az, hogy mindegyik rendszer több annál, mint amit néhány tutoriálból leszűrsz.

Neked nem jó sem az angular, sem a silex, sem keretrendszer. A válasz egyszerű, ne használd, nem a te problémádat oldja meg. Én ezt megértem, és én sem állnék neki baltával erdőt írtani, sőt lánfűrésszel fogpiszkálót aprítani sem. De ha egy erdőhöz felbérelek egy profi csapatot, akik jó pénzért kirtják, és felköbözik a fát, akkor én elégedett vagyok!

Ez az érem másik oldala!
147

Nettó

Hidvégi Gábor · 2017. Aug. 16. (Sze), 09.59
Látom, nem megy át a mondanivalóm, sajnálom. De most elővettem a 2009-es kódomat, ami az első változata volt a kódomnak, és nettó tizenöt kilobájt, ami a frontendet vezérli (és nem weboldalspecifikus), ezt sikerült nyolcra lecsökkenteni.

Azt értsd meg, amiről szintén volt szó párszor, hogy egy API vezérelt szolgáltatás backendjétől nem várhatok HTML kódot, sem oldalak közti navigációt, sem állapotkezelést, sem egyéb sok más dolgot.
Miért nem? És miért is jó ez? Valahol csak kell kezelni a kliensoldali állapot, amit persze megtehetsz a kliensen, ami definíció szerint undefined. Ezért minden platformra (böngésző, kereső, mobileszköz) le kell fejleszteni, míg például a mi esetünkben csak egyszer. Háromszoros kód, háromszoros hibázási lehetőség. Erről a főnököd is tud?

Igen, de szerintem 692kb difi megér annyit, hogy nem szívtam vele 10 évet, plusz kaptam hozzá egy rakat más feature-t a DOM fa manipulálásán kívül.
Mi az a rakat más dolog? Fel tudnád őket sorolni?
148

Szóval összegezve 10 éve

inf · 2017. Aug. 16. (Sze), 10.53
Szóval összegezve 10 éve írtál egy 15kb-os keretrendszert frontendre, ami már akkor jobb volt, mint a react vagy az angular ma, és ezt tovább fejlesztetted, úgy, hogy mára már csak 8kb. Esetleg megosztanád a közösséggel is mondjuk githubon, vagy ez szigorú üzleti titok, és ebben rejlik az üzleti sikered?

Pont azért használunk ezer shim-et, polyfill-t meg keretrendszereket kliensen, hogy csak egy kódot kelljen írni a három helyett. Nyilván ennek van annyi hátránya, hogy a gagyi samsungos felhasználóknak lassú az oldal, de ha van benne annyi pénz, akkor megéri mobilra optimalizálni nekik, ha meg nincs benne pénz, akkor így jártak, majd megnézik otthon asztali gépnél vagy egy komolyabb mobillal, ami elviszi a javascriptet.
149

Igen

Hidvégi Gábor · 2017. Aug. 16. (Sze), 11.09
Pontosan. Minden tudnivalót leírtam, ami alapján el lehet készíteni egy ugyanilyen rendszert, hogy megosszam-e a kódot, azon még gondolkodom. Mondjuk nyolc kilobájt nem olyan sok, ennyi erőfeszítésre bárki képes : )
150

Komolyan kérdezed, hogy miért

smokey · 2017. Aug. 16. (Sze), 12.13
Komolyan kérdezed, hogy miért nem várhatok HTML kódot a backendtől? Hát nem undefined a kliensed? Ha igen, akkor pláne ne küldéjl HTML-t, mert azt egy iOS appban cseszheted. Te backend oldalon feltételezed, hogy böngésző lesz a kliensed, az meg már nem undefined.! Egyébként szerintem nálad a kliens ugyanaz, mint a böngésző, ami azért nem igaz.

Nyílván a te rendszereddel krosszplatform vagyok. Na ne...

Amúgy, tessék, mazsolázz.
151

Komolyan

Hidvégi Gábor · 2017. Aug. 16. (Sze), 14.04
Látom, számodra ez a sarkos pontja a témának, úgyhogy kifejtem mégegyszer, hogyan működik nálunk a dolog.

A rendszerünk három rétegből áll:
1, megjelenítés
2, üzleti logika és állapot
3, adatforrások (API)

Ebből csak és kizárólag a megjelenítés van a kliensen, aminek két feladata az események elküldése a 2,-es rétegnek, valamint az onnan kapott adatok kirajzolása a képernyőre.

Alapvetően böngészőre épül az egész, és az, hogy az 1,-es réteg mit kap, függ attól, hogy mire képes. Ha buta a kliens, például kereső (google és társaik), akkor bizony HTML-t küldünk. Minden más esetben (böngészők) pedig adatokat, amelyek HTML-lé való transzformációját a kliensen végezzük el.

Mivel az állapotmenedzser csak a megváltozott komponenseket és azok tartalmát küldi el a kliensnek, a forgalom minimális. Mivel semmilyen állapot és üzleti logika nincs a kliensen, a kliensprogram végtelenül egyszerű, ezért olyan kicsi a mérete.

Tipikusan bizonyos speciális eseménykezelők beépítése miatt kell módosítani a klienst, ami meglehetősen ritka. Mivel minden üzleti logika a szerveren van, a tartalom és/vagy a dizájn lecserélése nem érinti a klienst.

Lehetőségünk van arra, hogy az adatforrásokat az API egyszerre szolgálja ki (a képernyőn megjelenő adatokat küldi ki), de akár arra is, hogy egyesével "csatornázzuk" be a kliensbe, így nagyon szépen lehet gyorstárazni.

A felépítésből adódik, hogy teljesen moduláris az egész, az állapotmenedzser és az adatforrások akár külön szerveren is lehetnek.

---

Nézzük az Angular featúráit:
  • Use modern web platform capabilities to deliver app-like experiences. High performance, offline, and zero-step installation.
    Mivel a rendszerünkben lehetőség van a 2,-es réteg, azaz az alkalmazáslogika és az állapotmenedzser kliensoldalon való elhelyezésére, sőt, az adatok is lehetnek ott, így ez pipa
  • Build native mobile apps with strategies from Ionic Framework, NativeScript, and React Native.
    Mivel a megjelenítő réteg végtelenül egyszerű, egy web view segítségével bármelyik mobil platformon tudjuk a rendszerünket használni, és csak annyit kell programozni, hogy az eszköz erőforrásait elérjük. Pipa
  • Create desktop-installed apps across Mac, Windows, and Linux
    Mint az előbb. Mondjuk mi arra törekszünk, hogy mindent a böngészőben oldjunk meg, ami eddig sikerült is. Pipa
  • Angular turns your templates into code that's highly optimized for today's JavaScript virtual machines, giving you all the benefits of hand-written code with the productivity of a framework.
    Nálunk ilyenre nincs szükség. Pipa
  • Serve the first view of your application on node.js, .NET, PHP, and other servers for near-instant rendering in just HTML and CSS. Also paves the way for sites that optimize for SEO.
    Bármilyen platformon működik a rendszerünk. Pipa
  • Angular apps load quickly with the new Component Router, which delivers automatic code-splitting so users only load code required to render the view they request.
    Abszolút moduláris a rendszerünk ebből a szempontból is, bármilyen kicsi részre szét tudjuk bontani a kódot. Pipa
  • Quickly create UI views with simple and powerful template syntax.
    Teljesen szabványos sablonokat használunk. Pipa
  • Command line tools: start building fast, add components and tests, then instantly deploy.
    Erre nincs szükség a rendszerünkben. Pipa
  • Get intelligent code completion, instant errors, and other feedback in popular editors and IDEs.
    Mivel szabványos sablonokat használunk, támogatott a kódgyártás. Pipa
  • Tesztelés: bármilyen megszokott tesztrendszerrel lehetséges. Pipa
  • Animáció: CSS és ha szükséges, JS. Pipa
  • Accessibility: HTML szabvány Pipa
159

Workaround létezik mindenre,

smokey · 2017. Aug. 17. (Cs), 13.09
Workaround létezik mindenre, ugyanúgy, ahogy támogatott megoldás is. Én akkor sem ölök időt olyanba, ami már készen van. Fent már említettem, ha az angular és társai nem megoldás a problémádra, akkor ne használd.
160

Innen szép a győzelem : )

Hidvégi Gábor · 2017. Aug. 17. (Cs), 13.19
Innen szép a győzelem : )
163

Nem azt mondtam, hogy tényleg

smokey · 2017. Aug. 17. (Cs), 13.33
Nem azt mondtam, hogy tényleg szar :D.
134

Kíváncsi vagyok mikor adod

inf · 2017. Aug. 15. (K), 11.12
Kíváncsi vagyok mikor adod fel. :D
135

Negatív drukker, fuj!

Pepita · 2017. Aug. 15. (K), 14.59
Én annak szurkolok, hogy ne adja fel, talán érhet el eredményt.. :)
Szóval SOS-ben javíts a hozzáállásodon, másképp azt fogom hinni, hogy "nem tiszteled eléggé A Családot"! :-D (A Keresztapa c. film)
137

Elnézést keresztapa. :D

inf · 2017. Aug. 15. (K), 17.25
Elnézést keresztapa. :D
126

Folytatás

Hidvégi Gábor · 2017. Aug. 14. (H), 10.03
Az előzőt neked írtam, csak előbb egy nagyobb képet kezdtem el vázolni.

A weboldal és a webes alkalmazás között a különbség, hogy az utóbbiban a tartalmat dinamikusan állítjuk elő, de a végeredmény egy-egy diszkrét pillanatban ugyanaz, egy statikus HTML kód. A háttérben (legyen akár kliens-, akár szerveroldal) van pár nyers adatforrás (pl. adatbázis), valamint az aktuális oldal állapota, ami jellemzően pártíz változó.

Az alkalmazáslogika azt mondja meg, hogy ezeknek a változóknak mi az értéke, és amikor megváltoznak, akkor ez a felhasználó képernyőjén fog tükröződni. Már bocsánat, de pártíz változó kezeléséhez minek keretrendszer?

Nálunk a kliens és a szerver között van egy interfész, egy json vagy xml adatstruktúra, ami tíz éve nagyjából változatlan (kikerült belőle pár redundáns apróság). Közben mind a backend, mind pedig a frontend le lett cserélve (méretükben jelentősen csökkentek, a sebességük pedig nőtt, szerveroldalon két-háromszorosára, mert az adatbázisokon nem nagyon lehet segíteni, kliensoldalon húsz-harmincszorosára).

Ez innováció. A kezünket nem köti semmi, csak saját magunk. A jól megválasztott sablonozás a lényeg: mi döntjük el, hogy kvázi natív sebességgel dolgozunk, de némileg több munkával, vagy pedig valamivel lassabb megjelenítéssel (ami persze észrevehetetlen), de kevés munkával. Ezekre egy általános tudással bárki rájöhet, míg UI keretrendszerek mellett csak nagyon nehezen, hisz abból sok jó nem jöhet ki, ha mondjuk elkezdesz dolgozni React-tel, és ha valahol lassú, akkor kókányolsz bele valamit.

---

A PHP-ben vannak valóban furcsaságok és inkonzisztenciák, de nem számottevő.
128

Diszkrét pillanat :)

T.G · 2017. Aug. 14. (H), 16.53
A weboldal és a webes alkalmazás között a különbség, hogy az utóbbiban a tartalmat dinamikusan állítjuk elő, de a végeredmény egy-egy diszkrét pillanatban ugyanaz, egy statikus HTML kód.


Ez most egy definíció szeretne lenne, vagy csak valami életérzés? :)

Az ezekkel a mondatokkal a baj, hogy nehéz hozzá csatlakozni. Az igazságtartalmáról értelmetlen diskurálni, sőt, most nem is akarom megkérdőjelezni, ám mégis nehéz lenne azt mondani, hogy sikerült a különbség lényegét megfogni. Fizikában jártas kollégák biztos helyreteszik majd a hasonlatomat, de nekem rögtön az jutott eszembe, hogy amikor a csiga és a repülőgép sebességét egy diszkrét pillanatban nézzük, akkor azt tapasztaljuk, hogy egy helyben állnak. Ám sejtjük, hogy mégiscsak gyorsabb az egyik a másiknál.
130

Diszkrét

Hidvégi Gábor · 2017. Aug. 15. (K), 07.37
Pontosan mi az, amit nem értesz? Nem az a lényeg, hogy melyik gyorsabb, hanem hogy a műveletek végén statikus lesz a DOM fa.
141

Szóval a framework rossz,

BlaZe · 2017. Aug. 15. (K), 21.57
Szóval a framework rossz, ezért saját frameworköt használtok... Ami egy framework. Én továbbra is ellentmondást érzek :)

Továbbá kiemeled a layerek közötti interface fontosságát (xml, json alapú protocol a layerek között), mint a flexibilitás kulcsát (és milyen igazad van). Következő mondatban meg írod, hogy minek pár változó miatt framework (amit te magad is írtál és használtál). Nem a framework a lényeg, hanem a layerek közötti szeparáció. A framework pont ezt adja. Ha ez nem jelenik meg az architektúrádban, akkor ezeket a rétegeket összetaknyoltad, aminek fizeted a költségét rendszeresen (max nem veszed észre). Mert azt ugye nem gondoljuk, hogy front-enden nincsenek alkalmazás rétegek...?

A PHP-ben vannak valóban furcsaságok és inkonzisztenciák, de nem számottevő
A PHP egy önmagával semmilyen irányban nem kompatibilis ötlethalom, ami verzióróról verzióra kisebb-nagyobb kötelező pénzkidobásra kényszeríti a használóit. Pont ezért nem állnak érte sorban enterprise környezetben. De már nem követem eléggé közelről, lehet javul valamit PHP7 után.
144

Keretrendszer

Hidvégi Gábor · 2017. Aug. 16. (Sze), 09.35
Ha a te logikádat vesszük alapul, akkor minden keretrendszer, mert ha már mondjuk egy bizonyos feladatnál (pl. adatok kérése a szerverről) mindig ugyanazokat a lépéseket tesszük meg (pl. adatok ellenőrzése, jogosultságok ellenőrzése, üzleti logik), akkor van egy keret, ami szerint dolgozunk.

Ha így vesszük, igen, mi is keretrendszert használunk, csak nem egy általánosat, hanem teljesen sajátot. Ebben minden úgy működik, ahogy nekünk kell, és nincs benne semmi fölösleges.

Az általános keretrendszerek ezzel szemben olyan megoldásokat használnak, amelyek általánosak, és a sok absztrakció miatt sok olyan kód is van benne, ami az adott szituációban szükségtelen. Ez növeli a karbantartás költségeit, mind a keretrendszer fejlesztői, mind pedig a használói körében. Tessék, ebben az esetben meg itt folyik el a pénz.

Mert azt ugye nem gondoljuk, hogy front-enden nincsenek alkalmazás rétegek...?
Ezt kifejthetnéd bővebben.

A PHP egy önmagával semmilyen irányban nem kompatibilis ötlethalom, ami verzióróról verzióra kisebb-nagyobb kötelező pénzkidobásra kényszeríti a használóit. Pont ezért nem állnak érte sorban enterprise környezetben.
A PHP sok tekintetben rugalmasabb és könnyebben használható, mint a Java, ezért nem állnak sorban ez utóbbiért nem enterprise környezetben. Azért, mert valami nagyvállalati, szükségszerűen jobb?
152

Hát valami ilyesmi a

BlaZe · 2017. Aug. 16. (Sze), 20.06
Hát valami ilyesmi a keretrendszer definíciója, úgyhogy én ezt értem alatta.

A karbantartásba nem akarok belemenni, nagyon mást gondolunk róla :) (Nem is értem egy open-source framework karbantartása miért lenne a project költsége)

Front-end rétegek: valami felteszem kommunikál a backenddel, valami transzformál pl json->belső modell->DOM között, megjelenít, validál stb.

Az enterprise software nem a multi szinonimája. A lényeg az volt, hogy a PHP nem backward compatible. Azért hoztam csak fel, mert mondtad, hogy nincs vele sok gond. Hát ha létezik gyengéje a PHP-nak, ez a tulajdonsága az első sorban szerepel.
153

Költségek

Hidvégi Gábor · 2017. Aug. 17. (Cs), 07.22
Egy nyílt forrású keretrendszer karbantartása azért a projekt költsége, mert ha mondjuk kiderülnek a hibái, akkor választhatsz, hogy 1, javítod magad, 2, megvárod, hogy megjavítsák, 3, lecseréled.

Nekünk anno az Ext-tel volt rengeteg problémánk, a listboxaik, azon felül, hogy nagyon lassúak voltak, tele voltak hibával (hat vagy nyolcszoros volt öröklődési lánc), és rengeteg idő ment el a hegesztgetéssel. Végül megelégeltem, és kétszáz sorból újraírtam, ami mára feleennyire csökkent.

Zárójelben megjegyzem, kliens-szerver alkalmazásnál nem sok értelme van bármit is kliensoldalon validálni.
154

Egy nyílt forrású

BlaZe · 2017. Aug. 17. (Cs), 08.19
Egy nyílt forrású keretrendszer karbantartása azért a projekt költsége, mert ha mondjuk kiderülnek a hibái, akkor választhatsz, hogy 1, javítod magad, 2, megvárod, hogy megjavítsák, 3, lecseréled.
Vagy a következő verzióban már javították, mert a sokezer felhasználó közül más is jelentette. Egy kezemen meg tudom számolni hányszor voltam ebben a helyzetben eddigi karrierem során. Ezzel szemben sajátnál biztos a projectnek kell a javításra áldozni.

Zárójelben megjegyzem, kliens-szerver alkalmazásnál nem sok értelme van bármit is kliensoldalon validálni.
Ezt gondold át még egyszer...
155

Nyílt forrás

Hidvégi Gábor · 2017. Aug. 17. (Cs), 09.25
Akkor neked szerencséd volt, nálunk sok probléma adódott ezekből, ráadásul az új verziókban bár javítottak bizonyos hibákat, de cserébe kaptunk újakat.

Úgy látszik, nyílt forrás és nyílt forrás között van különbség.

Ezt gondold át még egyszer...
Átgondoltam. Mivel a kliens megbízhatatlan, az ellenőrzést szerveroldalon is el kell végezni, azaz dupla munka; csak formai ellenőrzésekre lehet használni; ha újabb ellenőrzéseket kell betenni, a klienst újra kell tölteni. Ezzel szemben, ha minden ellenőrzést szerveroldalon végzünk, akkor egyszerre többnek az eredményét is megjeleníthetjük, a kliens megváltoztatása nélkül adhatunk és vehetünk el az ellenőrzésekből, valamint kevesebbet kell dolgozni.
158

Mint az már szerintem

MadBence · 2017. Aug. 17. (Cs), 12.59
Mint az már szerintem rengetegszer elhangzott, a kliens-oldali validáció kényelmi (és nem valami biztonsági) funkciót lát el, így teljesen felesleges arról beszélni, hogy mennyire megbízhatatlan. Az, hogy az ellenőrzés rögtön megtörténik, az alkalmazás UX-én fog javítani. Inkább erről kéne vitatkozni, nem a validáció létjogosultságán...

Az pedig, hogy milyen validációkat (és mennyit) végzel el kliens-oldalon, implementációs részlet, és nem eredendő velejárója a kliensoldali ellenőrzéseknek, így számomra ez sem érv a js validáció mellőzésére.
161

Élmény volt

Hidvégi Gábor · 2017. Aug. 17. (Cs), 13.24
Akár egymilliószor is el lehet ismételni valamit, attól nem válik valós érvvé.

Ötvenkétmillió mérés alapján az átlagos emberi reakcióidő 282 ezredmásodperc, azaz majdnem egyharmad másodperc. Ez azt jelenti, hogy felesleges ez alá menni, mert az emberek túlnyomó többsége nem fog tudni gyorsabban reagálni. Nem tudják megmondani, hogy valami azonnal, vagy pedig 0,3 másodperc alatt jelent meg. Tehát az azonnali ellenőrzés nem javít a felhasználói élményen, ha a válaszidő 282 ezredmásodperc alatt van.

Ezzel szemben a legtöbb operációs rendszerbeli animáció fél másodperc hosszú, ráadásul a műveleteket csak a befejezése után indítják el.

Ennyit a felhasználói élményről.
164

Azt remélem tudod, hogy a

Endyl · 2017. Aug. 17. (Cs), 13.55
Azt remélem tudod, hogy a reakcióidő nem arról szól, hogy mennyi idő alatt észlelünk valamit, hanem hogy amit észleltünk, azt mennyi idő alatt dolgozzuk fel és reagálunk rá.

Ha mindenre ráérnénk 282 ezredmásodpercenként "reagálni", akkor 3-4 fps-sel mennének a filmek, játékok, stb., ami azért elég abszurd lenne. Igazából a különbség még 30 (33 ezredmásoperc) és 60 (16-17 ezredmásodperc) fps között is bőven észlelhető.

Ez azt jelenti, hogy felesleges ez alá menni, mert az emberek túlnyomó többsége nem fog tudni gyorsabban reagálni. Nem tudják megmondani, hogy valami azonnal, vagy pedig 0,3 másodperc alatt jelent meg. Tehát az azonnali ellenőrzés nem javít a felhasználói élményen, ha a válaszidő 282 ezredmásodperc alatt van.

Akkor szerinted ezen a kis "játékon" nem lehet eldönteni, hogy melyik szám villan fel utoljára?
166

Igaz

Hidvégi Gábor · 2017. Aug. 17. (Cs), 14.02
Valóban. Egy tanulmány szerint viszont:
  • A response time of 100ms is perceived as instantaneous.
  • Response times of 1 second or less are fast enough for users to feel they are interacting freely with the information.
Tehát egytized másodperc alatt az ember nem érzékeli a különbséget, és ha egy másodpercen belül van válasz, az még abszolút elfogadható.
167

A szerver oldali validáció

MadBence · 2017. Aug. 17. (Cs), 14.22
A szerver oldali validáció pedig akkor történik meg, ha elküldöd a formot (ami meg nem egy másodpercen belül történik meg, hiszen lehet, hogy még egy rakás egyéb mezőt is ki kell töltened)
169

Ezt azért lehet jobban is

Hidvégi Gábor · 2017. Aug. 17. (Cs), 14.42
Amikor valaki elhagy egy mezőt, akkor annak a tartalmát nem lehet mindjárt elküldeni a szerverre, és ott validálni, és ha szükséges, jelezni, ha gond van?
173

A kliens oldali (formai)

inf · 2017. Aug. 17. (Cs), 15.33
A kliens oldali (formai) validációt arra találták ki elsősorban, hogy csökkentse a szerver terhelését és gyorsítsa a felhasználói élményt. Mivel a HTML5-nek része lett már évekkel ezelőtt, ezért elég nagy balgaság azt állítani, hogy nincs semmi értelme, és bad practice. Természetesen lehet js-el is megcsináltatni ugyanazt, ha valaki json küldözgetésében gondolkozik, és nem akar HTML-t generálni a szerveren, ízlés meg persze projekt kérdése.
175

Értelem

Hidvégi Gábor · 2017. Aug. 17. (Cs), 16.02
Azért, mert valami bekerül a HTML5-be, már automatikusan van értelme és best practice-szé válik?

A terhelést elhanyagolható mértékben csökkenti, de szerveroldalon ugyanúgy kell ellenőrizni, ráadásul korlátozott a használata, többek között a css lehetőségei miatt is.
179

Általában kipróbált

inf · 2017. Aug. 17. (Cs), 17.59
Általában kipróbált technológiák szoktak bekerülni a HTML-be, nem véletlenül tart ott a szabvány, ahol és van szükség shimekre. Szóval bár nem automatikusan válik azzá, de azért erős a korreláció. A HTML-es változat egyébként valóban korlátozott leginkább a hibaüzenetek terén. Ha annál jobbat akarsz, akkor érdemes js-el csinálni vagy azzal kiegészíteni.

Az, hogy mi elhanyagolható erősen kontextus függő. Sűrűn látogatott oldalaknál számít az 1% is.
209

Értelem

Hidvégi Gábor · 2017. Aug. 19. (Szo), 11.10
Szerintem meg sokszor az kerül be a HTML-be, ami épp divat, és nem feltétlenül van bármiféle haszna. Cserébe rengeteg időt elvesz mindenkitől, mert nem a lényegre koncentrálnak.

A legjobb példa erre a data-* attribútumok bevezetése, amelyeknek minimum tízszer lassabb az elérése a hagyományos változókénál (hisz egy DOM fában kell keresni, ami nem a gyorsaságáról híres, nem véletlenül vezették be a nagy keretrendszerek a Shadow DOM-ot).

De ugyanígy nem segített semmit sem a "szemantikus" elemek (<article>, <footer> és társaik) bevezetése, hisz sem a felhasználó, sem pedig a keresők nem profitálnak belőle.
210

Jogod van a véleményedhez.

inf · 2017. Aug. 19. (Szo), 11.56
Jogod van a véleményedhez.
176

új érted ajaxozni, majd

MadBence · 2017. Aug. 17. (Cs), 16.40
új érted ajaxozni, majd megjeleníteni az eredményt? de lehet, és nálam ez is a kliens-oldali validációhoz tartozik (ezek szerintem más-más fogalmakban gondolkoztunk). ha viszont egy mező hosszúságának ellenőrzéséhez is ajaxot használsz (csak mert hogy egy helyen legyen a validáció), arra maximum azt tudom mondani, hogy nagyon nem hatékony, de alapvetően más gondom nics vele.
168

Tehát egytized másodperc

Endyl · 2017. Aug. 17. (Cs), 14.29
Tehát egytized másodperc alatt az ember nem érzékeli a különbséget

Én szerintem 90+ százalékban el tudom dönteni, hogy melyik szám villant fel előbb a 16 és a 33 ezredmásodperces közül. Az igaz, hogy mindkettő egészen azonnalinak érződik, de ez azért függ a kontextustól is.

Azért azt se felejtsd el idézni, hogy az említett tanulmány 1968-as, azóta pedig szerintem azért változtak az emberek elvárásai a (vizuális) visszajelzésekkel kapcsolatban. Valamint később írják a cikkben, hogy 13 ms-től kezdődően már észlelhető a különbség, és 75-100 ms-nél már becslés alapján is kell reagálunk, nem csak a vizuális infó alapján, mert az már túl lassú visszajelzés (nem tudom, ők honnan idézik az utóbbi részét).

Nem mondom, hogy egy űrlapnak kötelező 60 fps-sel renderelnie a hibákat, stb., de hogy reszponzívabbnak és folyamatosabbnak érződik az interakció, mint egy 30 fps-es renderelésű, egy 10 vagy annál kevesebb fps-es renderelésűnél meg pláne, az biztos. Azt döntse el (tesztelje le) mindenki magának, hogy a célcsoportja milyen válaszidőt vár el az alkalmazásától, és optimalizálja az alapján :)
170

Hibaüzenet per szekundum

Hidvégi Gábor · 2017. Aug. 17. (Cs), 14.47
Ha egy másodperc alatt felvillantok egy helyen tíz különböző hibaüzenetet – hogy ne mondjak sokat –, akkor szerinted abból mennyit fogsz felfogni?

Azért azt se felejtsd el idézni, hogy az említett tanulmány 1968-as, azóta pedig szerintem azért változtak az emberek elvárásai a (vizuális) visszajelzésekkel kapcsolatban.
Az egyetemen tanultuk, hogy az emberi agy kétszázötvenezer éve nem változott. Mint ahogy az információfeldolgozó képességünk sem.
177

Ha egy másodperc alatt

Endyl · 2017. Aug. 17. (Cs), 16.55
Ha egy másodperc alatt felvillantok egy helyen tíz különböző hibaüzenetet – hogy ne mondjak sokat –, akkor szerinted abból mennyit fogsz felfogni?

Azt sehol sem állítottam, hogy gyorsabban fogom feldolgozni az űrlapot vagy több hibaüzenetet tudok értelmezni, ha 100 ms helyett 13 ms alatt jelenik meg a hibaüzenet (mivel a reakcióidő magasabb ezeknél). Annyi a mondandóm, hogy minél közelebb van a program visszajelzési ideje a 13 ms-hez, annál reszponzívabbnak fog érződni, mert ilyen különbségeket még tud észlelni az emberek egy adott része.

Az más kérdés, hogy egy adott alkalmazásnál milyen válaszidőre van szükség. Ez célközönség és alkalmazásfüggő. A lényeg, hogy bármilyen visszajelzésnél változhat a vizuális élmény (UX) az eltelt idő függvényében egészen 13 ms-ig. (Tehát ne írjunk olyat a kezdők, vagy lustábbak kedvéért (akik még nem néztek utána ilyeneknek, vagy nem akarnak), hogy 0.3 másodperc vagy akár 0.1 másodperc alatti válaszidők között már nem érezhető a különbség. Nyilván nem az űrlapokhoz tartozik, de ha már előkerült a reakcióidő, akkor szerintem "gamerek" hada igazolná, hogy ég és föld különbséggel lehet játszani attól függően, hogy a játék 30 vagy 60 fps-es válaszidővel reagál.)

Az egyetemen tanultuk, hogy az emberi agy kétszázötvenezer éve nem változott. Mint ahogy az információfeldolgozó képességünk sem.

Ugye nem azt akarod mondani, hogy az emberre nem hatnak a különböző evolúciós faktorok (vagy akár csak az agyra)?
Ugyanakkor ismét nem állítottam, hogy '68-óta lényegében változott volna az emberi agy szerkezete, és ezért nagyságrendekkel több információt tudnánk ma feldolgozni, mint akkor. Annyit írtam, hogy az elvárásaink változtak meg a technológiával kapcsolatban. Ugyanúgy, mint ahogy régebben örültünk, ha volt betárcsázós internet, ma meg sokaknak eszükbe jut másik oldal keresése, ha néhány másodpercnél lassabban töltődik be egy oldal.
181

Reakció

Hidvégi Gábor · 2017. Aug. 17. (Cs), 18.09
Viszont itt nem játékokról van szó, hanem alkalmazásról. Ráadásul játékoknál vagy filmeknél tizenhárom ezredmásodpercenként nem újabbnál újabb dolgok jelennek meg, hanem egy adott dolog mozog egyik helyről a másikra, azaz már volt előtte tudásod róla.

Harmadszor, hiába lesz piszkosul reszponzív pl. az email formai validációja, ha ahhoz úgyis várni kell, hogy megtudd, szerepel-e már az adatbázisban, ilyen névvel lehet-e regisztrálni, szerepel-e az adott érték bizonyos határok között.

Negyedszer, dolgozhatsz kétszer, hisz szerveroldalon úgyis mindent le kell ellenőrizni, utána kliensoldalon meg kell jeleníteni a hibaüzenetet, és nem elég a required-re vagy a patternre megírni a css selectort, kell még class-t is készíteni.

Ötödször, ha valamilyen oknál fogva más platformon is el kell készíteni az alkalmazást, akkor ott is programozhatod le a kliensoldali ellenőrzést.

Ugye nem azt akarod mondani, hogy az emberre nem hatnak a különböző evolúciós faktorok (vagy akár csak az agyra)?
Hatnak, csak itt évszázezrekben kell számolni, internet meg van huszonöt éve.

Lehet, hogy az igényed nőtt a több információra, de biológiailag nem változtál semmit. Egyébként meg szerinted véletlenül van annyi túlmozgásos, hiperaktív gyerek, akiket nem lehet lekötni pár percnél tovább semmivel? Pont az információtúladagolás az egyik oka ennek.
184

Felesleges

Endyl · 2017. Aug. 17. (Cs), 19.06
Ahogy említettem, nem arról írok, hogy hol kell validálni. Azt sem írtam, hogy az űrlapok és a játékok egy kalap alá tartoznak. Annyit írtam, hogy ha körülményektől (alkalmazás típusa, célközönség) függően szükséges, akkor egészen 13 ms-ig érdemes lehet levinni a visszajelzés/frissítés idejét. Nyilván nem muszáj mindenhol idáig menni, de ahol elmennek, az észrevehető (nem biztos, hogy üzletileg hasznos, de észrevehető).

Hatnak, csak itt évszázezrekben kell számolni, internet meg van huszonöt éve.

Ez lényegtelen ebből szempontból, valamint biológusok sem vagyunk, úgyhogy kár ezt feszegetni; ugyanakkor például a laktóz tolerancia az állatartással kézenfogva jelent meg az embereknél kb. tízezer éve (tudom, az még mindig nagyságrendekkel több a huszonpár évnél, de ez az elvárások szempontjából irreleváns).

Lehet, hogy az igényed nőtt a több információra, de biológiailag nem változtál semmit.

Ki beszélt itt több információról? A visszajelzés sebességéről beszélünk; hogy gyorsabbnak érzünk-e egy 30 ms-es válaszidőt egy 100 ms-esnél.

Egyébként meg szerinted véletlenül van annyi túlmozgásos, hiperaktív gyerek, akiket nem lehet lekötni pár percnél tovább semmivel? Pont az információtúladagolás az egyik oka ennek.

Nem vagyok a téma szakértője, így erről kár nyilatkoznom, és nagyon offtopic is. (A véleményem mindenesetre az, hogy ha létezik ez a trend, akkor az "információtúladagolás" a legkevésbé lényegi okozója lehet ennek, ha egyáltalán okozza és nem csak korrelál vele).
186

Sebesség

Hidvégi Gábor · 2017. Aug. 17. (Cs), 19.26
Nyilván vannak olyan szolgáltatások, ahol fontos a minél gyorsabb válaszidő, de egy átlag webes alkalmazásnál vagy weboldalnál nem az. Egy regisztráció során egy felhasználónak nagyjából édesmindegy, hogy a mező elhagyása után a háttérben elindított kérés hánytized másodperc múlva jeleníti meg a hibaüzenetet, mert még az egérrel fogja a következő cellát keresni.

Alá tudod valamivel támasztani, hogy nőtt az igény a visszajelzés gyorsaságára? Egyébként folyamatosan gyorsulnak a hardverek és az internet elérési sebessége, szóval ez a rész hardverből megvan.
189

Én egyetértek az első

inf · 2017. Aug. 17. (Cs), 20.57
Én egyetértek az első felével, egy webes űrlapnál belefér az 1sec rendereléssel együtt, talán még egy picivel több is. Én egyébként elhiszem, hogy nőtt az igény a sebességre, de általánosságok helyett jobb lenne valami statisztikát látni ezzel kapcsolatban, hogy mégis mennyivel, és hogy mint fejlesztő egyáltalán kell e reagálnunk rá vagy sem. Egy másik észrevétel ezzel kapcsolatban, hogy nem biztos, hogy minden felhasználói csoportban így van, hacsak megnézem szüleim korosztályát, sokszor keresik a betűket a billentyűzeten vagy hogy mire kell kattintani a képernyőn, szóval nekik van idejük rá. A mi korosztályunknál meg a fiatalabbaknál már más lehet a helyzet.
194

Lassul

Hidvégi Gábor · 2017. Aug. 18. (P), 07.55
Ahogy idősödik az ember, lassul az agya, mert, ugye, húsz éves korunktól minden nap átlag kétszázezer-egymillió agysejtünk pusztul el. Az ötven felettiek számára például kifejezetten zavaróak az animációk, mert elvonják a figyelmet, és akár újra kell gondolniuk, mi is volt az, amiért elkezdték csinálni.

A mai huszonévesek is lesznek egyszer ötvenesek.
192

Ha az említett '68-as papír

Endyl · 2017. Aug. 17. (Cs), 23.11
Ha az említett '68-as papír állítása az, hogy egy másodperc alatti válaszidő megfelelően lekötő volt az emberek számára, ugyanakkor az Amazontól és a Goggle-től előkerülő kimutatások meg arra utalnak, hogy 100 ms-es válaszidő növekedés jelentős bevételi/használati esést jelent, akkor feltételezem, hogy azóta kevésbé türelmesek az emberek (vagy ugyanannyira türelmesek, csak más volt a megszokás a válaszidő tekintetében).
193

Megegyezik

Hidvégi Gábor · 2017. Aug. 18. (P), 07.52
Adatbetöltésnél valami minél gyorsabb, annál jobb, ez tény. Ismerem a Google és az Amazon kimutatásait, és nem vagyok meggyőződve arról, hogy azok nem marketinganyagok.

Ezzel szemben vannak más faktorok is, amik alapján döntünk, amikor egy webes szolgáltatást használunk.

Az emberek akkor fogják n szolgáltatás közül a leggyorsabbat választani, ha azok minden egyéb másban megegyeznek. Ha van két webes áruház, amelyikben a termékek árai megegyeznek, a kiszállítás díja megegyezik, akkor a vevő gondolkodás nélkül a gyorsabbikhoz fog menni.

De ha az egyik száz forinttal olcsóbb, akkor az egyszeri magyar állampolgár onnan fog vásárolni, hiába jóval lassabb.

Az ismerőseim egy részét Facebook Messengeren keresztül tudom elérni. Lemértem, a kezdőlapon a Messenger linkre kattintva tíz másodperc alatt töltődött be az utolsó beszélgetés tartalma (közben mind a négy magot körülbelül 50%-ban használta). Mivel nincs választási lehetőségem, ezt fogom használni. Hiába gyorsabb a Skype, ha Facebookon van fenn, akinek üzenni szeretnék – így nincs választási lehetőségem.

Ugyancsak ide tartozik, hogy ha van két hasonló szolgáltatás, amiből az egyiket ismerem, a másikat nem, akkor azt fogom választani, amelyiket ismerem, mert ott tudom, mire számíthatok, míg a másikat meg kell tanulni.

Tehát az UX szép dolog, csak kissé összetettebb annál, hogy a gyorsabb a jobb.
198

Tehát abban egyetértünk, hogy

Endyl · 2017. Aug. 18. (P), 10.45
Tehát abban egyetértünk, hogy ha más különbség nincs, akkor jobb a gyorsabb. Én semmi mással nem vitáztam itt lényegében, csak hogy meddig észrevehető, hogy valami gyorsabb.
188

Hatnak, csak itt

inf · 2017. Aug. 17. (Cs), 20.50
Hatnak, csak itt évszázezrekben kell számolni, internet meg van huszonöt éve.


Ha erős szelekciós nyomás lenne, mondjuk megtizedelődne az emberiség emiatt, akkor 100 év elég lenne, hogy lemenjen az emberek reakcióideje. Mivel nincs, max nagyon enyhe, így nem igazán fog változni semmi ezen a téren valszeg 100k év múlva sem. Nyilván attól függ, hogy merre fejlődik tovább a technológia, és mennyire lesz nehéz az átlag embernek követni.
172

Ezt alá tudom támasztani az

inf · 2017. Aug. 17. (Cs), 15.26
Ezt alá tudom támasztani az online játékos tapasztalatommal. Elég gyorsan lehet reagálni félig feldolgozott vizuális ingerre. Egyébként a hang is előbb jön valamivel, google szerint 170ms a hang feldolgozás és 250ms a kép feldolgozás. Én a kettő között szoktam reagálni, ha komolyan veszem a játékot, és mire megjelenik a kép, addigra már kiosztok egy fejest jó esetben. Online játékoknál 50ms-es ping még jó, 100-as már erősen érezhető, de még a játszható kategória, 200ms játszhatatlan, 300-nál meg kirúgnak, mert eltolódik a hitboxod és nem találnak el.
171

Nem kéne ennyire pongyolán

inf · 2017. Aug. 17. (Cs), 15.08
Nem kéne ennyire pongyolán fogalmazni, különben marhaság jön ki. Maradjunk inkább annyiban, hogy az embereknél még nem üti meg az ingerküszöböt, ha 0.5-1 másodperc alatt töltődik be egy oldal, de ha már 2 másodperc, akkor azt már észreveszik, 5 másodpercnél meg elhagyják az oldalt. Gondolom ennyi a lényeg.

A reakcióidővel szerintem ne foglalkozz, mert gőzöd sincs róla.
178

A reakcióidővel szerintem ne

Hidvégi Gábor · 2017. Aug. 17. (Cs), 17.56
A reakcióidővel szerintem ne foglalkozz, mert gőzöd sincs róla.
A fórumon te vagy az egyedüli, aki alpári, kicsit visszafoghatnád magad!
180

Miért tenném?

inf · 2017. Aug. 17. (Cs), 18.00
Miért tenném?
182

Minta

Hidvégi Gábor · 2017. Aug. 17. (Cs), 18.13
Egyrészt azért, mert némelyek ebből azt gondolhatják, hogy itt ez a sztenderd, másrészt meg moderátor vagy. Az emberek azért választanak maguknak elöljárókat, mert általában azok valamiben jobbak az átlagnál, így jobban figyelnek rájuk. Magyarul felelősséged van.
183

Asszem egyszerre dolgozunk

BlaZe · 2017. Aug. 17. (Cs), 18.34
Asszem egyszerre dolgozunk ugyanannál a cégnél, amikor egy karácsonyi játék végére egy játék újrakezdésre kliens oldali gomb lett betéve egy server request helyett. A szerver terhelése a töredékére esett. De lehet már keverek valamit, nem is emlékszem részleteiben. A lényeg, hogy ha a kliens oldalon teszel meg valamit, amit ott megtehetsz, azzal igen jelentős terhelést tudsz levenni a szerverről, hiszen csak formailag helyes inputtal kell dolgozzon. Ettől még persze formai validációt kell végezzen. De azon nem, amit a kliens előszűrt, és nem küldte el. Emellett egy szerveroldali request kiszolgálása, feldolgozása jellemzően nincs meg 100ms alatt. Én pl 50%-ban kb 70ms pingre vagyok a saját BIX-ben lévő szerveremtől, de vannak bőven 100ms feletti értékek is. És ez csak ping. Se adat, se feldolgozás egy gyors, nem túlterhelt vason. Ergo értékelem, ha nem kell elmennem odáig. Egy nem budapesti cloud szolgáltató esetében meg ez tartok tőle, hogy még jelentősebb lehet...

Ezek miatt én úgy gondolom, hogy komoly tévedésben vagy mind UX, mind erőforráskihasználtság tekintetében.
185

Tévedés

Hidvégi Gábor · 2017. Aug. 17. (Cs), 19.12
Mi meg VPN-en keresztül kapcsolódunk a céges, UPC-nél lévú ADSL-re, és átlag 13ms pingeket mérünk. Lehet, hogy nem jó szolgáltatót választottál.

A kliens megbízhatatlan, erről szól ez az egész fórumtéma.

A szerver pedig azért van, hogy dolgozzon. Nem tudom, miért akarsz mindenáron előre optimalizálni.

A szál korábbi ágában kifejtettem, hogy azért az elhanyagolható reszponzivitásért elég sok munkával kell fizetni. Így nem gondolom, hogy én lennék tévedésben UX vagy erőforrások kihasználtságával kapcsolatban.
187

Kevertem egy másik RTT-al.

BlaZe · 2017. Aug. 17. (Cs), 20.14
Kevertem egy másik RTT-al. Jobb azért a helyzet. Ettől még az igaz, hogy egy tőled fizikailag távol lévő gép ennek a többszöröse.

A kliens megbízhatatlan, erről szól ez az egész fórumtéma.
Nem, teljesen másról beszélünk :) Senki nem mondta, hogy kiens oldali validációban meg kell bízni.

A szerver pedig azért van, hogy dolgozzon. Nem tudom, miért akarsz mindenáron előre optimalizálni.
Hát...

A szál korábbi ágában kifejtettem, hogy azért az elhanyagolható reszponzivitásért elég sok munkával kell fizetni. Így nem gondolom, hogy én lennék tévedésben UX vagy erőforrások kihasználtságával kapcsolatban.
...így már értem miért mondod. Lehet egy "rossz" frameworkkel ez nem lenne elég sok munka...
195

Példa

Hidvégi Gábor · 2017. Aug. 18. (P), 08.27
Esetleg fel tudnád vázolni, hogy milyen lépésekből áll egy kliensoldali validáció leprogramozása, ha neked kéne elkészíteni? A "rossz" framework-ök ezt amúgy sem tudják beépítve, a CSS-t és a JS-t neked kell megírni. Mondjuk eleve ott kezdődnek a problémák, hogy mások a reguláris kifejezések az egyes programozási nyelvekben.
199

Ilyesmi. Nem mondom, hogy ez

BlaZe · 2017. Aug. 18. (P), 20.03
Ilyesmi. Nem mondom, hogy ez a legszebb, legtutibb dolog, de kb ennyi kell legyen egy basic formai validáció definíciója kliens és szerver oldalon egyszerre. Nem akkora kunszt ez, mint ahogy leírod.

Én amúgy megint csak azzal vitatkozom, hogy "semmi értelme". Ez teljesen nyilvánvalóan nem igaz. 2017-ben egy rich webappnál, meg a mai frameworkök mellett ez a kijelentés egy kicsit meghaladott.

Egyébként ez egy jó példa arra, hogy valójában egy házon belüli framework nem bír olyan rugalmassággal, mint egy külsős, elterjedt megoldás. Bár azt is meg lehet úgy írni, hogy könnyen kiterjeszthető legyen. Azzal érvelsz, hogy ez mekkora meló a semmi benefitért, pedig ott van fent az ellenpélda. Ez nem premature optimisation... Egy form alapú rendszernél meg még erősen indokolt is.
201

Én azt kérdeztem, hogy te

Hidvégi Gábor · 2017. Aug. 18. (P), 21.22
Én azt kérdeztem, hogy te hogyan oldanád meg. Persze, le lehet tölteni egy külső megoldást, mint amit linkeltél, ami mögött egy jQuery-re épülő keretrendszer, és természetesen a hibaüzeneteket data-* attribútumokba teszik. Pár éve csináltam egy tesztet, aminek az eredményeit bemásoltam ide, a weblaborra, ha akarod, rá is kereshetsz, az eredménye az volt, hogy jQuery-ből a data-* attribútumok elérése ezerszer lassabb, mintha ugyanezt natív változókkal oldanád meg.

Ez nagyon amatőr megoldás. Olyan 2017-es.

Természetesen semmi értelme nincs ilyet használni. Értem én, hogy lehet ilyet csinálni, de mivel szerveroldalon úgyis kell ellenőrizni, és onnan is kell ugyanúgy hibaüzeneteket küldeni, nem spórolsz meg vele semmit. Láthatóan nem lesz gyorsabb, de egy újabb függőséget kapsz a nyakadba.

Kliensoldalon csak formai ellenőrzéseket tudsz amúgy is végezni.

Ezzel szemben az, amit én javaslok, nulla plusz munkával jár, egyszerűbb a HTML, egyszerűbb a CSS, és egy sor javascriptet sem kell hozzá írni.

Egyébként ez egy jó példa arra, hogy valójában egy házon belüli framework nem bír olyan rugalmassággal, mint egy külsős, elterjedt megoldás.
Ez egy teljesen megalapozatlan kijelentés.

Azzal érvelsz, hogy ez mekkora meló a semmi benefitért, pedig ott van fent az ellenpélda.
A fenti ellenpéldából kimaradt, hogy van mögötte egy jQuery-re épülő saját keretrendszer.
203

Én így oldanám meg. Vannak

BlaZe · 2017. Aug. 18. (P), 22.03
Én így oldanám meg. Vannak erre frameworkök, a linkeltet pl volt is szerencsém használni, bár a JSF-et nem nagyon szeretem. De nem foglalkoznék olyannal, amire van egyszerű kész megoldás. Kivéve, ha nagyon speciális eset miatt az kell. De akkor a front-endet meg úgyse én csinálnám, hanem egy front-endes :)

Amit linkeltem amúgy, abban a definíció volt a lényeg, nem az implementáció. Azt hittem ez nem kérdés.

Ezzel szemben az, amit én javaslok, nulla plusz munkával jár, egyszerűbb a HTML, egyszerűbb a CSS, és egy sor javascriptet sem kell hozzá írni.
Ja, csak feleslegesen terheli a szervert, adott esetben országok között routeolódik a request egy sima validáció miatt, és egy esetleges szerveroldali terhelésnövekedés szétveri a UI-t, és még rá is tesz pár lapáttal.

Ez egy teljesen megalapozatlan kijelentés.
Te állítottad, hogy nagy meló :) Ha az, akkor miért egy sor kb egy másikban?

A fenti ellenpéldából kimaradt, hogy van mögötte egy jQuery-re épülő saját keretrendszer.
Nem maradt ki, ez volt a lényeg :) Mások megírták, leveszem a polcról, használom. Köszönöm szépen, én meg tudok az ügyfél igényével foglalkozni.

Természetesen semmi értelme nincs ilyet használni
Ok, itt a vége a vitának. Hoztak több eléggé megalapozott véleményt a tiéddel szemben, és megint érv nélkül ignorálod őket.
205

Ok, itt a vége a vitának.

inf · 2017. Aug. 18. (P), 22.58
Ok, itt a vége a vitának. Hoztak több eléggé megalapozott véleményt a tiéddel szemben, és megint érv nélkül ignorálod őket.


Ez kb. olyan, mint amikor valaki kijelenti, hogy a Föld lapos. Felesleges megpróbálni meggyőzni, mert olyan szinten ignorál minden tényt. Egyébként ha működik a módszere, akkor használja egészséggel, engem nem zavar, amíg nem kell belejavítanom később. Valószínűleg ezt a részét megúsztam, mert nem foglalkozom már egy ideje PHP-val, csak nagyon ritkán, ha könyörögnek. :D Én is voltam ebben a fázisban, azóta inkább bloggolok. Jobb, mint cikket írni a hülyeségeimről. :D
191

Nem akkora kunszt olyan

inf · 2017. Aug. 17. (Cs), 21.06
Nem akkora kunszt olyan framework-öt írni, ami szerver és kliens oldalon is validál ugyanaz alapján a konfig fájl alapján. Szóval nem muszáj kétszer dolgozni, ha nem akarsz. Igazából ez csak ilyen extra feature a felhasználónak, mert gyorsabban kiírja neki a hibát, illetve mivel nem kell újra betöltenie az oldalt, ezért pl a jelszó mező is kitöltve marad, meg ilyesmik. Én jobban szeretem az ajaxos megoldást, mint felhasználó. Ha értelmesen van megcsinálva, akkor gyorsabban rájövök, hogy hol van a hiba az űrlapon, mit kell még kitölteni, jobb esetben meg már a küldés előtt írja, amikor kitöltöm a mezőt. Ezzel szemben ha csak a szerver validál, akkor újratölti nekem az oldalt, elmegy a scroll onnan, ahol voltam, aztán görgethetek megin végig az egészen, mire megtalálom a hiba okát. Azért a kettő egész más felhasználói élmény. És akkor csak egy apróságról beszéltünk.
196

Nagyjából húsz éve van AJAX,

Hidvégi Gábor · 2017. Aug. 18. (P), 08.29
Nagyjából húsz éve van AJAX, azóta gond nélkül meg lehet csinálni az oldalújratöltés nélküli ellenőrzést.
200

Ha nem probléma, hogy

inf · 2017. Aug. 18. (P), 20.18
Ha nem probléma, hogy bonyolultabb oldalnál jelentős mennyiségű többlet forgalom van, akkor persze rendben van úgy is.
202

Jelentős

Hidvégi Gábor · 2017. Aug. 18. (P), 21.34
Miért lenne jelentős mennyiségű többletforgalom? De nem is értem a problémát, amikor az internetes forgalom több, mint fele videóletöltés. A Facebook kezdőlapja 3-600 kilobájtot tölt be minden görgetésnél, amikor új tartalmat kér le.

Ezzel szemben egy ilyen validációnál párszáz bájtról beszélünk fejlécestül, mindenestül.
190

Volt már ez a sztori itt azt

inf · 2017. Aug. 17. (Cs), 21.01
Volt már ez a sztori itt azt hiszem, az volt a lényege, hogy a menübe nem kellett visszalépni az újrakezdéshez, és ezért nem jött le a toplista, ami a terhelést okozta.
197

Rég volt

Hidvégi Gábor · 2017. Aug. 18. (P), 08.34
Biztos akkor még nem találták ki az indexelést. Eleve érdekes az egész, hogy egy darab kérés ennyire meg tud fektetni egy szervert.

Abban az időben még nem lehetett azt a toplistát előre legenerálni, esetleg más táblába tenni. Valószínűleg a fél világ azzal a játékkal múlatta az idejét.

Ezért egyszerűbb volt a toplistát elhagyni, hisz szemmel láthatólag nem is érdekelt senkit.
156

Ext.js

Poetro · 2017. Aug. 17. (Cs), 10.53
Én nem is tudtam, hogy az Ext.js OSS. Tudtommal a Sencha fejleszti zárt ajtók mögött, és a forrása zárt. Ugyan, ahogy a Wikipédián olvastam elérhető GPLv3 licencel, de ez nem jelenti azt, hogy Open Source. Ráadásul a fejlesztés semmiképp sem nevezhető nyíltnak.
157

Zárt

Hidvégi Gábor · 2017. Aug. 17. (Cs), 11.22
Ez mit változtat bármin is? A rendszer forrása ott van nálam, hisz JS-ben írták, ha hibát találok benne, tudom javítani.
162

Ha a ti keretrendszeretek nem

smokey · 2017. Aug. 17. (Cs), 13.31
Ha a ti keretrendszeretek nem általános, akkor specifikus. Ebben az esetben is rá tudod húzni bármilyen igényre core módosítás nélkül?

Ez növeli a karbantartás költségeit, mind a keretrendszer fejlesztői, mind pedig a használói körében. Tessék, ebben az esetben meg itt folyik el a pénz.


A fejlesztői költségek nem érdekelnek. Én mint keretrendszer használó szem előtt tartom a keretrendszer fejlődését és kalkulálok a lehetséges költségekkel, amik még mindig alacsonyabbak, mint hegeszteni a sajátot.

angular1 vs angular2: ha az angular1-es appodat megfelelő átgondoltsággal raktad össze, fájdalom mentesen átlehet állni angular2-re. Nekünk konkrétan annyiból állt az átállás az egyik projectünkön, hogy az angular1-es definíciókat angular2-es dekorátorokra cseréltük, plusz elvégeztük a megfelelő utómunkát. Nyílván itt keletkezett többletköltség, viszont van egy gyönyörűen struktúrált könnyen fejleszthető frontendünk.

Egyébként ha már egyszer a kilobájtokat számoltuk: az angular app JSON apival jóval kisebb adatforgalmat generál mint egy régi megoldás.
165

Specifikus

Hidvégi Gábor · 2017. Aug. 17. (Cs), 13.57
A keretrendszerünk specifikus, természetesen, mert így a leghatékonyabb. De már évek óta nem kellett hozzányúlni, mert stabilan működik, csak apró kiegészítéseket tettünk bele.

Egyébként ha már egyszer a kilobájtokat számoltuk: az angular app JSON apival jóval kisebb adatforgalmat generál mint egy régi megoldás.
Pontosan milyen régi megoldásra célzol?
204

Pontosan milyen régi

smokey · 2017. Aug. 18. (P), 22.33
Pontosan milyen régi megoldásra célzol?


Rosszul fogalmaztam. A "régi megoldás" nem jó kifejezés. Kizárólag oldal újratöltéssel működő megoldásra gondolok. Hogy értsd, direkt sarkítok: gombnyomásra változtatok egy szót egy. Melyik megoldás generál kisebb adatforgalmat? Újra töltöm az egész oldalt, vagy elkérem a két új szót egy kéréssel, és beállítom.
206

Miért?

Hidvégi Gábor · 2017. Aug. 19. (Szo), 08.12
Bocs, de nem értem, miért hozod fel a teljes újratöltést, hisz már lassan húsz éve anélkül is meg lehet oldani a tartalom frissitését. Vagy ti még így dolgoztok?
207

HTML = újratöltés, JSON/XML =

inf · 2017. Aug. 19. (Szo), 10.00
HTML = újratöltés, JSON/XML = AJAX. Gondolom mivel annyira emlegeted a HTML-t. Kevesen vannak már olyanok, akik egész űrlapokat rántanak át HTML fragment-ként AJAX-al. Mindennki afelé ment el, hogyha már van js, akkor dom manipuláció is, és JSON alapján elég egyszerűen megoldható pár mező kiszínezése meg egy hibaüzenet kiírása. Nagyjából ebből fejlődhetett ki később, hogy akkor már legyen data binding, és az űrlapot is egy model alapján generáljuk, mert az spórolósabb, mint HTML template-el bohóckodni, ha nem egyedi űrlap kell, hanem mondjuk egy admin oldalról van szó, ahol tökmindegy milyen a kinézete.
208

HTML

Hidvégi Gábor · 2017. Aug. 19. (Szo), 11.00
Párszor már leírtam, ha gondolod, linkelem is őket, de akkor megismétlem: mi több mint egy évtizede JSON/XML-lel kommunikálunk a kliens és a szerver között. AJAX-szal nem küldünk HTML-t, bár sokan ezt megteszik, például a Facebook, ami a kétmilliárd felhasználójukat egyébként nem zavarja. Némileg több lesz így az adatforgalom, cserébe gyorsabb ugyanennyivel a megjelenítés.
211

Hogyan kezelitek a

smokey · 2017. Aug. 19. (Szo), 18.03
Hogyan kezelitek a route-okat? Hogy működik a navigáció?
212

Ahogy jólesik

Hidvégi Gábor · 2017. Aug. 19. (Szo), 18.45
Nem tudom, ez hogyan jön a témához. Virtuális url-ekkel dolgozunk, én személy szerint az akarmi.html-t preferálom, de akár könyvtárstruktúrának is kinézhet, ízlés kérdése, teljesen független a megjelenítéstől. Természetesen az oda-vissza gombok működnek.
213

Csak eszembe jutott, és

smokey · 2017. Aug. 19. (Szo), 20.58
Csak eszembe jutott, és gondoltam megkérdezem, mert ugyebár ez is lehet a frontend szerves része.
174

Tömörítve hasonló lesz

inf · 2017. Aug. 17. (Cs), 15.36
Tömörítve hasonló lesz json-ban és xml-ben is az adat mennyiség.
146

Enterprise

Hidvégi Gábor · 2017. Aug. 16. (Sze), 09.50
A nagyvállalati környezet a maga bürokráciájával és lomhaságával az innováció legnagyobb ellensége. Egy-két kivétellel az összes nagy tech cég nem csinál mást, csak felvásárol kis startupokat, akiknek van pár jó ötlete, és megpróbálnak belőle valamit gyúrni, ami vagy sikerül vagy nem.

Tipikus példa erre a Google, akiknek a keresőalgoritmusa semmit nem fejlődött két évtizede, csak reszelgettek rajta itt-ott. Ugyanilyen állóvíz az internet, ami huszonöt éve technológiailag változatlanul ugyanarra alapul.
114

Ezek a keretrendszerek

MadBence · 2017. Aug. 9. (Sze), 00.26
Ezek a keretrendszerek alapból kliensoldali sablonozást valósítanak meg, ami egy annyira abszurd ötlet [...]


Sajnos az utána következő érvekből számomra nem derült ki, hogy miért lenne abszurd ötlet? A szerveren renderelt markupnál is elvesznek a beírt adatok, ha újratöltöd az oldalt.

Azaz lényegében fogalmunk sincs, hogy a kliensoldalon mi van, csak feltételezések.


Azért én árnyalnám a helyzetet azzal, hogy ha van egy célközönsége a termékednek, akkor azért be tudod lőni, hogy milyen eszközökről illetve milyen minőségű kapcsolaton keresztül látogatják az oldalad. Ha pedig van egy meglévő oldalad, akkor az analitika alapján a számszerű eloszlásokat is ismered, és ennek függvényében tudsz kompromisszumokat kötni. Ha olyan weboldalt szeretnél, ami egy ezer éves böngészőben is jól használható, azt is meg lehet írni, de lemondani egy új technológiáról pont ugyanolyan, mint lemondani egy régebbi böngésző támogatásáról.

"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.


Az, hogy az újabb böngészőkben a createElement gyorsabb, nem jelenti azt, hogy a régebbiekben lassabb lett volna az innerHTML állításnál.

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?


A semver módszerét követik, amiben egyébként szó nince ilyesmiről,
hogy a 0.x verziók béták. Ha érdekel major verzió ugrásának oka, ajánlom a témában a react posztját.

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 [...]


Senkit sem kényszerítenek, hogy dobja ki a meglévő kódját. Az Angular 1.x egy stabil keretrendszer, az Angular 2 (3, stb) pedig tulajdonképpen egy teljesen másik (ami ha jól tudom már követi a semver szabályait). Nem kötelező frissíteni rá.

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.


A szerver oldali renderelés hiánya valóban egy fájó pont, de nem megoldhatatlan (persze ez csak egy a sok lehetséges megoldás közül). Egyébként újabban a google már képes js-t futtatni, szóval a jövőben csak javulhat a helyzet.

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.


Az async/await milyen kompromisszumokra kényszeríti a fejlesztőt?

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.


Nekem sikerült "átvészelnem" ezt a "viharos" időszakot. Valójában egyáltalán nem volt az, a project stagnálása miatt a core fejlesztők kiváltak, és iojs névent ment tovább a project, majd miután a márkanevet birtokló Joyenttel sikerül megegyezni, újra nodejs név alatt mentek tovább. Azóta egyébként már a Node.js Foundation-é a márkanév, és fejlesztési döntések teljesen demokratikusak (és átláthatóak).

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.


Továbbra sem kell. Aki pedig szeretne a neten jelen lenni, de egy havi 5 dolláros VM-be nem tud beruházni, ott komolyabb gondok is vannak. Ha neked menedzselt környezet kell, az sem sokkal drágább (heroku, illetve egyéb PaaS szolgáltatók).

Í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.


Szerintem a node előnye pont az, hogy nem kell a szerveren egy másik nyelvet használni, a frontendes is bármikor meg tudja érteni, hogy mit csinál a backend kód. Pont hogy kevesebb a függőség.

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


Szerintem a reactos megközelítés kifejezetten a produktivitás előnyére vált. Egyébként a viselkedés továbbra is szétválasztható, nem kötelező ott helyben megírni az üzleti logikát (sőt, nem is ajánlott). Olvass utána a flux architektúrának, vagy a redux könyvtárnak bátran, nagyon tanulságos.

[...] 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.


Az, hogy kliens oldalon manipulálod az adatokat, nem mentesít az alól, hogy szerver oldalon validálni kell azokat (linkelhetném a bkk balhét, de úgyis mindenki ismeri a sztorit). Lehet egyébként ezt csinálni, a régebbi asp.net kb pont így működött, és borzalmas élményt adott (de ez csak személyes tapasztalat/vélemény)

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.


Az inferno egy a react-hoz nagyon hasonló könyvtár, 9kb :). Egyébként szerintem el vagy tévedve, a JSX-es szintaktikában az <button onClick={foo} /> egy React.createElement('button', { onClick: foo })-nak felel meg, nem generálódik tényleges HTML kód, pusztán egy virtuális DOM fa, amit az aktuális DOM fával összehasonlít a megjelenítő algoritmus, és csak a szükséges változtatásokat hajtja végre.

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.


Tehát ignoráljunk minden új technológiát? A react 2013 óta van itt, és nem úgy tűnik, mintha leáldozóban lenne. A fejlesztés során szerzett tapasztalataim alapján bárkinek tudom ajánlani, hogy építsen rá. Ha értesz egy kicsit is az angular/react-hoz, garantáltan lesz munkád, szóval szerintem ez elég erős csúsztatás, hogy a ezek csak hóbortok.

[...] Ezt elég egyszer megírni


A szoftver sajnos nem egy statikus dolog, a valóság nem így működik. Ha a saját keretrendszerre gondolsz, akkor meg azt tudom válaszolni, hogy használj egy meglévőt, és akkor egyszer sem kell megírnod :).

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?


Egy hulladék keretrendszerrel, és egy "fun" keretrendszerrel is meg lehet oldani a problémát, és ráadásul ugyanolyan jól, azonos idő alatt. Én azt választanám, amit élvezek is csinálni.

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.


Ezzel így nem értek egyet, a React és a többi keretrendszer mellett meg kell tanulni a HTML/CSS/JS-t is (mondjuk én azt hittem, hogy ez utóbbi egy teljesen nyilvánvaló dolog).
116

Azaz lényegében fogalmunk

inf · 2017. Aug. 9. (Sze), 00.43
Azaz lényegében fogalmunk sincs, hogy a kliensoldalon mi van, csak feltételezések.


Egyrészt lehet a user agent alapján is sejteni valamit már szerver oldalon, ha meg van a kliens oldalon js, akkor le lehet vele tesztelni, hogy egy-egy feature működik e. Szóval a fogalmunk sincs nagyon erős túlzás.

Az inferno-t megnézem, nomen est omen. :D