Vývoj webovej aplikácie pomocou GWT

28.10.2015 20:20 | Přečteno: 2152× | Vývoj | | poslední úprava: 28.10.2015 20:18

Viem že neprinášam na stránkach tohto blogu žiadnu novinku ale napriek tomu sa chcem podeliť o skúsenosti z vývoja WebUI aplikácie s pomocou GWT. Google Web Toolkit GWT je nástroj na vývoj WebUI aplikácie, ktorý je založený na myšlienke krížovej kompilácie Java -> JavaScript. Pre javovských vývojárov prináša jednoduchú cestu ako písať WebUI aplikáciu, v známom jazyku, bez toho aby sa museli učiť JavaScript. Určite sa ale nevyhnú CSS a HTML.

Pár slov o GWT:

• JAVA kód je prekladaný krížovým prekladačom do optimalizovaného cross-browser JavaScript-u
• Čisto klientská technológia, server može byť iný ako založený na Jave (Java server ma výhodu GWT-RPC komunikácie)
• Komunikácia zo serverom prebieha formou asynchrónnych požiadaviek AJAX (XMLHTTPRequest)
• Podpora pre rôzne prehliadače
• Nepodporuje: dynamic class loading, reflection ( na klientskej strane, JavaScript nič také nepozná)
• SDK
  • Sada balíkov com.google.gwt.*, ktorá umožňuje vytvorenie GWT aplikácie
  • Triedy pre UI, komunikáciu zo serverom , internacionalizáciu, XML, JSON, animáciu, DOM ...
  • Najpoužívanejšie: com.google.gwt.user.client.ui, com.google.gwt.user.rpc.*,  com.google.gwt.core.client,com.google.gwt.i18.*
• Nástroje SDK 
  • Compiler – com.google.gwt.dev.Compiler, kompilácia JAVA programu do JavaScriptu,
  • Optimalizácia: in-lining methods, removing dead code, optimizing strings, splitting code to fast startup, permutations
  • DevMode – com.google.gwt.dev.DevMode, serverový nástroj zjednodušuje vývojový cyklus tým že nie je nutná rekompilácia po zmenách v zdrojovom kóde.
  • GWT developer plugin – klientská časť DevMode nástroja, podporované prehliadače Firefox, IE, Chrome, Safari (browser plugin, problemy s kompatibilitou)
  • SuperDevMode - nová náhrada za GWT developer plugin
  • WebAppCreator – nástroj na vytvorenie GWT projektu
  • GWT Eclipse plugin – integrácia GWT do IDE Eclipse
• JAVA kompatibilita
  • JRE emulation library- rozsah JRE emulation library je limitovaný možnosťami JavaScriptu
  • Intrinzické typy: podpora pre primitívne typy, Object, String, polia a triedy s niektorými výnimkami pre čísla JS ma iba double
  • Výnimky: podporované, getStackTrace() nepodporované v produkčnom mode
  • Assert: podporované v DevMode
  • Multithreading: nepodporované, JS interpreter je single thread
  • Nepodporovane reflection, finalizácia, serializácia

Vývojové kroky:

• Generovanie aplikácie pomocou nástroja webAppCreator napr. webAppCreator -out HelloWorld sk.dominanz.gwt.HelloWorld' čo vytvorí kostru aplikácie v súborovom systéme
• Kódovanie Java tried, deklaratívnej definície UI, resource a iných súčastí
• Testovanie aplikácie je možné bez krížovej kompilácie v devmode ant devmode. (Krížová kompilácia je pri väčšom projekte dosť dlhý proces.)
• Kompilácia produkčnej verzie a vytvorenie war pre nasadenie do JSP kontajnera ant war.

Vývoj aplikácie

Dôvodov prečo sme sa rozhodli používať GWT bolo niekoľko. Vymenujem ich v poradí od toho s najväčšou váhou.

• GWT nám umožní vyvíjať JS klientskú aplikáciu bez znalosti JS, čo vyhovovalo nášmu vyvojárskemu tímu, kde boli k dispozícií Java programátori so znalosťou HTML a CSS ale s okrajovými znalosťami JavaScriptu.
• Náklady na osvojenie GWT prijateľné. Množstvo znalostí z Javy je recyklovateľných napr. UI knižnice sú podobné AWT, udalostný systém totožný s AWT.
• Kvalita generovaného JS je prijateľná. Vygenerovaný (kr. prekladačom) JS je optimalizovaný a v permutáciach pre rôzne prehliadače a lokalizácie.
• Robustnosť frameworku, dobre možnosti spolužitia s Java svetom v pozadí
• Deklaratívny spôsob definovania UI, komunikácia so serverom cez GWT-RPC.
• Kvalitný plugin pre Eclipse, dobrá podpora debugovania a testovania, možnosť refaktorizácie

Projekt, ktorý sme pomocou GWT realizovali možme v automobilovej terminológii nazvať nižšia stredna trieda. Rozsah projektu je cca. 1400 súborov/160000 riadkov z toho *.java je cca. 1100 súborov/ 135000riadkov. Projekt rieši problematiku DMS klienta.

Rozdelenie kódu aplikácie.

Kód klienta, je časť kódu, ktorá je prekladaná kr. prekladačom do JS. Obsahuje UI časť aplikácie. Funkcionalita je obmedzená možnosťami JRE emulation library.

Serverová časť, je Java kód, ktorý beží na strane servlet kontajnera napr. Tomcat. V tejto časti je prístupná Java v plnej funkcionalite.

Zdielana časť, slúži na prepojenie serverovej a klientskej časti. Platia pre ňu obmedzenia ako v klientskej časti. Na tomto mieste definuje triedy, ktoré sú jednoduché, väčšinou iba zapúzdruju dáta a používajú sa v GWT-RPC volaniach.

WS - WebServices

DMS systém poskytuje SOAP-WS API definované vo wsdl súbore. Klientské triedy sme generovali utilitou wsimport, označme ich ako skupina A. Problém na ktorý sme narazili bola nepoužiteľnosť niektorých tried zo skupiny A na klientskej strane kódu kvôli obmedzeniam JRE emulation library. Kedže dochádza k úpravam wsdl definície a tým pádom k regenerovaniu WS klienta ako jedine schopné riešenie sa ukázalo vygenerovanie tried zo schémy vo wsdl utilitou xjc, označme túto skupinu ako B. Skupinu tried B sme potom pomocou starých dobrých utilít ako sed, awk, grep upravili triedy do formy vhodnej pre klientskú časť kódu. Takto sme získali dva typy tried vygenerovaných z tej istej schémy ale problémom nebol koniec. Ešte bolo potrebné vyriešiť mapovanie z A do B a naopak. Použili sme niečo čo sa volá modelmapper. S obmedzeniami, ale pomohol.

CSS štýlovanie

Použili sme asi všetky dostupné metódy štýlovania dostupné v GWT aplikáciach kým sme našli podľa naších kritérii optimum. Všeobecné štýly a redefinície GWT štýlov sme umiestnili do statického css súboru. V deklaratívnych definíciach UI komponentov sme definovali štýly riadiace rozloženie. Štýly spoločné pre deklaratívne definície UI sme definovali v triedach odvodených z CssResource.

Deklaratívne UI

Spôsob definície UI komponentov deklaráciou v xml formáte. Ku každému xml existuje Java trieda implemetujúca funkcionalitu. Viď komentovaný príklad.

<!DOCTYPE ui:UiBinder SYSTEM "http://dl.google.com/gwt/DTD/xhtml.ent">
<ui:UiBinder xmlns:ui="urn:ui:com.google.gwt.uibinder"
	xmlns:g="urn:import:com.google.gwt.user.client.ui" 
    xmlns:c="urn:import:com.google.gwt.user.cellview.client"
	xmlns:cw="urn:import:sk.dominanz.gwt.ui.client" 
    ui:generateFormat='com.google.gwt.i18n.rebind.format.PropertiesFormat'
	ui:generateKeys="com.google.gwt.i18n.server.keygen.MD5KeyGenerator"
	ui:generateLocales="default">
    <!-- xmlns:g - namespace Google GWT komponentov  -->
    <!-- xmlns:cw - namespace vyvojara, package obsahuje komponent view -->
    <!-- ui:generate* - podpora pre generovanie jazykových resourcov -->
    
    
	<ui:with type="sk.dominanz.coarui.client.ui.CoarUIResources"
		field="coaruires"></ui:with>
    <!-- coaruires - resources zdielane v UI komponentoch, obsahuje retazce, CSS, obrazky   -->
    
    <!-- lokálny štýl komponentu -->
	<ui:style field="style"
		type="sk.dominanz.coarui.client.ui.logoutWidget.LogoutWidget.Style">
		.mainPanel {
		width: 54.5em;
		background-color: white;
		box-shadow: rgba(0, 0, 0, 0.5) 0 2px 6px;
		margin-top: 1.2em;
		}
	</ui:style>

    <!-- GWT komponent panel, renderovany ako div.  
     {style.mainPanel} - volanie metody getMailPanel objektu style, vrati meno stylu 
     ako je deklarovany v lokalnych styloch
    -->
	<g:HTMLPanel addStyleNames=' {style.mainPanel} '>
        <!-- HTML komponent div 
            {coaruires.style.dialogTitle} - volanie metody coauires.getStyle().getDialogTitle(), vrati meno stylu 
            ako je deklarovany v zdielanych stýloch
        -->
		<div class='{coaruires.style.dialogTitle} '>
            <!-- Kompilátor generuje pre ui:msg deklaracne subory pre jazykove mutacie -->
			<ui:msg key="title">Logout</ui:msg>
		</div>

		<div class='{coaruires.style.buttonPanel}'>
                <!-- ui:field vazba na premenu v java triede -->
		<g:Button addStyleNames=' {coaruires.style.button}'
				ui:field="logoutButton">
				<ui:msg key="logoutButton">Logout</ui:msg>
			</g:Button>
			<g:Button addStyleNames=' {coaruires.style.button}'
				ui:field="cancelButton">
				<ui:msg key="cancelButton">Cancel</ui:msg>
			</g:Button>
			<g:Button addStyleNames=' {coaruires.style.button}'
				ui:field="saveButton">
				<ui:msg key="saveButton">Save objects</ui:msg>
			</g:Button>
		</div>
	</g:HTMLPanel>
</ui:UiBinder>

Vytváranie komponentov deklaráciou je veľmi výhodné. Urychľuje vývoj, sprehľadňuje kód, rozloženie komponentu je zo zdrojového kódu aspoň predstaviteľné. Komponent sa dá použiť v iných deklaráciach alebo priamo imperatívne v programe Comp c = new Comp();. Imperatívný spôsob vytvárania UI sme prakticky nepoužili.

Statické typovanie

Ako veľmi výhodná sa ukázala typová kontrola kompilátora najmä pri častých zmenách WS. V Jave samozrejmosť, čo sa nedá povedať o kombinácii JS,JSON.

GWT-RPC

Volanie serverovej funkcie je na strane klienta redukované na volanie funkcie a definovanie handlera pre onSuccess a onFailure prípady. Všetky volania servera sú asynchrónne.

			demoService.rpcFunction(textToServer, new AsyncCallback<String>() {
					public void onFailure(Throwable caught) {
						// Show the RPC error message to the user
						dialogBox.setText("Remote Procedure Call - Failure");
					}

					public void onSuccess(String result) {
						dialogBox.setText("Remote Procedure Call");
					}
				});

Event bus

Mechanizmus šírenia udalostí v GWT nazvaný Event Bus sa ukázal ako veľmi výhodný, pretože umožňuje spracovanie udalostí v oddelenom režime. To znamená že nie je nutné aby príjimateľ poznal objekt od ktorého udalosti chce spracovávať a stačí aby sa zaregistroval na príjem určitého typu udalosti na EventBus. Event Bus sme najviac ocenili pri spracovaní globálnych udalostí pochádzajúcich napríklad z menu a udalostí generovaných v handleroch asynchrónnych volaní.

SuperDevMode

Základné informácie o SuperDevMode nájdete tu. Na veľkú časť vývoja sme použili spomínaný SuperDevMode ale vyskytli sa situácie keď bol potrebný návrat ku klasickému devmode. Tu sú tie situácie:

• Výpis stacktrace nie je identický s java kódom čo zťažuje identifikáciu výnimiek a v niektorých prípadoch je potrebný návrat ku klasickému DevMode.
• Kvalita debugovania v SuperDevMode nie je postačujúca najmä v zložitejších prípadoch.

Záver

Vývoj GWT aplikácie splnil naše očakávania a nelíšil sa od zverejnených hodnotení. Bolo pár vecí, ktoré znepríjemňovali život, napríklad ešte nie dokonalý SuperDevMode alebo zmena mien štýlov v deklaratívnych UI. Porovnať GWT s JS frameworkom nedokážem preto neviem ani posúdiť efektivitu vývoja snáď okrem jedného aspektu a to je výhoda statického typovania. Celkovo možem povedať že na ďalší WebUI projekt zvolíme GWT opäť.

       

Komentáře

[Bedňa]

Vyzerá to fajn, no kód ktorý väčšinou lezie von s podobných frameworkov je hrozný a proste skôr, alebo neskôr narazíš na veľké problémy. Toš moja skúsenosť.

[lacod]

V generovanom kóde nie je problém, dokonca sa vychádza z tvrdenia že GWT generuje lepší kód ako ručne písaný kód. Pochybnosti mám v otázke uvoľňovania pamäti po nepoužívaných objektoch najmä pri event listeneroch/handleroch. Do určitej miery to rieši Event Bus.

[mirec]

Tvrdiť, že kód prekladaný z jedného jazyka do druhého je lepší než ručne písaný kód je asi ako tvrdiť, že C je lepšie než assembler. Keby to bola pravda neoptimalizovalo by sa napríklad enkódovanie / dekódovanie videa v assembleri.

Takže späť od marketingových kecov k realite. Neviem kto používa GWT (rád by som si pozrel ukážku generovaného kódu na nejakej stredne veľkej webovej aplikácii). Neviem, či google používa niekde GWT, ale tipol by som, že google hangouts / google + ... sú postavené práve na tom. Ak je to tak potom ten kód ktorý z toho lezie je mnohonásobne horší než čokoľve čo som predtým videl. Je katastrofálne veľký s katastrofálnym výkonom. Ale to je len úvaha, neviem v čom to píšu ;)

Kedysi som uvažoval o písaní js aplikácií v coffee scripte / typescripte. Tie sú lightweight a viem čo z toho lezie. Nemôžem však ovplyvňovať spôsob generovania niektorých výrazov napr. list comprehension sa vždy preloží na for namiesto forEach (forEach má podstatne vyšší výkon vo firefoxe, ale v chrome je pomalý, v mnohých benchmarkoch chrome podáva lepšie výsledky lebo je kód písaný na mieru chromu). Nakoniec skončím s niekoľkonásobne pomalším kódom vo firefoxe pretože autor prekladača bol chromofil.

Jedinú výhodu písania aplikácie v inom jazyku vidím v tom, že je to iný jazyk ;) Javascript je hnusný, má hnusnú syntax, hnusnú podporu objektov, default unsafe, ignoruje chyby ktoré vybublú niekde úplne inde než sa stali ... Argumentovať použitie prekladača tým, že z toho lezie dobrý kód je blbosť, jediný dôvod pre výber iného jazyka pohodlie a rýchlosť vývoja.

[lacod]

Neviem či si pamätate na prekladač Watcom C/C++, ten bol príkladom že kompilátor môže generovať lepší kód ako ručne písaný asm.(nebavme sa o konkrétnych algoritmoch ako encode videa, na nich pracujú vývojari aj niekoľko rokov)

Zdroj wiki: Google has noted that some of its products are GWT based:[20] Blogger AdWords Flights Wallet Offers Groups Inbox[21] Hangout tam nie je.

GWT generuje permutácie JS pre podporované prehliadače, a tie obsahujú optimalizovaný JS kód.

Tu je vzorka kódu na analýzu. Seriózne by ma zaujímal výsledok.

[mirec]

Neviem či si pamätate na prekladač Watcom C/C++, ten bol príkladom že kompilátor môže generovať lepší kód ako ručne písaný asm.(nebavme sa o konkrétnych algoritmoch ako encode videa, na nich pracujú vývojari aj niekoľko rokov)

Nie. Rovnaké kecy ako kecy typu java je rýchlejšia net X. Všetko závisí od konkrétneho človeka ktorý optimalizuje. Videl som mnoho katastrofálne "optimalizovaného" javascriptu. To, že väčšina ľudí netuší ako písať kód poriadne nevypovedá to nič o kvalite prekladu.

Tá vzorka na analýzu ako vážne 2 MB kódu ktorý sa načítava a inicializuje naraz?

[lacod]

net X ?

2MB aky je v tom problém, na alokácii RAM pre tab v GoogleChrome je to +10MB.

[mirec]

Aký je v tom problém? Mne to načítava 3 minúty (EDGE). Ďalších 10s je parsovanie v browseri na to aby som zobrazil 2 inputy. Nazývať taký kód "lepší než ručne písaný" je jednoducho blbosť.

Keby mi ktokoľvek napísal 2MB javascriptu a načítal to naraz pre zobrazenie loginu tak ho asi pošlem kade ľahšie.

Takže ešte raz, ako nástroj na statickú kontrolu kódu fajn, ale tvrdiť, že to generuje dobrý kód je blbosť. Generuje to rovnaký odpad ako keby som sa assembler snažil strojovo preložiť na C (java je nižší jazyk než javascript, v js sa dajú využiť rôzne dynamické vlastnosti jazyka, ktoré nespomalia kód, ale niekoľkonásobne zmenšia veľkosť). Vo výsledku z toho vylezie možno niečo čo po stiahnutí a spustení o pár % prekoná js kód priemerného frontend developera, ale samotné parsovanie bude trvať podstatne dlhšie.

[lacod]

Je to trochu inak, v tych 2MB je celá aplikácia nielen obrazovka prihlásenie. Dá sa do toho prihlásiť u: ctest p: ccoorraa . Ešte jedna vec, sú to v skutočnosti 4MB kódu.

[mirec]

Je mi jasné, že je to celá aplikácia, práve o tom to je ;) Ak píšem aplikáciu tak jednoducho použijem spoločnú knižnicu (cca 10kB) kde mám pár utilít a asynchrónny loader. Pre jednotlivé časti webu potom dotiahnem samostatné skripty podľa potreby. Jednoducho js mi na to dá prostriedky a ja môžem písať efektívnejší kód.

Ps. 4MB je šialene veľa. Keď si vezmem, že môj linuxový portál má okolo 500kB a to je tam mnoho zbytočného kódu ktorý pôjde preč. Čo sa týka viacej javascriptových vecí to nemám nikde zverejnené, ale mám nejaké tie intranetové veci podstatne podstatne rozsiahlejšie a celkovo serverová aj klientská časť je menšia než 500kB.

[lacod]

GWT taktiež pozná moduly a kód sa dá deliť na časti a podľa potreby doťahovať. Veľkosť výsledného kódu som zrazil na 1.7M, kompilačnými parametrami kompilátora -style OBF (-style Script output style: OBF[USCATED], PRETTY, or DETAILED (defaults to OBF)).

[lacod]

Ako som už vyššie povedal, skôr mám obavy o memory leaks.

[xm]

Píšete jako kdybyste neznal běžné průměrné "webdevelopery" Věřím že strojově generovaný kód může být lepší než spousta toho co ručně vyprodukují

[mirec]

Mne vadilo generické tvrdenie. Priemerných webdeveloperov aj javistov poznám, majú toho spoločného celkom dosť. Minule som omylom na jednom webe vypol ghostery vďaka čomu nedošlo v behu javascriptu k výnimke a skončilo to namiesto prázdnej stránky OOM-kom. Web mal 16MB prevažne javascriptu čo bola celkom bomba na spravodajský web s 1 fotografiou a pár riadkami textu.

[mirec]

Ešte celkom zaujímavý materiál na túto tému je tu. Tomu kto by chcel písať celkom slušne optimalizovaný js v inom jazyku by som odporúčal scala-js.

[Saljack]

Neni nahodou GWT uz mrtvi projekt? Proc nesahnout rovnou po Vaadinu. Za me je to rozhodne hell po roce delani s Vaadinem musim rict, ze uz nikdy vice psat UI v Jave. Je nesmysl. I kdyz se dodrzuje striktne MVP pattern, tak to hrozne boptna. Spatne se v tom orientuje. Nejhorsi je, ze kvuli kazde zmene css classy, posunuti prvku se musi sahat do kodu. Podle me ma byt view resp. to jak to ma vypadat v necem jinem nez v "programovacim" jazyce napr. xml nebo json. Podle me jsou JSF tak 100x lepsi nez GWT.

[lacod]

Vaadin používa GWT, je z neho odvodený viď Vaadin API. Tie zmeny v kóde vs. css bola záležitosť verzií 1.x. Tak ako som v blogu napísal, deklaratívne UI a GWT 2.x posunulo celý vývoj k lepšiemu. Dizajn obrazoviek môže byť voliteľne založený na HTML alebo GWT Widget. Obidva však dovoľujú použitie štýlov tak ako ich používame v HTML.

[Saljack]

To je celekem pekny. Skoda, ze u nas uz je Vaadin tak priohnuty, ze by to asi nefungovalo.

[linear]

Vaadin nepoužívám, ale sleduji. Zatím to vidím jako nejlepší framework na Web aplikace. Možnost psát serverovu i klientskou část v stejném jazyce a IDE (Eclipse, Netbeans nebo IntelliJ), velká hromada komponent, vyspělý grid (tabulka) s propojením na DB... Hodně mi to připomíná Delphi před 20 lety který také vsadil na komponenty a integraci vývoje "pod jednu střechu". Kdybych rozjížděl nějakou web app, určitě bych šel do Vaadinu.

[msk]

Mam skusenost s Vaadinom z pred ~5 rokov a bol som spokojny. Mojim cielom bolo naprogramovat aplikaciu, ktorej zobrazovadlo bude namiesto gui app nejaky web browser a to sa aj podarilo. Argumenty web developerov o generovanom kode a nemoznosti to nasledne customizovat su relativne caste, stretol som sa s tym aj na mojom aktualnom projekte, kde sa nad spring stackom pouziva na web sablonovaci framework jade. Napriek argumentom nasich webistov, ze v jednoduchosti je krasa a blablablabla vidim, ze napriklad kazda validacia sa deje (rucne pisanym) javascriptom v browseri a potom este duplicitne pomocou hibernate validator v java kode. Takisto zlozitost naskoku noveho java vyvojara do projektu (musi do seba absorbovat aspon zaklady jade, javascriptu atd...) nie je argument k zahodeniu. Vyzera to tak, ze vaadin ubehol za tie roky vcelku velky kus cesty a dumam ci nenadisiel cas sa s nim znovu detailnejsie oboznamit...

[mirec]

Čistí javascripťáci sú idioti. Ja už pekných pár rokov validujem len na serveri a klientovi posielam chyby v jsone. O zobrazenie sa stará cca 100 riadkov javascriptu, ktorý používam u väčšiny nových projektov. Podpora na serveri je cca 50 riadkov. Celý kód vyzerá napr. takto:

# serverová časť

class ArticleCreateView(AjaxFormMixin, CreateView):
    model = Article
    fields = ('title', 'content')


# klientská časť

<form class="ajaxform" method="post" action="{{ request.path }}">{% csrf_token %}
  {% form form %}
</form>

Validáciu rieši server automaticky podľa modelu + možnosť dopísať vlastné validácie. Kód na serveri a u klienta je univerzálny. Generovanie formulára automatické podľa modelu + možnosť čokoľvek customizovať. Všetko s plnou podporou fallbacku (teda ide aj s vypnutým js). Pri zapnutom js funguje ako moderná aplikácia, ktorá je schopná vadlidovať počas písania. Layout formulára je buď automatický, alebo sa ručne napíše ({% formrow form.title %}, {% formrow form.content %}). Ako vyzerá výsledok som posielal tu.

[Josef Kufner]

Není ta serverová validace moc pomalá? Přecejen, validace na klientovi se dělá právě pro tu rychlou odezvu. Jak řešíš, například že část formuláře má být vidět, pokud je jisté políčko nějak vyplněno?

Jinak docela fajn mi přijde použít HTML5 validaci na to, kde stačí a u zbytku už obvykle nevadí, že to je jen validováno na serveru, pokud to tedy není něco interaktivního, jako ten příklad výše, nebo že datum zadané do jednoho políčka omezuje rozsah hodnot datumu zadaného do druhého políčka (začátek musí být dřív než konec).

[mirec]

Není ta serverová validace moc pomalá?

Došiel som k záveru, že 100% validácia u klienta je vúčšinou nemožná. Príklad: vkladám PSČ - musím kontrolovať v db, vkladám mesto, ulicu - kontrolujem db, vyberám kategóriu - kontrolujem db, vyberám username - kontrolujem db ... Jednoducho skoro všetko, čo robím potrebuje kontrolu dát v db (či už existenciu alebo duplicitu). Má zmysel robiť v takom prípade validáciu na 2 miestach, 2x písať kód ...? Samozrejme veci ako email, regexy, čísla sú validované cez html5 validáciu, ak to klient nepodporuje kontaktuje server, všetko nad rámec toho čo zvláda HTML5 ide na server.

Samotná serverová časť je fakt blbá ak je to písané vo frameworku, ktorý podporuje validáciu - ukážka AjaxFormMixin-u

class AjaxFormMixin(object):
    def post(self, request, *args, **kwargs):
        if request.is_ajax():
            response = super(AjaxFormMixin, self).post(request, *args, **kwargs)
            return self.get_form_status(response.context_data['form'])
        else:
            return super(AjaxFormMixin, self).post(request, *args, **kwargs)

    def get_form_status(self, form):
        if form.is_valid() and not 'only_validate' in self.request.POST:
            return self.form_valid(form)
        else:
            if form.is_valid():
                data = {'status': 'ok'}
            else:
                data = {'status': 'error', 'errors': form.errors.as_json()}
            return HttpResponse(json.dumps(), content_type='application/json')

Reálny kód ktorý používam je trochu dlhší, hlavne podporuje veci ako viacej formulárov na jednej stránke a ich selektívnu validácia a pod. Toto je len náčrt fungovania. Reálne mi potom v aplikácii stačí pridať AjaxFormMixin do každého viewu, v ktorom chcem obsluhovať formulár ajaxom, alebo pridať rovno do globálnych CreateView/UpdateView/DeleteView. Pri validácii musí klient posielať only_validate pre rozlíšenie medzi odoslaním a validáciou. Úspešnú akciu indikujem stavom 3xx, ktorý zase odchytáva iný mixin a posiela klientovi ako json (keďže javascript nedokáže odchytiť 3xx).

[Josef Kufner]

Jo, takle to vypadá celkem pěkně.

[neklan]

Souhlasím. validace na serveru je potřeba většinou tak, jako tak. Mnohdy jsou pro validaci potřeba datové kontexty, které klient třeba ani nesmí dostat. Obecně bezpečnost je v tomto zásadní. Chování javascriptu má klient možnost ovlivnit. Takže se reálně jedná spíš o takový "spellcheck" protože nevalidní data (v případě absence validace na straně serveru) nelze odmítnout. Takže nějaká forma validace/escapingu/security je vždy potřeba i na straně serveru.

[mirec]

Ešte pre istotu aby moje komentáre neboli zle pochopené ... reagoval som len na jednu vec, ktorá ma irituje, inak je blog dobrý, rozhodne by som nechel autora odradiť. Dozvedel som sa niečo o technológii, ktorú som prakticky nepoznal čo je dobré, programátor sa musí nonstop učiť nové veci. Jednoducho blog je svetelné roky pred napríklad seriálom JavaFX na rootovi (odporúčam pozrieť, ale pred tým si radšej vylúpnite oči) kde som sa o JavaFX nedozvedel nič, ale hlavne som sa dozvedel ako sa dá katastrofálne zmrviť PostgreSQL.

Momentálne sa tu tak trohu tvárim ako majster sveta na optimalizáciu, ktorý ani neukáže svoj kód ... no pokúsim sa to napraviť niekedy v budúcnosti v blogu. Nedávno som robil jednu intranetovú aplikáciu s cca 50. tabuľkami a asi 200 pohľadmi riešenú ako one page za necelé 2 mesiace, ale totálne iným spôsobom než to býva u väčšiny one page aplikácií. Časť z kódu by som chcel obaliť do knižnice a dať ako open source, potom hádam o tom napíšem blog.

[rADOn]

…Dozvedel som sa niečo o technológii, ktorú som prakticky nepoznal čo je dobré, programátor sa musí nonstop učiť nové veci.…

Programátor který se umí učit nové věci si přece přečte něco o javascriptu, vybere si nějaký framework a může bouchat. Tohle je šaškárna.

[mirec]

Pre programátorov je typická snaha uľahčovať si prácu. Nechcem pitvať či autor ovláda javascript. Sám si myslím, že ovládam javascript na akej-takej úrovni. Napriek tomu som sa pohrával s myšlienkou generovania js kódu z iného jazyka. Nakoniec som to nikdy neurobil.

Prvý problém, ktorý vidím v generovanom kóde je to, čo z toho lezie ;) Možno raz začnem písať v coffeescripte / typescripte, ktoré majú jednoduchú transformáciu do js. Písať v jave sa mi zdá ako keby som písal v assembleri a ten strojovo prechrúmal do C. Akonáhle píšem v nejakom jazyku a prekladám to do iného jazyka som obmedzený prienikom vlastností daných jazykov. JS je dynamický jazyk, zdá sa mi blbé nevyužiť to na skrátenie kódu.

Druhý problém vidím v tom, že aj tak nemôžem zdieľať kód medzi serverom a klientom. Malé fragmenty kódu sa síce dajú zdieľať, ale napríklad kompletnú validáciu formulára u klienta neurobím. U väčšiny formulárov musím reálne kontaktovať server kvôli kontrole duplicít a pod. Nakoniec som teda aj tak skončil s malým ajaxovým kódom ktorý pošle serveru formulár (na pozadí počas vypĺňania) a server vráti v jsone zoznam chýb. Celá podpora ajaxových formulárov má cca 100 riadkov u klienta a 50 riadkov na serveri (vrátane fallbacku vďaka ktorému to ide aj na linkse).

[neklan]

Ale je to levnější, a splní to to účel. To znamená, že je to lepší. Navíc se široce používaný a dobře zdokumentovaný framework snadněji udržuje a taktéž přináší přidanou hodnotu sledování vývoje širokého spektra prohlížečů atd...

Strategie samozvaných géniů, kteří někoho překecají nejlépe ještě přes známosti nebo úplatky a pěkně si ho zaháčkují do vendor-lock-in pomalu ale jistě přestává fungovat i v ČR. Nezbývá Vám než se s tím smířit.

[mirec]

taktéž přináší přidanou hodnotu sledování vývoje širokého spektra prohlížečů atd...

To je dvojsečná zbraň. Staré js kódy ktoré som kedysi písal zvyčajne fungujú. Frameworky sú písané podľa aktuálneho stavu prehliadačov a snažia sa ohackovať jednotlivé chyby / špecifiká prehliadačov tak, aby sa to správalo konzistentne. Po určitom čase sa tieto chyby môžu opraviť a ḱód ktorý danú chybu ohackoval do kódu zanesie novú chybu.

Takže zatiaľ čo js kód napísaný tak, aby sa vyhol špcifikám / chybám browserov bude bez problémov fungovať aj po 10 rokoch, o kóde, ktorý používa framework sa to isté prehlásiť nedá. Upgrade frameworku je kapitola sama o sebe. Niekedy to prebehne v poriadku, inokedy sa musí časť kódu prepísať.

[neklan]

A to jste jako před deseti lety napsal sám svůj vlastní kód, který používal websockety pro okamžitou propagaci změn mezi X klientů, sám si hlídal keepalive jestli má klient stále otevřený browser, na kterém záznamu tabulky se nachází, co má u sebe zobrazeno a podle toho optimalizuje přenos updatů, apod? Nevěřím, prostě ne, už jenom protože mluvíme o technologiích které byly specifikovány >2010 a jejich podpora do browserů je použitelná několik posledních let. Mám pocit, že vůbec nemáte tušení, co takový např. Vaadin všechno umí a jsem přesvědčen, že pokud máte kód 10 let starý, tak je co se týče funkcionality v porovnání se současností naprosto k smíchu. Fungovat může, to ano.

[mirec]

Nevěřím, prostě ne, už jenom protože mluvíme o technologiích které byly specifikovány >2010 a jejich podpora do browserů je použitelná několik posledních let.

Nerobím moc často propagáciu zmien klientom v reálnom čase. Pred cca 10 rokmi som to robil len raz. Pred 10 rokmi bola jediná možnosť long http polling. Vtedy bola požiadavka aby to išlo aj na IE 6 a pri troche snahy to dokonca bez hackov to aj fungovalo. Záťaž servera bola trochu vyššia než s websocketmi (myslím, že tam bol timeout 25s po ktorom sa vytváralo nové HTTP spojenie). Kód funguje dodnes.

Websockety sú typickým príkladom technológie, ktorú keby som použil pred pár rokmi dnes musím kód prepísať, alebo upgradnúť knižnicu na ktorom beží.

Nemám rád optimalizáciu pre konkrétne browsery. Skúsenosti ma naučili, že je to cesta do pekla. V použití v súčasnosti už odladenej technológie nevidím problém.

[mirec]

Ešte ma napadla jedna taká vec ... neberte to akorýpanie ale zaujíma ma to ako to funguje.

Chcel by som zobrazovať live údaje v tabuľke. Tabuľka má pár miliónov záznamov (jedna z tých menších). Chcel by som vedieť ako vaadin propaguje zmeny v takejto tabuľke.

V súčasnosti sa v mojej aplikácii musí klient sám prihlasovať / odhlasovať na počúvanie. Ak teda otvorím konkrétny záznam pošle sa serveru id záznamu ktorý má poslať klientovi. Po zatvorení sa zase odregistruje. Po ukončení spojenia sa všetky dáta a udalosti asociované so session zrušia. Na jednotlivých záznamoch to funguje skvele ...

Pri zobrazení tabuľky sa pri vkladaní / mazaní musí pre každého klienta zistiť či bol záznam vložený pred, alebo za zobrazovanú časť (podľa toho upraviť ktoré záznamy sa zobrazujú) pričom sa musí vziať do úvahy stránkovanie, zoradenie, filtrovanie ...). Zoraďovanie pri takomto množstve dát rieši samozrejme databáza. Ako sa to rieši v takomto prípade?

[neklan]

Zkusím to nějak heslovitě vysvětlit, berte to prosím jako hodně zjednodušené.

Používám většinou devstack vaadin-spring-tomcat-postgresql. V servlet enginu se vytvoří pro každou session, která si otevře onu tabulku, objekt. Ve vaadinu se jim říká Container, protože implementují tento interface. To potom slouží jako jakási "proxy" na databázi. Takový objekt je potom svázán přímo s tím, co vidí klient na browseru, pokud containeru změním obsah, framework automaticky zpropaguje změny přes web socket na browser klienta, říkají tomu push. Stejně tak, když klient edituje/smaže/přídá řádek do tabulky, tak se mění obsah containeru a zároveň se vytvoří event, který změní data v db a upozorní ostaní containery, že se něco děje. Vzhledem k tomu, že container ví co má nahráno za data, jaký má zobrazený buffer a offset, a jak jsou data filtrována a řazena, tak je aplikace schopna zhodnotit jaké containery je potřeba upozornit.

V případě tabulky s miliony záznamů se používá nějaký Lazy loading, kdy se udržuje jen buffer, offset a celkový počet záznamů v db tabulce. Praktické je nahrát více záznamů před a za tím, co má klient zobrazené v browseru, aby až bude scrollovat mu to zbytečně nelagovalo kvůli db selectu. To zase klade vyšší nároky na ram a cpu, protože je potřeba udržovat a naslouchat změnám více záznamů. Tyto paramentry je potřeba vyladit podle specifického užití.

Veškerá ostatní api jsou taktéž registrovaná na event broadcaster a pokud je už opravdu nutno strčit tam nějaký "servisní" sql dotaz "na hulváta", tak se buď odstaví aplikace, nebo se zakáže write (a eventy se nastrkají do fronty) a pak forcne update všech containerů.

Samozřejmě je tam spousta věcí pod kapotou, které je potřeba vyřešit. Především všechny ty UI update thready a event queue reduction a někde to synchronizovat, aby se to nepopralo, multi-column sorty, ale vždy se mi to podařilo vyřešit ke spokojenosti zákazníka.

Doufám, že je to alespoň trochu odpověď.

[Bedňa]

No keď zabudnem na to že z Mireca si spravil lamu a viem čo dokáže spraviť tak si ma trochu nasral.

To si fakt myslíš že translátor nahradí prekladateľa?

Zabudni a uznaj chybu, sú frameworky čo veľa riešia, no rozhodne zatiaľ neporazili ľudskú myseľ a natívne písanie kódu.

[neklan]

Nevím na čem jedete, ale vůbec nerozumím tomu, co píšete. Jaký sakra translator. Nevím, co mirec dokáže, položil mi otázku a já se na ní snažil odpovědět v rámci rozsahu přijatelném pro fórum. Navíc psal, že takovéto věci nedělá, naposledy před 10 lety neaktuální technologií.

Jakou bych měl uznávat chybu? Popisuji způsob, jakým pracuji a jaké technologie využívám, protože se mě na to ptal. Jsem spokojen, protože mi umožnuje vytvořit rychle aplikaci s kvalitní funkcionalitou.

A co takovému C compilátoru taky nevěříte a mastíte si rovnou assembler nebo bytecode binárky po večeru kleštičkama do děrných štítků? To je (skoro) uplně to samé.

Bežte si své mindráky léčit jinam.

[mirec]

Netvrdil som, že nerobím, len som popisoval čo som na to používal pred 10 rokmi. V súčasnosti fungujem buď na vlastnom custom riešení pre špecialitky (pár riadkov asynchrónneho kódu v tornade na serveri + sockjs na klientovi), alebo pre bežné veci swampdragon + redis + tornadoio kde funguje aktualizácia podľa popisu rovnako ako vo vaadine s tým rozdielom, že stav aplikácie je client side záležitosť, server rieši len zoznam listenerov a práva na jednotlivé kanály.

Inak dík za vysvetlenie.

[neklan]

Tak to jsem spatně pochopil, stane se. Určitě to jde dělat více způsoby a každý má svoje pro a proti. Do pythonu moc nevidím, něco málo jsem v něm dělal a nebylo mi to moc sympatické, zřejmě otázka osobních preferencí.

Na vaadinu a gwt mě baví předevšim, že je to celé v javě a js se v drtivé většině připadů vůbec nemusí řešit, což mi umožnilo konsolidovat vývoj a ušetřit. Proto jsem se pro něj rozhodl.

[mirec]

Příloha:

• projekt.png (339385 bytů)

S pythonom je to ťažké. Používam ho pekných pár rokov a ako-tak mu prichádzam na chuť až teraz. Keby som mal konvertovať nejaký tím na python asi by som rovno vybral nový tím ;)

Teraz trochu k efektivite vývoja. V pythone sa dajú pomerne rýchlo robiť pomerne komplexné aplikácie, ale človek na to musí mať prax aby to dokázal fakt rýchlo. V prílohe je screenshot projektu (work in progress). Všetký viewy, tabuľky, zoznamy, filtre, sortovania ... sú tam funkčné len zatiaľ chýba pár prepojení na api. Aktualizácie sú v reálnom čase, všetko je pekne ajaxové, kontrola sa vykonáva na serveri, stav filtrov / tabuliek je tak isto na serveri (preto som sa pýtal ako to rieši vaadin), ale samotná manipulácia s DOM a vykresľovanie je písané v js. Teraz trochu štatistiky. Tím tvorím +/- ja (viacej než 90% kódu je môjho). Čas realizácie zatiaľ mesiac a pol. Počet riadkov je celkom zaujímavá štatistika:

--------------------------------------------------------------------------------
Language                      files          blank        comment           code
--------------------------------------------------------------------------------
Javascript                       48           2435            641          11311
SASS                             64           1968           2560           8910
Python                          118           1865            181           6183
CSS                               3            622            236           5675
HTML                            161            371              0           4198
Bourne Again Shell                6              9              1             73
--------------------------------------------------------------------------------
SUM:                            400           7270           3619          36350
--------------------------------------------------------------------------------

[neklan]

Vypadá to celkem hezky, víc ze screenu pochopitelně nepoznám. zvláště pokud se bavíme updatu klienta. To tlačítko "uložit" mi ovšem přijde mírně podezřelé. Proč se to neuloží hned, jak klient položku změní? Asi to není zrovna příklad na tuto situaci, nechci zbytečně pitvat.

Každopádně tormado server jsem dosud neznal a musím se na něj podívat, takže díky za link. Python jde mimo mě, ale rád se koukám i ve vlaku z okna, co jde mimo mě, občas člověk vidí docela zajímavé věci.

[mirec]

Ukladanie neprebieha hneď pretože zákazník chce mať pekný čistý záznam udalostí typu užívateľ ... zmenil polia ... v dátum. Ukladanie po každej zmene by zbytočne zasieralo záznam (tých položiek v tomto konkrétnom formulári je vyše 100). V ľavom menu aby nebolo rozoznateľné čo tam je povedzme menu typov objektov. Čiže pod každou položkou sa skrýva zoznam (grafik je blázon takže každý je vyčačkaný tak trochu svojim spôsobom, niektoré majú aj rôzne typy zobrazení ako podrobný zoznam, krátky zoznam alebo napríklad kalendár podľa dní, týždňov, mesiacov, responzívne aj na malých patlatkách, všetko s filtrovaním, zoraďovaním ...), detaily objektov, formuláre pre úpravu...

[neklan]

Ještě zareaguji, pokud máte pocit, že to jde do ztracena, tak mě klidně okřikněte.

Ale... nevím sice jaké bylo zadání a kolik "operátorů" má modifikovat ty záznamy. Pokud jste někdy viděl CC (customer care), tak víte, že zákazníci volají divně - a tady pokud se bavíme o upper class CC, kde zákazník volá a operátor je mu dostupný vždy (po 30 sec čekání následuje brutální finanční penalizace, služba na měsíc zdarma, prostě podle tarifu, 1k eur min jen aby mohl volat), tak mnohdy se zákazník dovolá operátorovi, který neví ( a nemůže vědět) v rámci 30-60 sekund, že se hrabe v objednávce zákazníka, který volal jinému operátorovi.

Use case:

* zákazník zavolá na CC

* chce změnit adresu dodání

* chce změnit parametry služby

* operátor(1) změní adresu - hned dá uložit a asi to projde, pokud zrovna billing nedoplňuje jiné paramtry objednávky => ouch! nebo ticket systém s commenty

* na parametry služy se musí dotázat supervisora - zákazníka nelze nechat čekat

*zákazník zavolá znovu během 15sec, protože si vzpomenul, že nadiktoval špatné PSČ/ZIP (klidně si představte jiný údaj)

* dostane se na jiného operátora(2), který to změní a uloží

* oprátor(1) se poradí se supervisorem a svou objednávku, kterou má otevřenou změní.

* zavolá zákazníkovi, že se je to OK

otázka za $3k (reklamace + následná péče + poškozené jméno + dohra) dostane zákazník, to, co chce? A to je to rozumný člověk, který si pamatuje, co kdy komu a kdo mu co říkal i bez toho, že veškeré hovory jsou chronologicky nahrávané a ví co chce, jenom se spletl a zavolal, že to chce opravit.

A teď si vemte, že máte zákazníky na 5 kontinentech. Není jich ani tak moc, ale je jich celkem dost. To znamená, že služba "osobní bankéř" tam nejede. Protože oni chťejí mít k dispozici někoho na telefonu ve "své" pracovní době. Vy máte jedno centrum, kde se střídají schopní, doře vyškolení, vysoce placení a nadprůměrně zdatní operátoři (jeden z nich mě dokázal opravit požkozené hry z mého commodoru 128, který mám doma, jen tak pro ilustraci... z 25 let starých audio kazet) Ti operátoři tam jsou celkem 3 nonstop vždy + příchody a odchody. Jeden hovoří, druhý je v záloze a třetí je v případě možnosti na volání ven, nebo rovnou na admin-support. Celkový náklad cca 150k euro na měsíc na tři směny.

Když nastane chyba, tak "neějak se to dohodne" nepřichází v úvahu. Chyba je chyba a za chyby se platí.

Takže když analogicky k Vašemu systému změním operátorovi políčko, označím ho červenou barvou a v notification area mu hodím hlášku, že jiný operátor %jméno% udělal %změnu%, tak to ušetřím ranec peněz, času a nedorozumění.

A nějaký designer admin logu je mi úplně uzadnice. Protože jednoznačné události kdo, kdy a co změnil jsou mnohem jednoznačnější (pokud se tak muhu se vši skromností domnívat), než vaše. A designer je podřízený musí v tomto segmentu přizpůsobit. Tady je jeho úkolem zobrazit relevantní data tak, aby byla čitelná - ne si určovat, co jsou relevantní data jako na frontnedu.

[neklan]

a teď do toho ještě zakomponujte dalši oddělení, která vůbec nevědí, že někdo volal - tudíž si to editují jak chtějí

[neklan]

Ale tak, když už jste to nakousnul, tak v žertu můžeme poměřit ocasy)

-----------------------------------------------------------------------------------
Language                         files          blank        comment           code
-----------------------------------------------------------------------------------
Java                               227           3493           2050          17161
JSP                                 75             55            505           6242
CSS                                  8            223            128           1649
SQL                                  2           1248           1719           1531
Maven                                1              1             12            411
XSLT                                 2              9              0            400
XML                                  3              0              0             17
Visualforce Component                1              0              0             10
-----------------------------------------------------------------------------------
SUM:                               327           9850          14226          57173
-----------------------------------------------------------------------------------

taktéž více než 95% kódu ode mě, čas realizace cca 427 hodin po dobu 6 měsíců(včetně konzultací, specifikace, analýzy a managementu designerů/html, účtována každá započatá hodina), rozpočet 15k euro.

[neklan]

... bez započítání unit testů.

[lacod]

V pohode, ja sa nedám odradiť ;), programujem už nejaké tie roky a prežil som rôzne technologické vlny. Najhoršia zo všetkých bola vlna CASE, ktorú teraz nahradilo UML. Tie CASE nástroje snáď neboli kompatibilné ani medzi minor verziami. Na základe mojích skúseností si dovolím tvrdiť že GWT je jeden z mála frameworkov, ktoré za niečo stoja. Je vidieť že to robili profíci tak ako C robili super profíci. Tiež som zástanca ručne písaného kódu, ktorý má vývojár pod kontrolou ale tento princíp je konfrontovaný s efektivitou a ekonomikou a tu optimalizácia a podobné "programátorské výmysly" dostávaju na frak. Myslím si že GWT vo sfére WebUI pomáha zlepšiť pomer programátor vs. ekonomika v prospech programátora.

[msk]

Takto - nie som web vyvojar, ale zazil som projekty na Vaadin-ovi a zazil som projekty na Jade+Javascript. Mne ako ne-webistovi prisiel Vaadin super, pretoze som sa nemusel ucit mraky webovych sraciek (a ze ich je neurekom) a aplikaciu som pisal klasickym model-view sposobom akym som bol zvyknuty z QT. Na druhu stranu je mozne, ze vysledny (vygenerovany, cize pre mna nezaujimavy) kod nebol asi uplne najmensi a najprehladnejsi a takisto nevylucujem ze by som casom nenarazil na nejake limity (aj ked aj vaadin sa da rozne ohynat ked tomu clovek rozumie).

Co ale mozem napr. povedat po jemnych skusenostiach s vyvojom aplikacie nad spring stackom + jade je, ze to ani zdaleka nema taku eleganciu ako s Vaadinom. Chcem vo vaadinovi field, ktory je validovany na nejaku hodnotu? Ok, staci anotacia na field v modeli a mam to kontrolovane ako pre ui formulare, tak web services a nizsie vrstvy atd... Nemusim si pisat extra validaciu v JS a extra v business logike. Chcem aby sa field choval tak a tak? Upravim to v modeli, ziadne vrtanie sa v nejakych blackboxoch v /resources.

[kralyk z abclinuxu]

Nemůžu si pomoct, ale přijde mi to strašně překomplikovaný.

Co se týče jiných JS frameworků, zejména tam kde se používá Moustache/Handlebars nebo React apod., moc nechápu, proč chce někdo z JS generotvat HTML/DOM. To mi přijde jako hrozná blbost jak z programátorského hlediska, tak z hlediska efektivity. Přijde mi mnohem lepší přístup nebabrat se s nějakými templaty nebo HTML v JS, napsat DOM prostě v HTML a pak nadefinovat, jak DOM modifikují data modelu. Zatím nejblíž co jsem viděl tomuhle ideálu mi přijde framework Ampersand, ale stejně bych to nejradši ještě trochu zjednodušil...

[Josef Kufner]

Jenže pak musíš definovat, jak DOM ovlivňuje model. Tyhle frameworky, jako je React a Angular, ti tu práci ušetří. Tam jen řekneš, že tohle políčko má být stejné jako tahle proměnná v modelu a tím to pro tebe končí.

Moustache/Handlebars má opodstatnění v okamžiku, kdy chceš mít na serveru i na klientovi jednu šablonu. Tedy pokud má server umět generovat statickou stránku, ale současně ji chceš Javascriptem aktualizovat

[kralyk z abclinuxu]

Jenže pak musíš definovat, jak DOM ovlivňuje model.

Ano, jistě, to je součástí.

Tyhle frameworky, jako je React a Angular, ti tu práci ušetří.

Tomu právě moc nevěřim. Angular určitě ne, ten je příšerně překomplikovanej snad ve všech ohledech. React taky úplně nevidím, jak mi pomůže, protože bych v něm musel psát např. ty renderovací funkce, což je přesně to, co dělat nechci, to mi akorát zkomplikuje život. Obojí vyžaduje spoustu infrastruktury a spoustu boilerplate kódu.

Moustache/Handlebars má opodstatnění v okamžiku, kdy chceš mít na serveru i na klientovi jednu šablonu.

Hm, to zrovna mě asi moc nepomůže, vzhledem k tomu, že server akorát dodává data v JSONu...

[mirec]

Příloha:

• productforums.png (108337 bytů)

Trochu offtopic. Netuší niekto čím google generuje ten bordel v productforums? Viacej než 5MB komprimovaného javascriptu na obsluhu 1 tlačidla a zobrazenie textu nikto normálny hádam nemôže napísať, takže predpokladám, že je to generované.

[neklan]

Neřekl bych, že to je tím, že je to generované. Generovaný kód bývá menší už jenom protože místo funkce addClickEventListener() tam naobfuckuje gunkci q3().

Tohle je obyčejná kalkulovaná "lenost", která se projevuje všude, protože lidé hasí velké ohně a pár mega na stažení dnes není velký požár. Prostě ten javascript obsahuje i další funkce, které tam jsou jenom protože nikdo nezaplatí optimalizaci a udržování "lite" a "min" verzí.

Javascript nemá dynamické linkování shared objectů (protože by to bylo zase těžké na security), tak se tam prostě přibalí celá knihovna "staticky" - používám pouze jako příklad.

A největší sranda je, že někdo plýtvá svým časem na optimalizaci js kódu, aby místo 500Kb mohl stahnout jenom 150kb, což je krásné a v jisté bezvýznamné míře chválihodné, ale potom zákazník řekně, že tam chce tlačítka sociálů a nějaký google plugin a nějaký disqus a ... natahá si dalších 5MB knihoven od firem, které mají miliardové zisky a na vaší optimalizaci kašlou. Trošku ironie, že?

[Bedňa]

Aby som vám nezasahoval do vlákna, tak si spravím svoje S Mirecom sme sa o tom bavili a nedošli sme k riešeniu ako z nízko úrovňovej Javy spraviť vysoko úrovňový JavaScript aby to aspoň ako tak fungovalo. V tomto sme sa zhodli a prehlasovali ťa

JavaScript je fakt dosť vysoko na to aby nejaký framework dokázal s Javy dokázal vytvoriť optimalizovaný kód, najlepšie je si najať JS programátora.

Opačne to samozrejme nieje problém.