It would be nice to be able to use anonymous functions within the template registration call. It would help to be able to do this:

Jaml.register(‘selector’, function(c){
select({‘name’:'name-’+c.id},
function(){
for (i in c.opts){
option({‘value’:c.opts[i].val}, c.opts[i].text);
}
})
});

var data = {
“id” : 123,
“link_text” : “My link”
}

x.register(‘myhtml’,function(data){
“div” : [
{"class" : "myclass", "id" : "mydiv-" + data.id},
{ "a" : [{"id" : "mylink-" + data.id }, data.link_text]}
]
})

x.render(‘myhtml’, data);

In the other hand, nowadays we have sites that are more and more dynamic, putting a lot of resources on the client side. And it happens that we need to generate HTML code from Javascript, from building small page blocks to full page structures, single page sites, etc.

How we generate that HTML from JS is the question, and the Jaml syntax is a very good and nice way to do it :)

It really depends on the structure of your application. The point isn’t really to keep your languages separate, but to keep your logic domains separate. In some circumstances—an application that requires Javascript, perhaps intended for only certain user agents (eg Air) or devices (eg iPhone); server-side Javascript—it can make sense to do all of your document construction in Javascript. Likewise, it can make sense to do all of your styling in Javascript.

I personally find that idea appealing. You know, assuming that the application is intended for that sort of environment. I’d still keep my Javascript “stylesheets” separate from my Javascript “views” separate from my Javascript “controllers” separate from my Javascript “models” and so on. But in some cases there’s no reason not to do everything in one language. Context-switching between the languages can be awful.

A few days ago I created Mooml, a Jaml port that takes advantage of Mootools functions and classes. Check it out if you work with Mootools:
http://github.com/eneko/mooml/

In javascript “calling out” from main function body is one of the most expensive operations (because the scope/stack have to be saved and restored), so in nested loops it is a must to avoid that.

Creating “expandos” on elements causes reflow, at least in IE.

Using innerHTML in IE is not safe and not suggested even by less expert javascripters and it is maybe unsafe to do that also on other browsers.

In frameworks like ExtJS using something like this JAML “builder” make perfect sense, speed will still be very high if the simple boosting rules above are followed.

I don’t use it anymore, as it’s not fast. I always build html as text and inject it via innerHTML it’s ten times faster and (in real world scenarios) difference is noticable

This really depends on a lot of details, most prominently which browser you’re running. Single-reflow DOM operations (that is, single element additions, or elements added to a hidden div which is then attached) can be faster in the faster engines (WebKit, Gecko).

Side note: I don’t use it anymore, as it’s not fast. I always build html as text and inject it via innerHTML it’s ten times faster and (in real world scenarios) difference is noticable

DIV(null,
H1(“Some title”),
P(“Some exciting paragraph text”),
BR(),

UL(null,
LI(“First item”),
LI(“Second item”),
LI(“Third item”)
)
);

(you can choose to use MochiKit.DOM: namespace for all tags also)
Agree the initial MochiKit example could be intimidating at first look, but that’s mostly because it also shows of the functional programming techniques and how they coerce to DOM (like templates).

Remember that the more function calls you have the slower your code will execute!

Remember that the more code you execute, the slower your code will execute. Duh?

How is it any different from any other way of interacting with the DOM? Abstractions necessarily add a little overhead, but not necessarily much.

Actually at a former workplace, I migrated them off of Mochikit to YUI and have never regretted it.


var rows = [
["dataA1", "dataA2", "dataA3"],
["dataB1", "dataB2", "dataB3"]
];
row_display = function (row) {
return TR(null, map(partial(TD, null), row));
}
var newTable = TABLE({'class': 'prettytable'},
THEAD(null,
row_display(["head1", "head2", "head3"])),
TFOOT(null,
row_display(["foot1", "foot2", "foot3"])),
TBODY(null,
map(row_display, rows)));


…or not.