Javascript/JQUERY - pouzitie

anonymníí:
Tak nevím jaký argument mi můžeš napsat k tomu, že si sám raději napíšeš rekurzi na N míst, místo toho, abys ji napsal jednou a měl ji ve funkci, kterou budeš mít na všech projektech stejně pojmenovanou a řádně zdokumentovanou, abys ji příště nemusel hledat (to je to psaní vlastní knihovny/sbírky funkcí/... jQuery). Mám rád jednoduché věci, nesnáším složité řešení.

joe:
Proč se o to pořád snažíš? ;-) Já už jsem to dávno vzdal ... nemá smysl házet hrách na zeď ...
Nevysvětlíš ...

joe:
Nepsal jsem, že bych nepoužil funkci, to jsem psal hned ve svém prvním příspěvku. Vzal sis z něj jen to, co jsi chtěl.

Jen to nemusí být seznam funkcí, jak jsi to nazval ty, ale pár funkcí. Seznam působí moc velice, to není nutně pravda. O tom, že si napíšu jednu, dvě, tři funkce, jsem psal zkraje.

A pak, těch X míst bývá v řádu max. jednotek, ne ve tvých stovkách. To mi přijde z tvé strany nadsazené, nebo chybně napsané (v aplikaci, pokud toto potřebuješ tolikrát).

anonymníí:
Můžeš se zaregistrovat at víme s kým máme tu čest? Zatím na mě působíš jako bys sežral šalamounovo hov**

joe:
„Například úplně základní funkce, které by všude měl být - kontrola existence třídy, přidání nové třídy, odebrání, kontrola elementu vůči selektoru, nalezení nejbližšího rodiče, atp.“
Je fakt, že kontrolu existence třídy dodělávám poměrně často, ale existence a odebrání třídy jsou dvě jednořádkové funkce, na přidání se dá použít className += " jmeno" (ano, nekontroluje to, jestli ta třída už existuje, ale to obvykle ničemu nevadí).

Původní idea jQuery -podle mě a podle názvu jQuery- byla dotazování se na elementy DOMu přes selektory podobně jako v CSS. Jenže to dnešní prohlížeče zvládají přes querySelector a querySelectorAll

Jinak nevím, jestli k tomu svádí přímo jQuery, ale připadá mi, že s tím lidi občas dělají úplně zbytečné opičárny když problém má poměrně jednoduché řešení, kdyby se nad ním zamysleli.
Prostě občas někdo vykládá, jak jQuery nutně potřebuje, protože nativní funkce mu nestačí pro to co chce udělat. Pak se vytasí s kódem, kde šíleným selektorem vybere nějaký mezivýsledek, z něj se dalším šíleným selektorem dostane k dalšímu mezivýsledku a pak nějakou třetí operací najde požadovaný element.

A když se na to kouknu, zjistím, že by to celé šlo nahradit třeba jedním document.getElementById a jedním getElementsByTagName.

Možná to je trochu jako přísloví „Když máte po ruce jen kladivo, začne každý problém vypadat jako hřebík“. Když máte po ruce jQuery, začne každý problém vypadat jako něco, co vyžaduje kupu složitých selektorů :-)

„Kdokoli jiný přijde k projektu, bude muset hledat zda tam takové funkce někde jsou, jak se jmenují, možná narazí na chybu“
Udělat v těch zmíněných chybu je dost nepravděpodobné, je to jeden celkem jednoduchý příkaz a budiž, je možná rozumné si ty tři řádky kódu okopírovat podle jQuery.

anonymníí:

„Nepsal jsem, že bych nepoužil funkci“
Pak bys ji použil, pak ale vytváříš své funkce a vytváříš svůj seznam funkcí, které využíváš a z nějakého důvodu si to nechceš přiznat. Jen jsem psal, že je dobré mít tento seznam funkcí na každém projektu stejný (stejně funkční, stejně pojmenovaný, zdokumentovaný), ať nikdo další nemusí dohledávat, zda tam ona funkce je či není, protože je zbytečné to dělat. Jen jsem se to snažil vysvětlit na těch nejprimitivnějších funkcích, které se denně využívají.

„Seznam působí moc velice“
Seznam může mít třeba i jednu položku.

„A pak, těch X míst bývá v řádu max. jednotek, ne ve tvých stovkách. To mi přijde z tvé strany nadsazené“
Počet výskytu addClass na projektu, na kterém jsem nedávno pracoval je 170, pouze frontend. V administraci jich pak je přes 800.

Joker:
„ano, nekontroluje to, jestli ta třída už existuje, ale to obvykle ničemu nevadí“
Minimálně to vadí mně :-) a v Chromu, kde se pak duplikují nastavené styly pro element a není to pak přehledné.

„Udělat v těch zmíněných chybu je dost nepravděpodobné, je to jeden celkem jednoduchý příkaz a budiž, je možná rozumné si ty tři řádky kódu okopírovat podle jQuery.“
Ano, ale časem se kopírují další a další řádky, až se vlastně dojde k tomu, že by možná jednodušší bylo vzít celý soubor. A v případě, že se někdo pro celý soubor nerozhodne, vlastně si tak vytváří svou knihovnu, ikdyž odlehčenou.

Spíš se mi zdá, joe, že možná zbytečně používáš konstrukce, kterým by se dalo vyhnout. Potřeba třeba toho komplikovaného selektoru většinou vyplývá z neochoty navrhnout vhodný HTML kód.

Str4wberry:
Nebyl to nejvhodnější příklad, ale nastat to může. HTML nezáleží jen na mně, kolikrát musím pracovat s již hotovou strukturou a nemam moc příležitostí abych ji změnil.

joe:
„časem se kopírují další a další řádky, až se vlastně dojde k tomu, že by možná jednodušší bylo vzít celý soubor“
Nepozoruji, že by ten seznam měl tendenci se nafukovat.
Vlastně jak před vydáním jQuery, tak 8 let po něm, je to jedna funkce: hasClass. Dál uznávám, že se často hodí addClass, removeClass, getCookie a setCookie.

Když to vezmu obráceným směrem, i projekty, kde se jQuery použilo, využily jen mizivou část toho API (spíš drtivou většinu použití tvořilo opakování třeba tří-čtyř metod a sporadicky se používaly třeba tři-čtyři další).

Reaguji na joa:
„To není dobře, chybí kontrola, zda už stejná třída není přiřazena.“
Taková kontrola je užitečná jen tehdy, když při odebírání neodebírám všechny výskyty, ne?
Na jednom rozsáhlejším webu jsem si kdysi dávno napsal prakticky identický objekt, jako je později v prohlížečích zavedený classList. Pár řádků, žádná velká věda. Až úplně vymřou prohlížeče neznající classList, smrskne se to na jeden řádek. Pokud budu potřebovat přidávání tříd na jiném rozsáhlejším webu, použiju rovnou classList (s polyfillem), nevím, proč bych si měl zvykat na nějakou nestandardizovanou napodobeninu.

„kontrola elementu vůči selektoru“
Mně CSS selektory vůbec nepřipadají jako rozumně vymyšlený dotazovací jazyk. Neumějí zaměřovat textové uzly, fungují jednosměrně (jen dovnitř a dopředu), nepodporují @media queries, nepodporují hledání podle regulárů a jsou orientované na trošku jinou hierarchii dokumentu než je v DOMu (class má speciální podporu, name ne, selektory se starají víc o atributy než o vlastnosti). Podporují dynamické pseudotřídy a pseudoelementy, které v DOMu víceméně chybí, ale window a document jsou úplně mimo.

Kdybych kontrolu elementu vůči selektoru potřeboval, raději opět sáhnu po nativní metodě matchesSelector s polyfillem.
Zrovna tak, když potřebuji třeba trim na řetězci, nevím, proč bych si měl zvykat na $.trim, když prakticky všichni už mají String.prototype.trim a tam, kde není, jde též pohodlně doplnit.

Píšeš o základních věcech, které jsou tak oblíbené, že se je prohlížeče postupně učí nativně. Proč tedy spoléhat na nějakého prostředníka? Budou jeho zájmy vždy kompatibilní s mými? Nebudu v budoucnu nucený kvůli němu dělat nepříjemné kompromisy?


Reaguji na anonymníího:
„tedy i vím, jestli je např. rozbalený nebo není, a tím pádem, i jakou má třídu, aniž bych ji musel explicitně znovu zjišťovat a ověřovat“
Chytáš-li bublající události na společném rodiči, bývá často potřeba rozeznávat, na čem nastaly.


Reaguji na Kcka:
„Můžeš se zaregistrovat at víme s kým máme tu čest?“
Tuhle přezdívku používá už několik měsíců, myslím, že ani po registraci bys žádný smysluplný ad hominem argument nemohl vytasit :-)
Další nosorožčí výjevy typu „nehádejte se“ zde nebudou…

Joe:
Proč ne, ale můžeš říct, že lidé s pluginem noscript to dělají s nějakým rozumným důvodem? My jak tady jsme si ho vypínáme snad jen kvůli testování, další a jsem přesvědčen mizivé procento trpí paranoiou :). Bijte mě za to a válejte v sudu, ale být člověk dělající bez JS nepřístupné weby, klidně zapomenu že existují.

Joker:
Mně se hodí a denně používám: hledání podle CSS(3) selektoru (to je hodně návykové), addClass, hasClass, removeClass, is, ajax, data, funkce na AJAX, append, prepend, after, before, clone, bind, trigger, animace, ... je toho spousta na to, abych to všechno vypreparovával. a nazýval to svou knihovnou a nevím, která funkce se mi bude hodit i v budoucnu.

Chamurappi:
Je vhodné neduplikovat třídy na elementu minimálně z tohoto důvodu.

classList je fajn.

„Píšeš o základních věcech, které jsou tak oblíbené, že se je prohlížeče postupně učí nativně. Proč tedy spoléhat na nějakého prostředníka? Budou jeho zájmy vždy kompatibilní s mými?“
Uvidíme :-)

Škoda, že takové základní metody nejsou v základu JavaScriptu, hodily by se.

joe:
Škoda, že takové základní metody nejsou v základu JavaScriptu, hodily by se.
Väčšina tých "základných" metod tam je, všetko len brzdia stáre verzie prehliadačov, najmä teda IE. Napríklad classList ktorý si spomenul, insertAdjacentHtml - s ktorým prišiel práve IE už vo verzii 4 len mozilla to nepoznala až do verzie 8, matchesSelector a kopa ďalších.

Reaguji na Lextera:
„Proč ne, ale můžeš říct, že lidé s pluginem noscript to dělají s nějakým rozumným důvodem?“
Skripty jim brzdí načítání a otravují je zbytečné animace. Rozumím jejich důvodům. Kdybych používal pluginy v prohlížečích, zřejmě bych si NoScript nainstaloval také. Proč nemít nad věcmi kontrolu?

I kdyby neměli ke svému nastavení neměli rozumný důvod, tak jako autor budu rád, když můj web navštíví.


Reaguji na joa:
„Je vhodné neduplikovat třídy na elementu minimálně z tohoto důvodu.“
Nebudu u milionů návštěvníků vykonávat cosi navíc jen proto, abych měl lépe uklizeno ve své konzoli :-)
Dobrý argument proti duplikování by mohl být, že pokud se přežene, může mít dopad na celkový výkon. Kupříkladu kdyby se během animace šedesátkrát za sekundu přidávala tatáž třída…

„Uvidíme :-)“
Už vidíme. Momentálně šíří mezi méně pozorné lidi dvojkovou verzi knihovny, která nefunguje ve starších Explorerech. Jako každý dravý živočich v džungli webových formátů se učí, jaký mají vliv, tím, že vytvářejí problém. Je to další partner na scéně s vlastní hlavou a vlastními zájmy, spory o to, jak a zda mají věci fungovat, už nejsou jen mezi tvůrcem webu a prohlížečem.

„Škoda, že takové základní metody nejsou v základu JavaScriptu, hodily by se.“
Až tam za tři roky budou, půjde se závislosti na frameworku pohodlně zbavit? Jaký budoucí vývoj asi je v zájmu jQuery Foundation?

Mezi námi, když vezmeme JQuery a vynalézání kola do důsledků, tak to není žádná vyjímka. Dejme si ruku na srdce. Kdo nezkoušel u CSS level 1 vytvářet selektor engine jen pro srandu? Já teda jo sice ne v roce 1996, ale zkoušel a asi uspěl. Prakticky na tom samém principu (i funkcích) jsem dodělal i zbytek pro CSS 2 a 3, jakožto náhradu nynějších document.querySelecto a document.querySelectorAll. Vlastně to nebyla náhrada JQuery, ale Sizzle. JQuery je vlastně jen obal Sizzlu. JQuery vnitřek jsem vlastně nikdy nepochopil. Nepochopení nespočívalo ve fungování. Nepochopení spočívalo v zápisu. Jak někdo dokáže udělat něco jednoduchého tak složité? Koukali jste třeba na metodu, pokud se v selektoru naskytne pseudo třída :hover? No nechci říkat, že jsem odborník, ale pro mě to je extrém. Já prostě objektu upravím metody. A takto můžu pokračovat dokola. Jinak by se taky nestávalo, že nová verze JQuery je oproti starší o 80% rychlejší. Jak je to možné? Pak od JQuery 2.0+ máme haprování IE na úkor nějakých hloupých nesmyslů, které asi autory zaujali a připadá jim to jednoduší (efektivnější), leč nikdo neví proč.

No abych to celé zkrátil. JQuery jsem popravdě přestal používat, protože mě autoři iritují a nevidím v tom žádnou budoucnost.

Věřím tomu, že kdybychom dali tady na diskusi hlavy dohromady, tak nám za měsíc vypadne takový framework, který bude použitelný a převážně kompatibilní ve všech prohlížečích. Pokud bychom tedy dbali na nativní funkce/metody.

1Pupik1989:
„tak nám za měsíc vypadne takový framework, který bude použitelný a převážně kompatibilní ve všech prohlížečích“
A jsme zase u vynalézání kola. Pokud ti nevyhovuje jQuery, existuje mnoho alternativ. Osobně se mi hodně líbí řešení jménem Ender. Je to nástroj, který ti z vybraných knihoven „splácá“ DOM framework, takže tam máš ve finále jen to, co opravdu potřebuješ. Jako selector engine bych doporučil zest, nebo sel, pro manipulaci bonzo, nebo traversty a pro eventy bean.

Pořád se vynalézá kolo, akorát je více či méně kulatější.

Ender a traversty zkusím, až budu mít někdy Node.js.

Jednu dobu jsem používal i Google Closure, ale pak z toho sešlo. Nakonec přizpůsobuji HTML javascriptu, abych mohl dané DOM elementy lépe najít. To je asi nejjednodušší.

Reaguji na 1Pupika1989:
„Kdo nezkoušel u CSS level 1 vytvářet selektor engine jen pro srandu?“
Já si vyrobil hledání podle XPathu. Několik týdnů jsem si spokojeně xpathoval, než jsem si uvědomil, jak je to pomalé.

„kdybychom dali tady na diskusi hlavy dohromady, tak nám za měsíc vypadne takový framework, který bude použitelný a převážně kompatibilní ve všech prohlížečích“
Neshodli bychom se nejspíš na tom, co všechno má být odpovědností takového frameworku.


Reaguji na Radka9:
„Pokud ti nevyhovuje jQuery, existuje mnoho alternativ.“
Nemůžu si nevzpomenout na Legio :-)

joe:
„Mně se hodí a denně používám: hledání podle CSS(3) selektoru (to je hodně návykové)“
To jsem tu už psal, zatím jsem v reálném použití nenarazil na nic, co by nezvládl querySelector/-All.

„addClass, hasClass, removeClass“
Viz výše.

„ajax“
Tady bych řekl, že přes jQuery to je jinak než nativně, ale nevím, jestli lépe/intuitivněji/…
Výhodou jQuery je podpora starších prohlížečů, což úspěšně ruší jQuery 2. Paradoxně XMLHttpRequest má širší kompatibilitu, než jQuery 2.

„data“
S data() jsem měl jednak problém s rychlostí (možná od té doby zrychlilo) a jednak při kombinování práce s data-atributy přímo a metody data() se v některých situacích nevracela aktuální hodnota. Takže bylo nutné používat buď všude jen jQuery data(), nebo pracovat všude jen s data-atributy.

„funkce na AJAX, append, prepend, after, before, clone, bind, trigger, animace“
Jasně, tak pokud nějaký projekt využije všechno tohle, je lepší rovnou k němu připojit jQuery.

1Pupik1989:
„Kdo nezkoušel u CSS level 1 vytvářet selektor engine jen pro srandu?“
Já. Upřímně, před jQuery mě snad ani nenapadlo prvky DOMu selektovat podle CSS a i po jQuery jsem dlouho nechápal, proč bych to chtěl dělat.
Zřejmě jsem nebyl sám, vybavuji si perfektní začátek tehdejšího článku o jQuery na Intervalu:
„Chtěli jste někdy v Javascriptu pracovat s DOMem pomocí CSS selektorů? Ne? To nevadí, jQuery vám to stejně umožní.“
:-)
Nutno říct, že osm let po jQuery když vidím to slavné procházení podle CSS selektorů, převážná většina vypadá nějak $("#foo") a $(".foo"), tj. getElementById a getElementsByClassName.

Holt mě asi víc než vymýšlet šílené selektory baví vymýšlet, jak se k tomu prvku dobrat jednoduše :-)

Chamurappi:
„Nemůžu si nevzpomenout na Legio“
Jenže v té době jsem prostě s JavaScriptem stále experimentoval a jQuery jsem bral jako vzor. Taktéž jsem primárně JavaScript používal jen na manipulaci s DOMem. Dnes už ta knihovna ani nemá s DOMem nic společného (kromě načítání scriptů) a nabízí rozšíření core knihovny, ulehčuje vytváření konstruktorů a prototypů, typovou kontrolu, asynchronní programování a mnoho dalšího. ;-)

Podle mě to není o tom, co si člověk dokáže napsat sám. Musím si rozmyslet, jeslti chci čas věnovat vytváření knihovny, nebo vytváření produktu. Obvykle se chci soustředit na produkt a nevynalézat něco, co se dá možná udělat o trochu lépe, ale zabere mi to tolik času, že bych za tu dobu mohl mít půlku produktu hotovou.

Chamurappi: Myslím, že po 15 minutách bychom si vysvětlili, co má obsahovat a co ne.


Joker: Já v tom taky nevidím smysl a přizpůsobím si HTML. Prostě se mi líbí jen takové blbosti jako třeba softwarové WebGL nebo když někdo napíše, že je něco nemožné.