Peppy: Hledání elementů v DOM snadno a rychle
Nálepky:
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.
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.
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.
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.
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.
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.