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
[...] Querna wrote a fun little Apache module called mod_v8 that offers a proof of concept of Yet Another Server Side [...]
[...] 消息來源是這裡，這位老兄之前玩過 Rhino（Mozilla 專案下的用 Java 寫成的 JavaScript 引擎）之後有成功運用 Rhino 弄了 server-side 的 JavaScript 引擎（成果在此），後來 V8 的出現之後，他就努力地想把 V8 搬到伺服器上，所以他宣稱目前 mod_v8 可以在 httpd 2.4 上執行，未來等到他完成一些文件之後，其它人也可以拿到機器上 build 玩玩看。 [...]
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.
[...] cliente, es decir que se ejecuta en el navegador del visitante. Pero parece que ahora el autor del mod _v8 busca que javascript se pueda utilizar como lenguaje de servidor, como otros lenguajes ya conocidos [...]
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.