[JS/PHP] Client-side templates?

[Olaf van der Spek]

Iedereen kent server-side templates waarschijnlijk wel. Date + templates = response (HTML).
Een probleem van deze aanpak is dat templates vaak meerdere keren in response voorkomen en zeker meerdere keren in verschillende responsen. Zelfs met gzip compressie is dit een nadeel.
Een (mogelijke) oplossing is het gebruik van client-side templates. De templates zet je in een JavaScript file en de data stuur je in een response. De browser combineert de twee dan. De templates worden dus maar een keer verstuurd en daarna gecached door de client.
Nu is mijn vraag, waarom wordt dit in de praktijk (bijna) nooit gedaan?
Op de frontpage wordt het een beetje gebruikt, op het forum niet en verder zie je het ook nauwelijks.

Zijn er (PHP) template engines die dit wel toepassen en ook automatisch de JS code genereren?

[ Voor 7% gewijzigd door Olaf van der Spek op 05-11-2004 18:16 ]

[crisp]

Je site afhankelijk maken van JS is vanuit accessibility oogpunt gezien niet handig. Daarbij kleven er nog meer nadelen aan; bijvoorbeeld het feit dat je site niet meer geindexeerd kan worden door zoekmachines.
Gebruik van HTTP-compressie en minimale markup (dus goed gebruik maken van CSS) levert netto net zoveel rendement op als de javascript methode; vandaar dat je laatste ook steeds minder toegepast ziet worden (ook de Tnet FP zal er ooit wel eens vanaf stappen, net als GoT een paar jaar geleden).

[Olaf van der Spek]

crisp schreef op 05 november 2004 @ 18:22:
Je site afhankelijk maken van JS is vanuit accessibility oogpunt gezien niet handig. Daarbij kleven er nog meer nadelen aan; bijvoorbeeld het feit dat je site niet meer geindexeerd kan worden door zoekmachines.

Het voordeel van een engine is dat die natuurlijk ook niet-JS output kan genereren.
Qua zoekmachines heb je waarschijnlijk gelijk, ook al staat niets een zoekmachine in de weg zelf ook de JS code uit te voeren.
Maar welke browsers ondersteunen eigenlijk nog geen JS?

Gebruik van HTTP-compressie en minimale markup (dus goed gebruik maken van CSS) levert netto net zoveel rendement op als de javascript methode;

Dat betwijfel ik. De JS code is (bijna) altijd na compressie nog kleiner dan de markup. Ook kost de generatie van JS code op de server (veel) minder resources en dat is ook niet onbelangrijk als je een drukke site hebt.
Verder is er veel markup die op elke pagina weer terug komt.

vandaar dat je laatste ook steeds minder toegepast ziet worden (ook de Tnet FP zal er ooit wel eens vanaf stappen, net als GoT een paar jaar geleden).

Ook op GoT verlies je nog functionaliteit zonder JS. Er is bijvoorbeeld geen "Go" knop naast de dropdown menus.

[ Voor 3% gewijzigd door Olaf van der Spek op 05-11-2004 19:21 ]

[simon]

Als ik je goed begrijp wil je templates vanuit de clients laten 'parsen', is XML en XSLT dan niet wat?

[Olaf van der Spek]

Ik heb nog weinig ervaring met XML en XLST, maar XML is ook redelijk 'groot' ten opzichte van minimale JS-code.
Is XLST al zo 'ver' dat het gewoon goed werkt onder alle gangbare browsers?

[simon]

OlafvdSpek schreef op 05 november 2004 @ 19:18:
Ik heb nog weinig ervaring met XML en XSLT, maar XML is ook redelijk 'groot' ten opzichte van minimale JS-code.
Is XLST al zo 'ver' dat het gewoon goed werkt onder alle gangbare browsers?

Ik heb een beetje gespeeld met XML en XLST; en het werkt vrij goed in heel wat browsers, ik ben nog niets geks tegen gekomen

Ik vind XML en XSLT zelf wel mooier dan JS code, en ik denk dat het ook sneller is. XML/XSLT lijkt mij hier de beste oplossing

[ Voor 3% gewijzigd door simon op 05-11-2004 19:22 ]

[crisp]

OlafvdSpek schreef op 05 november 2004 @ 19:15:
[...]

Het voordeel van een engine is dat die natuurlijk ook niet-JS output kan genereren.
Qua zoekmachines heb je waarschijnlijk gelijk, ook al staat niets een zoekmachine in de weg zelf ook de JS code uit te voeren.
Maar welke browsers ondersteunen eigenlijk nog geen JS?

textreaders, mogelijk pda's en wap/imode browsers (geen idee eigenlijk), paranoia gebruikers (mensen die het advies van MS om active scripting te disablen ter harte nemen - dat zullen er best veel zijn), en uiteraard webcrawlers zoals de googlebot.

[...]

Dat betwijfel ik. De JS code is (bijna) altijd na compressie nog kleiner dan de markup. Ook kost de generatie van JS code op de server (veel) minder resources en dat is ook niet onbelangrijk als je een drukke site hebt.
Verder is er veel markup die op elke pagina weer terug komt.

Een goed opgezette site bestaat denk ik uit zo'n 10% markup en voor de rest content (cacheable objects zoals plaatjes, js en css even terzijde). Die 10% markup laat zich behoorlijk goed comprimeren met HTTP-compressie, waarschijnlijk beter dan de content zelf; je gaat dus besparen op hooguit 10% van je bandbreedte maar waarschijnlijk op een nog kleiner deel. Dat is gerommel in de marge lijkt me en weegt niet op tegen de nadelen.

[...]

Ook op GoT verlies je nog functionaliteit zonder JS. Er is bijvoorbeeld geen "Go" knop naast de dropdown menus.

Ja, JS wordt hier gebruikt voor extra functionaliteit, maar de primaire zaken werken prima zonder JS-ondersteuning.

Simon schreef op 05 november 2004 @ 19:16:
Als ik je goed begrijp wil je templates vanuit de clients laten 'parsen', is XML en XSLT dan niet wat?

XML transformatie dien je op de server te doen, niet op de client. Clientside XML transformatie is niets anders dan leuk speelgoed; de ondersteuning ervan laat nog zeer te wensen over. Met een database backend is het natuurlijk onzin om eerst XML te genereren en vervolgens nog eens te gaan transformeren (client of serverside); spuug dan meteen (X)HTML uit, scheelt bijna niets qua omvang - layout en styling regel je immers via CSS.

[Olaf van der Spek]

crisp schreef op 05 november 2004 @ 19:55:
Een goed opgezette site bestaat denk ik uit zo'n 10% markup en voor de rest content (cacheable objects zoals plaatjes, js en css even terzijde). Die 10% markup laat zich behoorlijk goed comprimeren met HTTP-compressie, waarschijnlijk beter dan de content zelf; je gaat dus besparen op hooguit 10% van je bandbreedte maar waarschijnlijk op een nog kleiner deel. Dat is gerommel in de marge lijkt me en weegt niet op tegen de nadelen.

Als ik een pagina van GoT save dan is de source 36 kb en de 'Ctrl+A, Ctrl+C' tekst 7 kb. Dat is toch een redelijk verschil en markup is zeker meer dan 10 %.

Ja, JS wordt hier gebruikt voor extra functionaliteit, maar de primaire zaken werken prima zonder JS-ondersteuning.

Een paar buttons in <noscript> tags zou toch wel netjes zijn.

[crisp]

OlafvdSpek schreef op 05 november 2004 @ 20:39:
[...]

Als ik een pagina van GoT save dan is de source 36 kb en de 'Ctrl+A, Ctrl+C' tekst 7 kb. Dat is toch een redelijk verschil en markup is zeker meer dan 10 %.

Ik had het over een goed opgezette site; de huidige layout is nogal een tag-soup met veel overhead

[...]

Een paar buttons in <noscript> tags zou toch wel netjes zijn.

Als het zo eenvoudig was had ik dat natuurlijk allang gedaan...

[Olaf van der Spek]

crisp schreef op 05 november 2004 @ 20:43:
Ik had het over een goed opgezette site; de huidige layout is nogal een tag-soup met veel overhead

Helaas zijn veel andere forums/sites/skins nog veel slechter.

[crisp]

OlafvdSpek schreef op 05 november 2004 @ 20:53:
[...]

Helaas zijn veel andere forums/sites/skins nog veel slechter.

de ctrl-a ctrl-c vergelijking is natuurlijk ook niet eerlijk. Ik heb net even met de nieuwe GoT layout een behoorlijk topic genomen wat in totaal 216KB aan HTML was. De helft hiervan was pure content (puur alle HTML-tags gestripped). Maar nu is het merendeel van de HTML-tags natuurlijk ook dynamische content (links, markup in posts, etcetera). Kijkend naar de templates schat ik dat je hooguit 20% had kunnen besparen door de boel clientside met JS te genereren. Dan heeft de JS zelf ook nog eens overhead, dus zodoende kom ik dan toch op maar een marginale besparing met in mijn ogen (te) grote opofferingen...

[Olaf van der Spek]

crisp schreef op 05 november 2004 @ 21:33:
de ctrl-a ctrl-c vergelijking is natuurlijk ook niet eerlijk. Ik heb net even met de nieuwe GoT layout een behoorlijk topic genomen wat in totaal 216KB aan HTML was. De helft hiervan was pure content (puur alle HTML-tags gestripped). Maar nu is het merendeel van de HTML-tags natuurlijk ook dynamische content (links, markup in posts, etcetera). Kijkend naar de templates schat ik dat je hooguit 20% had kunnen besparen door de boel clientside met JS te genereren.

Maar is een 'behoorlijk topic' een goede afspiegeling van de gemiddelde pagina van de gemiddelde site?
Veel pagina's hebben veel minder content en veel meer markup.

[crisp]

OlafvdSpek schreef op 05 november 2004 @ 22:31:
[...]

Maar is een 'behoorlijk topic' een goede afspiegeling van de gemiddelde pagina van de gemiddelde site?
Veel pagina's hebben veel minder content en veel meer markup.

Dan kan je beter iets aan je markup gaan doen, bespaar je veel meer mee

en ik denk dat dat voor de 'gemiddelde' site tevens ook het beste advies is...

[ Voor 11% gewijzigd door crisp op 05-11-2004 22:36 ]

[Olaf van der Spek]

Maar dat verschuift de taak van template engine naar gebruiker. En veel gebruikers zullen die taak (dus) nooit uitvoeren.

[gorgi_19]

* gorgi_19 vindt het veel te clientside allemaal..

>> Webdesign & Graphics

[crisp]

OlafvdSpek schreef op 05 november 2004 @ 23:04:
Maar dat verschuift de taak van template engine naar gebruiker. En veel gebruikers zullen die taak (dus) nooit uitvoeren.

Die opmerking kan ik even niet plaatsen, en zeker niet bij mijn laaste opmerking.
Jij begon over 'gemiddelde' sites. Mijn mening over gemiddelde sites is dat dat over het algemeen 1 grote tagsoup is die met goed gebruik van CSS en gestructureerde markup vaak al veel kleiner gemaakt kunnen worden.
Verder blijf ik erbij dat markup door de client laten genereren dmv javascript dan nog uiteindelijk maar minimale besparingen biedt tegenover grote nadelen...

[Olaf van der Spek]

crisp schreef op 05 november 2004 @ 23:42:
Die opmerking kan ik even niet plaatsen, en zeker niet bij mijn laaste opmerking.
Jij begon over 'gemiddelde' sites.

Ik bedoelde eigenlijk developer/skinner van een gemiddelde site, niet eindgebruiker.
Natuurlijk is goede markup nog beter, daar ben ik het wel mee eens.

[crisp]

Aha, jij bedoelt dus het vraagstuk wie verantwoordelijk is voor het omzetten van een design naar templates? De template engine staat daar toch los van?

[Olaf van der Spek]

Als de developer de HTML templates maakt en de template engine daar vervolgens JS templates van kan maken, dan heeft de developer dus geen kennis van JS nodig en kan hij toch over deze functionaliteit beschikken.

[KurtDB]

Wie heeft de template engine dan gemaakt? De designer?

Op tragere browsers zou client-side rendering met JS trouwens sowieso al een slecht idee zijn. Als je daarenboven dan ook niet geïndexeerd wordt door search engine spiders, dan is de kans dat iemand je site "toevallig" vindt ook veel kleiner. (hoeveel mensen hier zijn t.net niet tegengekomen door 'n zoekopdracht via 'n search engine?)

Vergeet trouwens ook niet dat de pagina-rendertijd van de browser ook belangrijk is. Je kan dan nog zo'n mooie parsetime hebben op je server, als de browser zoveel data terugkrijgt dat ie begint te flippen dan staat de user daar ook nog in de kou.

[Olaf van der Spek]

KurtDB schreef op 06 november 2004 @ 14:31:
Wie heeft de template engine dan gemaakt? De designer?

Nee. Een template engine in een forum of iets als phpNuke bijvoorbeeld wordt niet door de designer gebouwd. Een losse template engine kun je ook als PHP 'lib' gebruiken (Smarty).

Op tragere browsers zou client-side rendering met JS trouwens sowieso al een slecht idee zijn. Als je daarenboven dan ook niet geïndexeerd wordt door search engine spiders, dan is de kans dat iemand je site "toevallig" vindt ook veel kleiner. (hoeveel mensen hier zijn t.net niet tegengekomen door 'n zoekopdracht via 'n search engine?)

Vergeet trouwens ook niet dat de pagina-rendertijd van de browser ook belangrijk is. Je kan dan nog zo'n mooie parsetime hebben op je server, als de browser zoveel data terugkrijgt dat ie begint te flippen dan staat de user daar ook nog in de kou.

Zo complex is de JS code nu ook weer niet. Op een Pentium 60 met 10 mbit/s verbinding heb je kans dat de niet-JS versie sneller is, maar verder?

[KurtDB]

Klein vraagje: je veegt al onze argumenten met dezelfde tegenargumenten van tafel, zodus wil je eigenlijk wel 'n andere oplossing zien?

Ik vind de argumenten dat je niet geïndexeerd wordt door search engines en 't feit dat je 'n deel publiek discrimineert (o.a. mensen met 'n braille toetsenbord) al overtuigend genoeg, hoor.

Het feit dat je markup bij 'n niet-js oplossing 10kb groter zal zijn zal eigenlijk niet zo'n groot verschil maken naar mijn mening.

[crisp]

Verder lijkt het me dat als je de helft van je markup in JS hebt zitten dat niet zo eenvoudig te onderhouden is. Je kan dan iets gaan fabriceren dat van HTML templates JS code kan fabriceren, maar dat lijkt me toch vrij lastig - je levert al vrij snel een stuk flexibiliteit in.

[CrashOne]

Je maakt al een grote fout door de complete functionaliteit van je site van JS af te laten hangen.
Hou die functionaliteit lekker op de server, waarvan je zeker weet wat hij kan.

[Olaf van der Spek]

KurtDB schreef op 06 november 2004 @ 16:05:
Klein vraagje: je veegt al onze argumenten met dezelfde tegenargumenten van tafel, zodus wil je eigenlijk wel 'n andere oplossing zien?

Ik vind de argumenten dat je niet geïndexeerd wordt door search engines en 't feit dat je 'n deel publiek discrimineert (o.a. mensen met 'n braille toetsenbord) al overtuigend genoeg, hoor.

Ik veeg ze niet van tafel, in tegendeel, ik ben het ermee eens dat het (mogelijk) niet geindexeerd worden een nadeel is en dat het niet altijd grote voordelen oplevert.
Wat is het probleem met mensen met een braille toetsenbord eigenlijk?

Het feit dat je markup bij 'n niet-js oplossing 10kb groter zal zijn zal eigenlijk niet zo'n groot verschil maken naar mijn mening.

Dat is waar, het is niet zo'n groot verschil. Maar vanaf wat voor verschil zou je het wel de moeite waard vinden?

Je kan dan iets gaan fabriceren dat van HTML templates JS code kan fabriceren, maar dat lijkt me toch vrij lastig - je levert al vrij snel een stuk flexibiliteit in.

Dat hangt natuurlijk sterk af van wat je nodig hebt en wat een template engine (de template -> JS compiler) kan.

Je maakt al een grote fout door de complete functionaliteit van je site van JS af te laten hangen.

Het kan natuurlijk optioneel zijn, zodat je een site ook volledig zonder JS kan bekijken.

[ Voor 9% gewijzigd door Olaf van der Spek op 06-11-2004 19:44 ]

[crisp]

OlafvdSpek schreef op 06 november 2004 @ 19:32:
[...]

Ik veeg ze niet van tafel, in tegendeel, ik ben het ermee eens dat het (mogelijk) niet geindexeerd worden een nadeel is en dat het niet altijd grote voordelen oplevert.
Wat is het probleem met mensen met een braille toetsenbord eigenlijk?

braille readers kunnen net als textreaders (lynx bijvoorbeeld) geen JS interpreteren

Dat is waar, het is niet zo'n groot verschil. Maar vanaf wat voor verschil zou je het wel de moeite waard vinden?

[...]

Dat is een kwestie van voordelen tegen nadelen afwegen; 10% minder bandbreedte tegenover een ontoegankelijke site is een afweging die je zelf maakt...

Dat hangt natuurlijk sterk af van wat je nodig hebt en wat een template engine (de template -> JS compiler) kan.

[...]

tsja, al met al kost het tijd om zoiets te ontwikkelen; verspilde moeite imho gezien de nadelen...

Het kan natuurlijk optioneel zijn, zodat je een site ook volledig zonder JS kan bekijken.

Dus dan ga je zo'n systeem ontwikkelen naast een 'normaal' template systeem wat gewoon (X)HTML uitpoept; verspilde moeite imho...

[MisterICE]

In tegenstelling tot de meeste lijkt dit mij nu dus wel een goed idee....

In het ultieme systeem (waar je naar toe wilt streven) moeten templates niet elke keer gedownload worden.

- Misschien kan er ipv JS een andere engine gebruikt worden, misschien een transparante engine die standaard in elke browser zit ?

- Het argument de de huidige (google)bots de info niet meer kunnen lezen is technisch niet heel relevant natuurlijk, deze bots zouden ook eens kunnen rondkijken in de template map die je aangeeft via een of andere head tag.
Punt is wel dat omdat veel sites hiet nog niet mee werken en je _nu_ zoiets zou bouwen de bots je templates niet lezen.

Overingens werkt forum.fok wel al met (een soort van) deze techniek, ik heb geen idee of de bots nog goed werken (er word igg wel wat gevoden op fok via google) maar ik vind het op fok een relijk nette oplossing.

[crisp]

MisterICE schreef op 07 november 2004 @ 02:19:
In tegenstelling tot de meeste lijkt dit mij nu dus wel een goed idee....

In het ultieme systeem (waar je naar toe wilt streven) moeten templates niet elke keer gedownload worden.

- Misschien kan er ipv JS een andere engine gebruikt worden, misschien een transparante engine die standaard in elke browser zit ?

Dan ben je dus een clientside applicatie aan het bouwen die enkel nog serverside content hoeft op te halen. "Wilt u GoTten? Download dan eerst hier de GoT.exe en installeer die op uw pc."

- Het argument de de huidige (google)bots de info niet meer kunnen lezen is technisch niet heel relevant natuurlijk, deze bots zouden ook eens kunnen rondkijken in de template map die je aangeeft via een of andere head tag.

Templates bevatten doorgaans geen content

Punt is wel dat omdat veel sites hiet nog niet mee werken en je _nu_ zoiets zou bouwen de bots je templates niet lezen.

Overingens werkt forum.fok wel al met (een soort van) deze techniek, ik heb geen idee of de bots nog goed werken (er word igg wel wat gevoden op fok via google) maar ik vind het op fok een relijk nette oplossing.

Deze techniek is helemaal niet nieuw, zelfs GoT heeft er in het verleden gebruik van gemaakt en de frontpage doet het nog steeds. We zijn er echter vanaf gestapt vanwege de al eerder genoemde nadelen die een dergelijk systeem met zich meebrengt. Ook bij Fok kampen ze nu met die nadelen en zijn ze ook bezig met een non-JS template.

[Olaf van der Spek]

crisp schreef op 07 november 2004 @ 13:50:
Dan ben je dus een clientside applicatie aan het bouwen die enkel nog serverside content hoeft op te halen. "Wilt u GoTten? Download dan eerst hier de GoT.exe en installeer die op uw pc."

Meer client-side logica zou anders niet verkeerd zijn in bepaalde gevallen.
Zoeken binnen een pagina (beter dan Ctrl+F) of topic, smart pre-fetching en andere leuke dingen die nu niet mogelijk zijn.