Event driven development es Javascript

Sokaig csak egy valamit tudtam az event driven developmentrol. Hogy utalom. Meg annyit sejtettem, hogy azert utalom, mert mig proceduralis vagy objektumorientalt vagy MVC kodban masok aranylag atgondolatlanabb kodjaban is 5-10 perc alatt megtalaltam egy bugot (pl. PHP egy MVC frameworkkel), addig sokszor fogalmam sem volt rola, hogy miert nem talalom 3 oraja, hogy melyik mas altal irt Javascript listener miatt nem mukodik mar megint a kodom stopImmedaiatePropagation() nelkul. Az egesz talan a jquery-s document ready-knel csuszhatott el leginkabb.

De hogy miert utaltam valojaban az event driven developmentet, azt sokaig nem tudtam megmondani.

Eloszor azt hittem hogy csak azert, mert karbantarthatatlan es debuggolhatatlan (foleg JQuery-nel).

Aztan rajottem, hogy lehet nem is az event driven developmentet utalom, csak a javascriptet (JQuery-stol)


Side note: kozben sajnos ra kellett jonnom: reszben igazuk van azoknak, akik azt mondjak, hogy a Javascript az uj assembly. Csak nem azert assembly, amitol az ASM assembly. Az ASM ugyanis attol assembly hogy ennel kozelebb mar nem allhatna ahhoz, hogy utasitasokat adjon a processzornak, igy hat villamgyors, de CSEREBE az ASM kod karbantarthatatlan es debuggolhatatlan es nem is platformfuggetlen. Ekozben a Javascript ATTOL assembly, hogy karbantarthatatlan, debuggolhatatlan es nem is platformfuggetlen, CSEREBE lassu (igen messze all az ASM sebessegetol).

Ennek eredmenyekent mindenki probal a Javascript fole egy frameworkot csinalni, ugymond keresik a Javascript nevu assembly-nek a C-jet ami fut minden platformon (optimalis "per build" forditastol messze vagyunk, meg coffeescript eseten is, szoval az a keresett C sehol sincs meg). Erre egy gyenge minosegu, lassu futasidovel de megbizhatoan mukodo megoldas volt a JQuery, de vannak mar ertelmesebb MVC-hez kozelito megoldasok, mint pl. Angular (ami majdnem jo, csak bar ne a Google fejlesztene), Backbone, EmberJS, etc.

##(Amennyiben a fenti ket bekezdesre az asmjs-t vagy a V8-at akarnad felhozni, felhivom figyelmedet, hogy total nem ertetted meg, hogy mit szerettem volna ezzel mondani. Tudom jol mik azok, v8 compilertol nem lesz gyorsabb a regi IE-ket kerulgeto fuggvenyek ertelmezese a js frameworkokben, asmjs meg tok mas, ide nem illo dolog)##

Na de nezzuk tovabb, mit hittem meg, miert utalom az event driven developmentet, miutan eldontottem, hogy nem megyek a Javascript hibai miatt pszichologushoz.

Rajottem kesobb, hogy lehet hogy csak azert utalom, mert hanyingerem van a szintaxisatol.

Closure, closure, closure, es meg abban egy closure, itt most akkor ki is a "this"? Arrol nem is beszelve hogy meg nem talalkoztam olyan IDE-vel ami legalabb egy picit megprobalta volna kenyelmesen kiegesziteni a "});" -t es az ahhoz kapcsolodo indentalas merteket is eltalalta volna. Szemelyes kedvencem a document ready-ben definialt click eventben definialt .each (megintcsak jquery), a listener persze a leglogikatlanabb selector-ra rateve, arra is egy 3 fajllal arrebb keszitett string valtozoban, komment nelkul.

"De hat mi a baj a closure-rel?"

Az, hogy funkcionalis programozasi nyelvek autista fejlesztoi talaltak ki, mert soha az eletben nem gondoltak meg arra, hogy alkalmazasok debuggolasanal fontos lehet atlatni, hogy mi kap hamarabb erteket es mi mi utan kovetkezik, definialodik. A write-only programozas nem meno, es tobbet art a gazdasagnak, mint egy adoemeles (pedig azt nehez elerni), ezt mar a perl+regexp parosbol mindenkinek meg kellett volna tanulnia.

Bizony, ritkan tudtam olyan ideges lenni, mint mas event driven JS kodjanak debuggolasa kozben, csak aztan raebredtem valamire meg igen amator korombol.

Megpedig arra, hogy anno irtam evekkel ezelott egy Java alkalmazast. Es ott en is total logikatlanul tettem le a listenereket, ma mar szegyellnem azt a kodomat. Maskepp csinalnam (ezt az erzest tudom, hogy sokan ismeritek).

Ekkor jottem ra, hogy nem is az event driven developmentet utalom, hanem azt, hogy emberek pocsek event driven kodokat irnak. (including me?)

Es itt gondolkodtam el. Az event driven development egy szukseges rossz jelenleg, de akar szukseges jo is lehetne. Sokat gondolkodtam, mi hianyzik ehhez?

Es ezen elgondolkodtam, agyaltam es agyaltam. Aztan szep lassan leesett: ha mar az event driven developmenthez is lenne KOZTUDATBAN egy olyan konvencio/pattern/stb. gyujtemeny, mint ami az MVC melle kialakult az objektum orientalt fejleszteshez, minden rendben lenne. Ha mindenki tudna, hogy hogyan illik event listeneret definialni es hogyan nem illik, mi melle illik kommentet irni ha "levagtal egy kanyart", nem lenne semmi baj, es tok elheto lenne az event driven development vilaga.

Aztan tovabbgondolva eszembejutott par felkesz otletecske:
-pl. "MVC szeru megoldas (Angular, Backbone, EmberJS) es csak a view mappaban levo js-ekbe tehetsz listenert es csak data-event-listener attributumra.". Aztan kiderult, hogy az Angularnak van is ilyenje (ng-click talan?). (Akiben felmerult volna a "sok js fajl, sok http request" problema: a sok projekten beluli js file-t grunttal eggye varazsolod release-kor.)

Aztan pedig rajottem, hogy itt nem is nekem kene igazabol otletelnem. Valaki/valakik mar biztosan foglalkoztak ezzel es esetleg meg be is tartatnak valahol egy konvenciokeszletet event driven developmenthez, miutan meguntak, hogy eveken at szornyebbnel szornyebb jquery kodokat debuggoltak.

Es itt van amit keresek: egy minel egyszerubb es tomorebb konvenciokeszlet/patternkeszlet/antipatterngyujtemeny altalanosan event driven development-hez.

Ami megfelel:
-text weboldal pelda es ellenpelda kodokkal, rovid magyarazatokkal.

Amibol koszonom nem kerek:
-10 diabol allo hello world 20 perces videoanyagban elhuzva (meg ugy eleve semmi, ami csak videoban tudja nekem elmagyarazni)
-600 oldalas konyv event driven developmentrol

Ugyanis amit nem tudsz konnyeden elmagyarazni, azt igazabol nem is erted. Ezert lett ez a blogpost is ilyen hosszu ;) Masreszt pedig nem eleg, hogy en ertsem, a cel, hogy a koztudatba is bejusson az a tudasanyag, amit mar reg ugy meg kellett volna mindenkinek ismernie az event driven development mellett, mint az objektum orientaltsag mellett az MVC-t. Igen, tudom hogy "sokan az MVC-t is rosszul hasznaljak, nem ismerik elegge", de megis rengeteget jelent mar az is, hogy a legtobb dev legalabb par aprosagot betart belole es maris konnyebb hozzanyulni a kodjahoz, meg ha csak "felig ismeri is mit hogyan illik benne".

( BaT | 2015. 01. 03., szo – 14:27 )

"Az, hogy funkcionalis programozasi nyelvek autista fejlesztoi talaltak ki, mert soha az eletben nem gondoltak meg arra, hogy alkalmazasok debuggolasanal fontos lehet atlatni, hogy mi kap hamarabb erteket es mi mi utan kovetkezik, definialodik."

Sokan elfelejtik, hogy a funkcionális programozáshoz elengedhetetlen az immutabilitás. Van is erre egy jó kifejezés (ami nem jut az eszembe), hogy ha egy függvénynek nincs side effectje, akkor egy függvényhívás behelyettesíthető a visszatérési értékkel, vagyis a teljes program végül redukálható egyetlen értékre. (Nyilván a valóságban szükség van side effectekre (pl. logging), ezeket megfelelően elszeparálva kezelhető marad a program.)

A javascript azért egy nagyon szerencsétlen nyelv, mert a funkcionális programozás egyetlen elemét támogatja, a closure-t. Persze itt nem is funkcionális programozásról beszélsz, hanem event drivenről, amihez az elég is.

Ezzel egyet is ertek, ellenben egyre tobb olvashatosagot gatlo elemrol veszem eszre, hogy eredetileg funkcionalis programozok eszkoztaraba tartozo dolgot "masoltak ki", es ezert emlitettem meg oket "ellensegeskedoen". :) Ahogy egy boyolultabb rekurziv fuggvenyt is igen agyfacsaro tud lenni atgondolni, foleg ha szamit a futas sorrendje, vagy bele kell tenned a kozepere egy altalad is emlitett logolast. Egyszeruen eltunik benne az algoritmusok lenyege: az egyszeru reszfeladatokra bontas.

( szebeni | 2015. 01. 03., szo – 17:31 )

Here is my two cents
Gondolkoztam nehany mondatodon, de vegulis nincs ertelme kiragadni oket, ezert inkabb megprobalok a problemadra vezeto okot feltarni.
Minden front end fejleszto mast ert alatt javascript fejlesztesen, fuggoen attol h milyen az adott project.
Reszletezve frameworkok szerint (sajat/standard alacsony szintu/standard magas szintu), elotapasztalat szerint (semmi/backend) es a feladat szerint (vekony kliens/vastag kliens).
Ha ezektol fuggetlenul probalnank egy egzakt feltetelrendszert felallitani h mi a front end fejleszto szukseges es elegseges feltetelei akkor mindezt figyelembe kellene vennunk es kb megkapjuk azt a szintet amit egy nemzetkozi outsourcing cegnel elvarnak.
A nyelvet legeloszor is ismerni kell, Closure-ket nem agyba fobe hasznalunk mivel fogjak a kontextust, hanem a leheto legkisebb kontextust osztjuk meg es mindig takaritunk magunk utan (nem csak a dom-ban). - enelkul a kodunk fele proxy utasitasokkal lesz tele (vagy that/self = this; fele antipattern-el) es tobbek kozott olvashatatlan is lesz.
A nyelv ismerete utan alapveto a module pattern betartasa megpedig nem esz nelkul hanem a clear separation of concerns menten.
Ha ezek nincsenek meg a fejleszto csapatban mindenkinel es nincs egy egyseges developer guideline akkor nagy baj van.
De ha megis ez meg mindig nem elegseges, kellenek a static code analyserek mint a jshint/csshint valamint ezek mellett a unit es integracios tesztek (a 100 code coverage helyett ugye erdemesebb az edge casekre fokuszalni).
Viszont ha van egy egyseges developer guide-unk ami megszabja hogyan irjuk a moduljainkat, amik teszteltek onmagukban es egyuttmukodve is, akkor egeszen mas szintu problemak merulnek fel, mint hogy tobb esemenykezelo egymas workflowjaba bekavar, ami ugye a side-effecteknek koszonheto, plane ha aszinkron dolgokat vegzunk de nincs jol atgondolva.
(Persze ekkor is lehet latszatra szep kodot irni ugy h a vegeredmeny egy fabatkat se erjen...)
Ennek a developer guidelinenak a formai kovetelmenyeken tul le kell irnia h diszkret modulokat kell irni, ne pisaljunk bele a kozos medencebe, ezert hasznalunk pl. namespacelt esemenyeket h amikor leiratkozunk egy dom noderol csak a mi listenerunket vegyuk le, maset ne.
Ezen tul a frameworkokkel az a gond, h onnantol az adott fejleszto nem csak hasznalja a frameworkot, hanem a problema megoldasara fog tudni egy framework specifikus megoldast amit a framework nelkul csak sok izzadas aran tudna elerni.
Ezt kikerulendo rendkivul fontos h a csapatban minden fejleszto ismerje a framework belso mukodeset, minden apro magicet, amit csinal es ugye sajnos ez sokszor nem elmondhato es a jovobeni problemak elore lathatok.
Amire vegulis ki akartam lyukadni h egy nyelv mindegy milyen, csak annyira jo mint amennyire a csapat ismeri.
Erre egy jo pelda ledokumentalasa azert nem eletszeru, mert itt olyan kodrol van szo ami jol skalazodik nagyban, tobben fejlesztik es karbantartjak, ezert valoszinuleg zart forras, mint pl. azok is amikrol en tudok. - itt nem is igazan maga a kod kritikus mert ugye vegeredmenyben ott lesz a kliensen a cache-ben, hanem a meg nem releaselt uj funkciok, amik a conversiont emelik a versenytarsakkal szemben.
A nyilt forras ugye mas teszta, de hatha valaki mas tud peldat emliteni.
De roviden valaszolva a kerdesedre menj el egy multinacionalis software outsourcing ceghez (onsite lehetoleg), es ott remelhetoleg lesz lehetoseged a pozitiv pelda megismeresere is (leszamitva h rovid projecteken ott is mehet a ganyolas sajnos).

---
return NEVER;

Koszi, elsore jo gondolatebreszto. Elgondolkodok ezeken, meg utanuk nezek. De nem ettol fogok munkaugyben valtani. ;)

Nagyjabol amugy hasonloan gondoltam a legtobb dolgot, de ugyanakkor Javascriptnel amit irtal "idealis esetkent", az lehetetlen elvaras. Nem igazan realis az, hogy "ismerje mindenki azt az adott frameworkot alaposan" es igy tudd felvenni az n+1 fejlesztot aki kell neked. Ahhoz tul sok van frameworkokbol a piacon (pont ez a "babeli nyelvkavarodas" a legnagyobb baja a javascriptnek, amint tavolodnal el a jquery-tol). Oda inkabb velemenyem szerint egy jo es gyors es hatekony betanitas kell azoknak, akik hasznaltak mar hasonlo JS frameworkot, mint az ott hasznalt framework (vagy ehhez meg nem eleg egyszeruek a JS frameworkok? Lehet). Hozzateszem, kevesbe vagyok frontendes, csak van, hogy en vagyok felelos egy frontenden felroppeno hiba gyors javitasaert.

Szvsz ha egy front end fejleszto ismeri a nyelvet es nehany nagyobb frameworkot, akkor mar senior kategoriaban is elmozog, efelett akkor lesz lead front endes ha architekturalis ralatasa is van ezekre a frameworkokre, nekem legalabbis ez az elvarasom.
Nyilvan nem lesz mindenki azon a szinten a csapatban de szukseg van egy ilyenre aki segiti a tobbieket a megfelelo irany elereseben.
Sajnos ez ugy tunik nem sokat segit neked, mivel eszerint nalatok nincs dedikalt front endes team...
A babeli nyelvkavarodas erdekes amit irtal, erre talaltak ki a custom components-eket erinto szabvanyokat (Shadow dom, custom elements, html import, template), van meg par problema amit meg kell oldani (pl. html imports ami sokak csoret zavarja).
Ezen tul inkabb a valasztas szabadsaga adott ahol nem kotik meg az ember kezet h marpedig ezzel a technologiaval kell dolgozni, ilyet max rovid tavu projecten tudnek elkepzelni, altalaban az ugyfel fixen hozza a sajat stackjet.

---
return NEVER;

Ez az FRP dolog elso atfutasra kis utananezessel tetszik, tulajdonkeppen ugy tunik szamomra, hogy beletette a funkcionalis programozasba azokat a dolgokat, amik hianya miatt egy hulladeknak goindoltam oket. :)

Jol vettem ki, hogy itt pont arrol van szo, hogy a funkc prog-bol eldobjak a stateless baromsagot, direkt van state, es erre a state-re mellesleg minel egyszerubb (lehetoleg primitiv tipusokkal reprezentalo, fuggvenyek szamara egymas kozt konnyen atadhato) fuggoseg nelkuli adatszerkezetekkel fejezik ki a state-eket/side-effecteket? Vagy felreertettem valamit?

Ami erdekesseg meg, hogy "imperialista" backend kodolasi stilusom is kezdett ilyesmive alakulni. Volt hogy 3 osztalyt csinaltam egy helyett csak hogy legyen ketto jol tesztelheto, ami csak primitiv tipusokkal dolgozik, a 3. huzta rajuk layerkent ezt a framework-beli fuggosekgekre es definialta a leheto legegyszerubben hogy a frameworkon belul neki hol a helye. Tulajdonkeppen erre is regota kerestem hogy letezik-e valami "patternnev", vagy resze-e valamilyen patternnek, mert biztos voltam benne, hogy nem en voltam az egyetlen aki evek ota erre a kovetkeztetesre jutott, meg "hatha valaki megfogalmazta ezt egyszerubben".

Itt viszont mas iranyu kicsit a beszelgetes. Az egyebkent mukodo megoldasok, amiket felvazolsz rendelkeznek egy hatalmas hatrannyal: csak nagy cegeknek "vannak erre millioik". Marpedig JS-ezni egy ket devbol indulo es 5 masik dev altal folytatott startupoknak is kell, es ott is cserelodhetnek az emberek elobb-utobb. Es ez egy igen komoly gazdasagi szempont ahhoz, hogy kimondjuk: ezeknek a dolgoknak majd meg sokat kell egyszerusodnie.

En biztos vagyok benne, hogy eljon majd az az ido, amikor nem csak egy 15 fos csapat fog tudni rendes JS frontendet csinalni, ahogy az az ido is eljott, hogy nem csak 15 memoriahoz nagyon erto C/C++ dev tud elfogadhato sebesseggel futo alkalmazast irni. Ezeket a terheket szerintem elobb utobb valahogy le fogjak venni a JS fejlesztok vallarol, leven "idopocsekolas", hogy ezzel megy el a frontendeles, plane egy kozgazdasz szemevel. Es meg egy valami kiderult az evek soran: ezt a terhet nem az Adobe fogja levenni a frontendesek vallairol (flash, dreamweaver, koszonjuk, nem kerjuk). Es szerintem azert is van ennyire sok JS framework mostanaban, mert mindenki ezt a problemat probalja valahol megoldani, de ugy, hogy azert az altalanos kodolasalapu gondolkodas megmaradjon. De egyre tobb bicskat latok ebbe a feladatba beletorni.

Tehat en hiszek abban, hogy ez egy nap majd egyszerubb lesz, persze addigis lepest kell tartani (ezert nezegetem az Angulart, Emberjs-t meg backbone-t meg ha tudom is, hogy ezt a problemat nem en fogom megoldani, de azt meg tudom allapitani: ok se oldottak meg).

( wachag | 2015. 01. 03., szo – 18:55 )

> Az, hogy funkcionalis programozasi nyelvek autista fejlesztoi talaltak ki, mert soha az eletben nem gondoltak meg arra, hogy alkalmazasok debuggolasanal fontos lehet atlatni, hogy mi kap hamarabb erteket es mi mi utan kovetkezik, definialodik.

"Think about the idea of having a sea of imperative code that interacts with the outside world and in there have islands of pure code where you write your functions in a pure way.
But you have to decide how big the islands are and how big the sea is. But the answer is never that there are only islands or only sea. A good programmer knows exactly the right balance."
Erik Meijer

Hat ez az idezet nekem nem vedett meg semmit ami related to funkcionalis programozas. De meg mindig jobb erv mellette, mint a "nincsenek allapotok". ;)

Persze elfogadom, hogy letezhet az a ter, ahol a funkcionalis programozas elonyeit kifejezetten jol lehetne hasznalni. De userspace-ben semmi keresnivaloja, alkalmazas/webalkalmazas fejlesztesenel vegkepp nincs.

Ó, hajaj, dehogynem. Például validálót álomszépen lehet írni benne. Legutóbb meg digitális technika házi feladat javítót írtam Haskell nyelven, hogy ne kelljen kézzel kiszámolni minden hallgató megoldását :-)

Szerk: meg rengeteg funkcionális dolog átszivárgott az imperatív világba.

Ket olyan pelda megintcsak, aminek az "imperialista" valtozata sokkal atlathatobb es debuggolhatobb, es halsitennek nem pont ugy vettek at, ahogy funkcionalis nyelvekben volt, hanem "beletettek a maguket", mert szerencsere tekintettel voltak arra, hogy az adatszerkezeteket bizonyos problemak eseten logolni is szeretne az ember, meg ha total nem is olyanra akarta par nappal azelott kitalalni. :)

Raadasul ezeket elobb utobb maguktol is "feltalaltak volna imperialistaek" elobb utobb, nem bonyolult dolgok ezek, es elobb utobb elokerul a hianyuk.

De egyebkent nice try, kifejezetten szeretem a foreach-et meg a generikusokat hasznalni olyan objektumokon, amiknek vannak allapotai. ;)

tudom, a userspace rossz foglamazas volt reszemrol, az "alkalmazasfejlesztes" meg csak szimplan nem volt elegge definialva ;)

de a "maga kis sandbox-aban" elfogadom hogy jo, csak sajnos sokan atvittek oda, ahova nem kene (mar csak azert sem mert tul sok logikai modositas van, es azokat a kod mas olvasoinak is at kene latnia)

( jokeman | 2015. 01. 04., v – 03:13 )

Ha már feldobtad, hogy mit keresel. Ezek ugyan könyvek, de mindkettő csak 200 oldal körül mozog (amiből nyilván egy csomó sallang is van), ahogy láttam, agyonmagyarázva azért nincsenek.

Nem ígérem, hogy minden problémádra megoldást jelentenek (és sajnos nem is a legfrissebbek), de less rá a tartalomjegyzékükre meg a review-kra, és ha úgy gondolod, akkor szívesen kölcsönadom őket PDF-ben (csak írj rám privátban). ;)