Komentáře k článku
Mají budoucnost šablonovací systémy v JavaScriptu?
Co jsou to šablonovací systémy v JavaScriptu? K čemu se hodí a kdy je použít? Z jakých nástrojů si můžeme vybrat. Na to se alespoň částečně pokusí odpovědět tento článek.
37 komentářů k článku Mají budoucnost šablonovací systémy v JavaScriptu?:
Napsat komentář
Zdroj: http://www.zdrojak.cz/?p=3039
Pouzivam jTemplates, ale premyslim o prechodu na PURE
Pro http://hashpage.com
Pro ukazku malou knihovnu sablon mam tady: http://github.com/…lib/snippets
Na jTemplates se mi libi vnorovani sablon do sablon.
Ma nekdo realne zkusenosti s PURE? Do porucite prechod?
Re: Pouzivam jTemplates, ale premyslim o prechodu na PURE
Tak to je první projekt, o kterém vím, který takové šablonování
reaálně používá! Díky za informaci.
Ad PURE – připadá mi, že je na tom za posledni pul rok prakticky nic
neudelali, coz je skoro stejne jako ostatni systemy. Ale takova je aktualni
situace, clovek si to bude muset sam odzkouset.
XML a DOM
V AJAXU jsem napsal spíše jen pár drobností, ale už od začátku
seznamování jsem považoval posílání HTML fragmentu a jeho přímé
zobrazování za něco špatného (nevím, co ve mě ten názor utvořilo :).
Proto jsem u jednodušších případů posílal jen samotné hodnoty a
u složitějších jsem je zabalil do XML. V obou případech jsem pak hodnoty
vkládal do stránky pomocí čistých DOM funkcí. Bylo to trochu pracné, ale
fungovalo to :)
Re: XML a DOM
S tvojim nazorom plne suhlasim. Klient by mal od serveru dotahovat len data
v XML formate – napoveda to aj X v nazve AJAX – a interpretacia tychto
dat ako je napriklad aj zostavenie HTML fragmentu by podla mna mala byt ulohou
klienta.
Re: XML a DOM
Dovolim si nesouhlasit podle me je to otazka ucelnosti. Jsou pripady kdy HTML
je jednoznacne efektivnejsi. Napriklad naplneni nejakeho divu textem. Naopak
jsou veci kdy JSON vede napriklad Datagrid.
Z hlediska jakehokoliv jineho nez pouzitelnosti to nema cenu resit AJAX tak
jako tak musi ty data posilat takze uz je jedno jestli poslu vysledek nebo ho
zbytecne budu posilat v XML a pak prevadet na HTML.
Asp.net ajax 4.0 templating
Celkom zaujimave moznosti templatingu ponuka asp.net ajax 4.0 [http://aspnet.codeplex.com/Wiki/View.aspx?…]
Aj ked to na prvy pohlad vyzera, ze to je zviazane s .net, nie je to celkom
pravda o templating sa stara js, ktory je od .net nezavisly, pretoze je urceny
aj pre asp.mvc. Ak bude pokracovat trend MS, tak je mozne, ze technologiu vydaju
pod os licenciou a potom by jej rozsireniu na ine platformy nemalo branit nic.
Viac o templatingu a dalsich zaujimavych binding veciach v: http://www.aspnet.sk/…-100858.aspx
pohlad na js templating
Nevyhodou vyberu nejakeho js sablonovacieho systemu, je jeho zviazanost
s javascriptom. Kym generujem html na serveri nie je problem urobit stranku
tak, aby pri neexistencii javascriptu okolo toho html vlozila full page obalku.
Ak si uz ale vyberiem nejaky js templating a chcem podporovat aj nejs
prehliadace (typicky mobilne zariadenia) som nuteny robit view cast dvakrat.
sablonovaci system
pouzivam vlastny sablonovaci system, ktory dokaze robit presne, to
co chcem
Re: sablonovaci system
A nejaky priklad, kde bychom ho mohli videt a pro zajimavost porovnat?
Re: sablonovaci system
Tiez rozmyslam, ze zacnem pouzivat vlastne sablonovacnie riesenie pre JS. Nemam ale chut robit veci zlozite, natahovat kB roznych libiek. Elegantne riesenie poskytuje samotny JS a jeho rozsirovanie prototypov. Odporucam urcite aspon vyskusat:
slajdy 100 az 103
http://www.slideshare.net/…ing-language
enjoy.
OT: Kolize Chrome a FF
Koukám, že chrome://newtab/ ani chrome://newtab/content/ nepatří
Firefoxu, aspoň ne stabilnímu.
Re: OT: Kolize Chrome a FF
To nemá s Firefoxem vůbec nic společného 8-)
jQuery
Osobně nevidím jinou možnost pro efektivnější fungování HTML
stráněk než javascript.
Posílat stále objemné balíky dat je příšernost. AJAX je efektivní,
racionální a budoucnost. POST, GET A SESSION je stejna jak při HTML, tak
o co jde. JO asi to bude v té přístupnostri a v tom SEO, či jak se to jen
ta pitomost jmenuje.
Re: jQuery
Ja som začínal s Ajaxom ešte v dobe keď (na Slovensku) ešte nikto
nevedel čo to je Ajax. Vytvoril som Joomla komponentu JoomlaComment ktorá
pomocou XMLHttpRequest komunikovala priamo so serverom.
A práve preto si myslím že JavaScript je cesta do pekla, JavaScript neni
plnohodnotný objektový jazyk a hlavne chýba mi v ňom statická typová
kontrola, interpretované jazyky IMHO nemajú budúcnosť vývoj v takomto
jazyku je oveľa pracnejší lebo vačšinu chýb nezachytí kompilátor, a
preto je aj omnoho drahší a aplikácie napísané v dynamickom jazyku sú
nespoľahlivé. JavaScript sa hodí maximálne na kontrolu formulára pred
odoslaním. Myslím že presúvanie aplikačnej logiky zo servera ku klientovy
je vývoj nesprávnym smerom.
Re: jQuery
Já myslím, že vývoj programovacích jazyků dobře ukazuje, že tu bude
místo jak pro kompilované jazyky tak pro ty interpretované.
Re: jQuery
Na to jsem cekal. JS memo objektovy jazyk. Cestina taky neni a prezila.
Nechapu jak nekdo dokaze objektovost povisovat na pouzitelnost. Nemyslim si ze
objektovost automaticky znamena dobry jazyk. Objektovost znamena jazyk, ktery
(teoreticky) dokaze psat prehlednejsi kod. Jinak neznamena nic vic. Dokonce ani
ona proklamovana cast, ktera udajne setri praci. Je sporna.
E J S
Nedavno jsem to potreboval zaclenit do sveho vetsiho projektu, takze jsem si
delal porovnani javascriptovych sablonovacich systemu a jako nejlepsi reseni mi
vyslo EJS http://embeddedjs.com/ – moje
prakticke zkusenosti z pravidelneho pouzivani jsou velmi pozitivni…
Re: E J S
Tak ten jsem ani nenasel, diky za tip!
A teď stopnout a zamyslet se...
Kdybych věděl, jak bude vypadat budoucnost, tak bych asi byl někde jinde,
nicméně doufám, že v šablonovacích systémech v JS to nebude.
které jsou s JS dost neslučitelné a narozdíl od předchozího
diskutujícího si nemyslím, že jde o blbosti.
otevřít 60 tabů stránek bez javascriptu a 60 tabů stránek
s javascriptem, optimálně okořeněného flashovými bannery. Moje zkušenost
je taková, že v druhém případě je celý systém tuhý víc, než jeden
náš kolega po ránu, když ještě neměl kafe (zjištěný konverzní poměr
je cca 10 tabů na –1 hodinu kolegova spánku). Zatímco v prvním
případě, co se týče rychlosti, je systém stále lepší, byť jsem při
provedeném testování kolegu zvýhodnil informací, že moje sekretářka má
dneska minisukni. (pro potenciální rýpaly na téma, kdo si otevírá
60 tabů najednou, bych rád uvedl situaci, kdy hledáte nějakou informaci,
která zrovna není na 1. stránce v Googlu)
„webová aplikace“. Webové aplikace se často vyvíjí i s konkrétní
znalostí toho, na jakých PC poběží, a představa, že někdo bude hledat
adresu na přihlášení do firemního systému přes Google, je za
střízlivého stavu poněkud nepravděpodobná. Tam potom oba dva předchozí
argumenty pochopitelně postrádají praktického významu.
Re: A teď stopnout a zamyslet se...
Přístupnost, SEO…jsou s JS dost neslučitelné
Doporučuji aktualizaci znalostí, tohle totiž není již pár let pravda.
Při správném použití se tyhle věci vůbec vůbec nevylučují.
Re: A teď stopnout a zamyslet se...
Jak si správně podotknul, při správném použití. Jednak si obecně
myslím, že tahle cesta správné použití není, ale diskutujeme tady obecně
o budoucnosti téhle myšlenky a ve mně se ozval varovný pud sebezáchovy.
(Předem se omlouvám za poněkud neformální charakter příspěvku.)
Řeknu Ti story, úplně to vidim. Píše se rok 2012. Jedu autem do nějakého
maloměsta, kde sem nikdy nebyl. Prší jak blázen, na ulici ani noha. Kam jedu
zapomenu, ale na webu mají přeci mapku. Adresu taky zapomenu. Tahám mobil,
googlim. Nic. Tak zkoušim domény. Trefím se (úplnou náhodou). A nic –
AJAX. Pořiďte si lepší prohlížeč.
Chápeš to, že já budu někde v ňákym vidlákově, v autě, leje jak
blázen, nevim kam mam jet a sem totálně v p*deli jenom kvůli tomu, že
nějakej rádobywebmaster kouzlil s timhletim?
Možná sem staromódní, ale přístupnost informace se pro mě rovná tomu,
že ji najdu na 486ce v textovym režimu a nejlíp telnetem na port 80 a ten
požadavek GET tomu serveru napíšu sám. Což zvládnu do chvíle, než bude
webová stránka pouhou aplikací, kde pro dostupnost informace je potřeba se
serverem komunikovat mandarínskou čínštinou.
Re: A teď stopnout a zamyslet se...
To bude nějaký alternativní vesmír, já na mobilu se stránkami a
aplikacemi problém nemám.
Re: A teď stopnout a zamyslet se...
Jenomze s mobilem, ktery plno lidi nepozna od PDAcka a prazskym signalem,
kde zvladneme pres 3G stahovat film od Cerneho mostu na Zlicin bez vypadku je
potreba se podivat na ruzne varianty jine:
vlastnici telefon s cernobilym displejem a na WAP se podivaj (kdo rika, ze
nekoukal na jizdni rady ve WML, ten to dela dodnes).
AJAX) nam nebude vadit, dokud se nedostaneme do mist s vypadavajicim signalem,
nebo jeste lepe, nebudeme si je chtit stahnout do notebooku pro cteni v letadle
(a myslim ze jeste hodne dlouho na svete najdeme spoje, kde nebude dostupne
Wi-Fi). A pak je to jednoduche – kdyz bude iDnes v AJAXu a Lidovky
„postaru“, ktery internetovy denik bude v letadlech ctenejsi?
Re: A teď stopnout a zamyslet se...
Nechápu – proč by měl být web iDNESu postavený na AJAXu? Mám pocit
jakobys byl kompletně mimo stávající téma. Je rozdíl mezi webem
používajícím AJAX a webem postaveným na AJAXu.
Re: A teď stopnout a zamyslet se...
Já jenom chtěl upozornit na to, že AJAX není samospásný a mělo by se
s ním jednat uvážlivě, což ty pochopitelně víš, ale u začátečníků
a některých dalších si tím nejsem zcela jist. Necháme toho :-)
Re: A teď stopnout a zamyslet se...
Chybu jsi udělal v tom kroku, že jsi zapomněl, že tohle je odborný
magazín pro vývojáře, kde zrovna takovou věc (v zásadě) všichni vědí
(tudíž je to nošení dříví do lesa) a od diskutujících na takové téma
se čeká „co víc“. Na Lupě bych takovou reakce pochopil, sem nepatří
(rozhodně ne v téhle podobě).
Re: A teď stopnout a zamyslet se...
Dnešním mobilním prohlížečům Javascript moc nedělá problém, aspoň
jednodušší. V Opeře mini jsem si nechal zobrazit stolní Google
Reader a nebyl problém. Výkon může být problém, ale to se zlepšuje (JITka
apod.) a, jak říkáte, je potřeba rozlišovat mezi aplikací a stránkou.
Spustíte si někdy 60 desktopových aplikací?
Re: A teď stopnout a zamyslet se...
Presne tak – v opere mini jsem zkousel projizdet web (spis to byl
administracni system) postaveny na javacriptovych sablonach (EJS) a slo to –
po lehke optimalizaci to bude uplne bez problemu. Neni divu, kdyz je to prohnane
pres upravene jadro desktopove opery – vznikaji tak zajimave paradoxy,
v dnesni dobe si muzu napr. v Opere mini prohlidnout obrazky delane pres
canvas, coz si ale uz neprohlidnu ani pres dospely Internet Explorer (to ze
existuje i „emulace“ canvasu pro IE ted neni podstatne). Marek Soldat zjevne
nevychazi z reality, ale argumentuje fundamentalisticky.
Pár poznámek
K úvodním odstavečkům bych měl několik poznámek. Protože zdejší
redakční systém k**ví komentáře, budu se části snažit oddělovat reakce
alespoň řadou spojovníků.
ad „Webová stránka na základě události vytvoří AJAXové volání na
server, server vrátí data ve formátu HTML, webová stránka přijatý
fragment HTML zobrazí“
_ Tento přístup má obrovskou výhodu. Aplikace na serveru totiž HTML
fragment vygenerovat umí, takže je neefektivní stejnou funkčnost duplikovat
na straně JavaScriptu. Zbytečná práce navíc, možnost zavlečení chyby,
v případě změny nutnost aktualizovat dvě místa.
_ Ano, jsou situace, kdy je lepší poslat data a z nich vygenerovat HTML
kód, typickým případem jsou třeba našeptávače. Ale tady se práce
neduplikuje – HTML podobu našeptávače totiž webový server obvykle
negeneruje, jde čistě o JS záležitost.
ad „Od začátku mi tomhle řešení připadlo svým způsobem nečisté.
Ať už proto, že se zde obvykle neprovádí žádná kontrola
přijatých dat“
_ Všimni si, že žádná kontrola se neprovádí ani při použití JS
šablonovacích systémů.
ad „…Ale i proto, že v takovém případě nemohu pracovat s daty,
ale jen s jejich HTML výstupem“
_ To není tak úplně pravda, třeba zrovna ve zmíněném Nette Framework
se zpravidla v jedné odpovědi odesílá obojí – JS data i HTML
fragmenty.
ad „pokud budu chtít použít stejnou AJAXovou službu na
jiném webu…“
_ To nejde už kvůli bezpečnostní politice prohlížečů.
Re: Pár poznámek
Všimni si, že žádná kontrola se neprovádí ani při použití JS
šablonovacích systémů.
V příkladech, které jsem zmínil sice ne, jenže to je jen dočasný
stav. On tam je ideální prostor k provádění kontroly, který se
nevyužívá prostě jen protože validace a la JSON schema se zatím příliš
nerozšířily, ale to je jen otázka času.
To nejde už kvůli bezpečnostní politice prohlížečů.
Pochopitelně je myšleno stejnou službu spustit na jiném webu.
Re: Pár poznámek
Souhlas! Ac s Davidem obcas nemusism souhlasit, tak ted mi mluvi z duse.
A napsal jsem to i nize. Proste proc delat jednu praci dvakrat. Navic skutecne
JS neni zrovna nejrychlejsi ve vetsine prohlizecu by se dal pokladat naopak za
pomaly. Cim vic mu toho nalozime a parsovani do HTML z XML, je presne to co mu
nalozime zjistime, ze pak se aplikace skoro nepohne.
PrototypeJS template
Ještě připomenu Template v Prototype: http://www.prototypejs.org/api/template,
který implementuje něco podobného jako ERB v Ruby. Ideální právě na
použití při zpracování JSON dat do stránky.
(Ale Prototype je asi beznadějně un-cool, co? :)
Re: PrototypeJS template
Pozor na to, uncool může znamenat totéž co hot 8-)
obrazek clanku
to je docela dobrej figl s tim nosorozcem ten obrazek clanku, predpokladam
ze to je nejaky prebal knihy o javascriptu… takhle to na navstevnika tohohle
webu budi dojem ze pujde bud: za a) o clanek ktery je autorem te knihy, nebo za
b) o clanek ktery pochazi z te knihy, ale asi ani jedno neni pravda co?
Re: obrazek clanku
Hlavně tento nosorožec, který pochází z nejznámější knihy
o JavaScriptu vůbec, a také z projektu Rhino (implementace JavaScriptu
v Javě) je asociován s JavaScriptem obecně a proto je použit jako
ilustrační obrázek v perexu.
On všechny, kdo se JavaScriptem vážně zabývají, na první pohled
upozorní, že tenhle článek se zabývá JavaScriptem, což bylo cílem. A je
obecným cílem takových perexových obrázků.
přehled
Pro zájemce – Mozilla nabízí pěkný přehled dostupných
šablonovacích systémů https://developer.mozilla.org/…pt_templates
fragment HTML vs. XML?
Fragment HTML se používá protože innerHTML je daleko rychlejší, než
operace přes DOM. A je daleko jednodušší na implementaci.
Posílat XML? Vždyť posíláme validní (x)HTML, není to
totéž? KISS!
A pokud mám nějakou JS komponentu, pak dobře, ale ať má stabilní
data API.
Dobrý serverový framework pozná, jestli je dotaz AJAX nebo ne. Pak může
posílat fragment nebo celou stránku.