There are plenty of definitions of ‘closure’ term on the web. Most of them quite generic and here is my attempt to define what is the closure under the hood. Hope it will help to someone to understand better the subject.

Technically speaking closure is a data structure that combines reference to function body and non-empty list of call frames active at the moment of declaration.

Closure is created by executing some code that contains declaration of a function that uses variables from outer scopes. In this case VM (virtual machine), while executing the code, has to create not just reference to the function but closure structure – function reference and reference to its current environment[s] – list of call frames that hold used outer variables.

Here is JavaScript example of function that returns closure:

function Foo() {
   var zoo = 2;
   function Bar(p) {
     return zoo + 2; // using 'zoo' variable from outer scope.
   }
   return Bar; // returning inner function reference
}
var bar = Foo(); // here 'bar' contains Bar instance (the closure).
...
alert( bar() );  // invoking the function-closure.

In order Bar function to work it should have reference to outer call frame (the one that contained ‘zoo’ variable).

And here is an example of plain function declaration – function referred by bar uses only its own variables:

var baz = function() {
   var zoo = 2;
   return zoo + 2; // using 'zoo' variable from its own scope.
}

To represent JavaScript closure and plain function we can use following definitions (C++):

  struct Function { // plain JS function
    bytes bytecode; // executable code of the function.
  };
  struct Closure {  // JS closure
    bytes bytecode;        // executable code of the function.
    cframe* cframe_chain;  // callframe chain, used to get/set variables in outer call frames.
  };

If we don’t care too much about memory consumption then we can declare JS function as a generic class that will cover functions and closures in single entity:

  struct Function {
    bytes bytecode;      // executable code of the function.
    cframe* cframe_chain_nullable; // callframe chain, is NULL for plain functions.
  };

For any given JS function compiler can determine is it using outer variables or not. So it can tell if closure creation is required for given function declaration. It makes sense to do such detection as creation of closure is pretty expensive – VM shall move call frames from stack to the heap – convert callframes to GCable objects. If closure is not required by the nature of particular function VM should not create the closure and so heap will not be polluted by unused call frames.

Preface

Modern Web applications frequently use AJAX kind of client/server interaction. They receive data from the server in pure JSON format. That means instead of generating markup on the server such applications are composing HTML inside the browser (on client side).

Straightforward approach is to use string concatenation spagetti like : "<b>" + data + "</b>".  But this almost always will end up in non-maintainable mess. Real Jedi use markup templates. Typical PHP page is a script with embedded HTML – typical template the gets "instantiated" for the particular GET request/data/user.

PHP or plain old ASP are not only possible template formats. There are a lot of template engines and template languages in the wild. All of them fall into four major groups:

1. Minimalistic, logic-less: {{mustache}} and (probably) PURE;
2. Still simple TDLs but with some simple logic like if/else construcs: jQuery.tmpl() and the KiTE,
3. PHP or ASP alike templates: JavaScript constructs embedded in HTML using <% %> brackets: jQote, John Resig’s Micro Templates, EJS, etc.
4. Group of template engines based on #haml/Ruby ideas – they use special non-HTML markup.

In general: as simple language, less syntax noise it creates – as better. Easier to comprehend and so easier to maintain. The worst case from this perspective is actually PHP (group #3) – mix of two different syntaxes in single source (script and markup) can easily become not readable.  

Speed of template instantiation is on other axis of "templates space". Implementation of PHP alike templating (group #3) is relatively straightforward with JavaScript. Basic idea is to replace all text between
"%> ... some markup... <%"  
by something like
 out += "... some markup...";  
and wrap the template into
 compiled = new Function(transformed_template).

Template instantiation in this case is a matter of calling such function. This approach potentially is as fast as JavaScript itself. But as I said the template source is too "dirty" even in simple cases. I believe that code from this article http://blog.futtta.be/2011/01/18/how-to-do-jquery-templates-with-jqote2/ is a good example of how messy it can be with just few if/else’s.

On other side {{mustache}} templates are pretty clean but current {{mustache}} implementation is extremely slow. According to jsperf.com/dom-vs-innerhtml-based-templating/96 it is 150 times slower than the most effective jQote2. Too bad to be honest.

Another problem with the {{mustache}} is its logic-less nature. I understand the motivation but in reality some simple logic is required. Something like "if fieldA > 10 then render the record one way otherwise in some other".

So I came up with …

The KiTE.

KiTE is lightweight (180 lines of code) and fast JavaScript template engine. It uses template defintion language (TDL) that is close to {{mustache}} but with few additions: conditional sections and custom formatting functions.

Here is an example of KiTE template that emits simple list of contacts:

<ul>
  {{#contacts}}
    <li><b>{{firstName}}</b> <i>{{lastName}}</i></li>
  {{/contacts}}
</ul>

When given by JS data in following format:

{ contacts:
  [ { firstName: "Ernest", lastName:"Hemingway" },
    { firstName: "Scott", lastName:"Fitzgerald" } ]
}

the template will be instantiated as this list:

• Ernest Hemingway
• Scott Fitzgerald

KiTE templates can be placed in

<script type="text/x-kite">
  ...
</script>

sections on the page so they will not polute JavaScript code.

You can use this document http://terrainformatica.com/kite/test-kite.htm to get a feeling of the KiTE templates.

Idea behind KiTE implementation, defintion of TDL and the kite() function are all explained here code.google.com/p/kite/

And the last: the name "KiTE" is acronym of "KiTE is a Template Engine".

Behaviors as an entity is a declarative way to assign/bind scripting methods to DOM elements.

We can think that browsers have following declarations in their default CSS declarations:

input[type=text]   { binding: TextEditorImpl; }
input[type=button] { binding: ButtonImpl; }
select             { binding: SelectImpl; }
...

So when we define <input type="text" /> in our markup we declare that the element will behave as a text editor – it will have set of all needed methods and will generate all associated events.  

It would be nice if in script we would be able to define our own behaviors for classes of DOM elements too.

As an example: blog article may have hyperlinks inside and particular blog engine may require some special behavior/reaction assigned to all hyperlinks in the article. Ideally such declaration should like this:

#content div.article a[href][title]
{
  color: orange; // ui style
  behavior: LinkWithSmartTooltip; // behavioral style
}

In Sciter [1] that is an embeddable HTML/CSS/TIScript engine I have a luxury to step beyond W3C specifications so I’ve implemented the Behaviors in the way as I think they should be:

Behaviors in the Sciter engine

I have added the prototype attribute to my implementation of CSS:

some-CSS-selector
{
   prototype: SomeBehaviorClass [ url(of a script file) ];
   ...
}

When the engine assignes CSS styles to elements it also tries to find class named SomeBehaviorClass. If such class is found then the element gets "subclassed" by the class. Technically the subclassing means that for all DOM elements that satisfy some-CSS-selector both these statements are true:

element instanceof SomeBehaviorClass;
element instanceof Element; // Element is a super class of all DOM elements.

The SomeBehaviorClass looks in TIScript like this:

class SomeBehaviorClass: Behavior
{
   function attached() {} // constructor, sort of
   ...
}

The attached method plays a role of a constructor function in realm of Behaviors. It is called when particular element gets the behavior with this variable referring to the element. All this is I would say is pretty human readable an transparent.

Ok, back to the reality of the Web. Below is my attempt to define similar functionality using jQuery:

Behaviors for conventional browsers,  jQuery extension.

First of all here is my initial implementation of the behavior functionality: jquery-behaviors.js. It is pretty simple – near 75 lines of code.

It allows to declare behaviors on elements by using (a) class DOM attribute like this (purely in markup):

<span class="behavior uix-slider" />
<input class="behavior uix-date" />

and/or by (b) declaration of selector rules in script code:

$.behaviors.selector("ul.ext-list > li", MyExtListItem );

Later case allows to add behaviors non-intrusively – to any existing markup.

The Behaviors implementation above introduces three methods:

1. $.behaviors.add( name, behaviorObj ) – add named behavior that can be used in "a" case above – in class names.
2. $.behaviors.selector( selectorStr, behaviorObj ) – add "CSS selector -> behavior" association – case (b) above.
3. $.fn.behaviors() – that is a plug-in that extends jQuery object wrapping set of elements. It used after calls of DOM mutating methods to assign behaviors to DOM elements:
   $("#update-panel").html("....").behaviors();

The behaviorObj above is the behavior implementation per se. It is a plain JavaScript object that defines set of methods and properties that will be mixed into the DOM element property map.

Here is a typical structure of some behavior named "x-checkbox" (see it’s demo here …) :

$.behaviors.add( "x-checkbox",
{
  $attached: function(params) { ... },
  $value: function(v) { ... },
  $clear: function() { ... }
});

Function $attached here has special meaning – it gets called by the Behaviors engine when the element gets this behavior attached. The params here is a parsed version of the params DOM attribute that allows to parametrize instance of the behavior for the element. For example particular instances of a slider may have different initial settings:

<span id="first" class="behavior uix-slider"
     params="min:0, max:100, values:[15,50]" />
<span id="second" class="behavior uix-slider"
     params="min:10, max:200, value:50" />

Input behaviors, concept of the value. The "x-form" behavior.

In principle there are two distinct types of behaviors:

• input behaviors – behaviors of elements that have a concept of the value. Input elements have at least these two methods:
• method $value(v) – getter/setter of the value.
• method $clear() – clear the value – revert it to the initial, markup declared state.
• UI behaviors – behaviors implementing various UI effects like "click here – expand/collapse there".

The $value and $clear methods are used by the x-form behavior for gathering and setting values of input elements it contains. The x-form element is by itself is an input element (compound one). Its value is a map of name/value pairs – values of standard inputs and elements that have input behaviors attached. Behavior x-form can be assigned to any container that has inputs and call of its method $("#my-form")[0].$value() will give collection of values that are e.g. ready to be send over the AJAX.

The x-form and individual input behaviors may also implement concept of $validate() – that is not implemented yet but planned.

Demos

Here is couple of demonstrations of the approach:

• jq-ui.htm – demo of jQuery-UI widgets wrapped into input and UI behaviors (implementation: jquery-ui-behaviors.js).  Also demonstrates use of x-form to gather/set/clear form data and dynamic html loading with behavior assignment.
• std-behaviors.htm – purely declarative sample. Demonstrates x-checkbox behavior – is a input and UI element that can be bound declaratively with show/hide of "buddy" elements. Uses std-behaviors.js – implementation of the x-form and x-checkbox.

References

1. The Sciter – an embeddable HTML/CSS/Scripting engine;
2. TIScript language – JavaScript++ if you wish. Used in Sciter.
3. Behaviors in Sciter, part I, part II and part III

One of differences of TIScript from JavaScript is that it has classes and namespaces.

Declaration of a class in source code looks like this:

class Baz
{
  function foo() { ... }
  property bar(v) { ... }
  // ... other functions, properties, variables,
  // constants and decorator calls ...
}

As you see class declartion in TIScript is pretty similar to the ones in Java or in C++. The only difference is that in TIScript class declaration is an executable (in runtime) entity. While parsing the class declaration above the compiler produces bytecode that is equivalent of this:

const Baz = new Class();
      Baz.foo = function() { .... }
      Baz.bar = property(v) { .... }
...

So while loading bytecodes produced by the compiler TIScript VM will execute sequence of commands to build such class object.

As class construction is an executable chunk of code then in principle we can modify/synthesize class declarations in runtime. And decorators in TIScript are just about this – they allow to execute decorator functions in context of class that is being declared.

Decorator is an ordinary function with the name starting from ‘@’ character. It should have at least one parameter that will receive reference to the object being decorated.

Example of the decorator function, the @returns decorator creates proxy function around call of declarating function and verifies its return value:

function @returns(func, returnType)
{
   return function(params..)
   {
      var r = func.apply(this,params);
      assert typeof r == returnType;
      return r;
   }
}

Having such decorator in place we can declare methods of classes with checks of their return values:

class Zum
{
   @returns #integer
     function Add(i1,i2) {...}
}

The @returns #int function()...  here is a decorator function invocation. Under the hood all this will produce following code:

const Zum = new Class();
      Zum.Add = @returns( function(i1,i2) {...}, #integer );

Call of the @returns() creates proxy for its parameter function. The result (the proxy function) will be assigned to the Add field of the class object. As you may see decorators are pretty much syntax sugar that if properly used may increase expressiveness of your code a lot.

The this environment variable inside the decorator function is getting reference to the context object of the decorator call. E.g. inside class declaration this inside decorator function body will contain reference to the class object.

TIScript supports three types of decorators in total:

1. Function decorators:  @decorator [...params..] function() { ... }
2. Class (or namespace) decorators: @decorator [...params..] class { ... }
3. Empty decorators: @decorator [...params..] ;

Last one – empty decorator – is used in cases when it is a need to synthesize some properties or functions.

Here is practical example of empty decorators used to declare events in class VGrid (Sciter SDK/samples/ideas/virtual-grid/. Virtual Grid is created by Dmitrii Yakimov from http://activekitten.com).

class VGrid: Behavior
{
    const BUF_ROWS = 64;
    ...

   // Events supported by VGrid instances:

   // onCurrentRowChanged( this_grid, row )
   @DECLARE_EVENT #onCurrentRowChanged;

   // onHeaderClick( this_grid, evt, colNo, th )
   @DECLARE_EVENT #onHeaderClick;

   // onCellClick( this_grid, evt, colNo, rowNo, td)
   @DECLARE_EVENT #onCellClick;

   // onRowClick( this_grid, evt, rowNo, tr)
   @DECLARE_EVENT #onRowClick;
}

Each @DECLARE_EVENT eventName; decorator call here creates in the class these three fields:

• property eventName(v) – that represents list of event handlers assigned to the grid instance by users of the class,
• function notify_eventName() – function used internally by the class to "raise the event" and
• var _eventName = [] – variable that holds a list (array) of event handlers (functions) attached to the event by users of the grid.

And here is the implementation of the @DECLARE_EVENT decorator function:

function @DECLARE_EVENT(dummy, eventName)
{
  // create symbols for the fields:
  var notify_sym = symbol( "notify_" + eventName.toString());
  var list_sym = symbol( "_" + eventName.toString());
  var prop_sym = eventName;

  // generate 'notify_' function:
  this[ notify_sym ] = // 'this' here is a class being decorated
    function(params..)
    {
      // 'this' here is VGrid *instance*
      var list = this[list_sym];
      if(typeof list == #array)
      {
        // invoke each function in subscriptions list:
        for( var f in list )
          f.apply(this, this, params); // always pass 'this' in the
                                       // first param - source element
      }
    }
  // adding property  that allows to push
  this[prop_sym] = // 'this' here is a class being decorated,
                   // generating computable property for it.
    property(v)
    {
      get { return this[list_sym] || (this[list_sym] = []); }
      set { throw String.$(Use element.{ list_sym }.push(func)
                                             to subscribe to this event); }
    }
}

The decorator function above is a bit cryptic but defintions like:

@DECLARE_EVENT #onCurrentRowChanged;
@DECLARE_EVENT #onHeaderClick;
...

allow to declare and see the whole event set in compact and convenient form.

As we know parameters of functions are passed by value in languages like TIScript and JavaScript. Inside the function we can modify paramaters and their new values will not be seen outside the function.

Let’s say we need to implement function expand(rect, dx, dy) : rect that should increase dimensions of the rectangle.

If the rect is an object then we will write something like this:

function expand(rect, dx, dy)
{
   return {
     x: rect.x - dx,
     y: rect.y - dy,
     w: rect.w + 2*dx,
     h: rect.h + 2*dy };
}

Problem with this implementation: it allocates brand new object on each call. That is not desirable if the function is used frequently.

If TIScript would support pass-by-reference for parameters then this function will have signature like this: inset(&x, &y, &w, &h, dx, dy) but no such thing as pass-by-reference in JS and TIScript for many good reasons.

As a solution: in TIScript we can use so called multi-return and multi-assignment feature – function is allowed to return multiple values.

Using this feature we can rewrite our function as:

function expand( x, y, w, h , dx, dy)
{
   return ( rect.x - dx, rect.y - dy, rect.w + 2*dx, rect.h + 2*dy );
          // returns "list" or tuple if you wish of four values.
}

To call such function and to get multiple values from it we will use list of values as an l-value expression:

var x = 10, y = 10, w = 100, h = 100;
(x,y,w,h) = expand(x,y,w,h, 20, 20 );

Parameters and return values are passed using stack of the VM so this will not create additional payload for the heap manager.

And yet it is pretty convenient for other cases too. For example this:

var a = 10, b = 5;
(a,b) = (b,a);

is how you can swap values of two variables.

Small feature but quite usefull.

Main challenge was to plug value lists into existing syntax of JavaScript. Implementation is quite simple.

Motivation.

Tasks of defining string expressions and textual fragments in script code are pretty common.

Typical example in JS/browser is:

someelement.innerHTML = 
   "<span style=\"color:#ffffff\">" + somestuff + "</span>";

As you see this could be quite noisy and complex to be comprehensible by human.

Various scripting languages are trying to reduce syntax noise in various ways. Scala for example allows to define XML literals http://programming-scala.labs.oreilly.com/ch10.html inline without need of "mangling" it by quotes. This feature appears as quite neat but is limited by XML only. E.g. it will not work for HTML ("HTML is not XML"™) or for things like CSS selectors, etc.

Another example is string templates in Ruby. They allow to define string literals with embedded code:

template = 'Dear #{customer},\nPlease pay us #{amount} now.\n'

but this still needs string literal. One more problem with such approach: various types of strings need different escapement rules applied to values being embedded in the string. E.g. for HTML it should be String.htmlEscape() call, for URLs – String.urlEscape(), etc.

So there is a need to have some syntax construction that will allow to define various ways to define string compostions.

Solution.

As a solution I’ve implemented in TIScript so called stringizer functions.

Stringizer function is a function (or method) with the name starting from ‘$’ character and with variable number of parameters.

Call of such function is written in the form:

$name( ... some text here... )

Where the text inside ‘(‘ and ‘)’ is not required to be enclosed in quotes. Characters ‘(‘ and ‘)’ are serving role of quotes by themselves.

Example of such stringizer call:

var firstDiv = self.$( #content > div:first-child );

$ here a stringizer method that accepts CSS selector expressions. The sample above is a direct equivalent of this:

var firstDiv = self.select( "#content > div:first-child" );

Text inside ‘(‘ and ‘)’ may contain expressions enclosed in curly brackets ‘{‘ and ‘}’. Result of the expression in such brackets will be passed into the stringizer function as is.

Having all this in place the very first example of the article can be written in Sciter simply as:

someelement.html
    = $html( <span style="color:#ffffff">{ somestuff }</span> );

TIScript will de facto compile this call as:

someelement.html
    = $html( "<span style="color:#ffffff">",
               somestuff,
               "</span>" );

The only thing left is an implementation of the $html() function that we can define like this:

function $html(params..)
{
  for( var (n,v) in params )
    if( n & 1 ) // each odd paramter is a
                    // value of expression inside '{' and '}'
      params[n] = v.toHtmlString(); // calling method
                    // that will do HTML escapement
  return params.join(""); //return composed string
}

Some ideas

Here are some ideas for such stringizer functions we can use in the Sciter:

• function Element.$append( ... inline html ... ) – method of the DOM element class – appends the html after last child of the element.
• function Element.$prepend( ... inline html ... ) – prepends the html before first child of the element.
• function $text( ... some text ... ) – simple way of composing texts.
• function Stream.$print(... some text ... ) – simply prints text with possible { } inclusions.
• function $xml( ... some xml... ) – to compose XML string and create XML tree using built-in XML parser.
• you name it…