Mod_v8

http://journal.paul.querna.org/articles/2008/12/23/mod_v8/

by davidw • 18 years ago

49 17 18 years ago

journal.paul.querna.org

inklesspen2• 18 years ago

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.

randallsquared2• 18 years ago

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

davidw2• 18 years ago

Paul Querna is one of the Apache httpd developers, so I think he's quite likely to go on using Apache, instead of the event based server du jour.

inklesspen2• 18 years ago

Well, that's nice for him, but not so nice for us.

geuis• 18 years ago

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.

nikils• 18 years ago

http://jsext.sourceforge.net/ supports lighttpd

gsmaverick• 18 years ago

Awesome stuff, V8 is one of the superior javascript engines and this would be an amazing step forward.

moonpolysoft2• 18 years ago

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.

randallsquared2• 18 years ago

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.

wmf• 18 years ago

Maybe a common FFI would be a good first step.

smoody• 18 years ago

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.

ROFISH• 18 years ago

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.

tlrobinson• 18 years ago

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.

jerf• 18 years ago

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

Mod_v8

Related Stories