Přejít k navigační liště

Zdroják » JavaScript » JavaScriptové MVC frameworky

JavaScriptové MVC frameworky

Články JavaScript

Subjektivní pohled Ondřeje Žáry na současný stav MVC frameworků v JavaScriptu. Jsou opravdu tou správnou cestou?

Nálepky:

0 Varování

Tento text odráží osobní názory a je pravděpodobné, že s ním nebudete souhlasit. Když ale dočtete až ke třetí kapitole, budete moci osobní názory objektivně konfrontovat přímo s konkrétní implementací.

1 Historický exkurz

MVC jako paradigma psaní webových aplikací existuje od nepaměti. Studentům každý rok do hlavy vtloukáme, že dokud bude výsledkem jejich práce spaghetti code, nelze mluvit o udržovatelnosti, čitelnosti a podobně.

Na MVC přitom nic objevného není – je to jen konkrétní aplikace SRP, SoC a podobně v prostředí interaktivního uživatelského rozhraní, syceného daty z nějakého (DB) úložiště. Právě proto se při tradičním psaní webů žádný MVC framework nepoužívá (a přesto to MVC je): prostě se výsledné HTML renderuje šablonou (view), data se papají z nějak abstrahované databáze (model) a zbytek – což může být párřádkový skript i všechoschopný moloch – se stará o logiku spolupráce těchto dvou (controller).

Veškeré serverové logice se samosebou občas říka framework (Nette, Zend, …); to je ale proto, že tím autor dává najevo, že jeho kód se umí postarat o všechny aspekty zpracovávání požadavků (jinak by to byl toolkit, knihovna, nebo něco obdobného). A zrovna náhodou při implementaci použil MVC, proč ne.

Během boomu JavaScriptových aplikací (čti: webových stránek, ve kterých logiku zpracovávání interakce a zobrazování dat realizuje klientský JavaScript) však kdosi přichází s myšlenkou, že “serverové MVC” by z jakéhosi důvodu mělo mít svůj klientský komplement – když to dobře fungovalo v místě A, jistě to bude skvěle fungovat i v místě B. (“Polsko jsme zabrali bez problémů. Co takhle to zkusit ještě s Ruskem?”)

Jaké argumenty v takových chvílích slýcháme?

  1. “Vyrábět větší kusy HTML JavaScriptem je opruz. Proto potřebujeme JS šablony.”
  2. “Můj web už obsahuje více než N řádků JS, z čehož je patrné, že se JavaScript stal hlavní komponentou stránky. Je na čase použít nějaký nástroj, který mi usnadní jeho psaní a zařídí, abych toho kódu nemusel psát tolik.”
  3. “Programátoři na backendu používají MVC. Jaká ostuda, že já se svým JavaScriptem také nemám něco tak prďáckého!”

Za těchto okolností proto světlo světa spatřují JavaScriptové šablonovací systémy: klientské skripty, které na vstupu dostávají strukturovaná data a pseudo-HTML šablonu; provedou substituci a vrátí výsledný fragment HTML dokumentu. Nikdo pořádně neví, jak to dělat – kolik logiky v šablonách nabízet (mustache: logic-less templates), jestli duplikovat serverovou syntaxi (ejs, underscore), jak napasovat nutnost šablonovacích direktiv na fragmenty HTML (plates, PURE). Ve finále je rozhodně z čeho vybírat.

javascript template

2 Šablony a jejich zásadní nedostatek

Použití šablonovacího systému na serverové straně bylo posledním krokem před dokončením zpracování požadavku: typický controller měl na svém posledním řádku něco jako template.render(data). Ve světě JavaScriptových šablon ale nekončíme vykreslením; jedná se o interaktivní aplikaci, a proto je nutné na vzniklou DOM strukturu ještě navěsit relevantní posluchače. Tím se dostáváme k zásadnímu problému všech šablonovacích systémů, jejichž výstupem je řetězec: není možné přímočaře pracovat s posluchači. Z výsledku je prve nutno postavit strom (innerHTML), ten procházet (querySelector) a přidávat události (addEventListener). A právě procházení je pracné a vyžaduje jasně a jednoznačně definované API mezi stránkou a JS (například pomocí atributů ID či class). Tato skutečnost je hlavním koncepčním nedostatkem samotných JavaScriptových šablon.

V tuto chvíli je možná na místě připomenout, že zmiňovaný neduh vůbec nepřipadá v úvahu při tradičním psaní JavaScriptu, známém též jako DOM manipulation. Uzly, které vyrobím pomocí createElement (nebo nějaké nadstavby), mám okamžitě k ruce a ve vhodnou chvíli na nich události pořeším.

A nyní přichází konfrontace s prvním argumentem, zmiňovaným v předchozí kapitole – totiž že DOM manipulation je opruz, je to pracné, je to zdlouhavé a ušetřený čas by se mohl věnovat něčemu užitečnějšímu. Jaké stanovisko k tomuto zaujmout?

Autor tohoto textu píše JavaScriptové aplikace zhruba osm let a zastává názor, že zmiňovaný argument je prázdná fráze. Proč?

  1. Práce s DOMem může být pracná, ale k tomu slouží různá syntaktická zjednodušení, která abstrahují tyto úkony, nabízí zkrácený zápis a řeší kompatibilitu. Týká se to jak tvorby značek (create(“input”, {type:“button”, value:“A”, id:“b”, color:“red”})), tak konstrukce stromu (ul( li(), li( a() ), li()).
  2. Vývojářův čas, strávený psaním DOM manipulation, je minimální v porovnání s ostatními aspekty JS aplikace: logikou zpracování událostí, komunikací s backendy, psaním chytrých algoritmů na zpracování dat. Správní vývojáři jsou líní a mohu potvrdit, že se při práci snažím maximum času přemýšlet (nad algoritmy, nad logikou toku programu, …) a jen čas od času něco málo skutečně napsat. Nikdy mi nepřišlo, že bych měl optimalizovat právě čas věnovaný tvorbě těch pár pitomých odstavců, divů a formulářových prvků.

Ve světle toho, jak málo mne DOM manipulation obtěžuje, nevidím mnoho přínosů pro JavaScriptové šablonovací systémy.

Občas se ještě objevuje myšlenka, že oddělené šablony pak mohou spravovat úplně jiní lidé a cenný čas JS programátora může být pálen psaním hardcore JS logiky. Ani náhodou, říkám: šablona je s přidruženým JavaScriptem symbioticky provázána a jakmile do ní začne sahat někdo cizí, dříve nebo později provede nekompatibilní změnu takovou, že si na takto “opravené” šabloně vyláme kód zuby. Nebo naopak, samosebou.

Pojďme se nyní podívat, jakým způsobem na zmiňovaný nedostatek klientského šablonování zareagovali chytří chlapci a děvčata na Internetu.

3 MVC framework

Vítejte ve světě JS MVC: nástrojů, které vzaly šablonování a doplnily do něj události. Jedná se o bleeding edge technologii; nové rostou jako houby po dešti a opět je z čeho vybírat. Bylo by nespravedlivé tyto frameworky označit jen za vylepšené šablony – zpravidla toho s sebou nesou ještě mnohem více, typicky podporu pro HTTP, práci s URL a data binding. Ve finále však ale všechny sdílí jeden základní společný rys: berou nějaký šablonovací systém a dovolují vzniklé HTML počůrat tak, aby se nad ním dalo komfortně (čti: semi-automaticky) pracovat s událostmi.

JavaScript MVC framework

Pokud to doposud nebylo zcela patrné, tak je nejvyšší čas odhalit hlavní sdělení tohoto článku: Dle mého názoru jsou JS MVC frameworky nafouklá bublina, která vznikla opakovaným záplatováním jednoho konkrétního nádoru. Pojďme se podívat na mé argumenty:

  1. Zmiňované počůrání HTML šablony je nekoncepční a vzniklo jako ctnost z nouze, způsobené nedostatkem JS šablonování. Více o tomto níže, u konkrétních ukázek.
  2. MVC frameworky způsobují fragmentaci vývojářů. Nesdílí společná API ani vývojová paradigmata; každý je postavený dle nejlepšího vědomí a svědomí svého autora. Řadu let se JS komunita těší na konvergenci JS API v prohlížečích, aby se daly tradiční cross-browser problémy (addEventListener, querySelector, XHR, …) řešit bez zastřešujících můstků. A do této skvělé doby, kdy nekompatibilní prohlížeče skutečně mizí z trhu, najednou přichází desítky nových nástrojů se zcela odlišným zevnějškem. Hledáte JS vývojáře? Možná vám dříve stačilo, když měl skvělé povědomí o jazyce, znal prototypovou dědičnost, chápal uzávěry a event loop. Dnes už musí navíc hovořit tím dialektem JS, ve kterém je psaný firemní MVC framework – protože firemní MVC framework nectí operátor new ani klíčové slovo this; používá vlastní abstrakci, která sere na prototypy a věci, které jsou původnímu JavaScriptu blízké.

V rámci férovosti je nyní dobrá chvíle pozorovat některé populární JS MVC frameworky v jejich přirozeném prostředí. Ideální je pro to služba TodoMVC, která ukazuje implementaci triviální aplikace pomocí řady frameworků. Musíme ale opatrně – delší expozice vede k depresím z toho, v jakém marasmu se situace kolem frameworků nyní nachází.

3a Ember.js

Používá šablony Handlebars, což je syntaxe Mustache + další featury (explicitní IF a podobně). Ve vzorovém HTML jsou šablony vychytrale uloženy v uzlu <script>, což jednak není pravda (není to skript, ale hybrid HTML + custom markup), a za druhé to spolehlivě zmate většinu syntax highlighterů.

Události jsou provázány pomocí tagu či atributu action, kterému v šabloně upřesníme DOM událost a sdělíme název metody controlleru, která ji bude zpracovávat. Zatímco dříve bylo fujfujfuj napsat <label ondblclick=”editTodo()”>, nyní je hujhujhuj varianta <label {{action "editTodo" on="doubleClick"}}>.

V JavaScriptové části kódu je zcela zavrhnuto new a namísto toho věci vyrábíme různými variantami extend() a create(). Nomenklatura používá různé automagické konvence; můžeme si o nich přečíst v dokumentaci. Například controller TodosController, který je mj. zodpovědný za přidání nové položky, je sice definován s tímto jménem, ale jinak se jeho název už nikde dále v kódu nepoužívá (což neznamená, že ho můžeme pojmenovat jak chceme – aplikace očekává, že s ohledem na pojmenování okolních věcí bude něco s tímto názvem existovat. Data binding je realizován explicitním voláním set() na controlleru, který následně notifikuje posluchače o změně hodnoty.

Implementační zajímavost: v Ember.js mají funkce prototypovou metodu property, která jim definuje metadata (závislosti), na kterých volání této funkce závisí. Mimo jiné i kvůli tomu není možno používat tradiční prototypový přístup, kdy je jedna funkce sdílena spoustou různých objektů.

3b Backbone.js

Backbone nepoužívá žádné vestavěné šablonování, ale zhusta závisí na low-level knihovně Underscore. K provázání DOM událostí definuje vlastní syntaxi, podobnou CSS selektorům prefixovaným názvem události; zároveň s tím nabízí implementaci vzoru observer a tím pádem i užívání vlastních událostí.

To, čemu se jinde říká Controller, je v Backbone nazýváno View. Vlastní vyrábíme voláním create(), na prototypy můžeme zapomenout. Spolupráce s URL je zcela oddělená součást frameworku; jedná se o prosté mapování vzorů URL na vlastní funkce či události.

Zajímavost #1: ke zdrojovému kódu Backbone existuje anotace téměř ke každému řádku.

Zajímavost #2: Backbone jako jeden z mála nástrojů nenabízí vlastní abstrahovaný super; namísto toho zodpovědně vybízí k používání čistě JavaScriptového volání předka.

3c Angular.js

Tento super-heroic framework používá vlastní šablonovací jazyk, založený na speciálních HTML značkách a atributech (které z nějakého důvodu začínají na ng a připomínají tak, že až se do šablon někdo podívá za deset let, jistě mu budou připadat velmi New Generation). Výsledný mix HTML a NG je špatně čitelná směs. Vzpomínáte, jak se říkalo, že <form onsubmit=”...”> je fuj? Tak dnes frčí <form ng-submit=”...”>.

Hlavním tahounem Angularu je jeho obousměrný data-binding, totiž automatické reagování na změny v datech, se kterými se pracuje (ať už iniciované Angularem, nebo uživatelem). Realizace funguje na bázi opakovaného monitorování dat: funkcí $watch říkáme, která data chceme sledovat; (implicitním) voláním funkcí $apply a $digest dochází k ověření změny hodnot a automatickým aktualizacím. Více o těchto konceptech je k vidění v dokumentaci.

Implementační zajímavost #1: K detekci změn v datech dochází často (vlastně skoro pořád – po každém požadavku, po každé události); pro účely této detekce se musí data jednak porovnávat a druhak kopírovat (nutno si někde pamatovat minulý stav). To může mít samosbou dost neblahý vliv na výkon celé aplikace (mousemove? objemnější datové struktury?).

Implementační zajímavost #2: po změně ve watchovaných datech je volán relevantní posluchač (zpravidla ten, který má nová data vykreslit či jinak zpracovat). Jeho volání může ovšem způsobit změnu v datech někde jinde; proto je celý proces $digest potenciálně rekurzivní. Autoři tuto rekurzi omezili magickou konstantou 10, takže je nutné s daty dokonvergovat do stabilního stavu nejvýše na 10 iterací.

3d CanJS

Tento nástroj je postaven na spolupráci (a tedy i prerekvizitě) s jedním z low-level JS toolkitů: jQuery, Zepto, Dojo, YUI či Mootools. Nativně podporuje šablony EJS (syntaxe ve stylu ASP, v šabloně tedy vidíme např. <% todos.each(function( todo ) { %> či) a k dispozici je též plugin pro Mustache.

Posluchače událostí se definují vlastní CSS-like syntaxí (ať už pro DOM události či realizaci observeru). Pokud v šabloně použijeme výpis hodnoty, která je Observable (typicky .each nebo .attr), dojde v rámci šablony k navěšení posluchače na změnu tohoto Observable; při této se pak automaticky přerenderuje relevantní část šablony.

Dle dokumentace je doporučováno provazování HTML uzlů s datovými objekty – tato pochybná technika je k vidění v ukázkové aplikaci.

Zajímavost: autoři CanJS používají nezvykle obskurní techniku předávání undefined jako (nedefinovaného) parametru do všudepřítomné obalující anonymní funkce (viz první a poslední řádky zdrojových souborů).

3e KnockoutJS

Namísto tradičního šablonování si KnockoutJS počůrává části HTML atributem data-bind, ve kterém je možno specifikovat provázání obsahu prvku s daty i vyšší logiku (cykly, podmínky). Zápis

<a data-bind="css: { selected: showMode() == 'all' }" href="#/all">All</a>

tedy prvku přidá class=”selected”, pokud vykonání fragmentu JS vrátí pravdivou hodnotu. Implementace takového chování s sebou přirozeně nese takové radosti jako vnořené with a Function constructor (techniky, které patří k těm nejméně doporučovaným vůbec).

Automatická aktualizace HTML probíhá na základě vzoru Observer; voláním ko.observable() (implicitně při data-bind) vytvoříme hodnotu, která při své změně notifikuje posluchače. Sympatické je, že Model je zcela v režii uživatele a zpravidla to bývá tradiční JS konstrukční funkce. Jen ta data, která se následně propagují do HTML, jsou obalena jako ko.observable.

KnockoutJS nenabízí žádnou vestavěnou podporu pro práci s URL. Namísto Controller se v něm říká ViewModel, ale to je jen terminologický blázinec.

3z VanillaJS

Bylo by nezodpovědné jen hodnotit cizí práci a nepředvést nic vlastního. V rámci projektu TodoMVC existuje čistokrevná vanilla verze, ale není udržovaná a obyčejnému JavaScriptu dělá spíše medvědí službu. Naimplementoval jsem proto vlastní variantu ukázkové úlohy, na které je vidět, jakým způsobem k této problematice přistupujeme bez nutnosti nějakých MVC nástrojů.

Kód je rozdělen do dvou souborů – todo.js odpovídá jedné položce úkolovníku, udržuje její data i vizuální reprezentaci, zpracovává události. app.js zastřešuje celou aplikaci, aplikuje filtry, přistupuje k localStorage. Jak je vidno, hlavní manipulace s DOMem se odehrává ve funkci Todo.prototype._build – a není to nijak hrozné. Nabízejí se tato další rozšíření kódu:

  1. Helper pro tvorbu DOM prvků (pomocí výčtu vlastností v objektu nebo CSS selektorem),
  2. oddělení vizuální reprezentace do vlastního objektu (např. Todo.Visual), která by se starala výhradně o DOM a události; data by držel stávající objekt Todo.

4 Závěr

Zastánci MVC frameworků argumentují tím, že tyto nástroje dokážou zastřešit a provázat práci s individuálními komponentami a knihovnami aplikace. Dle mého názoru je tato výpomoc vágní, protože aplikační kód (controller) si člověk musí vždy vyrobit sám; to za něj žádný framework neudělá.

Naštěstí ale máme k dispozici návrhové vzory a hotová řešení pro všechny elementární úkony (práce s URL, RPC, Promise, DOM, Storage, Template, události, …) – proto mi přijde, že přidávání dalších úrovní indirekce/abstrakce má jen velmi malou přidanou hodnotu.

Až budete zvažovat použití nějakého JS MVC frameworku, zkuste si zodpovědět tyto otázky:

  1. Rozumím tomu nástroji dobře? Dokážu v implementaci ospravedlnit existenci každé řádky svého kódu a vysvětlit, proč ho používám?
  2. Bude výslednému kódu rozumět i ten, kdo k němu přijde po mně? I za dva roky?
  3. Volím framework proto, že je to nejlepší řešení mého problému? Nebo jen proto, že mi ho někdo doporučil a/nebo je zrovna in něco takového používat?
  4. Ospravedlní mi těch pár uspořených kilobajtů aplikačního kódu přítomnost frameworku, který leckdy sahá na několik set kilobajtů?
  5. Je pro mne práce s DOMem skutečně tolik obtížná a repetitivní, že kvůli ní musím klesnout k užití string-based šablon?

Komentáře

Subscribe
Upozornit na
guest
31 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
Radek

Moc pěkně rozebráno. Myslím, že podobný vývoj se neustále opakuje v různých obměnách. Není to tak dávno, kdy každý psal vlastní framework v PHP vynikající „chytým“ řešením některých detailů ale celkově nedostatkem koncepce. Věřím, že se to časem ustálí na nějakém více méně standardním řešení, to už bude snaha „hurá zlepšovatelů“ upřena jinam :-)

Petr Taborsky

Zkuste to priste bez hrubych vyrazu jako „sere na prototypy“ atd. Rekl bych, ze do tohoto prostredi se nehodi. Jinak moc pekny clanek.

Petr Novák

Asi tak. Jemné narážky na Hitlera samozřejmě potěší, ale sraní bych v seriosním periodiku spíše už nečekal.

Martin Hassman

Za to můžu já, přesvědčil jsem Ondru, ať nám článek na Zdroják dá, ač ho původně napsal bokem a už nebyl čas na nějaké dramatické změny. Ať tak či tak, jsem rád, že tu vyšel, věřím, že čtenáři jsou tolerantní.

Lukáš Vlček

Sice nejsem fandou zemitých lidových výrazů v takových článcích (ono to pak skoro vypadá, že práce s JavaScriptem je něco podobného kydání hnoje), ale jinak dík za zajímavé tipy ohledně řady MVC řešeních.
Zajímalo by mě, jestli má autor také nějaké zkušenosti s [Google] Closure Tools a jak by ho zhodnotil.

Chleba

VanillaJS fakt dobra Ondro. Musim pouzit !

Rexxar

A ja som si myslel, ze vanilla je naozajstny framework

Karel Fučík

Jsem z toho článku na rozpacích. Na jednu stranu se o všech těch frameworcích vyjadřujete dehonestujícím způsobem (ačkoliv souhlasím, že vytýkané věci často opravdu nejsou nic pěkného), na druhou stranu nenabízíte adekvátní alternativu. Ten vanilla JS příklad přece neřeší problémy, kvůli kterým MVC frameworky vznikají.

Třeba šablonování – opravdu navrhujete místo šablon všechno vyrábět imperativně v JS pomocí DOM API? To mi připadá jako čirý masochismus.

Nebo data-binding, observované modely, vnořené views s automatickou inicializací/destrukcí, dependency injection atd. To všechno se dá u miniaplikace dělat ručně, ale u větší? Co jiného než framework by to mělo řešit? (A nemusí to být striktně MVC, to je stejně jen taková módní nálepka).

Martin Hassman

Pokud je člověk z názorového článku v rozpacích, může to být dobré znamení. Nejspíš vede k zamyšlení a to je fajn.

jlx

Pod tenhle komentář bych se klidně podepsal, protože přesně shrnuje můj názor na tento článek. Věci které jsou vytýkány těm frameworkům jsou i celkem pravdivé – minimálně u těch, se kterými mám větší zkušenost (Backbone, CanJS). Ale to jsou z mého pohledu buď vyloženě povrchní věci, a/nebo vědomé volby tvůrců těchto frameworků.

Po tom, co jsem si pročet zdroják VanillaJS, tak jsem se prostě musel smát, protože s takovým přístupem bych totálně pohořel u projektů, na kterých pracuji (musel bych napsat asi tak 10x více kódu). Autor je možná megaproduktivní génius, ale já fakt ne.

A volba výrazů je no … ok, nechme to být.

jlx

Jo, ještě dodatek: zamyšlení proběhlo (a docela dlouhý), takže díky za článek!

Karel

Prave diky tomu pocuravani data-bind mam knockout rad.

Daniel Steigerwald

V pondělí vyjde můj pohled, na jinak hezký Onřejův článek. Demo verze je na mém Twitteru už teď.

lopata

Které pondělí a kde?

Martin Hassman

Vyjde pondělí 13. tady na Zdrojáku.

JoshB

Chapu, ze cilem bylo nejspis ukazat implementaci v cistem Javascriptu, ale jak uz nekdo psal nademnou… s timhle pristupem bych ve vetsich (mozna i mensich) projektech pohorel.
Neospravedlnuji existujici MVC frameworky, ale pokud se nekdo rozhodne psat bez nich, rozhodne je nutne pouzit alespon nejakou knihovnu (clanek to sice nenaznacuje, ale nekdo by to tak mohl pochopit…), nebo 90% procent kodu bude „sum“, ktery tam nema co delat.

Ja si nemuzu vynachvalit praci s frameworkem Dojo. Psani UI pomoci jadra + tridy _WidgetBase je radost ale pritom to je velmi podobne v clanku prezentovane forme.
Pozn.: Dojo ma i sablony, ale nikdy jsem jim neprisel na chut.

Kazdopadne pekny clanek, diky za nej.

maryo

To, že si to každej Framework dělá po svym se mi svym způsobem líbí. Nakonec jeden přístup vyhraje, případně někdo zkombinuje víc přístupu, někdo napíše standard a browsery to implementujou.

NkD

Naprosto luxusni clanek. Gratuluju. Konecne opravdu slusne zamysleni s vlastnim nazorem, ktery je tomu memu velice blizky. Jen vic a houst.

Futrál

Ano, tento článek je dobrý, až mi přijde, že je ho pro Zdroják škoda.

Martin Hassman

Vážně? Inu to už tak je, že někteří škarohlídi nám nepřejí, snaží se kazit, co se dá. Ale nevadí, poradíme si s tím, rozneseme všechny na kopytech 8-)

Futrál

Jen se snažte. Až tu budou články jako tenhle (a i lepší) vycházet každý den, tak třeba změním názor. A oba pak můžeme být spokojení :-)

Futrál

BTW: to máte nějaký limit článků, které můžete vydat? Že zatím nevyšla ani ta slibovaná odpověď kolegy Steigerwalda.

Vojtech Jasny

Ahoj, predevsim diky za clanek na zamysleni – takovych tady posledni dobou veru moc neni.

VanillaJS je hezke cviceni, ale obavam se, ze pro vetsi aplikaci naprosto neskalujici – nevim jak by neco takoveho mohl spravit nejaky DOM helper. Kdyz se podivam do todo.js nevidim temer zadnou SoC: na jednu stranu tam pracujeme s modelem a jeho serializaci/deserializaci, ale mame tam i elementy view a update rozhrani, casti by zase mohly byt v controlleru.

Bohuzel jsem se ve velmi realne (a radne velke) SPA s podobnym kodem setkal a muzu rict, ze ve vetsim meritku tohle vede k totalni katastrofe. Pokud by to melo fungovat, byla by nezbytna zelezna disciplina vsech developeru, aby tyhle modelo-view-controllery nenarostly do obludnych a nespravovatelnych rozmeru. Michani DOMu s modelem je tez naprosta katastrofa pro unit testy. Nemyslim, ze bys mohl tyhle velmi realny potreby v ramci nejakyho dema jen tak opomenout, protoze je budes ve skutecny aplikaci muset nejak resit od prvni chvile.

Na novejsich castech aplikace pouzivame Ember.js a ackoli zatim neni dokonaly, dava nam celkem slusne moznosti deleni kodu do malych komponent. Snadnosti zapisu nam velmi vyhovuje jeho abstrakce nad prototypovou dedicnosti. Handlebars sice nemilujeme, ale na priklad s onclick muzu namitnout, ze akce v Emberu jsou semanticke v ramci aplikace nebo controlleru, neni tak jako kdysi, kdyz bych do onclick strcil imperativni kod nebo primou manipulaci s DOMem.

Mohl bych pokracovat, ale asi se spokojim s konstatovanim, ze se autor nehezkym jazykem opira do frameworku resicich problem co pred par lety jeste moc lidi nemelo, ale sam nenabizi krome nametu na zamysleni vlastne zadne jine reseni :-).

Richard Šerý

Šablony samozřejmě způsobují mnoho nešvarů, tady musím bezvýhradně souhlasit. Ale připadá mi hloupé „házet“ to na MVC frameworky obecně, samotný princip MVC je i dnes správný a potřebný. S tím, že všechny současné šablonovací frameworky jsou tragické to přeci nikterak nesouvisí, vývojáři se teprve učí dělat UI.

Osobně v JS na tyhle věci většinou používám JQuery, kde model je samotná HTML stránka (včetně různých data- atributů) + to co přijde AJAXem. View pak tvoří „šablony“ (což je typicky kus HTML kódu), které se pak „obrábí“ metodami JQuery, jako je např. append, wrap, addClass atd.

Jistě, není to dokonalé, není to extra výkonné, ale je to jednoduché, flexibilní, každý to pochopí a snadno se to naučí. A funguje to lépe než jakýkoli šablonovací framework s jakým jsem se zatím setkal, včetně těch na straně serveru.

Mimochodem, „ctít“ klíčová slova „new“ a „this“ mi připadá jako cesta do pekel. Velké aplikace vyžadují srozumitelnost a zapouzdření a tato dvě klíčová slova jdou přímo proti těmto požadavkům. Nevidím žádný důvod proč nepoužívat tovární funkce a srozumitelně nepojmenovat všechno co pojmenovat jde.

S čím ale musím opět souhlasit je názor, že v podstatě jakýkoli dostupný MVC framework, obzvlášť v JS, vyžaduje železnou disciplínu při implementaci. Myslím si že příčinou je příliš velká flexibilita UI frameworků obecně (a v JS obzvlášť). Žádný z frameworků, co jsem viděl, neimplementuje složitější návrhové vzory (jako je např. seznam objektů s filtrem, napojením na messaging atd.), programátoři tak dělají spoustu zbytečných rozhodnutí, píšou spoustu kódu a kvalita trpí.

keff

– buď řeším logiku a soustředím se na ní (a jsem rád že můžu ignorovat šablonu a starám se jen o objekt který šablonovacímu systému předám k vyrendrování), anebo ladím vzhled, a vím, že si s šablonou můžu dělat co chci, pokud zachovám třídy nebo id na kterých mám zavěšené listenery událostí. Jsem fakt rád, že při ani jedné z činností nemusím v hlavě držet obě věci najednou.

My two cents.

Tomas Hodbod

Ondro tohle ti vazne prijde prehledne a pouzitelne?? Resp ptam se blbe – jasne, ze prijde… ale jeste nekomu??
Navic nekomu kdo treba ma produktivni zkusenosti s Backbone a underscore templaty (pokud tedy nechceme bindovat udalosti v html kodu jako angular apod).

JAK.DOM.append(
        [this.formRoot, moverTitle],
        [this.formRoot, this.form],
            [this.form, this.campaign],
                [this.campaign, this.campaignIn],
                    [this.campaignIn, this.campaignSelectLabelHeadline],
                    [this.campaignIn, this.campaignSelectOuter],
                        [this.campaignSelectOuter, this.campaignSelect],
            [this.form, this.group],
                [this.group, this.groupIn],
                    [this.groupIn, this.groupSelectLabelHeadline],
                    [this.groupIn, this.groupSelectOuter],
                        [this.groupSelectOuter, this.groupSelect],
            [this.form, this.loader],
        [this.formRoot, this.submitWrapper],
            [this.submitWrapper, submit],
        [this.formRoot, cleaner]
    );

Podle me ma byt v html html, vcetne logiky zobrazeni. V js pak k tomu kontrolery a zpracovani dat a udalosti.

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.