3 ms·

What is preventing JS from running at the OS level? Couldn't it just borrow the engine of another language?

by Raphael 18y ago

eyelidlessness 18y ago
Well, it's not borrowing another language engine (I'm not sure what that would even mean), but server-side Javascript with OS integration is becoming more feasible: http://www.aptana.com/jaxer http://www.aptana.com/jaxer
SwellJoe 18y ago
Couldn't it just borrow the engine of another language? What "engine" do you mean? I'm not sure one can point to a single chunk of code in any mainstream dynamic language and say, "There! JavaScript needs that!" libc is probably the place to start (it's where Perl started, anyway), though learning from the mistakes of prior languages that have solved these sorts of problems is also wise...while making it work the way a JavaScript programmer would expect. You couldn't simply take Perl's implementation and cram it into something else (though maybe you could on a Parrot-based JavaScript engine, or you could steal from JRuby on a JVM-based engine--I guess the Rhino folks have "solved" this by allowing access to the Java libs, but I'm not sure, as I've not yet used Rhino). It needs to work like JavaScript to be a "native" feature of the language, rather than consigned to the ghetto the way it has historically been under Lisp and Smalltalk. In Perl, for example, one can open a filehandle, similar to opening a file handle in C minus all of the icky stuff, and then work on every line in a "while" loop very concisely ( while <> ... ). So, the underlying code is talking to libc (or the Windows API, whatever it's called), but the user sees Perl. So, just connecting JavaScript to libc isn't going to solve this problem...someone has to decide what "JavaScript file I/O" ought to look like, and build it on top of libc (and whatever the Windows API is), preferably with a reasonable standard being defined sometime soon after. And that's just the beginning (though it's such an important, and challenging, beginning I'm having trouble thinking of what the other pieces are). In the end, before we can say "JavaScript is a Ruby/Perl/Python killer", it'll probably take a few smart people sitting down with Stevens' UNIX programming books and pretty much deal with all of the various things people do when programming on a UNIX (and whatever the Windows API bible(s) is/are) system. Signals and IPC, sockets, etc. Though the more I think about it, the more I realize that on UNIX, anyway, many of the "hard" things are just special cases of file I/O since most everything is a file anyway. So, really solving file I/O and providing a good FFI is probably a good 80% solution, and a CPAN-like library of code (JSAN, perhaps) could be developed by the community to fill the gaps. So, best case unless the JavaScript standards folks start thinking about these problems...one or more engines will start with a decent FFI, and someone will design clever OS wrappings for the most important bits and people will begin building ad hoc solutions to the various OS interaction problems via libraries. It'll take several years, perhaps, after server-side adoption begins to grow before a clear consensus on best practices appears. This, of course, means we'll have a lot of incompatible and ornery JavaScript OS interaction libs for a while...which is a big problem, similar to C on Windows before a standard API emerged (and even UNIX if you count the networking API schism and the BSD vs. SysV split), for many years. Looking a bit further into this, Mozilla has/had io.js (which talks to XPCOM), but I can't find it anywhere as all the links on Google are dead or outdated stubs that refer to the dead links, and Opera has file-io.js. Jaxer has some file methods, which seems to be a reasonable server-side implementation. All the APIs I could find seem somewhat ugly and lacking in the fun of working with files in Perl (which eats files like candy), though. Just not very "native" feeling. But, I guess it's a start...and given all of the other factors making JavaScript seem like a great idea on the server, it may be enough for many people. I know I'm leaning more and more towards JavaScript for my next server-side project.

What is preventing JS from running at the OS level? Couldn't it just borrow the engine of another language?

by Raphael 18y ago

What is preventing JS from running at the OS level? Couldn't it just borrow the engine of another language?

Well, it's not borrowing another language engine (I'm not sure what that would even mean), but server-side Javascript with OS integration is becoming more feasible: http://www.aptana.com/jaxer http://www.aptana.com/jaxer

SwellJoe 18y ago

Couldn't it just borrow the engine of another language? What "engine" do you mean? I'm not sure one can point to a single chunk of code in any mainstream dynamic language and say, "There! JavaScript needs that!" libc is probably the place to start (it's where Perl started, anyway), though learning from the mistakes of prior languages that have solved these sorts of problems is also wise...while making it work the way a JavaScript programmer would expect. You couldn't simply take Perl's implementation and cram it into something else (though maybe you could on a Parrot-based JavaScript engine, or you could steal from JRuby on a JVM-based engine--I guess the Rhino folks have "solved" this by allowing access to the Java libs, but I'm not sure, as I've not yet used Rhino). It needs to work like JavaScript to be a "native" feature of the language, rather than consigned to the ghetto the way it has historically been under Lisp and Smalltalk. In Perl, for example, one can open a filehandle, similar to opening a file handle in C minus all of the icky stuff, and then work on every line in a "while" loop very concisely ( while <> ... ). So, the underlying code is talking to libc (or the Windows API, whatever it's called), but the user sees Perl. So, just connecting JavaScript to libc isn't going to solve this problem...someone has to decide what "JavaScript file I/O" ought to look like, and build it on top of libc (and whatever the Windows API is), preferably with a reasonable standard being defined sometime soon after. And that's just the beginning (though it's such an important, and challenging, beginning I'm having trouble thinking of what the other pieces are). In the end, before we can say "JavaScript is a Ruby/Perl/Python killer", it'll probably take a few smart people sitting down with Stevens' UNIX programming books and pretty much deal with all of the various things people do when programming on a UNIX (and whatever the Windows API bible(s) is/are) system. Signals and IPC, sockets, etc. Though the more I think about it, the more I realize that on UNIX, anyway, many of the "hard" things are just special cases of file I/O since most everything is a file anyway. So, really solving file I/O and providing a good FFI is probably a good 80% solution, and a CPAN-like library of code (JSAN, perhaps) could be developed by the community to fill the gaps. So, best case unless the JavaScript standards folks start thinking about these problems...one or more engines will start with a decent FFI, and someone will design clever OS wrappings for the most important bits and people will begin building ad hoc solutions to the various OS interaction problems via libraries. It'll take several years, perhaps, after server-side adoption begins to grow before a clear consensus on best practices appears. This, of course, means we'll have a lot of incompatible and ornery JavaScript OS interaction libs for a while...which is a big problem, similar to C on Windows before a standard API emerged (and even UNIX if you count the networking API schism and the BSD vs. SysV split), for many years. Looking a bit further into this, Mozilla has/had io.js (which talks to XPCOM), but I can't find it anywhere as all the links on Google are dead or outdated stubs that refer to the dead links, and Opera has file-io.js. Jaxer has some file methods, which seems to be a reasonable server-side implementation. All the APIs I could find seem somewhat ugly and lacking in the fun of working with files in Perl (which eats files like candy), though. Just not very "native" feeling. But, I guess it's a start...and given all of the other factors making JavaScript seem like a great idea on the server, it may be enough for many people. I know I'm leaning more and more towards JavaScript for my next server-side project.