Přejít k navigační liště

Zdroják » Zprávičky » Peppy: Hledání elementů v DOM snadno a rychle

Peppy: Hledání elementů v DOM snadno a rychle

Zprávičky JavaScript, Různé

James Donaghue zveřejnil první beta verzi javascriptového nástroje Peppy, který slouží k procházení DOM stromu a hledání elementů. Hledání je kompatibilní s CSS3 selektory. Vzhledem k velikosti (10kB) a k faktu, že funguje nezávisle na jiných knihovnách ve všech hlavních prohlížečích, by mohl být ideální volbou pro aplikace, které intenzivně pracují s DOM stromem.

Autor uvádí, že jeho knihovna je rychlejší než obdobné nástroje, použité ve většině JS frameworků (Prototype, jQuery, YUI apod.) a své tvrzení podporuje zajímavým benchmarkem.

Komentáře

Subscribe
Upozornit na
guest
5 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
jkubos

Prototype v tomhle testu tedy pořádně pohořel. Napadá mě několik důvodů:

– data vrací v rozšířených (extended) kolekcích, což může být pomalejší, než použití nativních

– vrací rozšířené (extended) DOM elementy, což může být pomalejší, než použití nativních

Neznám ostatní frameworky, ale pokud opravdu vracejí jen standardní kolekci standardních DOM elementů, pak se obávám, že ten test porovnává neporovnatelné. Stačí si představit kód následného zpracování vyhledaných elementů – nativní DOM (řešení nekompatibilit browserů) versus extended DOM prototype (Ruby styl práce). Takže to vidím na klasický problém: efektivita/elegance.

Martin Hassman

test porovnává neporovnatelné

Test Slickspeed porovnává přesně to, co porovnat má (a jak vývojáři prohlížečů, tak frameworků jeho výsledky dobře sledují), tedy čas pro získání objektů (ostatně řada vývojářů používá právě jen to a zbytek frameworku ignorují). Pokud bychom chtěli testovat nejen navrácení objektů, ale i jejich zpracování, mohl by výsledek možná dopadnout jinak, ale to už by byl úplně jiný test.

jkubos

Já jen tvrdím, že počet vrácených objektů není objektivní kritérium – pokud jeden vrací obyčejné DOM elementy a drůhý rozšířené. Tohle by tam mělo být explicitně zmíněno.

Martin Hassman

Jenže objektivní kritérium pro co? Ono „pro co“ je důležité dodat. Pro porovnání jak rychle mi framework vrátí výsledek, se kterým můžu dále pracovat, bude čas tím správným kritériem. Pokud framework mezitím dělá „něco navíc“, může se to projevit v kódu jinde a jinak (třeba na přehlednosti kódu, jeho snazší údržbě nebo prostě úplně jinak) a pokud to „něco navíc“ dokážu použít, tak je to pro mě plus, ale nijak to výsledek Slickspeedu nemění. Vývojáři prototype se rozhodli dělat „něco navíc“, čímž vyhledávání v DOMu zpomalili (a to správně Slickspeed ukazuje a proti tomu je těžké něco namítat) a přidaná hodnota „toho navíc“ se může (a nemusí) projevit – na to by se mohl hodit zcela jiný test.

johny.smrz

Ono je pravda zeneni porovnani jako porovnani, tenhle test rika pouze to jak rychle jednotlive frameworky umi prohledavat DOM a v tomto smeru je spravy a opravdy prototype pohorel. Pro me jako programatora je to rozhodne zajimave zjisteni ale musim se take podivat i na druhou stranu mince a to je uzitecnost. Prototype lze pouzit na mnohem vice veci nez jenom prohledavani DOMu, je to proste cena za urcitou abstrakci takze pokud budu delat neco sloziteho, pouziju treba prototype. Na druhou stranu vidim ze pokud budu potrebovat udelat neco jednoducheho a efektivniho kde se spokojim s par radky kodu, rad po Peppy sahnu.

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.

Pocta C64

Za prvopočátek své programátorské kariéry vděčím počítači Commodore 64. Tehdy jsem genialitu návrhu nemohl docenit. Dnes dokážu lehce nahlédnout pod pokličku. Chtěl bych se o to s vámi podělit a vzdát mu hold.