Kókányolás vs. szabványkövetés
2019-11-19T20:32:51+01:00
2020-04-17T09:36:43+02:00
2022-07-20T15:47:12+02:00
  • Amíg nincs későbbi post és max fél óráig... (post módosítás minimál tartalomra).
    Mutasd a teljes hozzászólást!
  • ..nem lehet itt törölni? :D
    Mutasd a teljes hozzászólást!
  • A CDN egy elfogadott iparági koncepció.
    Mi is használunk CDN-t, több MB-os jpg-k, png-k, mp3-ak, mp4-ek, zipek.. tárolására.

    200 kbyte-os szkripteket third party domainről, "script src"-vel betölteni, az szerintem továbbra is tréfa.
    Mutasd a teljes hozzászólást!
  • Részemről egészen konkrétan az idézett hozzászólásodra reagáltam.

    Kiegyezhetünk abban, hogy attól még komolyan vehető egy fejlesztő, ha adott esetben CDN-re épít?
    Mutasd a teljes hozzászólást!
  • El, igen, és nincs titkosítva.

    Este visszatérek erre (csak valamikor dolgozni is kell).
    Mutasd a teljes hozzászólást!
  • Hali!

    Szóval én abszolút nem vagyok az az arc, akit mindig mindennel tör a nyavalya…

    Inkább csak egyfajta „guru fenomén” (már az ex cathedra kinyilatkozásaidat nézve). 

    Ennek igen kimerítő részt szenteltem a szakdolgozatomban…

    Elkészült már? Van publikus elérhetősége? Nagyon érdekelne (főleg a szoftver-fejlesztés – filozófia „koordináta-térben” elfoglalt pozíciója).

    Mutasd a teljes hozzászólást!
  • Ez arra vonatkozik, amikor te odaülsz, és írod a kis kódod.

    A material ikonok (amik ugyanúgy a google fontnál vannak) teljes mérete 60 mega tömörítve.Ez nem a 200k jquery minify-olva, itt már érthető, ha az érintettek más megoldás után néznek.

    De mi nem erről beszélünk, hanem még mindig arról, hogy kinek nincs kedve körültekintően fejleszteni,  vagy éppen legalább VPS-t karbantarta(t)ni a 200 cpanel 1 core2duo-n típusú megoldásokkal szemben.
    Mutasd a teljes hozzászólást!
  • Még jó, hogy teljes kontextusban idéztelek:

    Komolyan vehető fejlesztő nem tölt be a googleapis-ról betűtípust (hogy egyebet ne mondjak).
    Mutasd a teljes hozzászólást!
  • Konkrétan az Angular Material saját template-je pontosan ezt teszi (mármint googleapis.com-ról tölt betűtípust).

    Szerinted a betűtípus lib? Most komolyan.

    Nyilván azt én sem fordítom bele a betűtípust semmilyen bundle-ba, mert akkor nem 2 meg 5 mega lenne.
    Csak azt hoztam fel, mert az a legszembeötlőbb, még WordPress témákban is egyből az arcodba szökik, nem kell hozzá egy sor kódot sem írnod.

    Szerinted miért?

    Tippjeim: hogy sajátosan gombolódósoknak legyen one-click install, emellett, hogy adatot gyűjtsenek látogatóról, üzemeltetőről egyaránt. A saját Terms-ük alapján ez a fő missziójuk, úgyhogy nem tartanám meglepőnek, ha igazam lenne.

    Viszont vannak még mindig platformok, amelyek nem támogatnak értelmes web betűtípus-formátumot, csak TrueType-ot.
    Igaz, hogy 2020 van, és ezek max vállalati gépeken vagy elmaradt területeken vannak, de anno mindenki tudta, hogy a TrueType betűtípus, az EXE formátum, és lehet benne vírus, úgyhogy aki akkoriban fejlesztett, az tudta, hogy ez bizalmi kérdés.

    De persze, aki falu haragjánál van cPanel-en, és olyan menő válalkozó, hogy a havi 1000-1500 forintos web üzemeltetési díjat is sokallja, az nyilván ilyeneken akar majd spórolni, és nem érdekli, hogy IE8-ról pl. nem lehet megnézni (és nem érdekelte 5 meg 8 éve se).
    Mutasd a teljes hozzászólást!
  • Bocs, nem akartam goromba lenni, csak néha kijövök a medremből.

    Szóval én abszolút nem vagyok az az arc, akit mindig mindennel tör a nyavalya, hogy írjuk át "ultramodernre", sőt, kiidegel, amikor valaki minden átgondoltság nélkül, esetleg valami holland, valamin rajtamaradt tudósforradalmár eszméje nyomán elkezd valamit tolni, és hirdeti mellé, hogy onnantól minden legacy, ami tegnap jött ki (ilyen például szerintem a "ReactiveX" nevű megközelítés).

    Ennek igen kimerítő részt szenteltem a szakdolgozatomban - a szakirodalom ezt a guru-jelenség néven ismeri, és a lényege az, hogy olyan arcokat raknak oda (techcégeknél, vagy állnak neki maguktól azon kívül) projektet tervezni és vinni, akiknek fő előnyük a népszerűség (hogy ez people person mibenlétükből, a nőknél aratott sikerükből, vagy valami egész másból ered, az másodlagos; de feltétel, hogy semmiképpen sem szakmai alapon jutnak el oda, hogy ezt elkezdhették elérni. Utána persze megy a hipihopi arról, hogy letettél az asztalra, meg mittudomén, ha rákérdezel valamire.).

    Álláspontom szerint például a Wordpress népszerűsége ezen alapul.

    Viszont ennél abszolút nem tartom előbbre azt, amikor valaki 2008 (vagy éppen 1997) eszméjét próbálja életben tartani.

    Volt olyan munkahelyem, ahonnan jelentős részben azért jöttem el, mert a kisfőnöknek ilyen dolgai voltak.
    Ha valamit nem bírok a szakmában, az a jó'vanazúgy hozzáállás (kivéve, ha például a megrendelő, már a megállapodást követően, khm, kancsóskodik).

    Az optimális az lenne, hogy a gondolkodó emberek egyfajta hegeli alapon a tézis és az antitézis felállítását követően megszülik a szintézist, amely nem olyan, mint 50 éve, de nem is a leghangosabb, legsikeresebb vagy legnépszerűbb alternatívát választják, hanem optimális esetben kidolgoznak valami átgondoltat, kevésbé optimálisban pedig alapos kutatómunkával választják ki a célokhoz megfelelő technológiát.

    Ezért szeretem az elektronikát. Veszel egy modult, összedugod ész nélkül, füstöl.
    Persze, Chen küld másikat másfél dollárért, éhen nem halsz - de ha semmilyen tanulságot nem vontál le, az is füstölni fog.
    A szoftveriparban - sajnos - mindent megcsinálnak (ha lehet, ha nem). Ahogy egyesek másra előszeretettel mondják, nincsenek fékek és egyensúlyok..
    Mutasd a teljes hozzászólást!
  • Komolyan vehető fejlesztő nem tölt be a googleapis-ról betűtípust (hogy egyebet ne mondjak).

    (...)

    A modern frontend megközelítés nem használ URL-ekről betöltött libeket. Egyáltalán.

    Konkrétan az Angular Material saját template-je pontosan ezt teszi (mármint googleapis.com-ról tölt betűtípust).

    Szerinted miért? Miért nem fordítják bele a bundle-be?

    Talán nem tekinthető modern frontend megközelítésnek egy Angular/Material páros? Ez Pistike CDN-esdi, és nem komolyan vehetőek a fejlesztői?
    Mutasd a teljes hozzászólást!
  • Ez nemhogy nem probléma ("gyerekem nálatok lakhatna" példád), hanem egyenesen javasolt gyakorlat.

    A modern frontend megközelítés nem használ URL-ekről betöltött libeket.

    Egyáltalán.

    ESM importban nincs is URL támogatás (vagy ha van is, olyan a jelentősége, hogy nincs külön példának sem kiemelve).

    Ha nagyon akarsz szenvedni, ilyen unpkg félékkel lehet.. de ha resolve-od nincs rá, akkor teljesen értelmetlen, mert csak teleszemeteled a window namespace-t a mindenféle global referenciával.

    "Use dynamic import only when necessary. The static form is preferable for loading initial dependencies, and can benefit more readily from static analysis tools and tree shaking."

    import

    Hangsúlyozom, ez csak a natív ESM támogatásra vonatkozik.
    A bundling (webpack, rollup, fülem tudja, mik vannak még) require/resolve implementációk abszolút nem támogatnak randomURL-húzgálásokat.

    Persze véletlenül sem gondolom, hogy ez, vagy az irány jobb és követendő lenne - de véleményem szerint annál sokkal jobb, mint ez a Pistike-CDN-esdi, amiről itt ti beszéltek.
    Mutasd a teljes hozzászólást!
  • A lényeg, hogy a böngésző legfeljebb kettő-három JS irányú kérést fog indítani (chunking strategy-től függetlenül).

    A legnagyobb projectek bundle-ja, amelyeken dolgoztam 1-2 MB-nál megállt (nem frontendes vagyok elsősorban), így nem nagyon van tényleges tapasztalatom nagyobb méretű klienseknél, de ha egy ilyen 5 MB-os bundle jönne szembe, én nem egy-két chunk-ot generálnék, hanem pont, hogy valamilyen dinamikus modul töltést alkalmaznék (pl. Angular implementáció), a libeket pedig pont, hogy párhuzamosan tölteném CDN-ből (egyszerre talán 6 szálon tölt egy böngésző, szóval libek mérete/száma dönti el a tényleges darabolási stratégiát, hiszen a túl sok kicsi file nyilvánvalóan lassúbb lehet adott esetben).

    Tehát a közös libeket igenis CDN-ből tölteném és nem fordítanám a bundle-ba, pont a meglévő cache kihasználása végett. Ez nemhogy nem probléma ("gyerekem nálatok lakhatna" példád), hanem egyenesen javasolt gyakorlat. Nagyterhelésű oldalakról beszélünk, ahol 100 ms javulás is érezhető lesz már az 1M+ egyidejű request esetén.

    Felesleges mindenféle oktatási követelményekre való célzásokat tenned, amikor nyilvánvalóan teljesen irreleváns a hosting cégek üzleti modellje itt. Rengeteg cég közvetett módon szerez bevételt abból, hogy ingyenes CDN szolgáltatást nyújt. Ha valamelyik majd fizetős lesz, akkor átmész egy másikhoz vagy kifizeted, mert megéri.

    A CDN-ek üzemeltetése kiforrott technológia, amelyekre tömegesen épülnek szolgáltatások. Fallback-re célszerű felkészülni valamilyen regionális, tranziens hiba miatt, de emiatt nem kihasználni az előnyüket, szerintem szakmai hiba.
    Mutasd a teljes hozzászólást!
  • Sőt igazából ha összeraktad, akkor már nem tudsz kihagyni belőle. Tehát mindent be kell töltened, pedig lehet hogy az adott oldalon nincs is szükség mondjuk a jQueryre. Vagy request közben rakod ki a CDN-re?

    Pont a CDN analógiával élve mindegy, hogy az adott oldalon mi van..
    Egyszer betöltöd a 2, 4, 5 megabyte adatot (mondjuk az 5 megát, azt CSS-el együtt értettem; van egy új hóbort, a node.js-eseknél, hogy a CSS is legyen .js file-okban, és majd require-olják (import-olják).. ez is megér egy pár misét, de ettől most eltekintek)..

    ..és onnantól semmilyen külön asset-et nem kell betöltened.
    Többet.
    (Amíg nem módosítod, persze.)

    Nyilván ez szíven üthet valakit, ha például mobilon az online erőműtervező alkalmazásodnak egy landing page-ére érkezik, ezt teljesen elfogadom. Mindazonáltal ezt a Pareto elv alapján is edge case-nek tekinteném.

    És innentől legacy és hybrid/progressive architektúráknál némi HTML, míg abszolút single page-eknél legtöbbször csak az initial data fog érkezni emellé, az utóbbi valahogy összecsomagolva.

    (Én különben abszolút nem vagyok single page fan - ennek az okai elsődlegesen a garbage collection hátrányai témájú kutatásokban, illetve a böngésző memóriakezelésében keresendő. De ettől egyelőre túl sok HTML-t mostanában nem írok.)

    Ha a google CDN-jét használod, akkor azt már simán letölthették még azelőtt, hogy a Te appodat megnyitották volna.

    Ezt azért én fenntartanám azoknak előnynek, akik drive by / online sales bullshittel foglalkoznak.
    Mindenki másnak (tudniillik, akik látogatóinak többsége vagy visszatérő, vagy legalább egy másik aloldalt meglátogat) a bundling előnyei inkább tetten érhetőek.
    Mutasd a teljes hozzászólást!
  • Ha a google CDN-jét használod, akkor azt már simán letölthették még azelőtt, hogy a Te appodat megnyitották volna. Az emberek többsége nem törölgeti a böngésző előzményeket. Ráadásul a Te saját CDN-ednek lesz elég sok más dolga. Oda kerülnek a képek is, amik mondjuk egy egy cikkhez készültek. És ez a szerver fogja kiszolgálna ezt a tök ismeretlen 4-5 megás összerakott filet, aminek a nagy része külön külön már ott lehet az ügyfél gépén. Sőt igazából ha összeraktad, akkor már nem tudsz kihagyni belőle. Tehát mindent be kell töltened, pedig lehet hogy az adott oldalon nincs is szükség mondjuk a jQueryre. Vagy request közben rakod ki a CDN-re? Vagy minden variációt kiraksz? Akkor a cachet ölöd meg. Erre világított rá netuddki (tudod, a vulgáris nevű, aki megnevezhetetlen ).
    Mutasd a teljes hozzászólást!
  • a try/catch blokk, amiről a vitánk szól

    vs

    Te nyilván mindegy for/forEach előtt megvizsgálod hogy az a tömb üres-e

    Igen, valóban hibakezelésről beszéltünk. Egy keresésnek lehet az az eredménye, hogy nem talált semmit. Lehet, hogy nincs az adott kategóriájú termékből még egy sem lett felvéve. Ezek üzletileg teljesen valid esetek*. Ergo, amikor foreach-csel létrehozod a html-t, akkor a megrendelés gomb létrehozása pontosan 0-szor fog lefutni és pontosan 0-szor fogod rátenni az eseménykezelőt. Legalábbis elméletben. Ha egy üres eredményhalmaz mellett lefut a kód, ami bekötné a megrendelésgombot (=nem létező gombra eseménykezelőt teszel), akkor arról lehet tudni akarsz.

    * Az üzlet szeretni szokta, ha egy üres listára kiírod, hogy tényleg üres és nem felhasználói vagy programhiba történt, szóval igen, elég gyakran lekezelem az üres listákat is. Ettől viszont most tekintsünk el, nem ez a lényeg.

    Amúgy meg lustaságból én is sokmindent szeretek elhagyni a kódban. De amikor ebből hibák esnek ki vagy rákérdeznek, hogy miért van az úgy ahogy, akkor elismerem, hogy ezt lehetett volna jobban is és nem próbálom mindenáron megvédeni magamat.
    Mutasd a teljes hozzászólást!
  • De nem töltötték le mind a 26 classodat, amit természetesen nem egy fájlba írtál, hogyan tölthették volna le? Honnan?

    Az, hogy a 34 külső library-t letöltik, az nem oldja meg a problémádat.

    Hát meg van, akinek AWS, Azure meg Google nélkül is van Web, és én ennek inkább a terjedésére számítok, bár ez lehet, csak tangenciális.
    Mutasd a teljes hozzászólást!
  • Tehát eljutottunk oda hogy a webre fejlesztünk web nélkül.  Én ilyesmivel nem szoktam görcsölni. Elfoglalom magam mással, míg elmúlik ez a lehetetlen állapot. Egyébként pont azt magyarázta netuddki, hogy bár van 35 requested, de csak egy vagy egy se megy kifele. Már azelőtt, mielőtt bárki a Te appodat elővenné, letöltötték.
    Mutasd a teljes hozzászólást!
  • Mert elvileg Te egy olyan hibát üldöztél, ami valójában nem hiba, csak a JavaScript kezeli hibaként.

    Ez ilyen Google-filozófia. Kitalálták, hogy a HTTP3-ban (QUIC) legyen implicit request bundling.
    Gondolom, az ő junior fejlesztőik is úgy gondolták, hogy a protokoll dolga eldönteni - nyilván nem az architecté - hogy mely kéréseknek kellene hova egyszerre menniük, ezért született ez a megoldás, mert elegük lett belőle :D
    Mutasd a teljes hozzászólást!
  • Ha pedig a mért számít akkor preact.

    Csak a preact! :D
    Én ráadásul (abomination warning) ES5 szintaxissal (de nem createClass-al), és JSX nélkül tolom.

    "Hatalmas" előnye, hogy ha valam(ely)i(k) kiidegel, akkor tök ugyanazokat a komponenseket simán kirenderelem egy Mithril-el vagy egy Svelte-vel is.

    Ha meg valaki megkérdi, hogy "ez mégis micsoda?!", akkor legfeljebb 3 jól megformázott regexszel át tudom alakítani ES6-ra :D
    Mutasd a teljes hozzászólást!
  • A CDN lényege pont az lenne, hogy az újrafelhasználható komponens nagy eséllyel már megvan a kliensnek a böngésző cache-ben, így gyorsabban tölt az oldal + nem terheli a webszerveredet.

    Ez talán egy "jquery.js", "jquery-ui.js", "slideshow.js" meg "site.js" minta (portfólió oldal pl.) mentén megfelelő lehet..

    De egy összetettebb site-nak a UI kódja mondjuk 4-5 megabyte is lehet, ami áll 5-10 (rosszabb esetben 300) külső libraryből, valamint 10-20 (rosszabb esetben 1) saját JS-ből.

    Ilyenkor elvárható, hogy pl. a webpack-el összemókolod egy-két chunk-ba, majd azt minify-olod. A lényeg, hogy a böngésző legfeljebb kettő-három JS irányú kérést fog indítani (chunking strategy-től függetlenül).
    Nyilvánvaló, hogy ebből egyetlen chunk sem fog sansszal semmivel sem megegyezni (hacsak nem valaminek a demo app-ját, hello world-jét, create-%s-app-ját, homestead-jét berhelted szét, egyelőre még említésre nem méltó módon).
    Cserébe nem kell 20-50 requestet megvárnod (plusz még ugye az a múmia időkben elterjedt szokás, hogy majd valami betölt, akkor $(document).ready-n elkezd valami mást töltögetni, annak a .done-jából jön megint valami más, és így az oldal betöltődése 8-10 sec is lehet csak azért, mert minden chainelve van és vár valamire, amik amúgy párhuzamosan kellene, hogy menjenek).

    Mondjuk állítólag lassan minden böngészőben van Node=>ES6 import támogatás, ez egyesek szerint majd jól kinyírja a bundling-ot, de szerintem nem nyújt megoldást a 30(0) request problémájára..

    Az, hogy csökkenti a szerverterhelésed, azt elnevezhetjük hi-tech-nek, meg civilizációs vívmánynak, vagy akár nyugati alapértéknek is, de hagyományos formális logikával ismerkedőként ugyanaz a kérdés, mint amikor valakit megtalálsz azzal, hogy "Te, figyelj, nem lakhatna minden második nap a gyerekem nálatok? Csak mert sokkal több kaja maradna nálunk a hűtőben."

    Az meg, hogy valaki elhiszi, hogy fenntarthatatlansága ellenére ingyen van és mindig így lesz, az.. hát.. az egyik legfőbb érv azok kapcsán, akik a felsőoktatási végzettség követelményét támasztják..

    A legfőbb, rutinpistikék számára is érthető problémát (hogy a francba fogsz fejleszteni, ha épp nincs Interneted) a fallback megoldásoddal valóban némileg körbe lehet járni - de az fontos, hogy ha a böngészőre bízod a fallback-et, átlagos esetben 1-2-5 perc is lehet, mire el-timeout-ol az eredeti kérés, hogy kiszolgáljon (pl.) localhost-ról..
    Mutasd a teljes hozzászólást!
  • én úgy szoktam, hogy ha kész vagyok vele, akkor leellenőrzöm

    Ezt már nem is kommentálom :)
    Mutasd a teljes hozzászólást!
  • Hát, megmutathatnám egy most készülő projektemen a console.logot, akkor belátnád hogy nem éri meg De akkor Te nyilván mindegy for/forEach előtt megvizsgálod hogy az a tömb üres-e, mert ha nem, akkor csak másoktól várod el azt, hogy átgondolják hogy 10 év múlva a 20x megváltoztatott kód nem-e fog valakinek kellemetlenséget okozni, ha ezt kihagyja. 

    Most gondolj egy olyan példára hogy mondjuk vannak termékek, amiknek a "megrendel" gombjára teszem rá az eseménykezelőt. És akkor jön az az eset, amikor nincsenek termékek. Hiányozni fog valakinek az a gomb? Az lenne baj ha kint lenne. Úgyhogy ebben az esetben pont nem a tömb ürességét kellene ellenőriznem. De ezt sem teszem, mert nem számítok ilyenre. Te nyilván igen, ezért Te ezt az ágat is lekezeled. És jól teszed, mert valaki később létrehoz egy olyan osztálynévvel egy gombot, akkor hamarabb kibukik a hiba.

    Ettől függetlenül a try/catch blokk, amiről a vitánk szól, még megmaradna arra, amire szerintük nem való. Az hogy valaki a catchet nem tölti ki, vagy mielőtt egy tömbön valaki végig iterál, előtte nem ellenőrzi hogy üres-e, az már inkább attól függ, hogy mi lehet a következménye. Azt viszont másoktól ne várd el, hogy végiggondolják a program minden változását a következő 10-20 évben. Magaddal szemben lehetsz ennyire igényes, de másoktól dőreség ezt várnod.
    Mutasd a teljes hozzászólást!
  • A te példádban fel akarsz tenni egy eseménykezelőt egy gombra, ami nem létezik. Az a gomb hiányozni fog valakinek, nem? Szerintem egy console.log-ot megér...
    Mutasd a teljes hozzászólást!
  • Na jó, de mi lett volna a megoldás? Ha ott van egy 25 sorból álló if szerkezet, ami semmi hibát nem jelez, csak elnyeli a problémát, akkor hamarabb találtad volna meg a hibát?

    Mert elvileg Te egy olyan hibát üldöztél, ami valójában nem hiba, csak a JavaScript kezeli hibaként. Ezért került a try/catch blokkba. Ha valóban hiba lett volna akkor a catch nem üres.

    Tehát mi lett volna a megoldás? Egy olyan megoldás, ami elnyeli ugyan a hibát, nem küld emailt, nem naplóz, stb, de Te könnyebben megtalálod.
    Mutasd a teljes hozzászólást!
  • Amit nem veszel figyelembe az a kód karban tartása. Az addig ok, hogy te megírtad és az is, hogy akkor működött. Eltelik 10 év, rajtad kívül kb 6 másik ember nyúlt már hozzá. Tegnap feladtak egy hibajegyet, ami aztán az én mailboxomban landol, hogy ki kellene vizsgálni. Namost, itt vagyok egy hibával, ami semmilyen módon nem kerül logolásra, egy olyan kódbázis mellett, amivel nemigazán foglalkoztam, nem ismerem. Amikor rátalálok az üres catch blokk-ra 3 nap után, akkor talán jogosan érzem azt, hogy aki azt benne hagyta bármilyen meglátásból az elvett 3 napot az életemből... (valós történet alapján)
    Mutasd a teljes hozzászólást!
  • Nem tudom hogy Ti hogy dolgoztok, de én úgy szoktam, hogy ha kész vagyok vele, akkor leellenőrzöm. Az én tesztesetemben biztos hogy ott lesz a .keres és a clikcre le fog futni az alert. A későbbiek folyamán viszont előfordulhat hogy nem lesz ott az az elem.  Azt hogy elírtam-e valamit, másképp nem tudom leellenőrizni. Ideiglenesen beletehetek egy ellenőrzést, hogy $('.keresd').length >0, de ezzel még nincs elellenőrizve a munkám. Nekem a teszt alkalmával a rárakott eventet kell leellenőriznem. Tehát rá kell kattintanom az elemre. Előfordulhat, hogy arra az elemre kattintani se tudok.  Nem tehetem meg hogy nem tesztelem le manuálisan. Ahogy írtam már, ha fontos hogy az az elem a későbbiek folyamán ott legyen, akkor készül rá egy ellenőrzés, és ha nincs ott, akkor gondolom mennie kell valami hibaüzenetnek is, amit úgy se olvas el senki egy felhasználói felületen
    Mutasd a teljes hozzászólást!
  • Komolyan vehető fejlesztő nem tölt be a googleapis-ról betűtípust (hogy egyebet ne mondjak).

    Ez mondjuk nem nagyon vágom, hogy érted.

    A CDN lényege pont az lenne, hogy az újrafelhasználható komponens nagy eséllyel már megvan a kliensnek a böngésző cache-ben, így gyorsabban tölt az oldal + nem terheli a webszerveredet.

    Az más kérdés, hogy célszerű fallback-et használni, ha a CDN-nel gond lenne, de önmagában miért is probléma ez?
    Mutasd a teljes hozzászólást!
  • $('.keresd').bind('click', function(){alert('click')})

    .....

    akkor sem tudnám, hogy mi történik, mert nem érdekel 

    Nem érdekel, mert nem veszed észre a program végrehajtásáig (rossz esetben egy eldugott, kritikus, de ritkán futó ágig), hogy a sztring konstansként átadott paramétert (aka '.keresd' & 'click') elírtad.
    Mutasd a teljes hozzászólást!
  • Te hoztad fel hogy ne a jQueryt/vagy akármi mást használjunk.
    Mutasd a teljes hozzászólást!
abcd