Its this kind of thing that makes me think karma is a real thing. I've spent the last 2 days working on getting Rhino to work with lighttpd. Haven't gotten far, mainly problems getting lighttpd running on Mac OS X. Either way, its really nice to see other people working on variations of the same theme.
What any server-side javascript implementation needs to thrive is a set of solid, fast database client libraries (MySQL, etc). That, to me, is why some of the JVM-based alternate language implementations are so interesting -- because the database support is built-in.
Agreed, if there was some sort of external support, server-side JS would be amazing considering the speed war that's going on with the different implementations. I messed around with WebKit's SquirrelFish which was nice and fast for the bare bones of the language, but many important functions are in window.* which isn't available on the compilable terminal app.
Unfortunately Rhino is at least an order of magnitude slower than all the modern JavaScript engines (SquirrelFish Extreme, V8, TraceMonkey). I agree the JVM integration is very useful, I just wish there were a way to get the best of both worlds.
Port https://wiki.mozilla.org/JSctypes to v8, get C libraries for, well, cheap if not actually "free"... probably wouldn't take that much effort, but I'm just guessing. For bonus points, start sharing JSctypes-based wrappers between the two implementations.
Actually, if you're serious about JS-on-the-server, that's probably just about the most useful single thing you could possibly do to help it. Well, unless you're really attached to the JVM...
Decent idea, except for the part where you made it an Apache module. If you'd instead built an app/middleware/server spec like Python's WSGI or Ruby's Rack, it'd be possible to use this sort of thing with more lightweight servers.
It appears he traded some immediate use for greater ultimate potential, if believe that much of PHP's success is due to optimizing for ease of use with Apache first.
(After actually reading TFA, I realize that he actually did it as mod_v8 because he's an Apache maintainer or something).
If he does decide to pursue this project, probably the most important thing that will affect whether it gets completed is how useful it is to him and how much fun he has while doing it. I'd definitely love to see a more generic system that's not tied to Apache, but I'm fine with him starting off with an Apache specific setup if that's what gets him motivated and interested.
Right - that's how open source works. Scratch your own itch, and work on things you like. If someone wants to see something not based on Apache, well, you have the source code, a compiler, and an editor.
Also, Apache is a perfectly fine web server. These event-based things have been around for a while. I recall moving the images and some other static assets on linuxcare.com to the Boa web server to save memory. However, Apache manages to have its own advantages, and stay relevant through the hard work of people like Paul Querna, even if, no, it's probably not the absolute fastest/smallest thing out there. Look at Rails - after going through a succession of various mixes of lighttpd, nginx, mongrel, etc.. etc... it's now coming back around to Apache and Passenger, and rightly so, Passenger is a nicer, simpler, more robust way of doing things. Furthermore, in terms of the other post's "him" and "us", there are a lot more of "him" (Apache users) than "us" (users of whatever other system).
Cool. I really think there needs to be a concerted effort to build a standard library for general purpose javascript that all of the javascript engines will implement as the standard. It's kind of frustrating that we have this amazing V8 engine, but no way to use it to do any real work. Older engines have stdlib projects, but they are tied to the specific implementations.
A lot of the most useful stuff has to be tied to specific implementations, if not in API, then in detail. Most of that stuff would be interfaces to non-javascript libraries.
Or at least extending the javascript specification to include an API that all of the engines can implement. I think this is basically the one thing keeping javascript from entering the mainstream as a general purpose language. As soon as you can reasonably tell people that their server side javascript will run on more than one engine, you'll see a lot more development.
