19 ms·

No. I won't attempt to refute claims that Ruby is a temporary hype language (though I don't personally agree), but to suggest that Javascript will be the langu

by qhoxie 18y ago

No. I won't attempt to refute claims that Ruby is a temporary hype language (though I don't personally agree), but to suggest that Javascript will be the language to dethrone it is ludicrous. What he essentially suggests is that Javascript is becoming powerful enough to eliminate the current need for server side languages. This, simply, is not the case.

procrastitron 18y ago
Can you give some reasons you think Javascript isn't good enough for server side programming? Certainly the language is pretty powerful, and with Rhino it's fairly easy to integrate with existing libraries.
- iigs 18y ago
  Without a good platform there's not much to say about the validity of a programming language for a specific task other than it's Turing complete and it has features that might be nice someday if they could actually be used. Until Rails ruby wasn't a particularly nice language for coding server-side web applications. In 2002-2003 I worked for a company developing one, and had it taken off we would have had to rework it in another language very quickly.
  - jamesbritt 18y ago
    "Until Rails ruby wasn't a particularly nice language for coding server-side web applications. " Sure it was. You just had to know where to look for frameworks and libs and how to code in Ruby.
    - dasil003 18y ago
      Okay I'll bite... what were the Ruby web frameworks before Rails?
      - jrockway 18y ago
        What $foo web frameworks were people using before Rails? Until Rails, people mostly wrote CGI-style applications. (Yes, there was mod_perl, which people mostly used to make their framework-less web apps run a little faster; and there were Java MVC frameworks. Those were the exception, though, not the rule. Most people just wrote CGI scripts.)
        jamesbritt 18y ago
        Iowa and Cerise were running production apps before Rails. Nitro came out at the same time as Rails. (There may be more, but I'd have to go look it up. They're described in The Ruby Way 2nd ed.) Rolling your own request-handler+template thing is not hard. Nor is using DBI. Having stuff all bundled up is a big win, but it's not something essential. Ruby's a clean, fun language. "Until Rails, people mostly wrote CGI-style applications." Well, maybe that was prevalent with Ruby (whose mod_ruby is/was iffy), but mod_php was damn near everywhere before Rails.
        jrockway 18y ago
        mod_php apps are cached sets of CGI scripts.
briancooley 18y ago
>Of course, having faster JavaScript on the client still leaves a lot of room for server-side frameworks, and I still think Ruby is well suited for that. Based on the above quote, I don't think he's suggesting that Javascript will eliminate the need for server side languages at all. He seems concerned about hype, so maybe he thinks that that the hype might be moving from Ruby to Javascript. FWIW, I don't think Ruby is going away anytime soon.
SwellJoe 18y ago
What he essentially suggests is that Javascript is becoming powerful enough to eliminate the current need for server side languages. I think it's obvious that JavaScript is as powerful a language as Ruby, on the "blub" spectrum, anyway. Where it fails is on connecting to the underlying OS--breaking out of the VM and doing something with the system, which is something that Ruby (and Perl, from which Ruby inherited most of this stuff) has in spades. That said, when (not if) JavaScript gets a reasonable FFI and good ties to the underlying OS, on the order of Ruby, Python, and Perl, it will be the obvious choice for implementing just about everything. Faster implementations (V8 and Tracemonkey are faster for many classes of problem than any of the current dynamic language kings, and on par with Smalltalk) mean that once the "plays well with others" problem is solved sufficiently, there will be little reason to choose Ruby/Python/Perl except "I like it better"...and, though I do happen to like Ruby, Perl, and Python a lot, I also find JavaScript a very pretty language with a lot of power. If it gets block scope (which Ruby also doesn't really have, I think?), and the previously mentioned FFI and OS integration, I will have nothing else to complain about (except the DOM).
- Raphael 18y ago
  What is preventing JS from running at the OS level? Couldn't it just borrow the engine of another language?
  - 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.
nikils 18y ago
Did any one try to run javascript with llvm ? javascript without dom and with FFI might be interesting to use on server side.
- jrockway 18y ago
  Why do you need LLVM for this? Just use any server-side Javascript implementation, port your foreign functions over, and ignore DOM.

by qhoxie 18y ago

procrastitron 18y ago

Can you give some reasons you think Javascript isn't good enough for server side programming? Certainly the language is pretty powerful, and with Rhino it's fairly easy to integrate with existing libraries.

iigs 18y ago
Without a good platform there's not much to say about the validity of a programming language for a specific task other than it's Turing complete and it has features that might be nice someday if they could actually be used. Until Rails ruby wasn't a particularly nice language for coding server-side web applications. In 2002-2003 I worked for a company developing one, and had it taken off we would have had to rework it in another language very quickly.
- jamesbritt 18y ago
  "Until Rails ruby wasn't a particularly nice language for coding server-side web applications. " Sure it was. You just had to know where to look for frameworks and libs and how to code in Ruby.
  - dasil003 18y ago
    Okay I'll bite... what were the Ruby web frameworks before Rails?
    - jrockway 18y ago
      What $foo web frameworks were people using before Rails? Until Rails, people mostly wrote CGI-style applications. (Yes, there was mod_perl, which people mostly used to make their framework-less web apps run a little faster; and there were Java MVC frameworks. Those were the exception, though, not the rule. Most people just wrote CGI scripts.)
      - jamesbritt 18y ago
        Iowa and Cerise were running production apps before Rails. Nitro came out at the same time as Rails. (There may be more, but I'd have to go look it up. They're described in The Ruby Way 2nd ed.) Rolling your own request-handler+template thing is not hard. Nor is using DBI. Having stuff all bundled up is a big win, but it's not something essential. Ruby's a clean, fun language. "Until Rails, people mostly wrote CGI-style applications." Well, maybe that was prevalent with Ruby (whose mod_ruby is/was iffy), but mod_php was damn near everywhere before Rails.
        jrockway 18y ago
        mod_php apps are cached sets of CGI scripts.

briancooley 18y ago

>Of course, having faster JavaScript on the client still leaves a lot of room for server-side frameworks, and I still think Ruby is well suited for that. Based on the above quote, I don't think he's suggesting that Javascript will eliminate the need for server side languages at all. He seems concerned about hype, so maybe he thinks that that the hype might be moving from Ruby to Javascript. FWIW, I don't think Ruby is going away anytime soon.

SwellJoe 18y ago

What he essentially suggests is that Javascript is becoming powerful enough to eliminate the current need for server side languages. I think it's obvious that JavaScript is as powerful a language as Ruby, on the "blub" spectrum, anyway. Where it fails is on connecting to the underlying OS--breaking out of the VM and doing something with the system, which is something that Ruby (and Perl, from which Ruby inherited most of this stuff) has in spades. That said, when (not if) JavaScript gets a reasonable FFI and good ties to the underlying OS, on the order of Ruby, Python, and Perl, it will be the obvious choice for implementing just about everything. Faster implementations (V8 and Tracemonkey are faster for many classes of problem than any of the current dynamic language kings, and on par with Smalltalk) mean that once the "plays well with others" problem is solved sufficiently, there will be little reason to choose Ruby/Python/Perl except "I like it better"...and, though I do happen to like Ruby, Perl, and Python a lot, I also find JavaScript a very pretty language with a lot of power. If it gets block scope (which Ruby also doesn't really have, I think?), and the previously mentioned FFI and OS integration, I will have nothing else to complain about (except the DOM).

Raphael 18y ago
What is preventing JS from running at the OS level? Couldn't it just borrow the engine of another language?
- 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.

nikils 18y ago

Did any one try to run javascript with llvm ? javascript without dom and with FFI might be interesting to use on server side.

jrockway 18y ago
Why do you need LLVM for this? Just use any server-side Javascript implementation, port your foreign functions over, and ignore DOM.