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/
Valasz a masik megosztasodban :)
VálaszTörlésAz lehet hogy óriási sebessegkulonbseg, de tesztelesi időben is. Ugyanis ha dobjuk jqueryt, akkor pedig a nyakunkba vesszük a cross browser teszteket.
VálaszTörlésA másik postban kb. ugyanezt írtam én is. :)
VálaszTörlésDehogymar egy .html() -bol innerHTML-re valtas hozza el a poklot. Erdekes modon sok site kepes ra, hogy jQuery nelkul is hasznalhato es modern tudjon lenni. Csak ott ugye fejlesztok vannak.
VálaszTörlésPersze, nem minden változtatás ilyen. Amúgy mi van a jQuery .html()-ben, hogy ennyivel lassabb, mint az innerHTML?
VálaszTörlésFogalmam sincs, de láthatóan drasztikus a sebesség csökkenés
VálaszTörlésBalazs Nadasdi Felénk azért egy innerHTML-nél komolyabb JS-ek futnak kliens oldalon, és hidd el nem ez okoz problémát... Úgyhogy mielőtt sértegetsz/kritizálsz másokat gondold át még 2x amit írsz, mert nem mindenki hello word-öt fejleszt JS-ben. Kb minden böngészőbe letesztelni amit csinálok sprintenként 1 nap plusz munkát eredményezne, szóval pont lesz@rom, hogy hány milliseccel fut lassabban.
VálaszTörlésAmúgy is le kellene. Én már kiváltalak volna ha nem tesztelsz.
VálaszTörlésDenagyapofádkiccsikó! Biztos elképzelhetetlen számodra, hogy azért használunk cross browser toolokat, hogy a cross browser tesztelés terhét levegye a vállunkról? Nem mondtam, hogy nem tesztelek, azt mondtam, hogy nem nézem meg minden támogatott böngészőbe (mert Qva sok idő, mert nem 30 sor JS keletkezik egy sprintbe). Teszteljük a program logikát. Script kiddie-k kíméljenek :D
VálaszTörlésHa készül test mondjuk jasmin vagy nagyjából bármi akkor ok. És a cikkben és utána a kommentekben nem is azt mondtam hogy ne használj, hanem hogy óvatosan. Sok balfasz jquery alatt mindent az ö belépett függvényeivel akar megoldani, holott ha csak a feladat 1/3-a nem azzal lenne mert van egyszerű megoldás anélkül is sokat dobhat raja. Ezért lett a példám a DOM query css szelektorral és a html értékadás. Biztosan van olyan amikor sokat segít, de ha nem kell akkor nem biztos hogy az a legjobb választás.
VálaszTörlésAmúgy lehet, hogy ez framework függő dolog. Tehát lehet, hogy valami a jQuery-ben pont el van b@szva, de van olyan cross-browser framework, ami megközelíti, vagy meg is haladja a vanillajs teljesítményét. G+-t pl. valami closure tools-al csinálták (https://developers.google.com/closure/), amihez van cross-browser lib, sőt még valami optimalizáló js-js compiler is. Egy ilyenről el tudom képzelni, hogy jobb kódot generál, mint amit kézzel írsz.
VálaszTörlésA másik ugye a GWT, amiben bízok, csak még nem volt projekt, ahol ki tudtam volna próbálni.
Esetleg érdekes lehet még, hogy milyen JS-t fordít a Dart-JS fordító.
Tehát én az ilyen JS fölé rakott rétegekben hiszek. De persze ezt is teljesítménytesztekkel kellene alátámasztani.
A js feletti rétegekben én is csak a jquery -ben nem
VálaszTörlés