PURE, a JS templating engine

[Mic (BeeBole)]

Hi All,
I was wondering if HTML templating is of any interest here.
I've seen some old posts about it.

I'm the author of PURE, a fast and unobtrusive HTML/JSON rendering
engine.
The 2nd version was totally rewritten in functional JS and do not use
eval anymore.

Although it was primarily designed to run client side, Davey Waterson
from Aptana made it work with Jaxer (out of the box).
And Phil Harnish from Youtube made it to work on Rhino (not that out
of the box).
It is a very different approach from the <%...%> templating engines
alike, and keep a strong separation between the HTML and the JS.

The project page is here: http://wiki.github.com/pure/pure
And a here's a demo page: http://beebole.com/pure/version2

Cheers,
Mic

[Jonathan Fine]

Hi

I lurk in this group, and your post interested me, because I care about templating.

I had a look at your code at
    http://github.com/pure/pure/blob/master/js/pure.js
and spotted 
          return typeof obj.length === 'number' && !(obj.propertyIsEnumerable('length')) && typeof obj.splice === 'function';},

which seems to be testing obj for being an array.  (BTW, the display in my browser of this pages is messed up - the lines are truncated left and right.)

The best way, I think, to test for an array is to use what is known as the Miller Device:
$ js
js> Object.prototype.toString.call({})
[object Object]
js> Object.prototype.toString.call([])
[object Array]
js>

I'd like to see a little library of functions such as isArray() (or is_array()) that people such as yourself can consult and use.

There may be similar examples in  your code.

That said,  I do think templating is something that should be available in a library.

best regards

Jonathan

--

You received this message because you are subscribed to the Google Groups "CommonJS" group.
To post to this group, send email to comm...@googlegroups.com.
To unsubscribe from this group, send email to commonjs+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/commonjs?hl=en.

[Nathan Stott]

Hey Mic.  I've written a server-side JS framework called Bogart with a simple plugin extension model.  I'm looking to incorporate more templating engines.  Right now I have an EJS plugin and I'm going to add a HAML one very soon.  

After a quick glance I'm not sure if PURE would fit well with Bogart because Bogart on the server-side isn't so much about the DOM.  I'd like your opinion though and would welcome a plugin contribution.

http://github.com/nrstott/bogart

[Zachary Carter]

On Tue, Dec 1, 2009 at 12:58 PM, Jonathan Fine <jonatha...@googlemail.com> wrote:

Hi

I lurk in this group, and your post interested me, because I care about templating.

I had a look at your code at
    http://github.com/pure/pure/blob/master/js/pure.js
and spotted 
          return typeof obj.length === 'number' && !(obj.propertyIsEnumerable('length')) && typeof obj.splice === 'function';},

which seems to be testing obj for being an array.  (BTW, the display in my browser of this pages is messed up - the lines are truncated left and right.)

The best way, I think, to test for an array is to use what is known as the Miller Device:
$ js
js> Object.prototype.toString.call({})
[object Object]
js> Object.prototype.toString.call([])
[object Array]
js>

I'd like to see a little library of functions such as isArray() (or is_array()) that people such as yourself can consult and use.

 

ES 5 defines Array.isArray(). Narhwal provides this method as part of its bootstrapping[1] (which does use the Miller Device.) I suspect most CommonJS engine will provide methods such as these and other ES 5 features that are possible now.

[1]: http://github.com/tlrobinson/narwhal/blob/master/engines/default/lib/array.js#L7

--
Zach Carter
http://zach.carter.name

[Mic (BeeBole)]

Hi Jonathan,
This is the old version.
The new one is here: http://github.com/pure/pure/blob/version2/libs/pure2.js
Thanks for the comment.


On Dec 1, 6:58 pm, Jonathan Fine <jonathan.fi...@googlemail.com>
wrote:

> > commonjs+u...@googlegroups.com<commonjs%2Bunsubscribe@googlegroups.c om>
> > .

[Mário Valente]

On Tue, Dec 1, 2009 at 5:31 PM, Mic (BeeBole) <tch...@gmail.com> wrote:

I was wondering if HTML templating is of any interest here.
I've seen some old posts about it.

I'm the author of PURE, a fast and unobtrusive HTML/JSON rendering
engine.
The 2nd version was totally rewritten in functional JS and do not use
eval anymore.

Although it was primarily designed to run client side, Davey Waterson
from Aptana made it work with Jaxer (out of the box).
And Phil Harnish from Youtube made it to work on Rhino (not that out
of the box).
It is a very different approach from the <%...%> templating engines
alike, and keep a strong separation between the HTML and the JS.

  Anytime serverside templating is used, another kitten dies. And if the
 templating messes up with pure HTML (stuff like $var and {:var} and
 whatnot), another kitten also dies

  Hi Mic! :-) you know I've always liked PURE (if only you guys would change
 it to use the id= as the data binder)

   Let me also refer you to Chain.js, another interesting pure HTML templating
 system

  http://wiki.github.com/raid-ox/chain.js/

   Also, for further ideas/discussion, checkout

   http://mvalente.eu/2009/11/25/requirements-for-a-modern-web-development-framework/


   -- MV

[Nathan Stott]

I read your link about requirements for a modern web dev framework, Mário.  Are you suggesting that every page that loads should use JS to contact a server, retrieve a JSON object, and then do the databinding in the browser?  This seems like a bad arrangement for those of us concerned about load-time of pages.  Loading even the simplest of pages would then require 2 server round-trips.  Am I misunderstanding?

2009/12/1 Mário Valente <mfva...@gmail.com>

--

You received this message because you are subscribed to the Google Groups "CommonJS" group.
To post to this group, send email to comm...@googlegroups.com.

To unsubscribe from this group, send email to commonjs+u...@googlegroups.com.

[Mário Valente]

On Tue, Dec 1, 2009 at 6:54 PM, Nathan Stott <nrs...@gmail.com> wrote:

I read your link about requirements for a modern web dev framework, Mário.  Are you suggesting that every page that loads should use JS to contact a server, retrieve a JSON object, and then do the databinding in the browser?  This seems like a bad arrangement for those of us concerned about load-time of pages.  Loading even the simplest of pages would then require 2 server round-trips.  Am I misunderstanding?

  No, you are correct.

  But some comments:

  - note that not every page that loads has to retrieve a JSON object
  - also note that not every page that loads needs to retrieve each and every JSON element everytime
  - each page would only load as needed the JSON formatted data to fill in HTML elements;
  - also note that the various JSON pieces would be subjected to the several cache layers (server cache,
    browse cache, etc)

  I think that all of this would resolve any problems with page loading times; and even provide to make
 them better.
  Plus its an easy way to have a server API exposed. And plus its also inline with Roy Fieldings's REST thesis.

   All good things (TM)  :-)

  -- MV

[Nathan Stott]

Any dynamic page would need to retrieve a JSON object since server-side templating is avoided.

Even with the browser cache, an extra HTTP request would have to be made to see the HTTP 304.  This is 200ms of latency added to any dynamic page, right?

Maybe with HTML 5 and the ability to store data locally in the browser, we could avoid this.  On some of my sites 80%+ of users still use IE though so being able to use HTML 5 features is a long way off for me.

I agree it is an elegant way of coding and definitely RESTful.  Is it practical though?  

2009/12/1 Mário Valente <mfva...@gmail.com>

  -- MV

[Mic (BeeBole)]

Hi Mario,

You mean the automatic mapping through ID instead of CLASS ?
This shouldn't be a problem to make it as an option, I guess.
But what the ID's would bring as improvement?

I didn't like ID's as per definition they should be unique.
Or is it something you map and then remove?

Good to read you again ;)

> http://mvalente.eu/2009/11/25/requirements-for-a-modern-web-developme...
>
>    -- MV

[Irakli Gozalishvili]

Hi,

I liked the ideas and the engine itself but it seems to be quite tide to the browser, cause as I sew you're using dom. Obviously there is e4x on on rhino.

There is another one having similar s http://wiki.github.com/bard/seethrough_js

Regarding the >> Loading even the simplest of pages would then require 2 server round-trips.

I don't see there is any reason for not loading inital json together with the page and making separate request for it.

Regards
--
Irakli Gozalishvili
Web: http://rfobic.wordpress.com/
Phone: +31 614 205275
Address: Taksteeg 3 - 4, 1012PB Amsterdam, Netherlands

[Wes Garland]

Hi, Mario;

I hope you weren't serious about the evils of server-side templating in your previous message. My kitten is very worried.

--
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102

[Nathan Stott]

Irakli, how do you accomplish loading the initial dynamic JSON with the html page without server-side templating? :)

[Irakli Gozalishvili]

Yeap that's a good one!! Have not thought of it :D

--
Irakli Gozalishvili
Web: http://rfobic.wordpress.com/
Phone: +31 614 205275
Address: Taksteeg 3 - 4, 1012PB Amsterdam, Netherlands

[Francisco Tolmasky]

Clearly you have thought about this problem a lot, but many of the
rest of us haven't. The post you provided doesn't do a lot to explain
*why* these common practices are bad (such as generating the result on
the server). I am perfectly willing to believe you are correct, but
the post simply tells me that everyone is "doing it wrong", which
doesn't go a long way to convincing me, and much worse leaves me with
lots of unanswered questions since I don't know the crux of the issue.

For example, lets say we build this system where templates are *pure*
HTML, and data is swapped in after the fact using JSON. Would it be OK
to simply do the first JSON swap-in server side, allowing you to avoid
the extra HTTP request? This seems like a reasonable compromise to me,
it is the exact same system with a pure performance enhancement
layered on top. But since I don't know the fundamental problem with
the server-generated model, I'm not sure if I've now broken something
in your eyes.

A more useful post in my opinion would be an explanation of why
templating languages are bad, why generating stuff on the server is
bad, etc etc.

On Dec 1, 11:05 am, Mário Valente <mfvale...@gmail.com> wrote:

[Mic (BeeBole)]

Hi Francisco,

I'm on the same extreme views as Mario to generate everything on the
client.
PURE came from this need and have it as fast as XSLT/XML client side
but for JSON.

For me here are the reasons:
- offload all the rendering work from the server to the client
- reduce the network traffic: the data is always smaller than its HTML
representation
- except JSON data, all your app end up in the cache and reduce even
more the network load
- as HTML, JS, CSS are kind of inevitable today why put an additional
server technology to learn and maintain

And finally the 2 reasons I find useful to generate server pages are:
- SEO, this is a killer, but as we are building a web app, it's not a
concern
- generate pdf, csv, or HTML table based data to something else than a
browser.

[Kris Kowal]

On Tue, Dec 1, 2009 at 12:16 PM, Mic (BeeBole) <tch...@gmail.com> wrote:
> And finally the 2 reasons I find useful to generate server pages are:
> - SEO, this is a killer, but as we are building a web app, it's not a
> concern
> - generate pdf, csv, or HTML table based data to something else than a
> browser.

There's also the matter of accessibility and progressive enhancement.
The big win, in my opinion, for having JavaScript on both the client
and the server, is that we can deliver the same program on the client
and the server. I talked to Jörn Zaefferer at the conference and it
would be cool to use jQuery on both ends instead of using templates.

Kris Kowal

[Mic (BeeBole)]

Kris,
Rendering exclusively with dom manipulations wouldn't be too slow for
an app?
In the browser it is difficult. I don't know for server rendering.

[Nathan Stott]

Jaxer lets you build the DOM on the server-side and even interact with it using jQuery.  I did not find this approach to be productive for writing large applications.  However, maybe it was just because Jaxer ties everything so closely to the "webpage" idea.  It was hard to separate concerns.

[Kris Kowal]

On Tue, Dec 1, 2009 at 2:16 PM, Mic (BeeBole) <tch...@gmail.com> wrote:
> Kris,
> Rendering exclusively with dom manipulations wouldn't be too slow for
> an app?
> In the browser it is difficult. I don't know for server rendering.

Manipulating the DOM in a browser entrains reflow and rendering, which
are the bulk of the performance issue client-side. Moving pointers
around and allocating text should not be too slow on the server side.
That being said, I do not have a philosophical opinion that rendering
or templating should not be done on any particular side.

Kris Kowal

[Brian LeRoux]

Agree w/ you Kris. A solution that supports both runtime and 'compile
time' templating is the holy grail. Think, for example, of this
typical snippet of whatever code:

<% if (person.isSignedIn()) { %>
Welcome back Fred.
<% } else { %>
<a href="/signin">Sign in</a>
<% } %>

This sort of conditional stuff makes good clean sense for server
processing. The alternative to a pure client solution to this problem
smells like old socks. Maybe I'm wrong?

I'd like to see more use cases. Btw, Pure is fkn beautiful piece of
work and a lovely abstraction. We've been taking a similar approach
for mobile/phonegap apps at Nitobi for a while.

[Nathan Stott]

That code sample looks like EJS.  I agree that it is very useful.

From what I've seen of DOM on the server-side, it is less desirable than a more standard templating solution.  It'd be interesting to see a complete example of DOM on the server-side other than Jaxer though.

[Zachary Carter]

On Tue, Dec 1, 2009 at 3:16 PM, Mic (BeeBole) <tch...@gmail.com> wrote:

Hi Francisco,

I'm on the same extreme views as Mario to generate everything on the
client.
PURE came from this need and have it as fast as XSLT/XML client side
but for JSON.

For me here are the reasons:
- offload all the rendering work from the server to the client
- reduce the network traffic: the data is always smaller than its HTML
representation
- except JSON data, all your app end up in the cache and reduce even
more the network load

 

This is the most interesting advantage IMHO. Generic pages can be served statically and cached for all users, whereas pages with user specific elements will have to be served up individually for each user. With client-side templating, essentially all pages are generic.
 

- as HTML, JS, CSS are kind of inevitable today why put an additional
server technology to learn and maintain

And finally the 2 reasons I find useful to generate server pages are:
- SEO, this is a killer, but as we are building a web app, it's not a
concern
- generate pdf, csv, or HTML table based data to something else than a
browser.

[Zachary Carter]

On Tue, Dec 1, 2009 at 5:43 PM, Brian LeRoux <brian....@westcoastlogic.com> wrote:

Agree w/ you Kris. A solution that supports both runtime and 'compile
time' templating is the holy grail. Think, for example, of this
typical snippet of whatever code:

<% if (person.isSignedIn()) { %>
 Welcome back Fred.
<% } else { %>
 <a href="/signin">Sign in</a>
<% } %>

This sort of conditional stuff makes good clean sense for server
processing. The alternative to a pure client solution to this problem
smells like old socks. Maybe I'm wrong?

 

This seems to be a case where client-side templating might be better. If that code snippet was embedded in every page, or a large sub-set of pages served by the application, it would have to be rendered and served individually for each user on the server-side. With client-side templating, the page template could be served statically and cached for all users. Each user would still need an initial request for their `person` data, but this is still less work for the server, as it can be reused over all pages.

You could eek out some good performance gains going this route, and it's enhanced by developments such as resource packages[1], which favor less dynamic resources.

[1]: http://limi.net/articles/resource-packages/

[Brian LeRoux]

So, but then you'd have to do something like this right?

<div id="account">
<div id="signedIn"></div>
<div id="signedOut"></div>
</div>

Therefore sending extra extraneous, unrelated, and thus somewhat
un-semantic, markup to the client. Maybe this is solved with fragments
and clientside logic.

Maybe you are thinking along these lines?

<script>
x$('#account').xhr('/person', function() {
var person = eval('(' + this.responseText ')');

if (person) {
// render html fragment in place of the sign in fragment
}
});
</script>

I could be sold on that approach.

I mean, I don't think this is an either/or proposition. Client makes
sense for many if not most templating scenarios but the server can
make very good sense in conditional / stateful scenarios. As the
yogi's say, "Favor balance to purity".

JavaScript should be the vehicle of balance between server and client.
The middle path. Etc.

*zen bow*

[Zachary Carter]

On Tue, Dec 1, 2009 at 6:29 PM, Brian LeRoux <brian....@westcoastlogic.com> wrote:

So, but then you'd have to do something like this right?

<div id="account">
 <div id="signedIn"></div>
 <div id="signedOut"></div>
</div>

Therefore sending extra extraneous, unrelated, and thus somewhat
un-semantic, markup to the client. Maybe this is solved with fragments
and clientside logic.

I was thinking more of sending unrendered templates to the client (be it PURE, mustache.js, etc,) which when combined with the user's JSON data dictionary would produce the semantic and valid markup.
 

Maybe you are thinking along these lines?

<script>
x$('#account').xhr('/person', function() {
 var person = eval('(' + this.responseText ')');

 if (person) {
   // render html fragment in place of the sign in fragment
 }
});
</script>

This would also work.
 

I could be sold on that approach.

I mean, I don't think this is an either/or proposition. Client makes
sense for many if not most templating scenarios but the server can
make very good sense in conditional / stateful scenarios. As the
yogi's say, "Favor balance to purity".

JavaScript should be the vehicle of balance between server and client.
The middle path. Etc.

 

True. I suppose it depends on how you are optimizing, current infrastructure, etc.

 If I were starting an app today, I would go with heavy client and use the server as a RESTful persistence store. Still, you can't fully trust the client, so CommonJS is nice for reusing business logic on both ends.
 

[chris thatcher]

One thing that we do with jQuery-Claypool is add a serverside filter to intercept the model data that is passed to the template or document (we use both template engines and pure jquery dom manipulation on the server via envjs), and serialize it to json.  This allows us to treat the server as a json service. 

Even the server uses ajax to load external templates, so the client can use the same templates or dom manipulation routine.  Thus you can start by writing a pure server-side js website, and progressively move most of it onto the client.

For example look at any claypooljs page and add ?fo=json and you will get the model used to render the template.

eg

http://www.claypooljs.com (html)
http://www.claypooljs.com?fo=json (model)
http://www.claypooljs.com/templates/site/html/pages/home.js (template)

All pages work like this so having built the straight site we are currently beginning the process of using the same code to make the entire site available as a single url client 'application'.  SEO is happy, no javascript browsers are happy, and usabilty becomes enhanced.

Thatcher

Christopher Thatcher

[sleepy]

Glad to see this discussion!

I have been thinking about this kind of design for a while.

It's indeed a more ideal separation between static and dynamic content.

Also, it would be great to have a unified DOM manipulation API across client and server.

I tried some jQuery/DOM based template engine on server-side but non of them work properly.

Some of my early experiments such as server-side jQuery were presented in my talk on introducing server-side Javascript at our local conference. http://sleepnova.blogspot.com/2009/08/javascript-coscup-2009.html

2009/12/2 Zachary Carter <zack....@gmail.com>

--

[Francisco Tolmasky]

I think the idea of being able to cache the template 100% of the time
is certainly very intriguing. However, what exactly is the best way to
handle iteration in a pure html/json split? I would really like to see
a very elegant example of doing iteration since this is primarily the
reason that I am attracted to template languages in the first place.
If all template languages did was allow for swapping in simple
singular values here and there then they wouldn't be too enticing. It
would be awesome if HTML had something like this:

<ul id = "items" count = "0">
<li-prototype id = "item-{X}"></li>
</ul>

Then, you could just do $("items").count = json["amount"], and then
the internals would be magically generated and have the proper id's
and thus be able to be filled appropriately. Of course, this doesn't
exist, and thus it seems that my HTML templates will quickly turn into
HTML/JS-heavy templates that are quite imperative, working against the
goal of having a very simple declarative interface for this stuff. To
me, something like this:

<ul id = "titles">
<% while (index--) { %>
<li><%titles[index]%></li>
<% } %>
</ul>

Is very straightforward and easy to read, mainly because it sits
exactly where the content is supposed to be. The second I have to have
some onload function inject the contents, this becomes a much less
declarative task and makes it harder to understand the original
template:

in template.html
<ul id = "titles"> <!-- stuff will get added here later --> </ul>

in a completely separate place (but possibly in the same file):
titles.forEach(function() { add_li_element() // possibly remove
elements too... });

But again, I haven't done this much at all, so perhaps there is a
really good answer to this question.

[Francisco Tolmasky]

Sorry, wanted to respond to myself here. Having taken a closer look at
PURE (I had only seen the examples on the github page before), the way
iteration is handled looks pretty promising and I will be taking a
closer look at this, it may in fact serve very well for the
documentation app I am currently writing.

[tfreitas]

Hi people.

At present, we are developing an application with JAXER and PURE.
The separation of HTML / CSS and Data (JSON) is great, also allows us
to easily change the code on the client side to server side, and vice
versa in a very easy way.

I think the portability of code helps a lot:
- It allows us to determine what information is useful for SEO, which
will run on the server side.
- It allows us to evaluate and change (the side client / server) for
code execution performance.
- Bringing the framework of javascript to the server, saved us
development time, integration time and time on the learning curve with
respect to other technologies.
- Primarily the separation of presentation (HTML / CSS) of data (JSON
and JSONP) helped us in maintenance.

Personally, I'd really like some kind of HTML templating and the
possibility of running javascript frameworks (jquery, pure, etc.) on
the server side without change or the fewest possible changes. [1] [2]
[3]

[1] http://ejohn.org/blog/bringing-the-browser-to-the-server/
[2] http://ejohn.org/blog/server-side-javascript-with-jaxer/
[3] http://ejohn.org/blog/javascript-micro-templating/

[chris thatcher]

tfreitas

you should check out http://github.com.thatcher/env-js .  We have been working diligently for the past two years to, in John's words "Bring the browser to the Server".  We have an html5 parser, solid dom api, can support frames, ajax, timers, etc.  We run in rhino and have a ruby/johnson port for spidermonkey.  I use jquery on both the client and the server and we would love your help to make it better.

the site is http://www.envjs.com/ which runs on env-js on the server via google apps engine.  at some point when commonjs matures we hope to provide a norwhal interface, but for now our goal is leveraging the majority of javascript which was developed for the browser for use in any supported envjs platform.

thatcher

--

You received this message because you are subscribed to the Google Groups "CommonJS" group.
To post to this group, send email to comm...@googlegroups.com.
To unsubscribe from this group, send email to commonjs+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/commonjs?hl=en.

--
Christopher Thatcher

[chris thatcher]

ugh bad link http://github.com/thatcher/env-js is correct

--
Christopher Thatcher

[mvalente]

On Dec 2, 6:26 am, Francisco Tolmasky <franci...@280north.com> wrote:
> I think the idea of being able to cache the template 100% of the time
> is certainly very intriguing. However, what exactly is the best way to
> handle iteration in a pure html/json split? I would really like to see
> a very elegant example of doing iteration since this is primarily the
> reason that I am attracted to template languages in the first place.
> If all template languages did was allow for swapping in simple
> singular values here and there then they wouldn't be too enticing. It
> would be awesome if HTML had something like this:
>
> <ul id = "items" count = "0">
> <li-prototype id = "item-{X}"></li>
> </ul>
>
> Then, you could just do $("items").count = json["amount"], and then
> the internals would be magically generated and have the proper id's
> and thus be able to be filled appropriately. Of course, this doesn't
> exist, and thus it seems that my HTML templates will quickly turn into

Look at http://entrian.com/PyMeld/

In my opinion they're doing it right. And in a next post I will try
to reply
to your request of explaining what is "doin it wrong" :-)

They do one thing wrong though, which Mic referred to in a
previous
post: they repeat the "id" attribute on the various iterated elements
and
thus break the standard's rules. That can be solved by making the
clientside templating do what you just mentioned: generating "id"'s=
"name1","name2", etc for the iterated elements.

-- MV

[mvalente]

On Dec 2, 12:28 am, chris thatcher <thatcher.christop...@gmail.com>
wrote:

>
> For example look at any claypooljs page and add ?fo=json and you will get
> the model used to render the template.
>

> All pages work like this so having built the straight site we are currently
> beginning the process of using the same code to make the entire site
> available as a single url client 'application'.  SEO is happy, no javascript
> browsers are happy, and usabilty becomes enhanced.
>

Precisely. We built a prototype this weekend (post about it coming
up)
and used instead the Accept header = html || json to determine which
part to fetch/return.

-- MV

[mvalente]

On Dec 1, 10:43 pm, Brian LeRoux <brian.ler...@westcoastlogic.com>
wrote:

>
> I'd like to see more use cases. Btw, Pure is fkn beautiful piece of
> work and a lovely abstraction. We've been taking a similar approach
> for mobile/phonegap apps at Nitobi for a while.
>

Hi Brian

Thanks for your presentation at Codebits :-) I enjoyed it :-)

Like I said before, PURE is indeed the closest thing that is
available that works close to what I want/ed. But it still wasnt
perfect :-)

Me and a friend worked on this during this year's Codebits (
http://codebits.eu/ ). Or rather
he (Rui Lopes) worked and I stood on the side playing enterprise
systems architect :)

Rui already has a working prototype and hopefully he will unveil
it the coming days.

But here is an overview/example:

- I got to http://foo.com/ the Accept header is HTML (its a
browser request), the server
returns the index.html file (or the index_html object)
- assume that this HTML is basically:
<div id="header" class="html">
<div id="content" class="html>
<div id="footer" class="html">
- the clientside templating system makes requests for header.html,
content.html and footer.html, filling in the DIVs contents
- assume that content.html is:
<p> Hello <span id="name"> </p>
<p> The time is <span id="servertime"> </p>
- the clientside templating system will then make a request to
http://foo.com/content with Accept header JSON, receives a
JSON hash, retrieves the values for keys "name" and
"servertime"
and fills in the SPAN elements
- the browser now goes to http://foo.com/bar/
- since there's no index.html at that location, the templating
system
goes a level up in the hierarchy (filesystem or object) and
fetches
http://foo.com/ and gets back the already mentioned index.html
- once again it requests header, content and footer. Since
header.html
and footer.html dont exist, they are inherited from the level
above. Caching applies.
Since the content.html file (object) exists at /bar, that
local content.html
is used to fill in that slot.
- the clientside templating system then makes a request to
http://foo.com/bar/
with Accept JSON and receives back a JSON hash with keys and
values
with which to fill in the html elements identified by "id"
attribute.

Its working nice, Rui is ironing some sticky points, but thats how
it works. It
basically works in a way similar to Zope's DTML templates and
inheritance.

-- MV

[mvalente]

On Dec 1, 7:28 pm, "Mic (BeeBole)" <tch...@gmail.com> wrote:
> You mean the automatic mapping through ID instead of CLASS ?
> This shouldn't be a problem to make it as an option, I guess.
> But what the ID's would bring as improvement?
>
> I didn't like ID's as per definition they should be unique.
> Or is it something you map and then remove?
>

Yeah, the duplicate IDs are of course a problem. That's what Pymeld
is doin it wrong.
But that could be solved by generating id="foo-X" for iterated
HTML
elements.

Regarding IDs: I like them because per definition they are
unique :-)
As such they are better than class="x" or the use of any other
attributes.

-- MV

[mvalente]

On Dec 1, 7:11 pm, Nathan Stott <nrst...@gmail.com> wrote:
> Any dynamic page would need to retrieve a JSON object since server-side
> templating is avoided.
>
> Even with the browser cache, an extra HTTP request would have to be made to
> see the HTTP 304.  This is 200ms of latency added to any dynamic page,
> right?
>

Right-ish :-) Other people's posts already referred to a lot of
stuff that would
make this disadvantage relative.


> I agree it is an elegant way of coding and definitely RESTful.  Is it
> practical though?
>

In my opinion, yes.

First it allows for a clean separation of business logic from UI
logic, of
separation of concerns (MVC, etc). Namely these would be templates
that I could provide to any webdesigner or edit with any HTML editor
without fear of getting back corrupted template generation code
(since
its embedded in the template). The only communication point between
the webdesigner/UI people and the programmers would be the IDs used
(as attributes in HTML elements and as keys on returned JSON data)

Second it provides a ready made REStful JSONified API. I know that
I can got to http://foo.com/bar/ with Accept header HTML and get back
the pure HTML template. And I can got to http://foo.com/bar/ with
Accept header JSON and receive the correspondent plain data for
that resource.

-- MV

[Wes Garland]

Zach;

On Tue, Dec 1, 2009 at 5:49 PM, Zachary Carter <zack....@gmail.com> wrote:

This is the most interesting advantage IMHO. Generic pages can be served statically and cached for all users, whereas pages with user specific elements will have to be served up individually for each user. With client-side templating, essentially all pages are generic. 

This is true, but you have to understand a one-size-fits-all solution is almost never right in all cases.

Take the case where the page is a small bit of boiler plate, and a address book. Now imagine that address book is 5000 lines long.

I can VERY easily imagine a case where rending on the client by looping over JSON and poking at the DOM would be a full two orders of magnitude slower on a client running IE6 than looping over a database connection and spitting out HTML on the server.

In this case, the user experience would be much, much better and the server load would not be significantly different (especially if you were running mod_deflate or something).

This type of query is also cacheable, albeit only on a user-by-user basis, so you can't take advantage of centralized caches or CDNs.

Wes

[Wes Garland]

<ul id = "titles">
<% while (index--) { %>
<li><%titles[index]%></li>
<% } %>
</ul>

FWIW, Using curly braces in the mark-up like the preclues the possibility that the un-marked up content is ever represented as xhtml in E4X object literals.

While I do not advocate specifying the use of E4X (ECMA-357) in any way, I think it is wise to consider compatibility in CommonJS specifications which might be related to XML (including xhtml).

[mvalente]

On Dec 1, 7:21 pm, Francisco Tolmasky <franci...@280north.com> wrote:
> Clearly you have thought about this problem a lot,
>

I have, though I cant guarantee the correctness of my thoughts or
conclusions :-)

>but many of the
> rest of us haven't.
>

Somehow I doubt that...

>The post you provided doesn't do a lot to explain
> *why* these common practices are bad (such as generating the result on
> the server).
>

Yes. I dont like to write long answers. I do write long posts and
have
written about that extensively in my blog ( http://mvalente.eu/?s=future+web+development
)
but maybe in a fragmented way.

> For example, lets say we build this system where templates are *pure*
> HTML, and data is swapped in after the fact using JSON. Would it be OK
> to simply do the first JSON swap-in server side, allowing you to avoid
> the extra HTTP request? This seems like a reasonable compromise to me,
>

Indeed. A friend of mine implemented something like that by using
the LINK element in the page HEAD ( http://github.com/cpinto/sample-jstemplate
)
I could live with that.

> it is the exact same system with a pure performance enhancement
> layered on top. But since I don't know the fundamental problem with
> the server-generated model, I'm not sure if I've now broken something
> in your eyes.
>

LOL! :-) I dont hold my opinions as written in stone and as the
absolute truth. But they *are* my opinions and I can be pretty vocal
about them.

> A more useful post in my opinion would be an explanation of why
> templating languages are bad, why generating stuff on the server is
> bad, etc etc.
>

Indeed. As I said I've written extensively about this and linked to
several arguments supporting my point of view. But I will try to
structure my reasoning next. Long post ahead, beware! :-)

- in the beginning was the 3-tier architecture. And that was the
original sin :-). It is a systems architecture pattern, an
evolution
from the Client/Server architecture. But at the time (middle to
late 90s) it fit the budding web development industry quite well.
You could fit your DBserver/(PHP/Perl/Python)Appserver/Browser
stack into the Data/Logic/Presentation tiers and you had a model
that allowed to think about and architect web applications.

- pretty quickly we found out that that model created problems by
not providing a clear separation of concerns. Since the
Presentation
level was the browser and we hadnt yet gone to the REST/AJAX/JSON
era, it was assumed/agreed that all presentation should be
generated
serverside. It was what we had. But, once again, that created
problems.
Working in various serverside languages (with PHP being the
biggest
culprit) it was pretty easy to mix business logic and presentation
logic.
The pages contained in themselves data access, business logic,
view
generation and interface logic. No separation of concerns. Huge
development
management problems and code maintainability.

- presented with such problems, the webapp building community came
up with templates. That, admitedly, allowed to separate concerns
and
to separate business logic and views. In fact, no such thing
happened.
The templating systems actually had a DSL that you had to learn
and
that were/are so powerfull, that once again the mixing of concerns
is
possible, namely between business logic and application logic.

- after the templates, and much because of them, a different
pattern
was adopted, the MVC pattern. It allowed to think about web
applications
in a different way, taking into account the separation of concerns
using
templates. The templates being the View, the UI logic/URL routing
being the Controller and the Model representing the application
domain.

- in fact, the previous patterns (MVC and 3-tier) are not
exclusive. In
fact you have ad interest and advantages if you can provide some
way
of fitting them together. See http://is.gd/5dBOM . And this that
you
have to clearly separate UI logic and business logic and to deal
with them differently and in different parts. Otherwise you will
once
again break the separation of concerns and create problems.

- regarding the previous points, see Parr's paper on this matter,
he is
more clear on the subject than I could ever be http://is.gd/5dBBJ

- the previous exposition means that, to me, there are two
issues
that must be addressed: 1) our model for webapp architecture and
building; 2) some mechanisms to enforce the separation of
concerns

- regarding the second point I think that the right way to do
it is
by not allowing specialist clientside JS scripts and to provide
some way to program webpages in a declarative form. See this
post http://is.gd/5dCbZ for a better explanation than mine. The
more interesting part is actually at the end of the post.

- my solution to this issue is then my proposed solution: you do
not have a specific/DSL template generation language.
Templating
is done by a static/fixed/generic engine and you define your
view
(web page) in a declarative form using the ID attributes.

- regarding the first point, my opinion is that we have to come
up
with a systems architecture that encompasses both the 3-tier
system pattern and the MVC software design pattern. There are
several proposals and, once again, I would refer you and ask you
to read the following links (SOFEA/SOUI/RADAR)

http://wisdomofganesh.blogspot.com/2007/10/life-above-service-tier.html
http://www.appcelerant.com/mvc_is_dead.html
http://pragdave.pragprog.com/pragdave/2007/03/the_radar_archi.html

- the way I'm currently thinking about web applications and a
modern
web development framework is illustrated pretty well in the
following
presentation http://is.gd/5dCuk On page 9 I'm with the model
presented
on the 4th column/stack (although I think that there should be
a further
separation between business logic and data. Notice that there's
is a
clear separation between UI logic and business logic. And the
only
way to do that, in my opinion, is to provide for a clientside
declarative
templating system. Notice further that at page 19 an evolution
of the
MVC pattern (in fact a dual MVC model, the result of joining the
3-tier
architecture and the initial MVC pattern) is presented. Another
way of
thinking/modelling this is through MS Model-View-Presenter with
App Controler pattern or through the Presentation-Abstraction-
Control
pattern ( http://is.gd/5dCFd )


Given all of the above I hope I have made my opinion clearer: I
think
that we must think about webapp development in a different
architectural
way. That was what I tried to describe in my post about the
requirements
for a modern web development framework. And this different/new way
of thinking webapp architecture demands a restrictive, declarative,
client
side templating system that I think is better provided through the
use of
pure HTML as the templates themselves, managed by a fixed behaviour
templating system.

This framework should be JS/REST/JSON based throughout ( see
my presentation http://is.gd/5dD4Q from last year)

Feel free to break anything and no need to worry about my
eyes :-)

-- MV

PS - The problem with the server-generated solution is that it almost
always involves the same language and the same "container" and
thus inevitably leads to the mixup of business logic, UI logic and
view rendering, thus no separation of concerns with the consequent
problems and disadvantages. The problem could be solved by having
separate "containers" (servers, sandboxes, VMs), one only for
business
logic and for serving data-based computations and the other used only
for view/HTML generation. But even then you would have a much-too
powerful templating language that would always open the door for
business
data manipulation during view-rendering.

[Wes Garland]

> PS - The problem with the server-generated solution is that it almost
> always involves the same language and the same "container" and
> thus inevitably leads to the mixup of business logic, UI logic and
> view rendering, thus no separation of concerns with the consequent
> problems and disadvantages.

FWIW:

1 - If you arrange your solution so that the result is renderable, always, on either the client or the server based merely on a "where to render" directive, you mostly solve the this problem.

2 - No matter what you do, morons will still work around your nice architecture.

3 - The last time I personally implemented a major client-side-only application, I practically killed myself trying to get it to be fast enough. I wound up ditching large swaths of it for server-side solution instead. That was unfortunate, because it spike our bandwidth bill. But at least the app was usable. I suppose, though, the the client side has improved dramatically in the last 9 years or so. ;)

[Zachary Carter]

On Sat, Dec 5, 2009 at 7:37 PM, Wes Garland <w...@page.ca> wrote:

Zach;

On Tue, Dec 1, 2009 at 5:49 PM, Zachary Carter <zack....@gmail.com> wrote:

This is the most interesting advantage IMHO. Generic pages can be served statically and cached for all users, whereas pages with user specific elements will have to be served up individually for each user. With client-side templating, essentially all pages are generic. 

This is true, but you have to understand a one-size-fits-all solution is almost never right in all cases.

Indeed.
 

Take the case where the page is a small bit of boiler plate, and a address book. Now imagine that address book is 5000 lines long.

I can VERY easily imagine a case where rending on the client by looping over JSON and poking at the DOM would be a full two orders of magnitude slower on a client running IE6 than looping over a database connection and spitting out HTML on the server.

 

FWIW I would probably render this incrementally on the client, and perhaps even fetch incrementally. So as the user scrolls, the next "page" or so are requested in the background. Basically pagination without the pages, or the "infinite-scroll" trick. I could see this improving performance for slow clients like IE6, for at least the initial page load.

 

In this case, the user experience would be much, much better and the server load would not be significantly different (especially if you were running mod_deflate or something).

This type of query is also cacheable, albeit only on a user-by-user basis, so you can't take advantage of centralized caches or CDNs.

Wes

--
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102

--

You received this message because you are subscribed to the Google Groups "CommonJS" group.

To post to this group, send email to comm...@googlegroups.com.
To unsubscribe from this group, send email to commonjs+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/commonjs?hl=en.

[Wes Garland]

FWIW I would probably render this incrementally on the client, and perhaps even fetch incrementally. So as the user scrolls, the next "page" or so are requested in the background. Basically pagination without the pages, or the "infinite-scroll" trick. I could see this improving performance for slow clients like IE6, for at least the initial page load.

That's indeed a good solution, and something that like should have been considered during the design phase of the application.

This was a kind of unique instance where that would have been incredibly tricky though: the contact management system worked by filtering the address book based on contact groups. So, you click on a group and it would select all the contacts in that group for you -- allowing you to then go unselect certain contacts or contact groups. Basically, you could deliver traffic to intersections, unions, etc of contacts. Very special-purpose, yes we had a good use-case. ;)

I suppose they could have designed the system so it knew about all the contacts in memory, but only rendered them piece-meal, on-demand based on scroll position.  Rendering the list on the server wound up being easy and cheap, though.

Wes
 

[Mic (BeeBole)]

If I get you well on this (long) one ;)
The missing part in PURE is about loading HTML templates on the fly?
Then you have a kind of inheritance of templates. It will be
interesting to watch.

On Dec 6, 12:07 am, mvalente <mfvale...@gmail.com> wrote:
> On Dec 1, 10:43 pm, Brian LeRoux <brian.ler...@westcoastlogic.com>
> wrote:
>
>
>
> > I'd like to see more use cases. Btw, Pure is fkn beautiful piece of
> > work and a lovely abstraction. We've been taking a similar approach
> > for mobile/phonegap apps at Nitobi for a while.
>
>    Hi Brian
>
>    Thanks for your presentation at Codebits :-) I enjoyed it :-)
>
>    Like I said before, PURE is indeed the closest thing that is
>   available that works close to what I want/ed. But it still wasnt
>   perfect :-)
>

>   Me and a friend worked on this during this year's Codebits (http://codebits.eu/). Or rather

>  he (Rui Lopes) worked and I stood on the side playing enterprise
> systems architect :)
>
>     Rui already has a working prototype and hopefully he will unveil
> it the coming days.
>
>     But here is an overview/example:
>

>     - I got tohttp://foo.com/the Accept header is HTML (its a

> browser request), the server
>        returns the index.html file (or the index_html object)
>     - assume that this HTML is basically:
>                  <div id="header" class="html">
>                  <div id="content" class="html>
>                  <div id="footer" class="html">
>     - the clientside templating system makes requests for header.html,
>             content.html and footer.html, filling in the DIVs contents
>     - assume that content.html is:
>                <p> Hello <span id="name"> </p>
>                 <p> The time is <span id="servertime"> </p>
>     - the clientside templating system will then make a request to

>        http://foo.com/contentwith Accept header JSON, receives a

>        JSON hash, retrieves the values for keys "name" and
> "servertime"
>        and fills in the SPAN elements

>     - the browser now goes tohttp://foo.com/bar/

>     - since there's no index.html at that location, the templating
> system
>       goes a level up in the hierarchy (filesystem or object) and
> fetches

>      http://foo.com/and gets back the already mentioned index.html

>     - once again it requests header, content and footer. Since
> header.html
>        and footer.html dont exist, they are inherited from the level
> above. Caching applies.
>         Since the content.html file (object) exists at /bar, that
> local content.html
>        is used to fill in that slot.

>      - the clientside templating system then makes a request tohttp://foo.com/bar/