Přeskočit na hlavní obsah

jQuery není špatná knihovna

Na internetu v různých diskuzích neustále čtu, jak je jQuery knihovna špatná. Její rozšiřitelnost a vývoj jde špatným směrem. Pluginy jsou kus zpackaného balastu a vůbec podpora pro rozšíření je špatně implementováno. Mnoho diskuzí však je stále na jedno "brdo" a končí argumenty - "pluginy psané nad jQuery jsou špatné EQUALS jQuery je špatná ... ". Z těchto diskuzí mi však vyplývá jediné, že filozofie, z které jQuery vzešla je tak triviální, že je opomíjena. Je to již nějaký ten pátek, co jsem v javascriptu napsal nějaký ten řádek, přesto nedám na jQuery dopustit.

Podstata jQuery je v tom, že práce s ní je velmi jednoduchá a základním stavebním kamenem je práce s DOM a v tom je jQuery zatraceně silná.

 Jádro funkce jQuery(path) není ničím jiným než za pomocí regulárního výrazu nalézt HTML element, nebo množinu HTML elementů

Tohle je základní filozofie pro kterou Resig jQuery psal - snadný přístup k HTML elementům, jejím atributů v DOMu, včetně práce s CSS. Kdo očekává od jQuery víc, pak se nedivím, že je nespokojený. 

Stačí se podívat na dokumentaci jQuery - podstatná část se točí okolo dohledání patřičného elementu, popř. množiny elementů a jeho nastylování. Další nadstavby jako je správa událostí a práce s Ajax, která vás odstíní od odlišných implementací prohlížečů (to samé platí při práci s CSS pro různé prohlížeče) je přesně to na co byla jQuery navržena. Pro pořádek (koukal jsem na versi 1.4.3) v dokumentaci existují sekce:

  • Ajax (abstrakce xmlhttprequest specifikace),
  • Core,
  • CSS (práce se styly),
  • Dimension (základní informace rozměry HTML elementu)
  • Effects (uff, tohle se nepovedlo ... )
  • Events (abstrakce pro práci s událostmi)
  • Forms (speciální množina funkcí pro práci s formulářovými HTML elementy)
  • Manipulation (práce s DOM)
  • Offset (dohledání pozice elementu s ohledem k viewportu)
  • Plugin (nepoužíval jsem)
  • Properties (globální proměnné jQuery prostředí - počet elementů, vypnutí animací, podpora ...)
  • Selector (xpath-based formulovaný dotaz pro dohledávání elementu/ů)
  • Traversing (efektivní procházení již vrácených kolekcí elementů)
  • Utilities (nepoužíval jsem)

Tučný text jsou sekce, které jsem používal a jQuery odvádí v tomto ohledu profesionální práci - ostatní nemohu hodnotit nepoužíval jsem - nepotřeboval jsem tyto funkčnosti. jQuery je mocný nástroj pro práci s DOM v rovině vyhledávání/filtrování vrácených kolekcí, jejich nastylování a správy událostí, kdo chce víc - musí se ohlédnout po jiné knihovně!

jQuery is a fast and concise JavaScript Library that simplifies HTML document traversing, event handling, animating, and Ajax interactions for rapid web development. jQuery is designed to change the way that you write JavaScript.

Takže mi z toho vychází jediné - stačí si přeložit výše uvedenou citaci převzatou s oficiálního webu a máte zde odpověď všem "prudilům" - jQuery není špatná knihovna. Stačí si uvědomit k čemu byla knihovna navržena.

Komentáře

Populární příspěvky z tohoto blogu

How to override (hack) location directories eg. Model in Zend Framework projects

Content At beginning Use Case Standart directory layout Specific directory layout Solvetion Summary At beginning This approach is bad but it is trivial and works. First I thought about a way how to inject/override by my implementation but if I stood before "I need only change location where objects will be generated..." Use Case For example - your project's 'models' directory has different structure and you must remove each generated model's php file to your specific directory. Standart directory layout If you use command "zf create model ItemModel" . ItemModel file will be generated by default in directory 'models' . ----models |--DbTable |--ItemModel.php Specific directory layout We want to generate model class in subdirectory 'Domain' . That's all. ----models |--DbTable |--Domain |--ItemModel.php Solvetion We must find directory '%ZF_HOME%\library\Zend\Tool\Project\Context\Zf\' . T...

Zend framework - jak vytvořit modul

Úvod V příspěvku se zmíním o způsobu, jak vytvořit modul v Zend Frameworku. Dále si povíme o jeho registraci v projektu a namapování zdrojů, které bude daný modul používat. Architektura projektu Jak vytvořit modul Namapování adresářové struktury modulu Shrnutí Závěr Případné problémy Zdroje Jednu poznámku hned na začátku, seznam proměnných, které budu používat v textu: %APACHE_HOME% - adresář, v kterém máte nainstalován httpd server %APP_HOME% znamená %APACHE_HOME%/htdocs/zendapp/application , jedná se o lokaci aplikace, na které budu vysvětlovat tento návod Architektura projektu Adresářová struktura ZF projektu hraje klíčovou roli. Základní stavební jednotkou projektu je modul . Základní struktura aplikace, kterou získáváte stažením Zend Frameworku je považována za defaultní modul. Nicméně při implementaci větších projektů se setkáte s tím, že projekt je potřeba rozdělit na několik logických celků (administrace, blog, fotogalerie atd.). ZF nabízí architektům mod...

Nevytvářejte společného předka pro Zend_Controller_Action používejte Zend_Controller_Plugin

Je žádoucí mít jednu implementaci opakující se funkcionality na jednom místě a tu reusovat. Narazil jsem však při vytváření společného předka pro Zend_Controller_Action na jeden problém. Když vytvořím předka pro své controllery, pak nelze použít Zend_Tool pro generování akcí. Nastavení prostředí V projektu mám tuto hiearchii: |--library |--MyLibrary |--Controller |--Action |--Action.php Výše uvedenou knihovnu mám pak zaregistrovanou v Bootstrap.php souboru, potažmo namespace, aby ji Zend_Autoloader našel. Kod.1 public function _initLibraryNamespace(){ $loader = Zend_Loader_Autoloader::getInstance(); $loader->registerNamespace('MyLibrary_'); } Nyní vytvořím pomocí Zend_Tool controller v defaultním modulu. Na problém se však narazil i u controlleru, který byl v modulu. zf create controller Item 1 Nyní změním předka na svou implementaci controlleru. Kod.2 /** * @author...