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.
Example
HTML:
Usage
JAVASCRIPT:
-
-
var compiler = new EjsCompiler(ejs);
-
compiler.compile();
-
var compiled = eval(compiler.out);
-
Related Content:
3.2 rating from 25 votes
Just another javascript template engine? Lately there are already hunderds of it…
Yeah but does it work offline? I’m only interested in the internet if I don’t have to connect to it ;)
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.
@stu – It doesn’t use any Ajax, so it will work offline.
man .. this is ugly!!
Agreed, could be made a little prettier, the closing [% }); %] reminds me of the evils of java scriptlets in JSPs. Nevertheless, good work.
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
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.
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.
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.)
Yeah…what Scott said…
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?
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
does not look so bad .. but why does one have to integrate the whole prototype lib and not just the needed functions from it?
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.
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!