Nagyon jó kis "anti-jQuery" írás. Igazából én azt mondanám, hogy egyszerűbb dolgokra, és olyan helyen, ahol nem annyira lényeges a sebesség, érdemes jQuery-t használni, mert sokszor jóval egyszerűbb ezzel megvalósítani valamit. Ugyanakkor ha ennek már tényleg látható hatása van, akkor érdemes elgondolkodni rajta, hogy kidobjuk a jQuery-t, mert ahogy az írásból látszik, sokszor drasztikus teljesítménykülönbség van a jQuery és a direkt JS megvalósítás között.
Originally shared by [Dev] Folyam.info
Ezért nem szeretem a jQuery-t
Sokan lehet furcsálják, de ez van. Nagyobb oldalaknál ahol használtam sokkal "szmúszabb" működést értem el csak azzal, hogy kiszedtem a #jQuery -t és írtam helyette (vele egy funkcionalitást adó) #javascript kódot.
#performance #web #development #dev
http://dev.folyam.info/blog/2013/05/26/ezert-nem-szeretem-a-jquery-t/
Jo csak, ha mar elkezdted jQuery-vel akkor kesobb lehet nagyobb szopas kiszedni, mint inkabb megbaratkozni azzal, hogy ott van. Talalkoztam mar sok ilyen esettel.
VálaszTörlésA masik pedig fajobb pont. Mikor felmerul, hogy szedjuk ki a jQuery-t, akkor egy huzo indok mindig, hogy a jQuery-t sokan ismerik es sokan nem tudnak logikusan felepiteni egy Js strukturat kar csak egy fuggveny ereig sem VanillaJs-el. Ez munkaero kereses szempontjabol igenis gaz. Sok felvetelizo van, aki tudja mi az a Js, de jQuery nelkul meg soha nem nyult a DOM strukturajahoz, ami azert nagyon is ciki dolog szerintem.
Mondjuk jQuery egy absztrakció is a DOM fölé, ami elrejti a böngészők különbségeit. Tehát ha elkezdesz direktbe js-el piszkálódni, akkor jobban oda kell figyelned, hogy minden böngészőben jól menjen, stb.
VálaszTörlésÉn most GWT-vel szemezgetek. Java, kulturáltabb kódot lehet írni, jobban lehet debugolni, optimalizál neked, és elfedi a böngészős különbségeket. Mondjuk érdekes lenne azzal is egy teljesítményteszt.
Ok, hogy elfedi, de ha pl megirsz egyszer valamit, akkor azt nem kell ujra megirnod. Ezen kivul a jQuery amiket csinal annak minden oldal (egyesevel nezve) kb a 20%-at hasznalja a tobbi 80 az csak szemet, ha jobban tetszik. Az meg szerintem, hogy megeri-e jobban odafigyelni vagy elfogadjuk a ~0.5-1milla ops/sec -es sebesseg helyett a 20-30k-t nem kellene hogy kerdes legyen. Ezen a gepen ezt produkalta es ez nem egy gyenge gep.
VálaszTörlésSokan azt hiszik, hogy milyen fasza mindent JavaScript oldalon lerendezni es csak XHR kereseket kuldeni a szervernek. Es igazuk is van. Amennyiben van errorHandler-ed, van statikus oldalgeneralasod (ami szerver oldalon tortenik), ami akvazi egyenlove teszi azzal, hogy a htmlgeneralast igy is ugy is meg kell oldalon szerver oldalon is. Tovabba addig jo csak, amig a kliens gepe birja. Tok jok az animaciok, tok jok a fade effektes tartalombetoltesek, csak elfelejtik, hogy sokan a tartalomra kivancsiak nem a diszitesre es megtobben nem is latjak a tartalmat, mert pillanatok alatt betolt az oldal, mert a szerver semmit se csinal vele aztan a gepuk belehal a DOM iras/olvasasokba.
Erre volt anno egy otletem, hogy requestAnimFrame felhasznalasaval figyelni a kliens allapotat es ha mondjuk 30 fps ala megy, akkor biza kovetkezo kattintasra ujratolteni az oldalt egy light.js betoltesevel, ami joval kevesebb kliens oldali szamitast igenyel es tobbet ad a szervernek. Sokkal tobb melo, de ha pl felhuzol 3 breakpoint-ot, es csinalsz 3 valtozatot, akkor lehet ki tudod ertelmesen szepen, ahogyan te szeretted volna szolgalni azt a reteget, aki kepes fogadni is azt, a gyengebb gepeken kevesebb a js oldali muvelet es a nagyon szar helyeken, vagy pl a Google Fetcher-nek ott a full szerver oldalon torteno mukodes.
Ja, ez mondjuk jópofa, csak elég macerásan hangzik. Ha nagyon pikk-pakkra meg akarok valamit csinálni, akkor ok. De azért az esetek nagy részében ember összerakja mondjuk AngularJS-el, meg pár jQuery plugnnel, és ezzel a látogatók 99%-a korrektül ki is van szolgálva. Szóval azért mérlegelni kell, hogy mikor érdemes ebbe (nem kevés) energiát ölni, és mikor nem.
VálaszTörlésEz olyan, mint hogy mindent írhatnál C-ben, és bájtra kiszámolhatnád a memet. Akkor optimálisan használná az erőforrásokat. De inkább JS-ben írod, mert azzal egyszerűbb megcsinálni. :)
Azert nem mindegy. Lehet, hogy nalad tok jo, meg azoknal akiknek tobbmagos gepe van meg miegymas, de vannak masok is. En most nem arrol beszelek, hogy felejtse el mindenki a jQuery-t, hanem hogy merlegelje mindenki mielott hasznalja. Sokszor pl ami eleg zavaro, hogy egy html elem teljes tartalmat az altalam is hasznalt html metodussal cserelik le. Tok jo meg minden, de semmivel se nehezebb a html elemre az innerHTML tulajdonsagot felulirni. Es lathatoan eleg sok kulonbseg van a ketto hasznalata kozott. Legutobb mikor a ShoppingAll-nal bekerult egy tok szep plugin galerianak olyan memory leak-je volt, hogy az mar komolyan fajt. Sokan azt hiszik JS-ben nem kell optimalizalni. Otthagytad a bongeszot es a kezdeni 15 megas Heap megnott 150-re pedig nem csinaltal semmit 5 oran keresztul. Kerestem masikat, az is szivargot, harmadik is, negyedik Flash alapu volt. Az otodiknel megelegeltem es az szivargott a legkevesbe, fogtam es kiszedtem azt, ami nem kell bele + par helyen atirtam. Nem nyultam hozza mindenhez, mert akkor mar irtam volna ujat, de mar 5 ora alatt csak 3.5 megat no az oldal memoriahasznalata. Ciki tudom. De ez igenis elmeny. Ha ezt az oldalt teljes egeszeben XHR toltesbol oldod meg, akkor biza az a memoria sose szabadul fel es a 8. oldal betoltese utan egyszeruen belassul az egesz bongeszo rosszabb esetben a gep is, mert ugye nincs oldal-ujratoltes es igy sosem urul ki magatol. Ha van 8 giga memoriad, akkor nem fogod megerezni, de ha csak 1 van, akkor igen. Es ez csak egy plugin volt. Ha ehhez veszed hozza, hogy a mar megfogyatkozott memoriad mellett a procit is igy terheli mert mondjuk a beszurasokat jQuery-s html metodussal csinalja nem innerHTML, sot megjobb esetben appendChild-al, akkor az is zabalja neked a procit, a te XHR-jeid is, es az egyeb dolgaid is.
VálaszTörlésHasznaljon mindenki kenye kedvere jQuery-t, de mindig merlegelje, hogy mikor hasznalja a beepitett fuggvenyet a jQuery-nek es mikor nyul inkabb a DOM API-hoz "kezzel".
Jó, mondjuk ez tényleg igaz. Gonoszul fel tud futni a böngésző memóriafelhasználása. Bár gazából nem értem, hogy miért működik ilyen szarul. Java-ban ez úgy menne, hogy megcsinálod az xhr kérést, lecseréled az objektumokat, a garbage collector meg kidobálja ami nem kell. Itt nincs gc?
VálaszTörlésDe van, csak sokmindenrol nem tudja, hogy kell-e meg. Peldaul van egy valtozod egy adott scope-ban mondjuk global aztan azt hasznalod egy kisebb scope-ban. Ha mondjuk az egy eventListener akkor biza sose szunhet meg. A Head pont az ami ugye felszabadul, ha vege a scope-nak, ami meg kell maskor is az meg atkerul a Stack-be. Ha van egy fuggvenyed, amiben van egy XHR keres es a callback-ben majd felhasznalod az adatot, akkor a scopenak mar vege van, de a callback miatt kell, raadasul, ha a callback-ben mondjuk felhasznalot egy fuggvenyhez, ami Click event-re figyel, akkor az a valtozo nem szunhet meg, igy ott marad. Viszont a lathatosaga 3 scope-on megy at, marmint eleg sok referencia marad ra a Click event miatt pedig nem szunhet meg es ha ez mondjuk egy nagyobb objektum, ami sokmindent tartalmaz es ebbol kvazi felhasznalsz egy-ket property-t, akkor az egesz megmarad. Akkor most helyezd bele zt egy felelotlen ciklusba (setTimeout, setInterval, for, while). Ez pl egy lehetseges szivargasi pont. De sok ilyet lehetne sorolni.
VálaszTörlésDe ugyan ilyen szivatas a multkor emlitett cikllusban fuggveny keszitese. Amikor letrehozod a fuggvenyt ugye lerejon a fuggveny, majd eltarolodik. Ha csinalsz egy ciklust es ott irod a fuggvenyt, akkor minden egyes ciklusban ujra letrehozol egyet, ujra eltarolod, ahelyett hogy egy cimre hivatkoznal. Ha tul sok a hivatkozas es tul kusza, akkor a GC is nehezen birkozik meg vele. Pelda: Csinalsz egy ciklust, amin vegighaladsz egy tombon, mondjuk div-eken. A divekbe XHR-el toltod a tartalmat, de ugy hogy felhasznalod benne a div elemet es rapakolsz bent egy click esemenyt is, amiben megintcsak felhasznalod az elemet this helyett. Ekkor ugye a fo nagy tombod orokre a memoriaban marad es lesz egy csomo fuggvenyed, ami nem szunhet meg a scope miatt. Ha 50 div-rol van szo, akkor lesz a memoriaban egy 50 elemu tombot, amiben DOM elemek vannak, tartozik hozza 50 darab kulonallo fuggveny. Es akkor vedd hozza, hogy nem sima 50 darab DOM elemrol van szo, hanem mondjuk jQuery-srol, ami ugye meg hozzatesz egy csomo mindent.
modositottam a szovegen utolag tehat, ha mar olvastad, akkor fusd at megegyszer
Aham. Mondjuk ez szerintem részben a JS "elbaszottsága", részben a fejlesztő sara. Annyit esetleg lehetne engine szinten csinálni, hogy amihez egy ideig nem nyúl, azt kipakolhatná fájlrendszerbe valami virtuális memóriára. Ezt egyébként lehetne csinálni más resource-okkal is, pl. görgetem a G+-t, és be van töltve 200 kép, mikor igazából csak 2-t látsz. Ezzel szerintem sokat lehetne spórolni, és mivel nincs rájuk gyakran szükség, nem venne el sokat a teljesítményből, mert jó eséllyel soha nem kell visszatölteni őket. Persze van oprendszer szinten is swap, de így szerintem hatékonyabb lenne, mert az engine maga dönti el, mit swap-el ki, plusz ez így crossplatform. Tehát ha az engine-t leforgatod mondjuk ARM-ra, és Androidon futtatod, akkor is működik.
VálaszTörlésFokent a fejleszto sara, de ha felhasznal egy plugint amit nem o irt es tele van ilyenekkel, akkor arrol konkretan nem o tehet megis az o sara lesz.
VálaszTörlésÚgy beszéltek, mintha nagyon komoly dolgokról lenne szó. Néhány apró js függvény is bőven elég lehet egy weboldalhoz.
VálaszTörlésKovács János Nem ma. Ma már egy csomó dolgot JS végez kliens oldalon. Nagyon sok weboldalnál a JS rész hatalmas. Sok felvoldalhoz nem csak egy XHR from küldés vagy egy alert ablak kell.
VálaszTörlésBalázs. Nagyon sok oldalon, de nem minden oldalon. Még mindig rengeteg weboldal van, amelyik csak alapvető dolgokra használ js-t kis mennyiségben. Nem kell túlzásba vinni a js használatát és akkor nem is kell olyan sok függvény. Persze ez alól vannak kívételek, pl facebook, ami egy igen összetett rendszer.
VálaszTörlésKovács János én eleve nem csinálok olyan oldalakat amiket össze lehet kattintani... Ahhoz nem kellek.
VálaszTörlésNem erre gondoltam. Inkább arra, hogy kis kóddal is lehet jó weboldalt készíteni. A gond akkor van, hogy kell ilyen funkció is, meg olyan is, amikor egyáltalán nincs rá szükség és nincs szinte semmi hozadéka sem.
VálaszTörlésKovács János A felhasználó elvárja, hogy oldaltöltés nélkül kerüljön a kosarába a termék, oldaltöltés nélkül nézhessen galériát, belenagyíthasson a képekbe ha egy portfólió oldalról van szó. Az XYZ holding kft oldalához, ami csak azért van, mert jogilag kell neki és lesz rajta 3 havonta egy közérdekű információ, oda meg baromira nem kelleke. Felhúznak egy Wordpress-t, felvesznek egy sitebuildert töredékannyiért, mint engem kellene és kész. Még jobb esetben vesznek egy témát hozzá.
VálaszTörlésNézd meg mondjuk az elmu.hu-t. Ott egy oldalbetöltés van, és után semmi, minden JS-ből megy. HTML-t direktbe nem is használtunk semmihez, csak belső tartalom jön abban. És alapvetően ez a tendencia.
VálaszTörlés