Is JavaScript becoming a Ruby killer?
blog.jaoo.dk
blog.jaoo.dk
Certainly the language is pretty powerful, and with Rhino it's fairly easy to integrate with existing libraries.
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.
Sure it was. You just had to know where to look for frameworks and libs and how to code in Ruby.
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.)
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.
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.
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).
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.
> If it gets block scope [...]
block scoping overview and examples (search for let statements, let expressions, let definitions): http://developer.mozilla.org/en/New_in_JavaScript_1.7
I guess they had to use a different keyword instead of var (much like Perl introduced my because local already meant something strange in Perl 4, and for sort of the same purpose...though my became the new right way to declare variables anywhere, since the goal is always to get smaller scope for variables, and it doesn't look like that's the right idea with let).
JavaScript still doesn't have namespaces or a package/module concept, though (right?), so it seems like there'd still be some pain points in building large modular software. Of course, it's a pretty flexible language, and I've seen some interesting usage of closures to replicate namespaces and packages, so I guess standardizing on a library that provides those facilities is all that's really needed.
> though my became the new right way to declare variables
> anywhere, since the goal is always to get smaller
> scope for variables, and it doesn't look like that's the
> right idea with let
With Javascript, it's a choice between lexically scoped and lexically scoped - the only difference is the granularity: var has function level granularity, let has block level granularity. So in many cases it doesn't really matter, I think. At least the benefit of let over var isn't nearly as strong as it was in Perl of my over local.
Having said that, there is no particular reason why you shouldn't make let your variable declaration keyword of choice.
I probably don't. I'm just another Perl hacker who thinks it's nice being able to use any programming concept anyone ever thought of all in one language. It's a flaw.
Yeah, it does, but it's a little different. Here I iterate through an array in a block, assigning the current value to a local variable. Afterwards you can see that local_var remains undefind in the higher scope.
[norman@elis] +> irb
>> [1, 2, 3].each {|i| local_var = i; puts local_var}
1
2
3
=> [1, 2, 3]
>> puts local_var
NameError: undefined local variable or method `local_var'
for main:Object
from (irb):2
from :0
>>
However unlike C-like languages, Ruby doesn't treat if/else type statements as a block. So for example this works in Ruby:
>> if true
>> local_var = "hello"
>> end
=> "hello"
>> puts local_var
hello
- 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.
FWIW, I actually /do/ like JavaScript.
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.
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.
Just joshin'.
(Speaking of Lisp, I recently discovered reader macros. I mean, damn, but they're awesome.)
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.
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.)
This can be built on top of JS, of course, but I also recall Object Assembler ;-)
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.
he isnt even proposing JS on the server side.
Oh wait, no.