The Boogie experience - pár postřehů o programování v XUL

Včera jsem dokončil svou první větší aplikaci napsanou v XUL (čili v Mozille) – touto aplikací je Boogie, jednouchý bug-tracking systém, vytvořený hlavně pro mou vlastní potřebu. Pokud vím, je to první opravdová XUL aplikace v Čechách (opravdová znamená, že není jen pro ukázku či výukové účely, ale bude se doopravdy používat, a také že to není jen lokalizace aplikace již existující). Update: Tady jsem trochu přestřelil, už jsem byl opraven, že první nejsem :-(

Chtěl bych se tu nyní podělit o některé zkušenosti nabyté během posledního měsíce při jejím programování. Předesílám, že následující text předpokládá jisté znalosti o tom, jak funguje Mozilla vevnitř a jakožto platforma pro vývoj aplikací. Tyto znalosti si v případě potřeby můžete doplnit přečtením mojí loňské semestrální práce.

Musím říci, že v XUL se opravdu programuje poměrně příjemně. Pokud jste zvyklí tvořit webové stránky s dynamickými prvky (JavaScript, DOM a podobné hračky), pak pro vás XUL nejspíš nebude nic převratného a práce vám půjde poměrně rychle od ruky. Nicméně XUL a související technologie má i své mouchy, které tu rozhodně nehodlám zamlčet. Takže do toho.

Prvním bodem je absence nedostatek programátorské dokumentace. To je asi nejhorší věc na Mozille vůbec a pravděpodobně plyne hlavně z toho, že Mozilla je open-source. Vývojáři vnitřnosti znají, dokumentaci tedy příliš nepotřebují, a není nikdo (žádný šéf), kdo by je k jejímu napsání donutil. A sami to dělat nebudou, protože programování je přeci mnohem zábavnější.

Výsledkem je, že spousta funkcí není nikde dokumentována a ledacos je nutné vyčíst přímo ze zdrojových kódů. Světlým bodem jsou dva neoficiální dokumenty – XUL Tutorial a Mozilla XUL and Script Reference. Autorem obou je Neil Deakin a nutno říct, že odvedl velmi dobrou prácí. Pokud plánujete v XUL něco tvořit, bez těchto dvou materiálů se jednoduše neobejdete a tak 85 % potřebných věcí v nich najdete (zmiňované procento je samozřejmě velmi závislé na tom, co tvoříte za program). Naopak ale musím ocenit, že jsou vcelku poctivě komentovány všechny důležité IDL soubory, popisující API Mozilly. Aspoň toho se dá celkem chytit.

S absencí nedostatkem dokumentace souvisí i určitá zamlženost toho, co je externí a interní API. Přirozeně je nutné tyto dvě kategorie rozlišovat, protože externí API budou mít podstatně delší životnost, zatímco interní se můžou bez ohlášení změnit ze dne na den, a pokud je využíváte, váš program nemusí v nové verzi Mozilly fungovat. U interfaců v IDL je alespoň řečeno, zda jsou "frozen" – čili se nebudou měnit. Horší je ale situace například u CSS souborů, které jsou definované v globálním skinu. Nikde jsem nenašel nějaká pravdila pro to, zda například můžu použít nějakou CSS třídu, která je tam definovaná, ve své aplikaci bez obavy, že v další verzi tam nebude. Ale zde je možné, že jsem jen špatně hledal a někde ta pravidla napsaná jsou.

Na API Mozilly mi vadí také jedna věc – je totiž až moc vidět, že API vznikalo z velké části naprosto živelně bez nějaké hlubší koncepce. Nedá se to ani srovnat s promyšlenými knihovnami typu VCL nebo MFC. Podobně je dost často velký nepořádek i ve zdrojových souborech Mozilly samotné, například naprosto chybějí názvové konvence pro JavaScript. A podobně třeba i u prvků XUL – v jednom souboru Mozilla Firefoxu se například vyskytují tyto tři id: security-button, customToolbars, PersonalToolbar. Prostě míchání konvencí bez ladu a skladu. Obdobné příklady najdete třeba v konfiguračním sobuoru prefs.js i jinde.

Pravda, zmiňované nekonzistence nijak neovlivňují funkčnost Mozilly ani tvořené XUL aplikace, ale zanechají v programátorovi pocit, že Mozilla je prostě jeden obrovský hack. Nevím jak ostatní, ale já mám eleganci při programování hodně rád.

Na XUL mi také vadí jedna věc: co okno, to v podstatě separátní aplikace. V každém aplikačním okně, i když je to jen jednoduchý dialog, se načte samostatný XUL soubor, samostatně se provádí JavaScriptový kód a komunikace mezi okny probíhá v podstatě jen přes parametry funkce window.openDialog. Nejspíš to jde obejít (nezkoumal jsem podrobně, protože jsem to nepotřeboval), ale implicitně jsou jednotlivé části aplikace od sebe dost oddělené. Je to trochu neobvyklé řešení, aspoň pro člověka zvyklého např. na poměrně těsnou spolupráci mezi jednotlivými unitami v Delphi.

Vývojáři Mozilly také občas trochu přestřelili a "technologicky se zasnili". Konkrétně se mi nelíbí třeba to, že lokalizovatelné řetězce se zapisují do dvou různých typů souborů s odlišnou syntaxí (DTD a .properies soubory), podle toho, zda řetězce budou přímo v XUL souboru nebo se budou používat v JavaScriptu. Tady by podle mě bylo rozumnější .properties soubory používat i pro vkládání do XUL, místo "znásilňování" DTD souborů, určených původně k něčemu úplně jinému.

Obdobně nevidím žádné plus v používání formátu RDF na registraci komponent – myslím, že je to zbytečně "ukecaný" a obecný formát a že nějaký jiný (klidně také založený na XML, ale specializovanější) by byl vhodnější.

Pokud chcete tvořit velké aplikace, číhá na vás ještě jedno nebezpečí, a to je "křehkost" JavaScriptu a jeho nevhodnost pro vývoj ve velkém. Myslím, že hlavně absence typů, volnost v deklaracích proměnných a odlišný objektový model mohou dělat u velkých projektů docela paseku. V tomhle bude pravděpodobně lepší Microsoftí XAML, který bude umožňovat napsat aplikaci v libovolném jazyce fungujícím v .NET run-time.

Ale abych jen nekritizoval: V XUL je velice dobře propracovaná technologie oddělení logiky aplikace (JavaScript, XUL) od jejího vzhledu (CSS) a lokalizace. To je dáno v podstatě poděděním daných technologií z klasického (X)HTML.

A co se mi líbí ještě víc, je že díky promyšlenému způsobu instalace a registrace instalovaných součástí se můžou jednotlivé instalované "balíčky" vhodně doplňovat a rozšiřovat. Ze začátku to docela mate, ale dá se na to zvyknout a použitá koncepce má v praxi mnoho výhod.

Hezké je, že za jeden z balíčků je považován i samotný prohlížeč, což umožňuje snadno rozšiřovat i jej. No řekněte sami, ve kterém jiném programu můžete libovolně doplňovat uživatelské rozhraní, menu, ikonky, stavovou lištu nebo dokonce měnit a doplňovat chování existujících funkcí? Flexibilita XUL je v tomhle úžasná a myslím, že plně vyvažuje mnohde kritizovanou hardwarovou náročnost a i jiné nedostatky celého mechanismu.

Zdaleka jsem zde nevyjmenoval všechny plusy a mínusy XUL a Mozilly z pohledu vývojáře; omezil jsem se jen na to, na co jsem sám narazil. Kdybych měl své zkušenosti shrnout, tak vyznívají spíše pozitivně – program Boogie se mi podařilo napsat rychleji, než jsem sám čekal. Ale část z tohoto úspěchu musím přičíst tomu, že se v Mozille relativně orientuju a vím, do kterého zdrojáku se kouknout pro potřebné informace, když je nenajdu jinde. Méně zkušený programátor, neovládající navíc C++, by byl pravděpodobně mnohem víc zmaten, než já.

Nechci příliš zobecňovat jen na základě několikatýdenní zkušenosti s jednoduchou aplikací, ale asi bych mohl říct, že vývoj v XUL bych doporučil pro malé až střední aplikace, kde tolik nezávisí na výkonu jako spíš na rychlosti vývoje a kde může být výhodou spojení s internetovým prohlížečem a také multiplatformnost. U jiných typů projektů je asi lepší použít něco jiného.