jQuery - Přidání kódu s přidanými událostmi

„Je možné nějak přidat událost click už na prvním řádku nebo tohle je běžný postup?“

Běžný postup je si ten element vytvořit (createElement), přidat mu do onclicku, co má dělat a pak ho přilepit na potřebné místo (appendChild), tedy tak to je v normálním JS.

joe:
> nebo musím psát
> $(e). ...()
Proměnná e ti již odkazuje na instanci monolitického objektu jQuery, proč bys probůh chtěl tvořit nový objekt. jQuery knihovna je už dostatečně neefektivní ve způsobu jakým pracuje se svým objektem sama o sobě (při každém volání funkce $ dojde k zahození instance a vytvoření nové). Není nutné jí pomáhat. :)

joe:
„myslím ale, že někdy se mi stalo, že mi to hlásilo chybu, když jsem to právě neobalil $( ), ale asi jsem nepřistupoval k instanci jQuery objektu, právě this není, tak proto se to tak asi píše :) už mám jasno“
Ano, pokud instanceof proměnná == jQuery pak to nemusíš obalovat.

„Takže takhle to je správně?“
Pokud je tohle jediný způsob, jaký jQuery nabízí na vytvoření nového elementu (což se mi nezdá), tak ano. Pro potřeby čistoty kódu mi ale přijde tohle lepší:


OT: Už chápu, proč tu máme poslední dobou tolik javascriptem nepoznamenaných lepičů s dotazy ohledně jQuery, viz. text na stránkách nějakého příliš horlivého (nebo snad pomstychtivého?) člena fóra :)

jQuery – geniální javascriptový framework...
Pokud narazíte na neřešitelný problém, můžete zkusit některé české fórum o teorbě webu. Dobrou šanci na úspěch máte na diskusi.jakpsatweb.cz. Dotazy na téma jQuery směřujte do sekce JavaScript...

Zdroj: http://jquery.jslab.net/

joe:
Vytvoříš si funkci anonymní:


Mimochodem odkážu tě na časté potíže. Jedná se o téma se sepsanými základy syntaxe javascriptu a častými omyly. Světe div se, ty fígle fungují i pro jQuery, ačkoliv se její tvůrci snaží zapřít jazyk na kterém běží zuby nehty. :)

joe:
Problém bude nejspíš v tom, že instance jednoho Elementu je vložena do toku dokumentu vícekrát. To normálně není možné a pokud se pokusíš vícekrát vložit tu samou instanci objektu Element do dokumentu, nedojde k jejímu namnožení, ale pouze přesunutí. jQuery navrátí místo dané instance Elementu objekt jQuery, který se tváří, že dokáže objekt množit, ale viditelně to nefunguje tak, jak by mělo a to ani když vytvoříš element pomocí:

Můžeš zkusit nějaký z modulů: http://mg.to/2006/02/27/easy-dom-creation-for-jquery-and-prototype

Reaguji na Witika:
„Už chápu, proč tu máme poslední dobou tolik javascriptem nepoznamenaných lepičů s dotazy ohledně jQuery“
Ten text už je na zmíněném webu hodně dlouho a jsem za něj vděčný. Filosofické konfrontace jsou prospěšné.

„viz. text na stránkách nějakého příliš horlivého (nebo snad pomstychtivého?) člena fóra“
Spíš „váženého“. Vezmi si iniciály jeho jména, přidej 01 a máš jeho přezdívku.


Reaguji na joa:
„Myslím, že na dnešní dobu a rychlosti počítačů není jQuery problém používat.“
Samotný framework většinou nemá s výkonností problémy, neefektivní pitomosti vytvářejí většinou ti, kdo ho používají, protože si neuvědomují „cenu“ jednotlivých akcí.

joe:
„Tak to místo přidávání další knihovny nebo dalšího kusu kódu bude nejjednodušší napsat přímo atribut onclick do HTML, ne?“
Tím se při psaní funkcí omezuješ na čirý text bez možnosti předání jakékoliv reference na objekt.

Chamurappi:
„Spíš ‚váženého‘. Vezmi si iniciály jeho jména, přidej 01 a máš jeho přezdívku.“
Tak snad si to ah01 nevezme příliš vážně, bylo to myšleno s nadsázkou. Po pravdě řečeno mě víc zaskočil nadpis Geniální javascriptový framework než odkaz na toto fórum. :)

„Ten text už je na zmíněném webu hodně dlouho a jsem za něj vděčný. Filosofické konfrontace jsou prospěšné.“
Jsem rád, že je můj kritický pohled na jQuery prospěšný. :)

Witiko:
„jQuery knihovna je už dostatečně neefektivní ve způsobu jakým pracuje se svým objektem sama o sobě (při každém volání funkce $ dojde k zahození instance a vytvoření nové).“

Můžeš více přiblížit onu neefektivitu? Já bych rozlišil dvě věci.

První věc je ta, že chci-li využít javascript v několika jednoduchých scriptech, může být dostačující (a v poměru velikosti takového scriptu) i více prospěšné napsat si jednoduchý, dostačující kód sám. V tomto ohledu bych s tebou souhlasil.

Druhá věc je pak efektivnost, náročnost a rychlost provádění kódu. S tím dozajista jQuery, byť je jeho kód značně rozsáhlý, problém nemá.

Pokud jako neefektivnost bereš tebou zmíněné "při každém volání funkce $ dojde k zahození instance a vytvoření nové", o jakou neefektivnost přesně jde? Při mých testech vytváření 100 instancí v cyklu za sebou a porovnání všech moderních prohlížečů skončil nejlépe google chrome s časem několika milisekund. Pravda, IE ve verzích 7 - 9beta byl 8x pomalejší, pokud si však čas vydělíš hodnotou 100, "zahození a vytvoření nové" instance nepostřehneš.

Budu rád za kritické připomínky k neefektivním částem jQuery.

Suta:
„Při mých testech vytváření 100 instancí v cyklu za sebou a porovnání všech moderních prohlížečů skončil nejlépe google chrome s časem několika milisekund.“
To je pravda a také útěcha většiny pisatelů v jQuery. Nesmíš ovšem zapomínat, že je tu nezanedbatelná část uživatelů, kteří pracují z mobilních zařízení či starších počítačů. Kromě toho, že tato zařízení spolu se staršími prohlížeči nejsou ani ve velké většině podporována (viz. stránky jQuery - Podpora pro IE 6.0+, FF 2+, Safari 3.0+, Opera 9.0+, Chrome), dochází zde ke skutečně znatelnému poklesu v době výkonu scriptu (kromě celkové sobeckosti daného přístupu) v přímé úměrnosti k jeho délce (a také používání funkce $ tam, kde není potřeba). Jedno zavolání funkce $ a jedno zahození a vytvoření nové instance prototypu jQuery může být neznatelné, avšak s osmi voláními téže funkce na jedné řádce ke zpomalení dochází a k jeho logické kumulaci. Jedná se o problém v návrhu kódu a bez celkové změny API je neřešitelný. K tomu ovšem nedojde, protože tím by došlo ke ztrátě té "úžasné jednoduchosti" API, případně k jeho změně, což by způsobilo vlnu nevole. Místo toho řeší Resigův tým mikrooptimalizace, což je sice obdivuhodná, stejně tak však ta nejméně účinná změna, kterou mohou udělat.

Stejně tak oddělení OOP vrstvy od podložního API by rozhodně byl krok kupředu, ale to už se bavíme o bloat kódu - což však paradoxně mimo jiné také ovlivňuje velikost footprintu knihovny a s ním tedy i částěčně dobu zpracovávání (a samozřejmě stahování) jejího kódu na mobilních a starších zařízeních.

Myslím, že tohle zodpovídá i „Druhá věc je pak efektivnost, náročnost a rychlost provádění kódu. S tím dozajista jQuery, byť je jeho kód značně rozsáhlý, problém nemá.“ a poukazuje na fakt, že „problém nemá“ je velice vágní definice citelně postrádající objektivitu, které by nabyla poměřením s jiným frameworkem, který se svým kořenovým objektem nezachází tak velkodušně jako právě jQuery, nebo koneckonců s čirým kódem. Připomíná mi to ten oslavný graf úžasného navýšení rychlosti query selektoru od Johna Resiga k jQuery 1.4, který byl bez jednotek. :)

„První věc je ta, že chci-li využít javascript v několika jednoduchých scriptech, může být dostačující (a v poměru velikosti takového scriptu) i více prospěšné napsat si jednoduchý, dostačující kód sám. V tomto ohledu bych s tebou souhlasil.“
Jistěže, u delších scriptů jsme však svědky paradoxní situace. Za všeobecně platnou pravdu je považováno tvrzení, že čím delší je kód, tím oprávněnější je použití frameworku, podkládajíce toto tvrzení faktem, že se tak zvyšuje velikostní poměr kód:framework ve prospěch kódu. U jQuery toto neplatí, protože kromě velikosti frameworku musíme brát v úvahu i celkové zpomalení neustálým zabíráním prostředků tvořením a zahazováním instancí jQuery objektu pomocí volání jedné funkce, která si libuje v přetěžování. Toto celkové zpomalení je samozřejmě v možné míře můžeme sledovat i u konkurenčních frameworků, ale tam je povětšinou pouze symptomem exekuce funkce a s ní s spojeným vytvořením jmenného prostoru u čehož můžeme sledovat drobné zpomalení oproti čirému kódu. Takovýto způsob kódování (volání rekurzivní funkce namísto cyklu) je nicméně z větší části velmi dobře zvládán a rozdíly jsou marginální.


Samozřejmě většina vývojářů používá slovo rychlost v souvislosti s knihovnou jQuery ve spojení rychlost vývoje aplikací a stránek a jednoduchost kódu. To nelze jQuery upřít a pokud dokáže daný vývojář žít s tím, že uživatelé čehokoliv jiného než dnešního mainstreamového zařízení si budou rvát při návštěvě jeho stránek vlasy s hlavy a se zcela nezvládnutou abstrakcí (to samozřejmě není problém jen jQuery), má mnohonásobně ulehčenou práci. Proto asi to označení Geniální javascriptový framework na stránkách ah01.

Suta:
To co vytýká Witiko jQuery z hlediska výkonu je pravda. Je ale třeba si uvědomit, jestli to je v tvé aplikaci vůbec podstatné. Vytváříš komplexní JS aplikaci typu Google Maps, kde načítáš dynamicky mnoho obrázků a potřebuješ, aby to bylo co nejplynulejší? Používá nezanedbatelná část tvých uživatelů IE 5.5 nebo dokonce starší? Pak pro tebe asi jQuery nebude to pravé a musíš šáhnout po něčem jiném nebo si všechno napsat od základů sám. Pro zbylých 90% případů můžeš jQuery s klidným svědomím použít – nikdo to nepozná.

Jak píše Chamurappi:
„Samotný framework většinou nemá s výkonností problémy, neefektivní pitomosti vytvářejí většinou ti, kdo ho používají, protože si neuvědomují ‚cenu‘ jednotlivých akcí.“
Pokud se rozhodneš pro framework, musíš vědět jak ho správně používat. Výkonnostní problémy začni řešit, až na ně narazíš.

Witiko:
Ad „text na stránkách“
Ten text je tam už přes 2 roky. Díky za upozornění na překlep, opraveno.

Witiko, ah01:
Nechci polemizovat s tím, co Witiko vytýká jQuery. Ve své podstatě má pravdu. Jediná situace, kdy se mi ježí vlasy na hlavě a mám potřebu oponovat je tehdy, kdy je jQuery kritizován jako celek. A tady je právě rozdíl v tom, jak je na něj nahlíženo. Pravdou totiž je, že stejně jako může jQuery výrazně napomoci určité skupině koderů, stejně tak se může velmi lehce stát těžkopádným nástrojem, jež ztratí efektivitu. A pravidlo funguje i opačně - ano, jQuery může být a bohužel, často i je využíván nevhodně, nicméně, na mnoha místech a pro mnoho programátorů je neocenitelným pomocníkem.

Rozhodnu-li se jej používat, pak je efektivita jeho využití a efektivita kódu prováděného díky jQuery závislá na následujícím:

Mám jednoduchou stránku.
Na jedné straně můžu souhlasit s kritikou, jež v takovém případě nedoporučuje (v ostřejší reakci kritizuje) použití jQuery. Často jsou takovíto uživatelé odkazováni na vyhledání podobné jednoduché funkce, která se nachází na internetu. Ze zkušenosti však vím, že chci-li jednou využít jistý efekt či zjednodušení a ano, nejsem profesionál, je velmi pravděpodobné, že brzy budu chtít využít další. Vyhledání a začlenění takovýchto jednotlivých skriptů do stránky v případě, kdy javascript neovládám na vyšší úrovni může být velmi náročné. jQuery - či jakýkoliv jiný framework - s tímto může výrazně pomoci a ušetřit spoustu času.

Mám velký projekt.
Použití vlastní knihovny je pravděpodobné.

jQuery a mobilní telefony.
Souhlasím s tím, že v tomto případě není využití jQuery vhodné a může být těžkopádné, tedy všeobecně.


A ještě poznámka k efektivitě, těžkopádnosti a rychlosti kódu samotného jQuery. Ano, jQuery vytváří a zahazuje instance při každém použití. Ano, ve valné většině použití knihovny jQuery uživatel vlastním voláním využije jen malé procento kódu jQuery, ostatní kód nikdy nemusí zavolat. To může být bráno jako neefektivita. Já osobně však žádnou "praktickou neefektivitu" skutečně nevidím, protože v dnešní době jen velmi ojediněle uživatel použije takové zařízení, na kterém by jQuery pracovalo takovým způsobem, jež by jeho systém a odezvu stránky výrazněji zpomalilo.

Tzn. že, jak píše Witiko,
„U jQuery toto neplatí, protože kromě velikosti frameworku musíme brát v úvahu i celkové zpomalení neustálým zabíráním prostředků tvořením a zahazováním instancí jQuery objektu pomocí volání jedné funkce, která si libuje v přetěžování. Toto celkové zpomalení je samozřejmě v možné míře můžeme sledovat i u konkurenčních frameworků“ (...)
tento "problém" je jen teoretický, v praxi nemající opodstatnění.

Na druhé straně však skutečně platí, že jQuery může být použito nevhodně, viz Chamurappi:
„Samotný framework většinou nemá s výkonností problémy, neefektivní pitomosti vytvářejí většinou ti, kdo ho používají, protože si neuvědomují ‚cenu‘ jednotlivých akcí.“

Svatá pravda.

Suta:
„v dnešní době jen velmi ojediněle“
I kdyby jen 1% tvých návštěvníků přistupovalo ke stránkám z postarších strojů s windows 98 a MSIE 5, jedná se stále o část uživatelů, na něž musí být brán ohled. Nebo ztratíš kvůli použitému frameworku 1% svých zákazníků?

„tento "problém" je jen teoretický, v praxi nemající opodstatnění.“
Z této odpovědi jsem vyrozuměl, že jsi si vzal k ruce nějaké méně výkonné zařízení a porovnal jsi rychlost výkonu kódu za použití jQuery a bez něj? Pakliže ne, je tato odpověď naprosto vycucaná z prstu (opět). Stará zařízení jsou to, "kde se to počítá". Našlapaná mašina ti spolkne sebeneefektivněji napsaný kód bez cuknutí.

„Vyhledání a začlenění takovýchto jednotlivých skriptů do stránky v případě, kdy javascript neovládám na vyšší úrovni může být velmi náročné. jQuery - či jakýkoliv jiný framework - s tímto může výrazně pomoci a ušetřit spoustu času.“
Já nikde neoponuji tvrzení, že framework nezlehčí práci tvůrci, já tvrdím, že se to podepisuje na výsledném výkonu vytvořené aplikace.

Witiko:
Nechces toho špičkování už nechat, začínáš být trapnější než Chamurappi.

joe:
„Jak můžeš díky JS fw ztratit zákazníky?“
Třeba tak, že zákazníkovi zaseknu jeho prohlížeč tak, že přestane odpovídat? Není to ani zas tak těžké, většinu takových zařízení odvaří na půl minuty jen homepage facebooku. Chyba je samozřejmě ve vytvoření stránek - z nemalé části právě ve výběru javascriptového frameworku.

Kcko:
„začínáš být trapnější než Chamurappi.“
Pokud jsem tak trapný, jako Chamurappi, tak myslím, že jsem zatím v suchu. :-)

Pokud Ti věcné komentáře vadí, jdi na blog Johna Resiga, přispívej tam a klaň se nad jeho velkolepostí spolu s dalšími wannabe web developery. Proč vstupuješ do diskuze, ke které nemáš viditelně co říct, kromě vyjádření svého názoru na mě a Chamurappiho, jde mimo mě.

joe:
„vyzkoušel jsem a na nějaký to čekalo přes minutu“
Dovolím si poopravit - to je záměr. Facebook používá pro svůj chat metodu nazývanou Comet alias Server push, což je zjednodušeně řečeno způsob získání dat od serveru pomocí HTTP žádosti bez jejich výslovného vyžádání. Použitím speciálního mime type jako jedné z hlaviček dojde k navázání spojení se serverem, přičemž prohlížeč spojení neutne a neustále očekává další data. Jedná se o zajímavý koncept, který hodlám v několika projetech také využít.

„tak mi dáš za pravdu, že JavaScript při načítání nehraje moc velkou roli“
U AJAXu skutečně příliš ne, protože tady skutečně nemá javascript příliš velký manévrovací prostor. Situace začne být méně příznivá, když se framework pustí do manipulace s DOMem. Samozřejmě větší část zpomalení pochází ze strany uživatelů, kteří používají nesmyslné css query selektory, což se projeví u prohlížečů, kteří nepodporují document.querySelector nativně a musí tedy využít funkci frameworku na vyhledání elementů (u jQuery je to knihovna Sizzle).

joe:
„JavaScript za pomalost FB nemůže“
Skutečně není zase tolik možností jak prohlížeč pořádně zpomalit bez použití pluginu či javascriptu. V tomto případě zpomalení nemůže nebýt způsobeno javascriptem, je jím tvořena veškerá dynamika stránky, na statické stránce nemá co být pomalé.

Witiko:
„Nebo ztratíš kvůli použitému frameworku 1% svých zákazníků?“
Přesně tak. A naprosto v klidu. Budu-li ještě více upřímný, pak velmi rád a záměrně. A to je tebou zmíněné 1% v mém měřítku nic, byl bych velmi přísnější... Musíš totiž rozlišit dvě věci.

1. Pokud bych byl tvůrcem velkého portálu, jako je seznam.cz, facebook.com (...), nebo bych pracoval jako profesionální koder a vytvářel webovou stránku pro zákazníka, jež by při "ztrátě" 1% svých zákazníků měl nezanedbatelnou ztrátu, pak si tvrzení uvedené v předcházející větě samozřejmě nemůžu dovolit.

2. Proč bych tak však nemohl učinit v situaci, kdy vytvářím určitou webovou aplikaci, jež je založena na moderních technikách, jež jsou dnes dostupné pro 99% uživatelů (myslím co se týče technické vyspělosti zařízení, s nímž na mou stránku přijdou, nepočítám sem tedy hlasové čtečky zrakově postižených či zařízení jinak handicapovaných lidí, což se týče samotného rozhodnutí, zda-li vůbec a jak použít javascript - tohle nemá nic společného s jQuery), a naopak skutečně nejsou určeny uživatelům, jež používají proprietální zářízení? Vážně upravuješ své stránky tak, aby byly dostupné pro uživatelé s windows 98 či Internet Exploreru 5? Prober se!

Budu-li konkrétní, pak: osobně mě uživatel s Internet Explorerem nižším jak IE7 absolutně nezájímá a přijde-li takový na mou stránku, dám mu najevo, že s tímto prohlížečem to dnes opravdu nepůjde. Kolik takových asi bude? Budeš oponovat problematikou firemního rozpočtu, jež často neumožňuje přejít na současně používané prohlížeče? Ať jdou k čertu, nepotřebuji je. Avšak pozor, zdůrazňuji, že pokud by tomu tak však bylo, pak takto neučiním.

Tohle zodpovídá i:
„že jsi si vzal k ruce nějaké méně výkonné zařízení a porovnal jsi rychlost výkonu kódu za použití jQuery a bez něj?“ (...)
především proto, že takovýchto uživatelů je takové zanedbatelné množství (a nedokážeš mi z praktického úhlu pohledu opak), že mě jejich problém nedostupnosti stránky nezajímá.

Pochopitelně není solidární, pokud uživateli se zařízením, s nímž by na mé stránce využívající např. jQuery mohl mít problém, dovolím stránku zobrazit (a ten pak může čekat, aplikace mu může zasekat systém či cokoliv jiného). Dle mé teorie je však naprosto v pořádku, pokud sám takovéto zařízení informuji o požadavcích.

A několik věcí pro zamyšlení.

1. Proč tvůrci dnešních moderních PC her neoptimalizují moderní hry také pro stroje s méně výkonným hardwarem? Na slabším stroji si nezahraješ.
2. Na problematiku, kdy uživatelé se starším prohlížečem mohou mít se zobrazením tvé stránky problém, se můžeš podívat také z druhé strany. Oni mají zastaralý prohlížeč, ty však "musíš" ? často složitě optimalizovat tak, aby "oni" problém neměli? Můžeš-li si to dovolit, pak nemusíš.

Pokud vše výše uvedené dokážeš vstřebat, pak pochopíš moji obranu vůči tomu, že jQuery jako systém je neefektivní. Ty netvrdíš, že jQuery neulehčí práci koderům, jež jej využívají. Já zase netvrdím, že spoustu kódu, jež jQuery zprácovává, se nedá podstatně efektivněji vytvořit jiným frameworkem či obyčejnou funkcí. Z praktického hlediska však v dnešní době skutečně všeobecně nedokážu říci, že jQuery je neefektivní.