The Future of Tempest

February 15th, 2010

I have started a mailing list for Tempest which you can join by sending a message to tempest@librelist.com. This is my first post to get everything started off.

Tempest was designed with a slightly different philosophy from other client side templating systems. It is "purposefully stupid" to enforce the separation between the presentation and logic layers. Isn't that separation the *point* of using some type of templating? To alleviate the headache that occurs when your code is littered with strings of markup?

var elem = $("<li class='link'><a href='" + url + "'>" + title + "</a></li>");

But the presentation layer needs some very simple control structures; it would be useless without any logic or looping mechanisms. Right now, Tempest has the very minimum required in this regard. If statements with no else. Iteration via array-like data structures rather than template syntax.

This has served pretty well so far but I think there is room for improvement. I find the lack of else statements a nuisance (the only reason they are missing is that I was lazy and thought I could get away with it). I also think that a syntax for iteration inside templates is desirable. Tempest already has the building blocks for these features and extensions, it is just a matter of bootstrapping now.

David has written a custom tag1 that is a perfect example of taking advantage of what Tempest already can do to create new and useful syntax in the templates.

We (David and I) talked about an "each" (or "foreach" or simply "for") tag that might be used like this:

<ul>
  {% each person in people %}
    <li>{{ person.name }}</li>
  {% endeach %}
</ul>

in addition to incorporating something like the "iter" tag he wrote.

The more that I think about it, though, the more I am convinced that Tempest only needs one type of iteration syntax. I don't want Tempest to become a full blown mini language. Simplicity. Nothing more than needed. What do you think?

I also think that the FireUnit tests (which is Firefox only) need to be converted to something more portable. The big IE bug I just had to write a replacement "split" function for is a perfect example of why this is important.

David has also expressed interest in writing an extension to Tempest so that these two forms are equivalent:

$("#foo").tempest(template, data) // New way
$("#foo").html($.tempest(template, data)) // Old way

which sounds great to me. David, go ahead and grab the clone from github and let me know when you have something for me to look at.

Lastly, how do you guys think the documentation is? I think it is somewhat thorough, but might be lacking an overall picture. Suggestions for improvement?

  1. http://geekswithblogs.net/dotnetnomad/archive/2010/02/07/137844.aspx

« Previous Entry

Next Entry »

View Comments


Recent Entries


TryParenScript.com

On July 23rd, 2010


In response to "A JavaScript Function Guard"

On July 19th, 2010


My Notes from John Resig's "jQuery Hack Day" Talk

On July 5th, 2010


Announcing Pocco

On June 29th, 2010


Yet Another Lisp

On June 25th, 2010


Recent Happenings: All Play and No Work

On June 21st, 2010


Arguments.callee considered extraneous

On June 2nd, 2010


Javascript, "bind", and "this"

On May 20th, 2010


Class-Based Views and Django

On May 19th, 2010


Introducing Zoolander

On May 2nd, 2010


Creative Commons License

Fork me on GitHub