Tuesday, June 5th, 2007

EJS: Embedded JavaScript Client Side Preprocessor

Category: JavaScript, Library

As we develop richer and richer applications in the client-side logic, we inevitably run into the short-coming of HTML inside of JavaScript.

Edward Benson has created EJS, a port of Ruby’s Erb to the client side.


  1. [% var title = "Items to buy!"; %]
  2. <h4>[%= title %]</h4>
  3. <ul>
  4. [% ['cupcake', 'hardware'].each(function(item) { %]
  5. <li>[%= item %]</li>
  7. [% }); %]
  8. </ul>



  1. var compiler = new EjsCompiler(ejs);
  2. compiler.compile();
  3. var compiled = eval(compiler.out);

Posted by Dion Almaer at 7:54 am

3.2 rating from 30 votes


Comments feed TrackBack URI

Just another javascript template engine? Lately there are already hunderds of it…

Comment by Diego — June 5, 2007

Yeah but does it work offline? I’m only interested in the internet if I don’t have to connect to it ;)

Comment by stu — June 5, 2007

another template engine indeed. I guess we all should think about what do we do that are different than others? that really will help out the users quickly get up to speed.

Comment by Liming Xu — June 5, 2007

@stu – It doesn’t use any Ajax, so it will work offline.

Comment by Frederic — June 5, 2007

man .. this is ugly!!

Comment by himself — June 5, 2007

Agreed, could be made a little prettier, the closing [% }); %] reminds me of the evils of java scriptlets in JSPs. Nevertheless, good work.

Comment by stu — June 5, 2007

I kinda like it. In fact, if there was a JSTL like “tag” library that work with JavaScript, it would be really hot. I’ve used that in a Java site we did and it was hot. None of this

Comment by Jason Kichline — June 5, 2007

Heh — the tag choice *is* ugly. But every other character that came in opening/closing pairs seemed to be somehow taken or off-limits. I didn’t realize JS templating engines were so commonplace when I submitted this story– JavaScript Templates in particular (http://code.google.com/p/trimpath/wiki/JavaScriptTemplates) seems to be very well developed, but a different, more Velocity-like, approach than EJS.

Comment by Edward — June 5, 2007

When a template is served it can be compiled into JavaScript before it is sent out to the browser.

So a template file myTitle.jhtml

[%= title %]

is compiled server-side into

function myTitle(obj) {
return ”+obj.title+”;

Now serve this JavaScript to the browser. There is no need to send the template interpreting engine to the browser.

I believe this is what Perl’s Template::Toolkit does even when used server-side. It first compiles from the template to Perl just once and then uses the compiled version many times after for faster page rendering.

Comment by Peter Michaux — June 5, 2007

A rant/request, if you will: Please keep important information and data in HTML where it belongs and performs best, rather than creating or serving it via Javascript; search engines, accessibility agents and the internets in general will thank you. :)

(IMHO, you shouldn’t be using Javascript to create “core” HTML content on the client for numerous reasons, performance and otherwise.)

Comment by Scott Schiller — June 5, 2007

Yeah…what Scott said…

Comment by Michael Jackson — June 5, 2007

the server has no business creating a client side representation (HTML). the path to usable sites is not adding CSS3 to lynx, its providing everything as ATOM/RDF. it will be much easier for search engines to switch to using this data, than it was for them to get good at gleaning semantics out of HTML (which they still suck at)

now why the obsession with hacking subsets of javascript into custom/nonstandard DOM element attrs, or this sprintf/custom-parser style mix and match hell. people like unreadability?

Comment by ix — June 5, 2007

I’ve been trying to figure out for about a month now why anybody would ever use such a waste of bandwidth and cpu. It just struck me… the same reason that I switched from perl to php and java/jsp so many years ago. The answer, WYSIWYG using designers. Javscript coders are finally becoming sophisticated enough that they have to dumb down what they are doing for the Dreamweaver users of the world. Y

Comment by Vance Dubberly — June 5, 2007

does not look so bad .. but why does one have to integrate the whole prototype lib and not just the needed functions from it?

Comment by MP:Schorsch — June 6, 2007

So we have re-created the server-side component of the web on the client side. But tell me, where is the data that will populate the client-side template come from – the server?
The internet will eat itself, I promise.

Comment by Dan — June 6, 2007

Why all these template languages / frameworks? XSLT will do this faster, with much less code, and in a more understandable format on any browser created since IE 6!

Comment by John Hann — June 6, 2007

Leave a comment

You must be logged in to post a comment.