Minulý čtvrtek v Praze proběhl druhý JS meetup a jednou z prezentací bylo hezké představení Angularu od Pavola Daniše (slajdy i ukázky zde na GitHubu).
Už jsem psal, že mě Angular zajímá, ale až JS meetup pro mě byl první příležitostí vidět tuto věc naživo a moct se ptát člověka, který s ní už delší dobu pracuje. Tady jsou mé velmi hrubé první dojmy:
Edit: V komentářích najdete obsáhlé a erudované odpovědi přímo členů Angular týmu.
1. Konečně něco, co vypadá přijatelně. Doposud, když jsem zběžně procházel ukázky Backbonů, Emberů a dalších frameworků, tak jsem se vždy jen rychle osypal a šel o dům dál. Angular je první framework, ze kterého mi není fyzicky špatně, a který se konečně aspoň trochu podobá Flexu (tam je většina věcí, které se dnes kostrbatě a horko těžko řeší, odladěných už 5-6 let; bohužel se Flex kompiluje pro ActionScript VM, proto musím hledat jinde).
Tento první, chválivý bod je důležitý a dobře si ho pamatujte, protože teď už budu spíš kritizovat. Může to být mou neznalostí, píšu skutečně své první dojmy, které jsem si udělal během jedné prezentace. Těším se na vás v komentářích :)
2. Angular nemá model. Takhle, on tam nějaký je, ale v podstatě se jedná jen o data na nějakém “kontextu”. Důležitý rozdíl mezi daty a skutečným modelem je ten, že na modelu lze definovat některé další informace o datech, např. jak se hodnoty validují, jak se získávají některé složené vlastnosti apod.
Protože Angular takový model nemá, je např. potřeba validační pravidla uvádět v pseudo-HTML, tedy v podstatě ve View, což je minimálně nehezké (a možná může vést k duplicitám, ale to snad nějak řeší direktivy). Nebo tipuji, že se hůř seznamuje s cizím kódem, když systémem lítají jen JSONy bez skutečného modelu v pozadí atd. No prostě v Angularu bych chtěl vidět nějakou větší aplikaci a podívat se, jak toto řeší.
3. Angular se kompiluje až v browseru, a to myslím jako vážnou výtku. Pro JavaScriptisty to zní možná trochu absurdně, ale posuďte sami:
Když jsem se zdálky díval na pseudo-HTML Angularu, připadalo mi to jako MXML zdroják ve Flexu – prostě nějaký značkovací jazyk, kde se dávají dohromady layouty, komponenty, bindingy apod., aby se něco vykreslilo uživateli. V případě Angularu je sice pravda, že to celé máte označené jako a uvnitř můžete používat HTML značky, ale v podstatě to celé stojí a padá s vlastními značkami a atributy Angularu, kterým browser ani za mák nerozumí. Stejně jako ve Flexu – běhové prostředí nemá ani ponětí o komponentách typu TextInput, DataGrid apod.
Proto je v obou technologiích potřeba kompilátor, který značkovací jazyk projde a udělá z něj něco, čemu běhové prostředí rozumí (Angular stránku zkompiluje do HTML, Flex do SWF). Doposud všechno dobré. Jenže ve Flexu by nikoho ani nenapadlo dát na web server zdrojáky aplikace a až v uživatelově počítači to nějak překlápět do něčeho spustitelného. Proč taky? Nedává to smysl, přesto Angular takto funguje.
Kompilace Angularu v browseru má své dosti temné stránky – např. se zbytečně překlad provádí u každého klienta namísto aby se jednou provedl na serveru. Nebo se někomu nemusí líbit, že na klienta jde v podstatě přímý zdroják (nevím, jak s Angularem funguje minifikace – prý je to problematické, protože kompilátor na klientu očekává určité stringy apod., ale nevím). No a pak ještě jedna zásadní věc – definice UI “komponenty” (direktivy) se dá buďto udělat inline zápisem v HTML v JavaScriptu (ošklivé) nebo ji uložit do externího HTML souboru a odkázat se na tuto mini-šablonu pomocí templateUrl. Což udělá HTTP request. Přečtěte si předchozí větu ještě jednou a uvědomte si, co to v systému s tisíci komponentami znamená. Pro mě:
Jak jsem psal v bodu 1, Angular je první věc na uživatelská rozhraní v JavaScriptu, která mi připadá aspoň v zásadě správná. Některým konkrétním rozhodnutím nerozumím a taky by se samozřejmě našly drobnosti typu proč mě Angular u bindingu nutí psát dvě složené závorky namísto jedné, ale myslím, že tady můžeme skončit. Měly to být skutečně jen první dojmy.
Pokud Angular znáte a můžete mi body dva a tři vysvětlit nebo vyvrátit, budu za to jedině rád.
Kompilace v browseru, dobrý postřeh. Taky se mi nelíbí, ale hádám kluci to brzo fixnou. Šablony per request je bota jak hrom, souhlas. Co se týká modelu, klidně imho modely používat můžeš. Validace ve view se mi také moc nelíbí, vůbec bych ji od modelů neodděloval.
Ad Closure kompilace, kluci z Angularu opakovaně říkají, že funguje. Jenže ne advanced mód, a o ten jde především.
Angular je fajn, když chceš mrskat formuláře. Jakmile chceš mít vlastní modely, a trochu kompikovanější UI… obávám se, že Angular bude spíše brzda. Co se týká mobilních aplikací, tam bych se bál ještě více.
Kompilace na straně serveru nejenže hádám že bude, ale vím že bude, potvrdil to Vojta osobně i na Twitteru, pojede to přes Node.js.
Má to i jinej aspekt – pořád je hodně situací kdy chcí klientovi v response vyblejt přímo finální HTML, např. pro indexovatelnost vyhledávačema. Kompilace jak na serveru tak na klientovi je killer featura šablon, prostě potřebuješ oboje, naprostá většina JS templatů tímhle trpí. Má to, tuším, Closure.
Cau Borek,
Diky za post. Mam tu pre teba zopar odpovedi priamo od AngularJS teamu (prepac kostrbatu slovencinu, ale o tychto technickych veciach obycajne po slovensky nehovorim, tak nepoznam slovesnku/cesku terminologiu):
1/ AngularJS je designovany ako extension pre HTML. Nechceme aby sa ludia museli ucit novy jazyk od zakladov ked uz poznaju HTML a JS. A tym ze Angular je uplne rozsiritelny, tak si vlastne mozes prisposobit HTML svojim potrebam a potrebam tvojho projektu.
Flex je definitivne nieco co nas inspirovalo pri vyvoji Angularu.
2/ Angular jednoznacne model ma. Akurat ze ten model je taky ako ho chces mat ty a nie nejaky typ do ktoreho by sme ta nutili a viazali ti s nim ruky. Ak chces aby tvoj model vyzeral takto:
user = {name: 'Igor', hobby: 'running'}tak ho presne taky mozes mat. Ak tvoj project vyzaduje nieco sofistikovanejsie, tak si mozes vytvorit vlastny typ, napr.new User('Igor', Hobbies.RUNNING).Model nemusi byt len o datach, ale aj o behavior! Pozri sa na MemoryGame a PeepCode Tunes apps kde model je data + behavior.
Preco sa ti nezda ze validacia sa deje cez view? Ved predsta len cez view mozes zobrazit problemy s validaciu a obycajne iba cez view (form) moze user vytvorit model ktory je invalid a zaroven ho aj opravit. Samozrejme ze pre poriadnu aplikaciu potrebujes aj server-side validaciu, a ta je obycajne implementovana uplne inak ako na client-side takze sanca na code-reuse je mala.
3/ Client-side compilation is your friend.
Angular bol od zaciatku navrhovany tak aby bol developer-friendly a rychly (v tomto poradi). Vzdy ked nieco robime, tak chceme aby sa to lahko pouzivalo a pritom aby vysledne aplikacie neboli pomale.
Tym ze sa templaty kompiluju v prehliadaci zanamena ze medzi tvojim editorom a prehliadacom nestoji ziadna prekazka. Mozes teda pisat kod, ulozit subor a refreshnut prehliadac a hned uvidis co sa zmenilo. Porovnaj toto s GWT alebo niecim inym kde cakat sekundy, minuty alebo aj hodiny pokial uvidis co i len tu najmensiu zmenu v kode.
A kedze chceme aby Angular fungoval skvele s akymkolvek back-endom tak robit kompilaciu v prehliadaci je uplne prirodzene riesenie.
Cela kompilacia aj v najkomplikovanejsich applikaciach (napr DoubleClick Digital Marketing Manager) trva len niekolko milisekund, kedze sa spoliehame na to ze prehliadac urobi tu najtazsiu pracu (prasovanie html a vytvaranie DOM stromu) pre nas nativne a velmi rychlo.
To ze na server davas zdrojaky aplikacie je normalne. Ved to robis kazdy den s HTML a CSS. A kedze Angular je vlastne HTML, tak sa tam nie je comu cudovat.
ten isty argument by sa dal pouzit pre velku cas JS kodu v akejkolvek JS aplikacii. Ide o balansovanie medzi runtime efficiency a maintainability daneho kodu.
Ako Vojta spominal pracujeme aj na server-side pre-rendering, ale to je dost komplikovana zalezitost a potrva zopar mesiacov kym budeme mat nieco pouzitelne v produkcii.
No cely zdrojak by si urcite v production mat nemal. Velmi doporucujem minifikaciu javascriptoveho kodu (+concatenation +gzip!!), ktora vlastne sluzi aj ako obfuskacia. Minifikaciu funguje velmi dobre s roznimi minifikatormi ale v closure compilery iba v simple mode.
Pracujeme na podpore advanced modu, ale to este zopar mesiacov potrva kedze to nie je trivialna zalezitost a vyzaduje implementaciu minifikacie HTML spolu s JS takze to poriesime spolu so server-side pre-rendering.
Dobrou spravou je ze ak pises aplikacie s Angularom tak mas obycajne 80-90% menej kodu ako v typickej JS alebo GWT aplikacii a simple level optimizacia ti stale vytvori mensi payload ako advanced optimizacia s typickou aplikaciou.
nie je to pekne, ale pokial je templata velmi mala (1 riadok) tak je to dobre riesenie
tento sposob je urceny iba pre development mode. opat ide iba o to aby medzi tvojim editorom a prehliadacom nic nebolo. Urcite ale nedoporucujem pouzivat externe templaty pre direktivy na produkcnych serveroch.
Trochu ma prekvapuje ze nevies este o tretej moznosti: pouzivanie