Názory k článku
Mají budoucnost šablonovací systémy v JavaScriptu?

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?

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 :)

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.

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.

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

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.

Koukám, že chrome://newtab/ ani chrome://newtab/con­tent/ nepatří Firefoxu, aspoň ne stabilnímu.

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.

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…

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.

1. 1) Přístupnost, SEO, použitelnost z mobilu – to jsou všechno věci, které jsou s JS dost neslučitelné a narozdíl od předchozího diskutujícího si nemyslím, že jde o blbosti.
2. 2) Zkuste si (na běžném uživatelském PC) v normálním prohlížeči 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)
3. 3) Je na čase začít důsledně rozlišovat pojmy „webová stránka“ a „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.

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.

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: 

1. Je tezke to vysvetlovat lidem v IT, to se musi videt, stale existuji lide vlastnici telefon s cernobilym displejem a na WAP se podivaj (kdo rika, ze nekoukal na jizdni rady ve WML, ten to dela dodnes).

2. Byt zavisly pri prohlizeni jedne stranky na trvajicim pripojeni (typicky 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?

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 :-)

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

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.

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.

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? :)

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?

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.