HTML 2021

<div class="
	row
	row-xs-2
	row-md-3
	row-lg-4
	row-xl-5
	row-xxl-6 
	justify-content-xs-start 
	justify-content-xxl-between 
	flex-column-xs-reverse 
	flex-column-xxl-reverse
	align-items-xxl-center 
	gx-xs-1
	gx-md-2
	gx-lg-3
	gx-xxl-5
	order-xs-4
	order-xxl-3
	bg-primary
	text-scondary
	hover-color-black
">  LÓFASZ </div>

Hozzászólások

Mi akadályoz meg abban, hogy az onclick event handler legyen az, amelyik tovább hív a megfelelő függvényekre?

Ja az, hogy így még a végén véletlenül explicit, olvasható és értelmezhető lenne a kód, ami viszont manapság nem igazán dívik.

Az, hogy akkor az event handlernek kell minden helyen tudnia, hogy ki az, akit meg kell hívni - és nem a hívók felelnek érte, hogy ők feliratkozzanak. Modom, szorosan csatolt kód, ahol ahhoz, hogy egy új viselkedést adj az oldalhoz, két helyen kell belenyúlnod: az egyetlen egy darab onclick event handlerhez is hozzá kell nyúlnod, az új kódon felül. 

Ahelyett, hogy az új kód csak feliratkozna, és minden mástól függetlenül tudna működni. Ha benne van a script tagek között, folyik a viselkedés, ha nincs, nincs. Nem kell hozzá mást módosítani, pláne nem a globális event handler kódját.

Az, hogy Events.SomeButton-nak tudnia kell arról, hogy létezik doAThing(), doBThing(), ahelyett, hogy AThing és BThing létezéséről egyáltalán tudna, mert azok self-contained módon működnek. Miért kéne minden lehetséges eseménykezelőről tudni egy globális helyen, ahelyett, hogy ez teljesen egymástól függetlenül működnek? Például egy text mezőre külön aspektus tud lenni a szintaksziskiemelés, meg külön aspektus tud lenni a karakterszámláló kijelző.

Ezeket egymástól függetlenül tudod ráakasztani az összes vonatkozó szövegmezőre, anélkül, hogy expliciten csinálnád.

Olyan ez, mint a dependency injection - nem neked kell példányosítani a viselkedéseket, azok majd megteszik a maguk dolgát.

 

Persze, lehet írni ilyen erősen csatolt kódot, csak nagyon körülményes lesz bizonyos méret felett a karbantartása.

Spagettit vizionaltal. Attol, hogy Events osztalyunk latja a karakteszamlalo fuggveny scope-jat es a szintaxiskiemelo kodjat, meg messze vagyunk a spagetti kodtol.

De ha tudnal egy peldat mutatni, ahol addEventListener baratunk gyorsabb/eroforrasbaratabb, mint a szabvany html onclick="fuggvenyunk()", raadasul nem csak linearisan, hanem komplexitasban is, meg el is ismernem, hogy igazad van.

Egyeb esetben egy szubjektiv vita folyik epp arrol, hogy mi olvashato, mi karbantarthato, "hany wtfs/min-es a kod", raadasul ezek kozul is a "spagetti" erv leginkabb semmilyen labon nem all.

És az hol fog azon segíteni, hogy bizonyos dolgokat mondjuk nem akarok mindig futtatni?

Pl. akarok valamihez írni egy unit tesztet. Teszem azt, pizzarendelés-menedzsment app, tesztelendő funkció meg az, hogy ha a szakács a rendelést megsült státuszúra állítja. Vajon hogy lesz egyszerűbben karbantartható, ha a számla kinyomása és a futár értesítése funkció meghívása is ide lesz bedrótozva (aztán majd kerülgeted a teszt során), vagy ha inkább a számlázó meg a futár-értesítő feliratkozik a rendelés-megsült eseményre és tesztnél meg simán nem iratkozol fel rá?

Azert, mert 10 kulonbozo programozot lattam (kb 13-bol) rosszul osszespagettizni olvashatatlanra es karbantarthatatlanra a "feliratkozast" a jQuery-s idokbol.

Aki egy fuggvenyt rakott a html attributumra, annak meg kurva konnyu volt kezelni a kodjat. Sot, azok a JS-t (is) programozo ismeroseim vittek a legtobbre, akik mindigis igy csinaltak. Es mindannyiukat hasonloan gyenge ervekkel probaltak leszolni. Mi meg csak rohogunk. Barki hozzanyul a JS kodunkhoz, nem ul rajta sokat, mert azonnal megtalalja mi hol van. Ehhez mit szolsz?

(Egyebkent a definicionak szigoruan megfelelo unit teszt pont annyira tulertekelt, amennyire az integration test fogalma es fontossaga alulertekelt)

"(Egyebkent a definicionak szigoruan megfelelo unit teszt pont annyira tulertekelt, amennyire az integration test fogalma es fontossaga alulertekelt)"

Senki nem beszélt ész nélküli unit teszt gyártásról. Csak annyira nem fun, amikor nem lehet tesztelni valamit normálisan, mert össze-vissza hív a vakvilágba, mert a fejlesztője elfelejtette normálisan strukturálni a dolgait. Aztán meg mikor változnak az üzleti igények és át kell alakítani a kódbázist, hogy nem lehet normálisan hozzányúlni a kódhoz, mert már day 0-kor is olyan referenciák kerültek bele, aminek semmi keresnivalója nem lett volna ott.

Ez is elegge gyenge erv volt. Tudom, hogy tudsz te ennel jobbat is.

Mire optimalizaljunk kodot? Alacsony futasidore? Alacsony memoriahasznalatra? Konnyen hozza lehessen irni uj funkciot?

Nagy lofaszt: arra, hogy "mi lesz, ha majd valamit egyszer erdemes torolni a kodbol" (amit valszeg az interpreter minimalis overheaddel kihagy addigra). Mindezt sokat szidott, de ebben kivetelesen erosen segitokesz posztmodern IDE-k idejen.

Agyam eldobom, hogy egyebkent altalam ertelmesnek gondolt programozok mit hordtak ossze ebben a threadben. :(

Mivel tapasztalataim szerint egy kód törlése mutatja meg leggyorsabban, hogy mennyire spagetti a kód vagy mennyire vannak jól szétválasztva az egymáshoz nem vagy lazán kapcsolódó dolgok, bátorkodtam ezt a példát hozni. De ha nem érted a lényegét, akkor ¯\_(ツ)_/¯.

Persze, nyilván segít a spagetti felfedezésében egy jó IDE, csak mondjuk mi a jó isten tökéért kellett a spagettit létrehozni már első körben, hogy aztán bogarásznom kelljen ezer helyen a referenciákat?

Egy valamit javitanek:

ValamiOsztaly.DoAThing();
MasOsztaly.DoBThing();

Igy nekem is jobban tetszik, es legalabb nem hallgathatom, hogy spagetti.

Mostmar csak azon vitatkozunk, hogy 10-bol 4 forrasfajlban kelljen keresni, hogy "ki iratkozik fel erre a kurva html objectre", vagy "tudjon-e az Events osztaly a tobbi osztaly letezeserol" (a fentebbi unit tesztes peldad kezd erdekes lenni, de en azt se sulyoznam ily modon).

En egyertelmuen a "mindenrol tudo Events osztalyra" szavazok, miutan a jQuery-s idokben talalkoztam a legbrutalisabb spagettikkel, a la

$(document).on('click', 'span', function...

Es ilyenbol 5000 soron egy forrasfajlba behanyva, hogy mukodjenek oldalgeneralaskor dom-ban meg nem letezo  elemeken is...

En a "subscriber" modszert lattam karbantarthatosag tekinteteben nagyon sokszor nagyon csunyan megbukni.

egyenes út a fos spagetti kódok felé

Nem.

Hint: szandekosan irtam MyNamespace-t, ami tulajdonolja ezt a fuggvenyt, ha nem lett volna tiszta. Tessek hasznalni azt a fantaziat.

A spagetti kod (vagy valami annal is sokkal rosszabb) pont az, amikor egy html objektum betekint 10 forrasfajlba, es abbol 4-ben talal eventlistenert maganak.

A "decoupled esemenyek" meg tenyleg egy async nyelvben lenne problema? Egy fuggveny miert ne allhatna abbol, hogy meghiv masik 4-et akar parhuzamosan? Vagy netan van annak valami elonye, hogy nem ismerjuk a hivas sorrendjet? (Hint: nincs)

A kommented remek pelda arra, hogy miert tart ott a Javascript framework-tenger, ahol. Elarulom, nem technikai okai vannak, hanem elterjedt az a hulyeseg, hogy a Guglihoz valo jovobeli interjunal jo pont, ha van ilyen a githubodon. Igy jon az, hogy lelkes es egyebkent full tapasztalatlan 17-18 evesek nekiallnak event-driven kodot irni, es sokan patternkent kezelitek antipattern helyett azt, amit osszehanynak.

Aszinkron nyelvet mondott, nem többszálút. A kettő nem ugyanaz:

Async programming is about non-blocking execution between functions, and we can apply async with single-threaded or multithreaded programming.

Van egyszálú aszinkron modell:

Synchronous with a single thread: Tasks are executed one after another. Each task waits for its previous task to get executed.

Synchronous with multiple threads: Tasks are executed in different threads but wait for any other executing tasks on any other thread.

Asynchronous with a single thread: Tasks start being executed without waiting for a different task to finish. At a given time, only a single task can be executed.

Asynchronous with multiple threads: Tasks get executed in different threads without waiting for other tasks to be completed and finish their executions independently.

És a JS az.

Régóta mondom, hogy a HTML-3.2 (1997) volt az utolsó, ahol a tartalomra koncentráltunk.
Azóta a beágyazható videón kívül leginkább csak a csicsa és az indokolatlan erőforrás elpazarlás megy.

Tim Berners-Lee még <> közötti vezérlőparancsokkal TXT-ben leírható képi elemeket magába foglaló dokumentációs formátumot akart létrehozni. Ez nekem is tetszett, HTML és LaTeX volt a két kedvelt formátumom.
Azaz egyszerű és a jövő számára megőrizhető TXT alapú dokumentációs formátumban gondolkozott, ahol kellett oda képi elemeket beilleszve, de ALT szöveges taggel, ha netán nem tudnád a képet megjeleníteni.

Ma meg a web böngésző egy komplett virtual machine, amiben javascript és webassembly alapon futtatod a játékokat. Például: https://beta.unity3d.com/jonas/AngryBots/
Ez a web már nem a dokumentációs formátumról szól.

HTML 2021 2011

Jobb helyeket Sass-szal vagy Less-szel csinálnak erre egy (vagy max 2-3) CSS classt.

Ez loszar, meg egy rendes javascript sincs benne!

inkább <div><div><div><div> LF </div></div></div></div>