Weblabor

A CommonJS modul mintája mára már de facto JavaScript modul formátum. Szinkron betöltésre épít. Ezt használja például a Node.js. Kidolgozták mellette a Module Transport Format ajánlást, amely callback alapú modul kezelést valósít meg. A szinkron formátumra épül, ahhoz lényegében csak egy burkoló a kompatibilitás végett. Több lehetséges változat közül végül a Transport/C nyert teret, amelyet Asynchronous Module Definition (AMD) névre kereszteltek. Ezt a felületet implementálja a RequireJS is.

A Dojo régóta ehhez nagyban hasonlító modul rendszerrel rendelkezik a keretrendszer komponenseinek kezelésére, ill. ezt adja a fejlesztő keze alá is a saját fejlesztésekhez.

YUI 3-ban és Google Closure-ban a Dojoéhoz hasonló aszinkron modul réteg került megvalósításra. (Egyértelmúen nem határozható meg, hogy melyik eszköz honnan merített. Feltehetően a Dojo ihlette az AMD kidolgozását, majd a RequireJS is visszahatott a Dojo rendszerére. Ezt nem tisztem itt eldönteni, és a lényegen nem is változtat.)

Mindez azért érdekes, mert a Dojo az 1.6-os verziótól kezdve a 2.0-s kiadást megcélozva folyamatosan átáll a RequireJS-féle megvalósításra. (Azért folyamatosan, mert 2.0-ig visszafelé kompatibilitást nyújt, ill. a hamarosan megjelenő 1.6-osban a bejelentés szerint a modul betöltő még csak az AMD egy részét valósítja meg, és a gyári komponenseknek is csak egy része készült el AMD formátumban.) Ben Hockey közzétett egy példakódot, amelyben a megszokott dojo.require()-dojo.provide() páros helyett RequireJS-sel tölti be a szükséges komponenseket, majd definiál egy widgetet.

Azontúl, hogy a döntés szabványosabb irányba mozdítja el a projektet, teret enged annak is, hogy ugyanazon komponens egyidejűleg használható legyen kliens- és szerver oldalon. Mindezek mellett érdekes az a felvetés is, hogy a Deferred rétege helyett a Dojo a jövőben a CommonJS Promises ajánlására térjen át.