« Google Chrome at JAOO – V8 and GUI | Main | The secrets of doing agile offshoring with succes »
Is JavaScript becoming a Ruby killer?
By Ole Østergaard | September 11, 2008
I love Ruby. I participate in the local Ruby user group. I am a member of the program committee of the RubyFools conference. Occasionally, I give presentations on the greatnesses of Ruby and my own spare-time Ruby projects. I feel free when I code Ruby. I love the creativity of the Ruby community developing new kinds of frameworks and tools. I try to promote Ruby everywhere I can. In short, I’m a “Ruby dude”.
But lately, I’ve had this nagging feeling that we “Ruby dudes” are going extinct soon, with all this recent hype there’s been around the new JavaScript engines (like V8 and TraceMonkey). Suddenly JavaScript is getting a lot of attention, and people start saying that now, finally, it is feasible to create rich client applications entirely in JavaScript. Just about every single PC around the world has some kind of a JavaScript engine, and people are realising the potential.
Has Ruby really just been a “temporary hype language”, as many of my friends doing traditional Java/.NET development have been keen to point out to me? Have all the hyper-enthusiasts left the Ruby building? Did Ruby actually penetrate the market well enough to stay in the future? What will happen to the great Ruby community if the interest fades away? How can I justify the choice of Ruby as the development language for new commercial coding projects?
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. However, it doesn’t have that huge edge to other technologies that it used to have, since a lot of the ideas introduced by Rails have slowly, but steadily, found their way into other frameworks on other platforms.
Oh, and there’s another perspective: Ruby is not just Ruby. What people know as Ruby is Ruby 1.8, and a lot of work is currently being put into Ruby 1.9. Some new language constructs have been added, but the big question is whether Ruby 1.9 will “feel like Ruby” anymore? I haven’t played around with Ruby 1.9 yet, but I certainly don’t like all the new language constructs. New language constructs also make the language harder to learn for newcomers. If the community breaks in two (the “1.8 folks” and the “1.9 folks”), that cannot be good, can it?
I’m worried that my favourite language will get in trouble in the not so distant future. For the nearest future, however, I’ll keep using Ruby as a great tool for solving a lot of problems quickly, but I’ll keep my eyes open for what’s happening in e.g. the JavaScript world.
September 11th, 2008 at 6:42 pm
Is this an apples vs. oranges problem? I’ve never seen Ruby as anything but a server-side, testing, scripting, integration, network, and glue language. In short, anything but client-side. I know that there are ways to make GUIs with Ruby–I’ve used ‘em–but it always seemed like a stretch. Perhaps it’s because I’m not a GUI guy at heart. Perhaps it’s because Ruby is just a server-side animal. I don’t know for sure. But as a browser-side tool, I’ve not known Ruby to be a player at all. Could be my ignorance.
I’m still firmly planted in the 1.8 world. This is simply because some of the libraries I need to switch to 1.9 haven’t made it into Debian etch (testing) yet. Some of the new language constructs in Ruby 1.9 look lip-smacking powerful. Currying, for example. When you need it, no other tool will do. In the hands of a novice looking for a hammer when a screwdriver will do, it’s a fearsome tool for creating unreadable code. I already see some unreadable code being produced in libraries because some people prefer clever over clear (or, to be more kind, some people are just smarter than me), so some of the more advanced features do scare me a bit. It seemed to me that there was, when Ruby first came out, an emphasis on clear code, with the advanced features being used as a end to that means. Now I am seeing more and more code published using what I consider very advanced features. Is everybody getting that smart (or me that dumb, in my old age?), or is the emphasis on easy-to-read-and-refactor being deprecated?
All in all, I’d rather have the language let the programmer choose. Make all of the tools available and let the programmer choose that which are needed to get the job done, whether simple or advanced. Then let the programmer learn, through pain of maintenance, which tools are ultimately best. Over time, the repeated pain of, “did I really write this noise? What does it do!” does indeed teach a programmer not to use a 10 pound sledge when a 2 pound hammer will do.
September 11th, 2008 at 8:47 pm
To make matters ‘worse’, I’ve heard half-whispered rumors of projects taking Javascript to the server. Aptana’s Jaxer is just such a project. I don’t yet know whether it’ll take off or gain traction. I do wonder though…
September 11th, 2008 at 8:57 pm
The interesting stuff will begin to happen when people start writing server-side applications in JavaScript.
V8 can easily be used to run a server — JavaScript just needs a standard library for all the OS-level stuff (files, sockets, threads, etc.), and we’re good to go.
Web developers spend a lot of time writing JavaScript code for the client — why not use the same language on the server?
With V8, it even has tremendously better performance.
TraceMonkey and especially V8 are some of the first steps toward bringing JavaScript into the world of “real” general-purpose programming languages, and I think it’ll be amazing for all of us.
Personally, I wrote up a small app yesterday based on V8 that enables me to write my shell scripts in V8.
Congrats to the Google guys in Aarhus for creating such a well-designed VM that performs so well, and even making it Open Source!
- Simon
September 11th, 2008 at 10:30 pm
The comparison is strange.
First, javascript code looks almost as ugly as PHP code whereas ruby code looks a lot cleaner.
I also think that python code looks cleaner than javascript code. (Perl code looks uglier than any other of these “scripting” languages by far, so let’s ignore it for now)
But for a Java or C# guy this syntax noise in Javascript obviously is less of an issue.
For me it is and we can not go on and say million of people use a given language. Who cares? If the universe has 1000000000000000000000 people, and 99,9% of the languages suck, why would I want to use one of these just cuz it is popular? Java is popular but Java is annoying as hell.
Second, let’s be realistic. Ruby has a huge problem, and the problem is actually that people are stubborn and stick on using old languages like perl. On the other hand ALL the scripting languages ALWAYS compete against the static languages like C#. And let’s also be realistic – python is a very strong contender in that area.
Javascript has only one thing going for it – browsers.
For the rest of it Javascript simply sucks, and quite frankly I would rather use python or ruby instead of Javascript even if that means I can only target a small user base. I HATE JAVASCRIPT.
I hate the chaos of the libraries which are hyped but which actually suck. SIMPLE actions are not so simple, and then comes in XML again… I hate XML too.
The hype with javascript will cool down slowly, for me it does not matter because I am so hugely limited by javascript. This is simply a totally different situation with ruby.
Third, you talk about market, but who cares about market at all? I am using ruby like other people used perl – it simplifies my tasks a lot. I dont care if I get paid or not really, because I SIMPLY SAVE A LOT OF TIME COMPARED TO LANGUAGES LIKE PHP – or Javascript.
Lastly and this is the point I disagree with you mostly:
“Ruby is not just Ruby.”
There is always only one ruby, and I am annoyed about people who try to break it up in different implementations.
- The language created by matz.
I dont care about the others. If the others fullfill matz critera and have 100% of the ruby code work, all the better! If not, then they are not ruby.
Ruby 1.9 will be SO SIMILAR to ruby 1.8 actually, and what people seem to confuse is that you DO NOT HAVE TO USE NEW THINGS in most cases. I don’t for example.
I know people use a lot of lambda {} but I simply dont need them at all. Same for class vars. I dont need all that.
And I dont feel as if this is a problem. I stay as simple as possible and as direct as needed, without using everything what is available just for the sake of it being available.
Ruby is not one of the most popular languages, but it is the most elegant by far.
I look for new languages but they suck in so many aspects that it makes my head hurt… they lack in docu (yes ruby had that problem too, but for my personal use i am fine with the docu as it exists today), or these new languages have a horrible syntax.
And people still claim syntax is nothing… in the year 2008. Right.
To all these language designers, I will tell you something:
YOU SHOULD CAPTURE THE _INTENT_ OF THE HUMAN PROGRAMMER, NOT CREATE BARRIERS TO MAKE THE CREATION OF THIS INTENT HARDER!
As simple as possible. That is the goal. And that includes making a syntax either BEAUTIFUL or VERY SIMPLE.
“New language constructs also make the language harder to learn for newcomers.”
I agree with you on this, but let’s be honest – ruby is a complex language. After a few years you can still learn something new.
However unlike C++, Ruby is a lot more logical in structure and much more inherently structured (except gems, i think a ruby package mechanism should have existed at least for the windows folks from the very beginning).
“If the community breaks in two (the “1.8 folks” and the “1.9 folks”), that cannot be good, can it?”
They won’t. The moment 1.9 will work and matz will use it or endorse it will be the moment the community will quickly change. Trust me on this. Many are waiting and not switch for now because 1.9 is still an evolving target.
And Dave Thomas Pickaxe 3 will also have a HUGE influencing factor. Pickaxe 2 helped me learn Ruby back then and was by far the best book about Ruby. (BTW Dave if you read this, i hope you can extend the “advanced” sections for pickaxe 3 so guys like me won’t be bored too quickly
)
“I’m worried that my favourite language will get in trouble in the not so distant future.”
I think Ruby did grow. Not very quickly, but it did.
So I think it is not a problem, as long as ruby grows it is good.
“For the nearest future, however, I’ll keep using Ruby as a great tool for solving a lot of problems quickly, but I’ll keep my eyes open for what’s happening in e.g. the JavaScript world.”
Yes, tell me – how do you write gtk apps with Javascript?
Is there a yaml library for Javascript? Do you have something like rails, rack, ramaze, mongrel, rmagick or similar for Javascript?
Please, let Javascript die. It is designed by a committee and these guys that design in such a way simply suck.
A language needs to have a master that drives it. Or it must be community driven where IDEAS compete.
But a committee that is influenced so hugely by an industry will make a horrible language.
People will praise it forever though dont they
September 11th, 2008 at 10:37 pm
I forgot to add two things:
1) Personally I think both ruby and javascript share a very “prototype based object oriented approach”
I think pure prototypes that can be very flexible, can capture behaviour from other prototype objects etc… will be a better thought model than the old OOP with classes (in C# it is so strict and annoying to use compared to Ruby.. but unfortunately ruby is also neither pure prototypes with functional behaviour snatching)
2) ABout the cleaniness of syntax – I really mean it. Languages need to empower people, not the other way around. We have so fast machines, they become faster and faster. Why not make OUR time better as well?
For whenever speed is really needed, people will use compiled C code anyway etc…
But for the other area, the joy for programmers, why not make their life better? This is why visual programming was a good idea – create stuff by thinking, modelling etc.. without writing “int foo[22];” or memcpy-crap
September 12th, 2008 at 1:10 am
After playing with RoR and Seaside (www.seaside.st) I would
September 12th, 2008 at 1:10 am
… bet Seaside can kill Ruby earlier
September 12th, 2008 at 3:15 am
You can mix JS and Java on Rhino. It’s pretty amazing watching them interact.
September 12th, 2008 at 7:13 am
While Javascript will be a dominant language, it still does not compare with the readability of Ruby. Now, if Javascript got rid of all those { }’s and ;’s and added blocks, then I might start to wonder. Funny how such simple things can make such a big difference.
Also, 1.9 is not that different from 1.8. There are really only a fews changes that make it a major (non-backward compatible) transition.
September 12th, 2008 at 12:23 pm
Re: the comments about readability and the look of javascript, especially the {} – whilst these do decrease first-time readability the huge power they enable many times out-weigh any downside, they define object literals and are HUGELY powerful, hell, why do you think JSON is so nice and simple and powerful. It’s the same argument that people make about the parentheses in Lisp, yes they look weird at first (and at first are annoying to type) but the amazing power given by these soon outweigh any negatives.
September 12th, 2008 at 4:15 pm
I’m betting big on Javascript, I think Ruby is def on the temporary side. Let’s see, one language is already on a zillion desktops and handhelds across the world, and the other is known for Rails.
Js can be messy, but it’s ultimately a specification driven language that features expressive programming and a very low barrier to entry. That satisfies the senior and the junior devs/managers-and guess what? You HAVE to learn it since its on every browser. You don’t HAVE to learn Ruby.
It’s going places.
September 13th, 2008 at 1:19 am
The lesson of the ‘Chrome’ browser is that the server is going to move to the client. Google Gears puts a ‘lite’ version of Google’s server paradigm at the clientside’s fingertips, so the developer can have not only asynchronous callbacks, but a task queue in a separate process.
The new paradigm — we might as well call it “Thin Server” — of BigTable, map reduce (or Hadoop), a Condor-like task queue, GQL or Yahoo! Pig Latin, and a Gear’s style LocalServer or managed cache — essentially replicates the server-side paradigm that Ruby has thrived in on the client-side.
On the client side, JavaScript is both the language of choice and (for the new paradigm) a problem to solve.
It’s early days yet, for this new “Thin Server” paradigm and its client-side replicate, but if Ruby wants to thrive, it needs to figure out where it fits in.
September 13th, 2008 at 2:40 am
Ruby, Javascript, Python are all dynamically typed object oriented languages which support closures: to some degree, the differences will be personal preference on syntax. I think all three have a bright future on the server, javascript being the one where that is turning out to be a surprise.
http://www.10gen.com/blog/2008/7/why-javascript-
September 14th, 2008 at 4:18 am
Nice post. I think Ruby has it’s place as does Python and other languages. Really, the languages are tools. What I find nice about JS is that I can use the same language on both the client and server-side so I don’t have to shift language contexts as much when I do code.
I work for a company called Axiom Software and we’ve created a SSJS framework, the Axiom Stack (http://www.axiomstack.com). It’s based on Helma (http://www.helma.org). Both of these are based on Rhino and personally I agree with what Pete said above. It’s great to watch JS and Java interact.
September 15th, 2008 at 7:30 pm
[...] http://blog.jaoo.dk/2008/09/11/is-javascript-a-ruby-killer/ : Javascript, le langage qui va tuer Ruby ? [...]
September 19th, 2008 at 9:09 am
I am an avid fan of ruby who had to deal with javascript recently. I am personally not a big gui guy, I use ruby to write server side or adhoc command line apps.
I think ruby and JS won’t compete. They address 2 different audience I think. I could never imagine myself writing long ugly JS code to do the things I use ruby for on the command line. Ruby’s syntax is much too powerful.
Also I am not buying the whole rich client side app with a ‘thin server’ thing. If everything on the web turns to that model, then we are back to more client side computing than the all new ‘everything lives in the cloud’. I agree that we should try to leverage the processing power on our machines but we simply aren’t going to install a ‘web app’ for everything so server side web development are unlikely to disappear as fast as some may think.
I could partially agree with ‘web developers spend a lot of time using javascript on the client side’. Sure it makes sense to try to reuse your code and save yourself time javascript is such a waste of time. It really reminds me of java, how you have to write long ass code to do simple bloody things.
What I wish for is that someone writes a ruby interpreter in JS so I don’t have to use this yucky language anymore.
October 31st, 2008 at 3:18 am
Maybe this wouldn’t matter if someone comes up with a strong Ruby-to-Javascript framework like how GWT bridged the gap between Java and Javascript?
April 23rd, 2009 at 3:10 pm
I’ve already had a potential server-side javascript gig (Persevere, jslibs) come up. I love Ruby and JS equally – I’m hopeful and excited about the prospect.
April 11th, 2011 at 7:30 pm
Two and a half year later – nothing changed.