By Simon Willison

JavaScript and domain specific languages

By Simon Willison

I recently stumbled across a group of interesting JavaScript projects by Steve Yen: JavaScript Templates, TrimQuery and TrimSpreadsheet. The first is a JavaScript templating engine, similar to PHP’s Smarty. I was initially unconvinced by the wisdom of client-side templates, but Steve has a well considered blog entry in which he defends the idea in light of the increasing complexity of web applications. As an alternative to manually gluing strings together it’s likely to become a valuable tool.

TrimQuery and TrimSpreadsheet are even more interesting: the former is a SQL style data query language for interrogating JavaScript data structures, again designed to help build complex web applications, while the latter is a full Spreadsheet implementation in just 1700 lines of code.

All three projects are part of a wider exploration involving using JavaScript for domain specific languages. A domain specific language is a language which is designed to target a specific problem, such as SQL for processing relational data structures or regular expressions for matching patterns in text. Steve points out that JavaScript is well suited for implementing such mini-languages thanks to the little-used and much-maligned ‘eval’ and ‘with’ keywords. Here’s a neat example from TrimPath that uses ‘with’:

var queryLang = TrimPath.makeQueryLang(tableColumnDefinitions);
with (queryLang) {
stmt = SELECT(X.a.AS("Foo"), Y.ALL,

Steve’s code is well written and open-source; it’s well worth exploring.

  • sil

    Blimey. The templating stuff sounds cool. I’m less convinced by the minilang idea, since the SQL example given is a bit contrived, but I do like the idea of client-side templating, since with Ajax/remotescripting in play, the client *is* the server. People are experimenting with the best way to pass data back and forth — pass eval()able JS, pass XML and then parse it with a DOM clientside, pass formatted HTML to be slammed into the document. This is much the same as server-side things were, and templating is a good match there, so I see no reason why it wouldn’t be so on the client as well.

  • pd

    and the point of processing data on the client that inevitably needs to come from the server is?

  • People often mention the DOM as the Drudgery Object Model. Combine that with Model-View-Confusion, and it’s easy to miss the whole point of what an application interface is supposed to be doing.

    The traditional hypertext model of the server delivering a document to the browser is still as relevant as ever, but for some reason it is usually assumed that the more data intensive an application, the more work is required on the server.

    If we turn this idea on its head – the data has to come from the server, but the reason to emphasise processing on the client, is when the interface needs to wrap and manipulate that data as directly as possible (or: the interface is the data – the spreadsheet case being the best example).

    Steve Yen’s arguments are pretty convincing – but I think there is always going to be a question of where to draw the separation between client and server.

  • Alex Kapranoff

    “The point of processing data on the client that inevitably needs to come from the server” is that we now can send the data QUICKLY. Most of Google Suggest responses fit into a single IP packet.

  • Patrick Schriner

    Javascript has an even rarer construct that makes it even better:
    try – catch blocks
    I only found out a couple of weeks ago (allthough I

  • nico

    “and the point of processing data on the client that inevitably needs to come from the server is?”

    eheh… probably you would have a different opinion now, having seen google spreadsheets :)

Get the latest in JavaScript, once a week, for free.