I guess most of you have read the latest happenings in the whole NBL-story. Steve Yegge have created a Rhino on Rails; a JavaScript version of Rails. I have meant to write about this for a few weeks, but I felt I wanted to think it through before writing about it.
Of course, it's really cool that Rhino on Rails exists, and may someday be open sourced. On the other hand, the current version have no counterpart to ActiveRecord - instead it works against internal Google data systems. This may make very good sense from the pov of Google, but will make it hard to gain traction outside of Google when/if the open sourcing happens. At that point, a ActiveRecord version written using JDBC and Rails should happen. I'm personally looking forward to it, because such an undertaking would be able to take more advantage of JDBC than for example ActiveRecord-JDBC can do. ActiveRecord done "right" so to speak, but in JavaScript.
But is JavaScript the language of the future? What does it have that separates it from other current languages - most notably Ruby? Well, at first glance the big difference is in the amount of implementations. JavaScript have a multitude of implementations, while Ruby has three (Ruby, YARV? and JRuby), with many more in the works. JavaScript though, have a incredible amount of implementations, most of them bad.
It's got a standard. It's got full closures and a few more neat futures. And it has prototype object orientation; a very different object model compared to the standard of inheritance based object systems like Java, Ruby and Smalltalk.
On closer inspection, the prototype based object system is not really such a big deal. In fact, you already have it in Ruby. Just use Object.new and Kernel.clone. Not very practical in Ruby, but you can do it without any problem. Remember that the difference between dup and clone is that clone will actually copy the metaclass of the object, while dup just makes the duplicate use the same real class.
I see some advantages that JavaScript has over Ruby, that can actually count as real advantages. The spec is arguably one. Several good implementations is another. It's easier to make JavaScript have good performance. And maybe most important: most developers already know it to some degree or other.
But will it be the NBL in some form or another? No, I don't think so, for the simple reason that to many developers hate it. Not because of the language itself, but due to the connection with bad browser implementations. This is a debt that it will be very hard for JS to get away from, and I think it will tip the point against JavaScript compared any other language poised for the position of being a big language.
Further, I really don't believe in the idea that there will be a next big language. Call me strange, but just because we've had this cycle two or three times doesn't mean it will continue like that. I believe development is qualitively different now compared to 15 years ago. The challenges we meet are different and demand different tools. One single language will not cut it. I think the future lies in layered languages with different properties.
Prenumerera på:
Kommentarer till inlägget (Atom)
7 kommentarer:
The advantage that JavaScript has is in the ability to use a single language on both the client and the server.
Considering the number of languages required today in an AJAX application (HTML, CSS, DOM, JavaScript, and a Server-side-language) saving the server language is a good enough a reason.
Another benefit of JavaScript is the maturity of its many implementations, notably Mozilla's monkey and rhino.
It's in the browser baby! NOTHING else has that, and unless you think there is another device to run the next big language, I'm afraid we'll have to make do with JS. The tools are coming. The full server stack, the data encapsulation, the editor macro language,the compiler, the native browser access.
Top to tail a single language context. It is Inevitable. deal with it.
> Considering the number of languages required today in an AJAX application (HTML, CSS, DOM, JavaScript, and a Server-side-language)
You can add to that SQL. (Even if you use an ORM there are still times you need to fall back to raw SQL)
I don't like JS very much. It lacks a lot of things: for example: collections are very (too much) basic, regexp have a specific syntax, etc... a lot of JS libraries try to add very basic behaviors... that should exist in JS itself. But OK, the main point is that its behavior depends on the browser, so a JS program is often a list of if...else...
But OK, I agree that it is very useful in web applications, nothing could be done without it.
Calling it the next big language is like calling a hammer the next big tool.
It's been around, it's not the next big anything.
geekfreak - "I'm afraid we'll have to make do with JS" - c'mon! I'm afraid will just have to use hammers, its the only tool available everywhere, yadda yadda.
On the other hand, various major vendors are hard at work getting RUBY to run on their stacks. Hmm.
i suspect mr yeggy may be more literal minded in his choice of naming in the Next Big Language: my current blind guess would be that he is talking about javascript2 / ecmascript4 (which is shaping up to be significantly different from its predecessors), but is definitely still in the Next stages and not yet here. further, javascript for all its vast worth and versatility could hardly be regarded as big.
on further reflection he probably isnt talking about js20, conjecture on unborn languages could be regarded as unsound. but there were some notable absences on his laundry list of language requirements in javascript 1.7
Skicka en kommentar