Monday, December 29th, 2008

mod_v8: Another Server Side JavaScript

Category: JavaScript, Server

Paul Querna wrote a fun little Apache module called mod_v8 that offers a proof of concept of Yet Another Server Side JavaScript:

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….

Having an Apache module that “was just there” would be big for SSJS. V8 is great, but we would also need a really good standard library that would allow us to do things (Rhino can tie into Java, Jaxer ties into Mozilla, Java, and its own APIs, etc).

Paul also posted on how mod_lua is now in Apache trunk.

Posted by Dion Almaer at 6:07 am

3.8 rating from 17 votes


Comments feed TrackBack URI

I cannot wait for a Mozilla project called mod_tracemonkey. Meanwhile,
this is good news too.

Comment by Amenthes — December 29, 2008

Aptana Jaxer also runs as an Apache module (mod_jaxer) providing not only server-side JS, but also server-side DOM manipulation that other SSJS environments do not (Jaxer can do this becuase it embeds the whole Mozilla browser engine in the server, not just the JS part).

Comment by khakman2 — December 29, 2008

Is Jaxer using Trace Monkey for its js engine?

Comment by KKFC — December 29, 2008


No they are still using SpiderMonkey, but they are working on implementing Trace Monkey

Comment by V1 — December 30, 2008

The key to getting server side JavaScript to take off is awesome API’s.

Why do so many people use PHP even though most would admit that don’t like the language at all?

The API’s.

You can do almost anything with PHP. Files, databases, XML, image manipulation and much more.

If someone were to spend the time exposing into JavaScript (via v8 or trace monkey) all the capability PHP has, you would see that JavaScript program/module raise in popularity a lot.

Someone just needs to do it :)

There are several that have tried to do this, such as Jaxer and others, but they fall down in several places. Either they don’t expose enough (ie, just two or three API’s instead of like 10+) or they execute in Java land or their efforts are directed towards a hosted cloud (read paid) approach instead.

If someone came up with the framework for this, and made it easy for C programmers to create new API’s, I believe it could be a very popular open source project and in 3 years from now we could all be using that for our server side stuff instead of *ick* PHP.

Comment by Sembiance — December 31, 2008


It seems like “they execute in Java land” is a bad thing the way you write it. Why?

Comment by PeterMichaux — January 2, 2009

I do agree, though primarily I believe that the main reason most projects fail is because they try to build in a restricted environment.
Basically instead of building a set of libraries and then letting frameworks evolve out of it people go and build a framework tied to some webserver (Jaxer, Whitebeam, etc…) and then try to build libraries on that framework.

The two key things for making a good /language/ like PHP is a core language, and a good standard library along with the ability to extend that. PHP has it’s core language, the extensive std built into that (though it’s debatable if building it in is a good pattern), and pecl and pear for extending it.
JavaScript is a great core language, but it is missing a good std and extensions onto that.

There actually is a project working on providing libraries though, jslibs. Soubok is focusing on low/med level libraries. The community there seams to agree on a few points though:
– Most libraries actually shouldn’t be stuck implemented in C. TraceMonkey is already fast enough that the tradeoff between doing something in C vs. JS is so little that if you can do it in JS it’s better to just do it there, it makes portability easier and also makes it easier for the JS programmers to improve it.
– and environments like mod_somejssystem for Apache aren’t the way to go. The community agrees that it shouldn’t be tied down to an environment like Apache (there are plenty of reasons to use another webserver, a company might already have ISS established, or someone may prefer using a lightweight server like nginx or lighttpd) so the community has been focused instead on FastCGI.

With that in mind the focus of jslibs is providing those low level layers like jsio (Sockets, File, Directory; It’s NSPR basically) which allow you to write the actual protocol stuff like a HTTP library, right in JavaScript. Since that’s the project’s focus I also started MonkeyScript (codename for now) to extend jslibs with JavaScript libraries and also provide a method (similar to ASDF for Lisp) for including libraries and another method (Like pear, asdf-install, clbuild, gems, rocks, etc…) for downloading new libraries.


Comment by dantman — January 13, 2009

Leave a comment

You must be logged in to post a comment.