Need a distraction? Check out J4P5;
J4P5 is a JavaScript interpreter written in PHP 5, that allows to run untrusted scripts in a sandbox on your server. It aims to implement most of Ecma-262 3d edition.
I kid you not. In fact this looks like a pretty serious attempt. You’ll need to download and run yourself. There’s grammar rules for Javascript in there and a Javascript runtime written in PHP. It passes the “it works” test – the examples run straight out of $ unzip. Looking at what it does and the TODO list, aside from the Unicode issue strikes me J4P5 is already more than 50% of the way there.
Aside from novelty, one real world use might be an extension to SimpleTest’s web testing capabilities. With a little work there’s also potential to create an awesome Javascript source compressor – the lexing patterns are all there.
Need yet more distraction? Try metaphp from which J4P5 got it’s parser generator. Quite what metaphp was (is?) trying to achieve I’m not sure – seems to be attempting to build a higher level language on top of PHP with some ORM and functional programming in there for good measure (the FP stuff in the download is pretty interesting). Anyway – it produced a parser generator good enough implement a Javascript parser.
Anyone for R4P5? ;)
Related posts:
- Google Releases its JavaScript Closure Tools Do we need more JavaScript libraries and tools? Perhaps not,...
- Cross-browser JSON Serialization in JavaScript JSON serialization can be incredibly useful, but few browsers support...
- Server-side JavaScript Will Be as Common as PHP Despite the fact that JavaScript has been typecast as the...
- Will Server-Side JavaScript ever catch on? Server-side JavaScript appears to be a logical choice for web...
- Implementing Event Latency in JavaScript Craig provides some useful JavaScript code to slow down event...
I was JUST thinking of how cool it would be to have JavaScript on the server.
The way I see it is you could run the code on the client, but if JS is disabled, it can use the same code on the server only with pageloads.
I don’t think I’m going to make attempt at this, even now seeing J4P5, but I think it’d be cool if implemented properly. (Or if someone released a library that handled the intermediate is-it-local or not, making it effectively JUST writing a client-side program and going from there.)
January 19th, 2006 at 10:06 pm
FWIW, there is also an experimental PHP module that wraps mozilla’s spidermonkey: http://www.aurore.net/projects/php-js/
For someonewhois, you might be interested in whitebeam: http://whitebeam.org/about.rhtm
January 19th, 2006 at 11:04 pm
huh? My brain is just about to take a dump.
January 20th, 2006 at 3:49 am
Thanks – wasn’t aware of that. Had seen Omar’s json extension. Great that he’s now working on embedding spidermonkey.
Think that’s what this does – http://trimpath.com/project/wiki/TrimJunction – on the server it’s Java’s Rhino Javascript interpreter.
January 20th, 2006 at 4:31 am
How about UTF-8 support?
January 20th, 2006 at 5:13 am
Paul Sowden’s already got a Ruby JavaScript parser going: http://idontsmoke.co.uk/2005/rbnarcissus/
It doesn’t execute the parse tree yet though.
January 20th, 2006 at 5:25 am
So was I.
January 20th, 2006 at 8:52 am
Javascript is quickly gaining ground as the ubiquitous platform for client-side web application development. If I may echo a common sentiment here, having it on the server would be awesome.
For developers to be able to harness the same language for both client and server side coding would be something of a dream, especially such a great language as Javascript. I imagine this could result in greater proficiency as developers would no longer have to divide their attention between two sets of syntax.
I have done only one project in Java but even that was close enough that it awoke me to the potential of unifying the web developer’s toolkit on both server and client.
January 20th, 2006 at 4:00 pm
I personally would like to see a client-side implementation of php.
January 20th, 2006 at 4:17 pm
Client side PHP syntax etc, even if it was a plugin (;]) to start with, and maybe get it shipped with the fox.
January 20th, 2006 at 4:43 pm
Had a chance to really look at the code of J4P5 and metaphp – there’s some really amazing stuff there.
Examining J4P5 in detail, there’s actually a lot of potential there. At the moment it suffers (performance wise) from translating Javascript into a ton of PHP objects and function calls (these get cached to a PHP script under /tmp/es4php for re-execution, skipping the parse stage). If, instead, it could generate really raw PHP (spagetti, no objects, no function calls, use of whatever GOTO capability PHP is getting), the end effect might be better performance than standard PHP with functions, classes etc. That’s likely to be hard work to implement though. The only real commentary from the author I found on the metaphp mailing list here – whether this is still a live project remains to be seen. It’s also the same developer who did PDML.
Meanwhile metaphp really needs shouting about. The main author I tracked down to here – comment on the navy may explain why things have gone quiet. In one of the metaphp examples, he’s come exceptionally close to writing a parser for PHP in PHP – there’s some amazing work got into that parser generator. Need to do some benchmarks and see how parsers it produces compare with other PHP projects.
January 20th, 2006 at 6:48 pm
You are right, and honestly, I don’t see the point in this. As PHP is itself implemented in C, I think that a much better option — in terms of work required, flexibility and eventual performance — is to bring Javascript to the Web server side through SpiderMonkey directly. Perhaps even as a PHP extension, why not?
It might even be a nice side-project for the guys over at wxJS.
January 20th, 2006 at 6:58 pm
Yes and no. You’re right it’s a lot of work, a very likely to go nowhere. The reasons why it might be interesting to try though are a long discussion which I’m going to avoid right now but two short reasons – spagetti PHP is relatively fast (but unmaintable) – certainly faster than the equivalent OO code. Would be great to be able to convert OO code into spagetti automatically – suggested stuff alot that lines a while back here. But when you start thinking about what’s involved, it almost makes more sense to have “user code” written in a different language. Javascript is fairly well known and less verbose than PHP. Plus given a different language with a “PHP runtime”, you can hide it from all the uglier parts of PHP so users never need to care about them. The main reason to do this in PHP itself is extensibility – if you know C well enough and control the server, sure you could extend a Spidermonkey based runtime or similar. But considering the effort involved, it still might be smarter to use PHP.
January 20th, 2006 at 7:21 pm
I apologize for being so stubborn, but I just don’t see how. With PHP, you have to write a whole parser and interpreter, which is already readily available — with full implementation — as SpiderMonkey. I have no experience in writing PHP extensions, but it seems as much more effort writing a whole interpreter in PHP than a PHP extension wrapper for SpiderMonkey in C…
January 20th, 2006 at 7:33 pm
No problem. I’ll try to give a long answer in another blog soon. Right now perhaps the motive for doing this is best explained by a question:
So lets say you have either a Javascript extension for PHP or mod_js for Apache. People are writing code in Javascript, complete with classes, objects and all kinds of abstractions. This get’s fed into Spidermonkey and executed. The problem is though, all those abstractions will have a similar performance overhead to writing well abstracted PHP. Spidermonkey has to resolve them as it’s executing – many hash table lookups, call stacks to manage and so on. So how are you going to improve performance?
What I’m talking about is an intermediate stage which takes the well abstracted code someone has written and converts it into a single procedural mess, without any abstractions, then passing it the the interpreter. To make that possible you need a design something like WACT’s, with a hierarchy of compile-time classes and objects for generating fast, procedureal the code which will be handed to the interpreter. It’s this hierarchy that I believe would be very painful to attempt in C – I think you need a dynamic language there.
With J4P5, one of the hardest parts has been “done”, more or less. There’s a parser (thanks to metaphp) primed with the syntax and grammar of JS. The other “hard part” is only partly done (and has a slow implementation right now) – turning the syntax tree from the parser into executable code.
January 21st, 2006 at 6:57 am
Spidermonkey is smart enough to allow you to save interpreted code (context), so you can easily add an opcode-cache to it.
IMHO spidermonkey could make for an awesome serverside language. it has much of the same advantages as php, but a much more flexible object-engine. Wrapping spidermonkey in an apache-module is even fairly simple (took me a day or so to figure out on windows, and I’m rather rusty in C++) – The real bonus would be to compile it with XPCOM support (this get’s slightly more complicated), which would mean that performance-critical arts could be implemented in native C++ code, and be accessibly as extensions. There’s even a load of readily available extensions from the browser-project.
January 21st, 2006 at 9:18 pm
To that I have only one question: What the hell are we waiting for?
Can someone (better versed in C than I am, which means just about anyone) start a Sourceforge or even better Tigris project to that goal?
January 21st, 2006 at 9:26 pm
I’m fluent in php and javascript, but my C++ is only slightly better than my german (Well, wirklich seien sie ungefähr gleich). I thought about starting a project, but without some support from some more seasoned C++’ers, I’m pretty sure it would end up as another stranded whale on the beaches of sourceforge.
It’s a shame though – the technology have been available for several years now, and no-one have really picked up on it yet. There’s whitebeam and helma ofcourse, but I they both missed the point. Obviously they come from a java-background, which may explain how they managed to overcomplicate things beyond usability.
January 21st, 2006 at 10:01 pm
Yeah, thought Spidermonkey could operate as an opcode cache. The other method of increasing performance would be to target a JIT VM, which would be pretty straight forward I guess for either Rhino or Mono.
January 22nd, 2006 at 8:11 am
In which way will using an interpreter written in java increase performance ? I may have missed some obvious point here, but java is an interpreted language itself, so it’s magnitudes slover than native code.
Anyway – I wonder how important the performance-issue is anyway. PHP is comparably slower than native code, yet noone have any problems with it’s speed. It’s about the target audience, and since it should be used to render webapplications, not crunch huge batches of data, I don’t think the current speed of spidermonkey is a showstopper.
January 22nd, 2006 at 1:01 pm
Both the interpeter (rhino) & javascript are compiled into java bytecode, and with a good JIT VM.. native code.
Some people say that Rhino can outperform Spidermonkey good Java JIT VMs.
January 22nd, 2006 at 1:28 pm
Do you have some examples? I’m looking for information to start a module that can execute wxJS code. I can’t find many documentation on how to write an apache module.
January 22nd, 2006 at 3:29 pm
Ohmyohmyohmyohmyohmyohmyohmyohmyohmyohmyohmy! I’m so excited… This could actually happen pretty soon.
Then we need to integrate SQLite, and a decent templating engine (I vaguely remember one written in C?), and we can actually whip out a nice little Javascript on… hmmm… I got it!
Javascript on the Road Again! :o)
January 22nd, 2006 at 3:36 pm
Will MySql suffice ?
January 22nd, 2006 at 4:17 pm
Actually, SQLite would suffice; MySQL would be perfect!
But as wxJS ported ODBC in Javascript, the world is our oyster. :) Now we need a port of ADOdb!
January 22nd, 2006 at 4:22 pm
Either I’m missing something or I’ve got lost in all the hype on this.
Why is everyone so concerned about a universal runtime language? Surely a universal “development” language is more what you should be concerned about? Write your code in Javascript/ECMAScript, then compile to target platform, then run the compiled code.
Then you have NO performance issues at all as the performance is exactly what it was before. I think this may have been what Harry was eluding to before. Have different compile output formats, you could target your code for Ruby, ASP, PHP, Java, etc, etc while only maintaining a single code base.
Sure it would be nice to skip the compiling step, but sometimes thinking along the scripting langauge paradigm gets you locked into a certain way of thinking. I’d be more than happy to run a compile command before running my code (especially if it were IDE integrated).
That aside, just picking up on a comment from Harry, is PHP actually getting GOTO support? I tried to create a graphical IDE once using C# to generate the PHP output, but didn’t get very far because of the lack of GOTO support in PHP. Sure it can be an ugly and painful “feature” to debug and follow, but it does solve a few problems that nothing else quite does.
January 22nd, 2006 at 5:54 pm
Fascinating discussion.
For a simple script, no problem. But when you start moving into frameworks, etc, the story can get significantly different, without a lot of care and attention.
And with dynamic languages you can never really reduce everything to the most efficient form as you have things like eval (and in Javascript Function objects) which you never fully know about until they actually happen.
But anyway – wandering off topic.
January 22nd, 2006 at 5:59 pm
For Web development, I don’t think we should care too much about performance. Hardware is cheap these days, much cheaper than developer time.
Or to put it another way: if you have a Web application whose performance seriously threaten your hardware/hosting budget, you’re doing something very wrong. (Like using ASP.NET, for example… ;) )
January 22nd, 2006 at 6:05 pm
Don’t think think PHP would be as popular if had a compilation stage first. Or any language.
There is http://www.morfik.com supposedly common soon, which appears to have some sort of compilation, all looks cool and funky, but until its more than vapourware…
January 22nd, 2006 at 7:26 pm
Regarding Whitebeam – been taking another look and scanning the source. This basically is Apache mod_js.
It’s using the C Spidermonkey engine and if you want to, you could write stuff that looks alot like PHP with it – see here.
The differences (to PHP) that spring out from the docs;
First you have a much more limited API available to call from Javascript than with PHP. It seems they argue this from the point of view of providing a consistent framework with the ability to scale horizontally built-in “by default”. This seems to go to a pretty extreme level – e.g. they’ve only recently provided an API for file access. That said, if you know what you’re doing, I guess you could add XPCOM to this mix.
Second you also have an additional template language, for “code seperation”, which you can optionally use. Markup is “XML sytle” and it has an imperative syntax. The way forms work is interesting – gives the impression of something vaguely similar to XFORMs.
In other words looks like Whitebeam is similar to PHP but provides a higher level view. Perhaps you gain by having to make fewer choices when using it – are you happy with the loss of freedom?
January 23rd, 2006 at 8:42 am
One other thought on the “Javascript Strikes Back” front. I imagine that XPCOM is largely (or perhaps entirely) thread safe. I notice Whitebeam are thinking about this.
May be jumping to the wrong conclusions but that might make it an ideal choice for Apache 2.
As far as I know, none of the current mod_* (mod_php, mod_perl, mod_python etc.) are ideally positioned here. White the code engines are largely thread safe, there’s always some library or other everyone uses a lot which isn’t (e.g. believe PCRE was / is a problem).
January 23rd, 2006 at 8:55 am
I think whitebeam goes to far with proprietary “stuff”, as kyberfabrikken says, completely overcomplicating things.
Just need some classes to communicate with the outside, Request, Response, and Operating System, (filesystem, env vars and what not).. perhaps libxml2, libxslt in there, for few more options of handling xml other than e4x.
Doing AJAX/JSON applications would be soo nice. Especially with spidermonkeys .toSource() method.
January 23rd, 2006 at 11:21 am
I definately think XPCOM is the route to go, if one should make a mod_spidermonkey. Not only is it perfectly suited for cross-platform support, but it also makes it possible to load extensions on demand. Besides, it would make it possible to draw on all the extensions already available for the mozilla project.
On a side-note, it may seem that the difference in performance between spidermonkey and rhino isn’t exactly as I would have expected. This makes mod_gcj/rhinola a much more viable candidate for an mod_js. This ofcourse makes Java the natural choice for extensions, rather than native code, wrapped in XPCOM. I’m not really sure if that’s a good or a bad thing, although I think I would favor XPCOM of the two.
January 23rd, 2006 at 12:05 pm
Spidermonkey has LiveConnect ofcourse for a Java bridge, doesn’t appear to be a XPConnect equivalent for Rhino tho.
January 23rd, 2006 at 2:58 pm
I think this is all fun, but I don’t fully “get it”. As client capabilites expand (ie: ubiquitous JS support, better local services) I can imagine that the client application code will increasingly be cooridinating and sending simpler requests for pure data — perhaps using REST alone.
So I certainly think that JS on the client remains interesting but we already have more-than-adequate and proven tools to do the server-side processing. Assuming that “in the future” the client centric parts of our controllers/views (and perhaps models) are no longer dealt with at the server, what would mod_js buy us over mod_php? Is it just too late to do JS at the server at this point?
January 23rd, 2006 at 3:04 pm
Not much — just the ability to develop in one of the best kanguages available today.
January 23rd, 2006 at 3:21 pm
Actually, with AJAX it would be nice to develop using the same language on the server and the client. Easier to pass JSON (Javascript) objects back and forth, etc.
January 23rd, 2006 at 4:16 pm
I agree that JS is a great language but my question remains — how many of its “cool” features will really be indespensible at the server when the client is doing most of the work anyhow? It seems far more trivial to use a JSON serializer/deserializer than to implement/test/debug/support an entire new stack across multiple platforms. This doesn’t even address the unknowns of using JS at the server — some might argue that it is far too loose/forgiving of a language to trust at the server.
I’m not trying to pour cold water on this idea because I do think it is interesting. Then again, I’ve never been a one-language-to-rule-them-all sort of thinker. That said, if there is a language I would consider as a replacement for PHP it is likely Javascript — but only if the rest of the stack was in-place and as mature.
January 23rd, 2006 at 4:43 pm
Same here, and that’s exactly why I like the idea. Of course mod_js would not replace PHP and other server-side technologies — but having another option, and with one of the best languages I ever used, is enough to make me excited.
January 23rd, 2006 at 5:02 pm
I think Perl 6’s use of Parrot JIT bytecode compiler will throw open doors of opportunity to a lot of languages. (would love to link but all the servers were down at the time this was posted – please see http://parrotcode.org)
I cannot imagine Zend will ever allow PHP to make use of Parrot and I think it will be a while before anyone can wrest enough control from Zend to even raise the question.
But if there were a Javascript implementation you have to think the performance could be extremely favourable to server side implementations.
January 23rd, 2006 at 8:35 pm
JS on the server has been around for ages. Netscape iPlanet and IIS have both supported it for years. So its not exactly an unknown quantity. And imo, definately more known than Ruby or Python.
JSON serializer/deserializer doesnt transfer code. And for things like validation which has to performed on the server, and which is nice to run on the client too, you’ve less to write.
January 23rd, 2006 at 9:00 pm
[...] http://www.sitepoint.com/blogs/category/php/feed/ [...]
January 23rd, 2006 at 9:26 pm
oh gosh! looks like my small brain can’t comprehend this … so is it like you write javascript on the server side and it gets converted to php or is it like the js gets executed on the server (whats the point, why would i use php then?). Ummmm someone … explain this in a nutshell for me please
January 24th, 2006 at 3:00 am
I don’t understand, sorry. Javascript is a client side script, that detects events. How can you detect events server side? I already detect events and send a query to php/asp via javascript, getting the server to respond with a javascript output. But the query is created client side on event. You can’t create the query server side as the server can’t detect events.
Or am I missing something?
January 26th, 2006 at 5:20 am
That was by me, didn’t log in…..
January 26th, 2006 at 5:23 am
January 26th, 2006 at 5:24 am
By a long shot. Javascript is a programming language; what you’re talking about is a single, though most known implementation of Javascript.
January 26th, 2006 at 5:27 am
Yeah, for sure. I’ve been writing javascript alot longer than asp/php. But what your talking about can already be done server side. That leaves events, which must be fired client side. I’d like to see an example of what japs can do that server can’t already.
January 26th, 2006 at 5:37 am
First of all, PHP is open source, anyone can do anything they want with it. Secondly, it is a programming language – you’re talking about a particular implementation. In fact, there have been (and may still be) several PHP on Parrot projects. Also, there’s Phalanger, a free (as in beer) PHP-to-.NET cil compiler which implements all of PHP5 and parts of the libraries.
January 27th, 2006 at 9:08 am
[...] BTW, if you want computer science and PHP, take a look at (current favorite bizarre PHP project) J4P5 (a Javascript intepreter written in PHP). Can come up with endless projects of that nature if you’re interested. [...]
February 21st, 2006 at 8:02 pm
ϳɳ˫Ӱչ籾http://www.shuangchuang.com ϳɳ˫ӰƸԱԱ
June 6th, 2006 at 11:55 pm
ȺԱŮԱӰǣ˫ӰӰ籾ϳɳ˫ӰңӰ˾Ӱַhttp://www.shuangchuang.com
June 10th, 2006 at 7:25 pm
ӰݣӰԱӰ籾
ȺԱŮԱӰǣ˫ӰӰ籾ϳɳ˫ӰңӰ˾Ӱַhttp://www.shuangchuang.com
June 11th, 2006 at 6:58 am
Hi! Very interesting! pwlrdefzp
June 12th, 2006 at 5:38 am
˫Ӱ˾ӵרҵĵӰ籾Ӿ籾http://www.shuangchuang.com ӣӰӹ˾ƸӰԱӰݣӰӰ,籾Ӱ˾Ӱ˾ϳɳ˫Ӱң˫ӰչӰ籾ƸŮӰԱ
June 16th, 2006 at 9:05 pm
Ӱ˾http://www.shuangchuang.com ӣӰӹ˾ƸӰԱϳɳ˫Ӱң˫ӰչӰ籾ƸŮӰԱ
Ӱݺ˫Ӱ˾ӵרҵĵӰ籾Ӿ籾ӰӰ,籾Ӱ˾
June 17th, 2006 at 6:39 pm
TkScdxfQaN 5nQ3eY8wCGV GjGfszJX85pTa0
July 6th, 2006 at 11:59 am
Whitebeam (http://www.whitebeam.org/about.rhtm) is *not* from a Java background. I’m not sure which part is over-complicated? Do you mean that it does more than just put SpiderMonkey into an Apache module (which has been said to take a day) and leave the poor programmer to solve all the other problems (session storage, scalability, security, database integration)? Is it overcomplicated because it provides documentation, and so looks like it actually does a lot?
December 3rd, 2006 at 7:25 pm
There are actually a few reasons why the API is more limited than that available in PHP – the major one to be honest is that far fewer people have put effort into adding additional APIs.
The ‘file’ API was indeed added late. Whitebeam is designed to be scalable – meaning that it can run across an array of web-servers with a load-balancer in front. The load-balancer can field page requests to any of the web-servers. If you store information in an operating system ‘file’ then the next request can go to a different server and the file isn’t there. Further, if that server then fails you’ve lost the data completely. It’s generally better to store the file information in a database table which is then accessible by all front-end web servers. Database replication can then also stop you loosing the data if the database server itself fails.
I think there are very many cases where PHP applications do a fine job until they run out of steam on a single server and have to be re-written to work across an array of servers. By originally not providing things like a local file interface temptation wasn’t there to write apps that don’t scale.
Even with the file access in place I’ve never used it for any client applications – I’d basically be shooting myself in the foot.
With respect to templates they are there to make some things simple. Anyone that’s tried to write an arbitrarily deep hierarchical catalogue in SQL knows it’s not easy. Whitebeam lets you do just that and hides all the SQL with some JavaScript calls.
For those that want to though Whitebeam includes a full PostgreSQL interface, SMTP interface, HTTP interface (for SOAP/XML-RPC etc), and of course file system interface.
At a basic level, if you do want to write everything yourself, it’s very much like PHP but using JavaScript.
December 3rd, 2006 at 7:36 pm
Actually the ‘forms’ model referenced is just an XML/JavaScript library one of us wrote early in whitebeam development and we thought we’d make it available to the wide community. It’s not really part of Whitebeam itself – just some contributed code. Whitebeam itself has some calls to get hold of page parameters, headers and other environmental information. The library wraps these in a model. Because Whitebeam lets you write a JavaScript handler for an XML tag – you can build up your own XML syntax for things – which is what this library does. That is you can tell Whitebeam that when it sees a tag called ” it is to run a specified piece of JavaScript.
This page gives an example of writing your own ’searchfor’ tag. Again – it’s something in Whitebeam that, if you just want ot write lots of procedural JavaScript, you don’t use.
Second you also have an additional template language
It’s not a different language – the template functionality is all accessed throigh JavaScript calls. ‘Template’ is a bad name for these – it’s a way for us to provide modular, late bound functionality into Whitebeam.
December 3rd, 2006 at 7:57 pm
You may find this interesting:
http://web.2point1.com/2008/05/09/full-javascript-parser-for-php/
This JavaScript parser is based in a generic parser framework that produces a full parse tree. No download yet, but there will be eventually.
May 10th, 2008 at 7:46 am
Does anyone know of a parser FOR PHP, written in JavaScript?
I’m not looking for a compiler or interpreter, just a parser to add to enable syntax highlight for the CodeMirror JavaScript source code editor.
October 11th, 2008 at 8:25 am
I’m looking for the converse:
Does anyone know of a parser for PHP, written in JavaScript?
I’m trying to add syntax highlight for the JavaScript source code editor Codemirror and wouldn’t want to reinvent the wheel.
October 11th, 2008 at 8:32 am
The more experience I get in php, the more I’m asked to implement some javascript-powered ASP thing in PHP. Sometimes it is fun, sometimes it is just old and boring.
Nothing really big and complicated yet — but it would be nice to be able to just say “Oh you dope, PHP can run that out of the box, Javascript is easy!”
…
And, I guess, with J4P5 I can do exactly that! I must try it out, yay for shortcuts! A great way to learn either language is to make a portage from one to the other! Really! Exclamation marks! There’s nothing I can do in PHP that I can’t do in ECMA-262, I’m dead sure – although I might not know /how/ immediately, and I might need an extension on either side to get the job done…. But that’s why I say it’s a great learning experience.
Dan, take a look at “javascript syntax highlighter” (syntax highlighter on google code), editarea and codepress. None of those met my requirements when I was looking for a javascript alternative to Geshi :( — however they may spill a bit of information you could use to not reinvent the wheel.
December 16th, 2008 at 4:17 am