Názory k článku
Výhody XULRunneru od Mozilly proti AIR od Adobe

Linkovatelnost externich kodu a zpracovani ve vice vlaknech? Tyhle veci se v mozille vice-mene navzajem vylucuji. Pokud chcete v mozille cist ze socketu, tak si vytvorite vlakno to zavola poll a kdyz se vrati tak nenacte zadna data - misto toho poslete zpravu hlavnimu vlaknu a teprve hlavni vlakno nacte data ze socketu. Pokud mate nejakou knihovnu, ktera sama komunikuje po siti(ldap, jabber),
tak byste ji meli kompletne prepsat aby pouzivala NSPR api pro sockety.
V XULu musite skoro vsechno vcetne alokace pameti delat v hlavnim vlakne, protoze jinak by vam to mohlo spadnout. Ja teda nenadavam na XUL, ale na XPCOM ten je hodne divne navrzenej.

K tomu srovnani mezi XULem a AIR bych pridal. Kde nema mozilla nic, tam ma AIR dokumentaci. Kde ma mozilla dokumentaci, tam ma AIR tutorial. Kde si v XULu musite vystacit s vim-em, tam ma AIR IDE s outlinerem. AIR ma zatim jednu verzi, takze veskere informace/dokumentace/navody jsou aktualni a platne.

Pokud se potrebujete zorientovat v cizim kodu v XULu, tak to vetsinou vypada tak, ze si otevrete soubor .xul, tak najdete osetreni nejake udalosti(=fce v javascriptu). Tam si otevrete nejaky soubor .js a najdete tam tu fci. Ta fce zacina nejakym volanim getElementById, tak si otevrete nejaky .xul a najdete si tam ten element. A tak porad dokola. Takovahle operace je v prostredi AIR na jedno kliknuti. Kdyz delate v XULu tak si porad dokola spoustite grep tak dlouho, nez si nezapamatujete umisteni vsech xul elementu a poradi vsech funkci v .js souborech. Vyvoj aplikaci v XULu neni ani zdaleka tak rychly jak by se mohlo na prvni pohled zdat.

S tim poslednim odstavcem se da bohuzel jen souhlasit