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,
FROM(X, Y), WHERE(EQ(X.a, Y.a)), ORDER_BY(Foo.ASC)
)
}
Steve’s code is well written and open-source; it’s well worth exploring.
Related posts:
- 11 Domain Name Generators & Search Tools Picking a domain name can be a tiring task, so...
- Cookie-less Session Variables in JavaScript Cookies may be delicious, but they can be clumsy if...
- ICANN Approve International Domain Suffixes Until now, non-English computer users needed to contend with Latin-based...
- Truthy and Falsy: When All is Not Equal in JavaScript Anything in JavaScript can be considered to be either truthy...
- Will Server-Side JavaScript ever catch on? Server-side JavaScript appears to be a logical choice for web...
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.
March 1st, 2005 at 12:54 pm
and the point of processing data on the client that inevitably needs to come from the server is?
March 2nd, 2005 at 10:57 am
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.
March 2nd, 2005 at 6:07 pm
“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.
March 9th, 2005 at 8:37 am
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´ve been working with JS for years), as there are allmost no tutorials or samples that use try-catch.
March 29th, 2005 at 5:23 am
“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 :)
January 30th, 2008 at 2:02 pm