
Is JavaScript becoming a Ruby killer? - nreece
http://blog.jaoo.dk/2008/09/11/is-javascript-a-ruby-killer/
======
qhoxie
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.

~~~
SwellJoe
_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
What is preventing JS from running at the OS level? Couldn't it just borrow
the engine of another language?

~~~
SwellJoe
_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.

------
tlrobinson
There's two possiblities here:

\- Will JavaScript displace Ruby as a server-side language?

\- Will developers push more and more of their application logic to the
client, relegating the server to be a simple storage layer (with
authentication, etc, thereby reducing the usefulness of server side frameworks
like Rails.

I could see both happening. JavaScript is _the_ most widely deployed language
to clients, and you can control what you deploy on servers, so it seems like
the ideal language if you want the same across both clients and servers.

------
halo
No. Lots of people don't actually like JavaScript much, especially its
inheritance model, which is why you get obscene over-the-top technical
solutions to stop people from writing it. The language has also been slow to
evolve to fix core problems with it due to the fact that any changes need to
be agreed with by the major browser vendors. It's likely the language wouldn't
be popular if it wasn't for the fact it is the de facto in-browser programming
language.

FWIW, I actually /do/ like JavaScript.

------
jacobscott
Do people actually like javascript, or just like the fact that it is de-facto
always present in browsers due to its prevalence on the web (I could ask the
same question about flash). The vast majority of client-side js I look at is
spaghetti. To be fair, I'm looking at random webpages, not jQuery tutorial
websites.

~~~
eyelidlessness
I like Javascript, and given the choice I'd use it server-side as well. It's
an excellent language; very minimal, lends itself well to concise but powerful
code, and can be made to do pretty much anything given a decent API.

Most of the Javascript you look at is terrible because most of it is
copypasted from tutorials dating back many years, when Javascript was, at
best, not very well understood or known, and not the domain of serious
applications. The modern libraries like jQuery and Prototype definitely
exemplify how Javascript could be though.

~~~
jrockway
Actually, most JavaScript looks bad because of people cargo-culting bad DOM
code.

I don't really like Javascript, but I do agree that the core language is
minimal but complete. I will stick with Lisp when I want that, though, because
Lisp is nicer looking and has macros.

~~~
PieSquared
Javascript is a nice language, but that won't decide much. I mean, look at
Lisp.

(Speaking of Lisp, I recently discovered reader macros. I mean, damn, but
they're awesome.)

------
wayne
Microsoft's had JScript and JScript.NET for server programming for a while and
recently added Managed JScript: <http://en.wikipedia.org/wiki/JScript>

It's never really taken off, though Microsoft always pushed VBScript over
JScript and C#/VB.NET over the managed JScripts. I used server-side JScript a
little back in the old school ASP days and actually found it pretty confusing
having both server and client code in the same language, though it sounded
appealing in theory. More to wrap your head around.

I do admit a second love with client-side JavaScript after the recent
resurgence, but I definitely don't see it displacing Python, Ruby, or even
Perl anytime soon. The core language is nice, but it's got a long ways to go.

------
jhancock
The promise JavaScript holds for server side web apps is that a programmer is
far more productive with a tool he knows exceptionally well than with several
tools he knows just enough. In this way, JavaScript can be used on both client
and server and the programmer gets to be a real pro at just one language
instead of two or more. This is real value. But...sea changes in IT happen for
lots of unpredictable reasons. Just because you have nice rational for why it
makes sense does not mean it will happen.

------
omouse
No discussion of meta-programming? Can you duplicate the Ruby tricks in
JavaScript?

~~~
jrockway
_the_ Ruby tricks?

Why couldn't you? You have anonymous functions in JavaScript, that's as much
metaprogramming capability as you get in Ruby. (Notably absent from both are
macros.)

~~~
raganwald
Well, you are obviously right about JS having anonymous functions. In addition
to anonymous functions, Ruby also has a very late-binding object and class
system borrowed from SmallTalk that also--to the Java or C# programmer--looks
like trickery.

This can be built on top of JS, of course, but I also recall Object Assembler
;-)

------
jon_dahl
To his Ruby 1.8 vs. 1.9 question: the difference isn't huge, and I don't think
we'll see a split. You get fibers (coroutines); new hash syntax, like
User.create(name: "David", address: "123 Fake St."), Enumerators, and lots of
little changes. Ruby 1.9 programs should look pretty much like Ruby 1.8
programs for the most part.

The more likely split would be on the implementation level: MRI/YARV vs.
Rubinius vs. JRuby vs. Gemstone. The camps are working together pretty well
right now and aren't looking to divide the community, but I would hate to see
it turn into a Lisp-like situation. No offense to Lisp - I love it from the
outside, and would enjoy using it professionally - but the fragmentation is
definitely a barrier to entry.

------
aaronblohowiak
uhhh, what? how does having faster, fatter client side effect the server side
at all (in the m and the c.. the v may be data transforms from objects->html
to objects->json.. meh)

he isnt even proposing JS on the server side.

------
khangtoh
The browser is not the world.

------
bprater
Client != Server.

~~~
mpc
I don't understand. I was actually writing server-side javascript before
taking a break to read this site

~~~
r7000
[http://almaer.com/blog/rotating-java-and-javascript-on-
the-s...](http://almaer.com/blog/rotating-java-and-javascript-on-the-server)

------
shimi
There are too many script languages and implementation as is

~~~
jrockway
Yup, and every time a new language becomes popular, it will make your app
written in the "old" language stop working.

Oh wait, no.

