[Videó] Az Angular sötét oldala

Címkék

A modern szoftverfejlesztés egyik igen hasznos vívmánya a különböző fejlesztési minták elterjedése. Sokkal kevesebb szó esik viszont a velük egyszerre megjelenő anti-mintákról, pedig ugyanolyan fontos ismernünk őket, ha valamirevaló fejlesztővé szeretnénk válni. Az előadás során az Angular framework-re jellemző, igen gyakran előforduló hibás programozói mintákat fogjuk megvizsgálni, elemezni, és kijavítani.

Kiss Balázs (Webváltó) előadása a HWSW free! meetup-sorozat 2021. november 29-i modern webfejlesztés című állomásán hangzott

Hozzászólások

Szerkesztve: 2021. 12. 13., h – 21:59

https://hu.wikipedia.org/wiki/Antiminta
btw egyes vélemények szerint a singleton is az

Amúgy jó videó. Pont hasonló témákban kutakodom. Leginkább antipattern hibám feltárása és  kódszervezési módszerek  projekten belül.

Ebben olyan is van, amit premature optimization lenne kijavítani, pl. az Angular-t megkérni rá, hogy csak adott key változása esetén frissítse egy táblázat sorát.

Persze, ha 2000 soros a táblázat, és az egész program emiatt áll mint a cövek, akkor állítsuk be, de ha ezt valaki rosszul állítja be, évekig fogják vadászni, hogy mi a francé' nem frissül a táblázat.

Arról nem is beszélve, hogy emiatt törékenyebb is lesz a kód, kevésbé bírja ha megváltozik a világ körülötte... szóval néha az antipattern vadászat maga az antipattern.

2000 soros tablazatnal angulartol fuggetlenul fel kell tenni kereso mezoket, tudni kell sorbarendezni az oszlopokat, illetve kell meg egy lapozo. az elso 2-vel meg lehet talalni mindent, akik meg nem tudjak azokat hasznalni es szemmel akarjak megkeresni az adatot azoknak ott a lapozo.

neked aztan fura humorod van...

2000 soros táblázatnak backendből támogatott infinite scroll, meg reddis/solr/elasticsearch keresőbackend, meg sokminden kell, itt inkább arra céloztam, hogy:

user duplaklikkel, előjön a rekord formja, átír valamit, becsukja.

ha nem cseszegetem az angular-t, gondolkodás nélkül befrissül.

ha cseszegetem, akkor meg - ha benézem - nem.

és ez fontos akkor, amikor amúgy a táblázat hosszú, és a frontendes szűrhetőség, offline működés, meg hasonlók miatt betöltöm az egészet, de helyben lehet megörjíteni a usereket, ha ez amúgy csak pár sor, mondjuk egy autó 4 kereke.

Mi tartott ennyi evig? Par eve az jott mindenkitol, hogy milyen kurva jo, es senkinek nem lehetett elmagyarazni, hogy az Angular mekkora faszsag, meg hogy akkora JS dev csapatra talaltak ki, amekkorara csak Google meretu szereploknek van penze, nem startupokban kene eroltetni a maintaineleset.

Majd amikor kitalálják, hogy a natív programok sokkal jobbak, akkor lesz végre vége ennek az őrületnek.

De az csak 1 dologban más, nem? Hogy nem JS-ben írják de minden más kihívás/probléma azonos. Ugyanezt el lehetne érni úgy is ha a böngésző képes lenne JS helyett/mellett valami mást is futtatni, a Dart ebben elbukott a Wasm viszont nem, úgyhogy érkeznek a Qt C++ és C# "desktop" alkalmazások a böngészőkbe...

Ha mar ilyen iranyokba haladunk, jo lenne, ha lennenek emulacio-specifikus benchmarkok.

Jelenleg fogalmunk sincs mennyire gyors vagy lassu wasm-on a C++ Qt-val peldaul es mennyi eroforrast eszik, es ehhez kepest hogy teljesitenek mas jellegu retegezesek, es mindehhez kepest hogy teljesit maga a JS. Az informaciot is nehez megtalalni, hogy mit miben erdemes elkezdeni, ami nem JS.

Nem azonos implementáció, csak random google:  Qt és JS paint szerű dolog. Böngésző feladatkezelőjében a C++/Wasm Qt rajzolás közben 35% CPU-t és 383 MB RAM-ot evett, a JS verzió 75% CPU-t és 55 MB RAM-ot.

Az informaciot is nehez megtalalni, hogy mit miben erdemes elkezdeni, ami nem JS.

Hát ahol fontos a SEO ott marad a JS, ami meg alkalmazás (pl. dashboard, vagy XY termék szerkesztő/tervező alkalmazás, stb.) azt meg nem JS-ben. Egy landing page sosem lesz C++ Qt sem FlutterWeb, ellenben ezek létrehozására már létezik sok szoftver.

Én múlt héten egy sokkal egyszerűbb ökölszabályt tanítottam a MasterFieldben: ha zöldmezős és user interface, akkor JS.

Azaz azért nem találni ilyen anyagot, hogy miben érdemes UI-t fejleszteni ami nem JS, mert nem érdemes.

persze, vannak embedded eszközök amiken van képernyő és nem android fut rajtuk, de azok általában úgyis adottak.

desktopon amióta ha a teams-en nyomsz egy ctrl-shift-i -t, előjön a Chrome DevTools, ugyanez a Visual Studio-n is, a legnagyobb erőforrászabáló a grafikai tervezőprogram volt a gépemen mindig - idén migráltam Figma-ra. Nincs értelme non-JS desktop UI-ról beszélni.
 

kb az Office az uccsó natív app a gépemen, amit még rendszeresen használok.

Mert erre van ökoszisztéma. Kell egy plugin? Berakod. Kell plusz egy fejlesztő? GreenFox. Netről kell mennie? Megy. Kell linux app? Lesz. 
 

a FlutterWeb… hát anno volt az ASP.NET. Volt a java server faces. Volt a GWT 1.0. Volt a symfony meg a ruby on rails meg a django mindenféle jQuery-s izéi. Lehet azonos nyelven a frontend meg a backend, feltéve, ha az a nyelv a javascript/typescript. Az “írjunk backend nyelven webalkalmazást mert én senior *insert backendnyelv* programozó vagyok és fullstackeset akarok játszani, de neM vagyok hajlandó megtanulni a javascriptet/typescriptet mert elvből gyűlölöm”, ebből még mindig az lett, hogy akkor Béla te nem fejlesztesz frontendet és pont.

most az, hogy ebből van még egy (és a google-nél se ez az első), ez annyira nem befolyásol semmit.

Azért ne a js legyen már a non plusz ultra megváltás. A teams naponta háromszor fossa el magát és indul újra random művelettől. És cefet lassú az egész. És nagy. Egy sima iPad airen meg rányomok a hívás gombra és tíz másodperc múlva tárcsáz. Hát ez aztán nagy felhasználói élmény.

Az összes új weboldal is cseszett lassú eszi a CPU-t és lassítja az egész gépet.

Rühellem az egész kókány infrastruktúrát, hozzátéve, hogy ui ra választanám és fejlesztek benne ui oldalon.

Ahol lehet natívot választok mert ezek a js cuccok mindig valahogy rossz érzést keltenek bennem a használatkor. 

Nincs értelme non-JS desktop UI-ról beszélni.

Én ezt úgy írnám le inkább, hogy nincs értelme nem böngészőben futó desktop UI-ról beszélni, elsősorban disztribúció (frissítések) és a mérési lehetőségek miatt. De személy szerint azt nem gondolom, hogy a jövőben ez kizárólag kézzel írt JS-t jelent majd. Meg hát valamit kezdeni kell a frontend fejlesztők sötét oldalával amiről a fenti videó is szól, ennek első lépése lehet a JS kiváltása azokon a helyeken ahol már kiváltható.

Az antipatternt, "antimintának" fordítani ellenpélda helyett, nem egy kurva nagy "antiminta"?

Nekem is furának tűnt az "antiminta" ("anti-minta, régi Duna, kiskatona, ugorj a Dunába! Zsupsz!").

De szerintem az "ellenpélda" itt nem megfelelő. Esetleg "rossz gyakorlat" lehetne, az jobban kifejezi.

Szerk: az "antimitna" viszont nagyon jó palindróm lenne.

Ja! A címadásért jár az ajándék öklözőzsír. Le kellene már az ilyen címekről szokni. Minden cím a tartalomról szóljon. Legyen annak rövid kivonata.