JavaScriptové MVC frameworky (reakce na článek Ondřeje Žáry)

Jaký je současný stav MVC frameworků v JavaScriptu. Jsou tou správnou cestou? Minule nám svůj subjektivní pohled předložil Ondřej Žára, dnes na něj reaguje Daniel Steigerwald.

Ondřej Žára předminulý týden napsal článek, který mne zaujal. Předně, považuji Onřeje za špičkového programátora, ale v některých názorech s ním nesouhlasím. A nebo jen špatně čtu mezi řádky, i to je možné. Co se týká přehledu frameworků, ten by vydal na samostatný článek. Mimochodem, zrovna minulý víkend jsem na podobné téma přednášel na pardubickém DevFestu.

Proč dávám přednost šablonám před DOM manipulací

Kdysi dávno jsem šablony také nepoužíval. Teď je používám skoro vždy. Proč?

Bezpečnost, XSS a vůbec

Známá věc, programátor zapomene někde escapovat string, a je problém. Se šablonovacím systémem na to myslet nemusím (tolik), viz také developers.google.com/closure/templates/docs/security.

Rychlost

innerHTML je stále nejrychlejší. V Google Closure se šablony kompilují do funkcí. Celá aplikace je tedy jeden JavaScript. Ten obsahuje kód, HTML v šablonách, texty. Třeba takový tapomat.cz, celá aplikace má jen pár desítek kb.

Události

Opravdu není nutné registrovat onclick na každý řádek tabulky. Máme event bubbling a event delegation. V Este vyrenderuji třeba seznam objednávek, a click (respektive tap event) dostane v listeneru přímo model konkrétní objednávky. Registrace bublajících událostí je velmi jednoduchá, viz demo. Díky bublání eventů můžeme obsah elementu přerenderovávat přes innerHTML kolikrát chceme, a není nutné eventy deregistrovat.

Lokalizace

V Google Closure Templates mám perfektní podporu lokalizace. Stačí si pamatovat vždy použít <msg> pro šablony a goog.getMsg pro kód, a lokalizace je hračka, i když se aplikaci rozhodnete lokalizovat poté, co je rok ve vývoji. Mimochodem, nepoužité překlady Closure Compiler při kompilaci odstraní, takže není třeba řešit bobtnání slovníků.

Pořádek

Každá šablona, respektive vykompilovaná funkce z ní, je umístěná ve svém namespace. Aplikace se skládá z features, a pomocí feature toggle a Closure Compileru můžu vykompilovat jen to, co je třeba. Příklad, mobilní verze nebude mít administraci. Jeden projekt, dva vykompilované soubory pro každé zařízení zvlášť. Veliký pokrok proti script tagům v HTML stránce!

Budoucnost a Angular

Angular se od všech ostatních MVC frameworků liší tím, že používá něco, co bude jednou součástí nativního api prohlížeče (takže to bude používat i Ondrej Žára ). Ano, šablonovací systém Angularu je něco jako polyfill pro github.com/toolkitchen/mdv. To je mimochodem důvod, proč Este nemá něco jako Angulaří šablony. Este má svoje vlastní postupy a časem bude zahrnovat i vlastní MDV polyfill.

Jmenuji se Daniel Steigerwald a pomáhám firmám i jednotlivcům s vývojem webových aplikací. Pořádám školení, která si můžete objednat na javascript-skoleni.cz. Pokud máte dotazy, napište mi.

MVC Frameworky

Framework není nic jiného, než předprogramovaná aplikace. Zajímavé je, že v Google Closure žádný jeden univerzální MVC framework není. Proč Closure nemá jeden MVC framework? Protože v Googlu má každý tým vlastní framework. Jeden pro mapy, další pro Google Docs, a tak dále. Většina JS programátorů ale nepíše mapy nebo Google Docs. Chtějí SPA (Single Page Applications). A tam narazí na mnoho již vyřešených problémů. Například routing. Ten mimochodem naprostá většina MVC frameworků řeší špatně, (krom Este MVC samozřejmě).

Onřej má tedy pravdu, že na specifické příklady se hodí framework vlastní. Ale na 80 % zbytku je dobré postavit se na záda někomu, kdo SPA MVC aplikaci už psal.

Existuje ještě třetí možnost. Pokud MVC framework není monolitický bastl, můžu si půjčit jen to, co potřebuji. Příklad. Este MVC používá este.Model, este.Collection, este.Router, este.este.storage.* a tak dále. Nicméně, ve vaší aplikaci můžete využít třeba jen este.Router a este.storage.Local.

Onřej Žára TODO MVC

TodoMVC Ondřeje Žáry je technologická hříčka. Tímto způsobem se píší příspěvky do soutěže js1k.com. Psát takto něco většího by byla katastrofa. Co když budeme chtít vyrenderovat todo v jiném pohledu? Budeme muset rozdělit soubor todo.js na model a jeho view. Co když budeme chtít zpracovávat více cest, napíšeme si vlastní router? A tak dále, ale já myslím, že Ondřej tohle ví, a zmiňuji to zde hlavně proto, aby někoho nenapadlo psát JS aplikaci podobným způsobem. Frameworky jsou dobrá věc. Neřešte, co už je vyřešené.

Este TODO MVC

TodoMVC demo napsané nad este.App. Možná vás zarazí velikost – 496 kb JavaScriptu! Ale to je v pořádku. V Closure můžeme psát velkoryse, není třeba se omezovat. Klidně můžeme použít takovouhle obří enumeraci, nebo implementaci localStorage pro IE 6 a 7. Nemyslete si ale, že jsem musel explicitně ten kód volat, přidávat script tag, nebo něco takového. Stačilo goog.require('este.storage.Local'); a můžu používat svou vlastní local storage. Closure a Este se postará o zbytek. Tento mód používáme při vývoji. Pro nasazení použijeme vykompilovanou verzi. Vykompilovaná Este TodoMVC app má 22 kb (po gzipu). Mimochodem, nemá smysl řešit velikost bez gzipu. Ten podporují všechny prohlížeče, a Closure Compiler navíc optimalizuje kód tak, aby se dobře kompresil. 22 kb se šablonama, logikou, podporou IE, MVC frameworkem, lokalizací plural rules a mnoho další. Pro srovnání, samotné jQuery má něco kolem 32 kb.

Závěr

Onřej Žára napsal pěkný článek, který snad pomůže vybrat si framework. Líbí se mi, jak šel do architektonických detailů. S jeho závěry však nesouhlasím. Zkusil jsem si oba způsoby vývoje, psát si všechno sám a reuse, a neměnil bych. V Google Closure Library je tak neskutečné množství perfentního otestovaného kódu, že by byla fakt veliká škoda jej nevyužít. Velikost a rychlost výsledné aplikace je díky Closure Compileru naprosto bezkonkurenční. Většina aplikací je menší než samotné jQuery.

Odpovědi na otázky z předchozího článku:

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?

Ano, v Closure i Este mám všude podrobné testy a dema. Nevím o jiné knihovně tak dobře pokryté testy a zdokumentované.

Bude výslednému kódu rozumět i ten, kdo k němu přijde po mně? I za dva roky?

Jasně, Closure je v produkci už od roku 2007. Většina kódu se vůbec nemění, knihovna je stabilizovaná, breaking change jsem nezažil. Co se týká Este, snažím se psát hodně malých tříd, a minimalizovat breaking change. Změna signatury metody například, je navíc díky compileru bezpečná.

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?

Volím Google Closure, a nad ním postavené Este, protože jsem napsal zilióny řádků v jQuery, Mootools, YUI, a dalších. Špatné cesty jsem si poctivě prošlapal.

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ů?

Je to naopak. :) S Closure jsou moje aplikace řádově menší než aplikace jiných frameworků. Zdrojáky jsou obrovské, ale výsledný kompilovaný script maličký.

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?

Ani ne, ale používám ji tam, kde to dává smysl. Třeba když přepínám pohledy, píšu komponentu (ale ta též může využívat šablony), a podobně. Když jde o HTML strukturu, šablony používám vždy. Je to velmi praktické a pohodlné.

Independent software gardener, libertarian, web applications consultant and trainer. Google Developer Expert since 2012.

Věděli jste, že nám můžete zasílat zprávičky? (Jen pro přihlášené.)

Komentáře: 49

Přehled komentářů

Tom Reakce na reakci na článek
Martin Hassman Re: Reakce na reakci na článek
Lukas Este a google closure
Petr Re: Este a google closure
Daniel Steigerwald Re: Este a google closure
keff Re: Este a google closure
Kareves A příklad?
Daniel Steigerwald Re: A příklad?
Kareves Re: A příklad?
Daniel Steigerwald Re: A příklad?
Filip.Jirsak bezpečnost?
Daniel Steigerwald Re: bezpečnost?
Filip.Jirsak Re: bezpečnost?
Daniel Steigerwald Re: bezpečnost?
Filip.Jirsak Re: bezpečnost?
David Grudl Re: bezpečnost?
Martin Hassman Re: bezpečnost?
Filip.Jirsak Re: bezpečnost?
Martin Hassman Re: bezpečnost?
Filip.Jirsak Re: bezpečnost?
Filip.Jirsak Re: bezpečnost?
Daniel Steigerwald Re: bezpečnost?
Filip.Jirsak Re: bezpečnost?
Martin Hassman Re: bezpečnost?
David Grudl Re: bezpečnost?
Martin Hassman Re: bezpečnost?
Martin Hassman Re: bezpečnost?
Ondřej Žára Re: bezpečnost?
David Grudl Re: bezpečnost?
Ondřej Žára Re: bezpečnost?
David Grudl Re: bezpečnost?
Filip.Jirsak Re: bezpečnost?
Filip.Jirsak Re: bezpečnost?
David Grudl Re: bezpečnost?
David Grudl Re: bezpečnost?
David Grudl Re: bezpečnost?
Filip.Jirsak Re: bezpečnost?
Širo Nesúhlasím ...
Martin Hassman Re: Nesúhlasím ...
Daniel Steigerwald Re: Nesúhlasím ...
Daniel Steigerwald Re: Nesúhlasím ...
Širo Re: Nesúhlasím ...
David Grudl Routing
Daniel Steigerwald
David Grudl Re:
Igor Hlina Re:
David Grudl Re:
Daniel Steigerwald
Filip Procházka Rozbité odkazy
Zdroj: https://www.zdrojak.cz/?p=8149