After using Rhino for server side javascript at work, I can say I somewhat like server side javascript. Others like Steve were already convinced a long time ago.
However, I don’t really like being tied into the whole Java world because of it.
When Google released their v8 Javascript Engine earlier this year, I always wanted to build an Apache Module for it.
This afternoon I had some time, and so I created mod_v8.
It doesn’t do much beyond a Hello World right now, but it is as simple as this:
ap.write("Hello World!");
I’m not sure if I will spend time making it a proper project, I really want to spend more time on making httpd 2.4 before getting too distracted with shiny things….
Awesome. I hope this turns out into a solid project
Pingback: Ajaxian » mod_v8: Another Server Side JavaScript
Pingback: mod_v8: 伺服器端的 JavaScript 引擎 @ 國二學生認真打雜
Cool! That was pretty easy to get going on a Linux machine. What’s left? Exposing the apache request_rec as a JS object would take it much farther.
V8 is really amazing to work with. I modified the provided shell to accept shebang notation and read and write files in less than a day. My goal is to add support for “include” and “require” so that scripts run in isolated namespaces, as with modules in Chiron, so that the standard library I’m building can be used both server and client side. Ultimately, I think that these projects need to be about writing AJAX features once, not twice nor in different languages, for the server and client.
I attended Steve Yegge’s talk at Google IO. I believe, since he’s made extensions to Rhino that definitely don’t work on the client side, that the primary interest in JavaScript on the server is to provide a better balance between quick and easy fringe features and robust and hard features. That’s a good point, but not as painful and obvious in systems where both the server and client are in dynamic languages. I think that the goal should be portability and sharing code with no necessary modification.
Interesting idea! Have you thought about Ejscript in lieu of V8? They were represented on the ES4 board (as was Google) before it got disbanded but are continuing down that path. It’s basically ActionScript 3 if you’re familiar with it (in my opinion the best parts of both Java and JavaScript) sans Adobe and also implemented in C.
My bad looks like they’ve done that already!!
The downside with EJScript is their incompliance with EcmaScript-262, which means no prototypal inheritance. Without PI ES is just another Classic OOP language with syntactic sugar.
Pingback: Javascript como lenguaje de servidor — edgar.js weblog
This is really exciting and I do hope that viable SSJS comes to us all in 2009.
Tie it into the multitudes of already available FOSS libraries (database, graphics libraries, etc..) and what more does anyone need?!
Cool. I use Microsoft JScript and ASP on a site, and it’s very handy to use the same language on both the client and server side. For example, the same JSON.js file works on both sides. Mentally it’s a lot less taxing to switch between the two languages.
Those of you interesting in running javascript on the server with libraries for database and other io can take a look at JSEXT or perhaps helma
Even modjs
Quick update on Ejscript. We are adding full ECMAScript 3.1 compatibility and plan to release early this year. We’ve focussed on getting the basics working (VM, Module loader, compiler and system library) and getting it working in some web servers for server side Javascript.
What is being added now is prototype inheritance and quite few compatibility issues. We plan to pass the Mozilla SpiderMonkey test suites and the SunSpider benchmarks. Then you can have your cake and eat it too — either class based or prototype based inheritance.
I should also add that we’ve got an early prototype of a mod_ejs working for running Ejscript server side also. I’ll post more when it is available.
how to build it?
scons: done reading SConscript files.
scons: Building targets …
g++ -o libmod_v8.so -pthread -shared mod_v8.os -L/home/work/tools/v8/lib -lm -lv8
/usr/bin/ld: skipping incompatible /usr/local/lib/libv8.a when searching for -lv8
/usr/bin/ld: cannot find -lv8
collect2: ld returned 1 exit status
scons: *** [libmod_v8.so] Error 1
scons: building terminated because of errors.
Javascript on the back-end is good. I have it integrated into a wiki (jspwiki.org) for several years. Having this integration allows for easy inclusion of data from RESTful and SOAP api. The true advantage of Java is that it is simple to use any of the rich set of class libraries just by dropping the jar archive into the class path.
I like the lightness of using Apache. I don’t know how v8 enables dynamic linking of external libraries. Something to explore.
Hey, your svn host has been down the last two days.
http://code.google.com/p/v8cgi/ seems to do the same thing as this, but a little more fleshed out.
Pingback: Drinking the Node.js Kool-Aid « Paul's Journal