There’s a lot of buzz about Steve Yegge’s “port” of Rails to JavaScript, and Steve has now provided (in his funny, self-deprecating style) the background of how it came to be. He doesn’t quite say it explicitly in this post, but I think it reveals that the “Next Big Language” he has been hinting at is JavaScript.
I (mostly) agree:
JavaScript is in nearly every browser, including tiny ones (like the one in my BlackBerry Pearl). It may be the single most widely available language today.
Because of the above, an enormous population of JavaScript programmers (though sometimes of dubious skill) has emerged.
Starting with Java 6 it’s “in the box” there also. To me, this makes it the likely winner, by a wide margin, for a dynamic language to be used at Java shops or inside Java projects. Being “in the box” is a powerful advantage, one which the many other contenders will have a hard time overcoming.
Adobe’s new JavaScript virtual machine implementation, which they handed over to Mozilla as “Tamarin”, sounds like it will boost JavaScript performance great, making it good enough for a very wide variety of projects.
JavasScript uses curly braces, like the last few Big Languages.
Like Java, C, C++, etc., JavaScript has specs and multiple competing, complete, current, high quality implementations. This, to me, is a big advantage over Ruby, Python, and other currently popular dynamic languages. Of course there is plenty of room in the industry for these language to thrive also, I am not saying any of them will go away; we use Python with great results and expect to keep doing so.
Mark Volkmann initially thought I was nuts to predict JavaScript as a winner but came around a few month later (and said so in a user group talk).
In a project at work, we’d adopted JavaScript as our plugin extension language for user-customizable rules (billing rules, etc.). I’d have chosen Lua (as I did for another project), but there are at least 1000x as many JavaScript programs out there. So far it has worked very well. If we had it to do over we might implement far more of the project in JavaScript.
However, there are a few reasons why I only “mostly” agree:
First, with JavaScript there isn’t a good way to avoid shipping source code. Sure, you an obfuscate JavaScript with various tools, but the results remains far for amenable to readable-source recovery than in a more traditionally compiled language. For open source projects this is no big deal, but there are also many worthwhile businesses and projects which depend on proprietary, not open software (including most of our projects), and it’s not year clear that obfuscation is sufficient protection. (Update in reply to a comment below: This matters even for server-side software, because some of us create and sell software products for other people to run on their servers.)
Second, at the moment JavaScript appears to lack a module system, without which it’s painful to build large systems. I expect an upcoming language version will address this.
Apparently you’re out of the loop, this was the consensus several months ago.
One thing I see holding JS back (and perhaps this has been addressed in ecmascript 4) is a complete lack of threading. I will openly admit to not having written a lot of javascript, but I don’t see it going very far if it is constrained to a single processor, as we already have common dual-core and quad-core machines and 8-16 core is surely just around the corner. I think this is especially important in a dynamic language such as JS where performance is already (generally) below that of a compiled language such as C, and a developer needs access to every potential speed-up they can muster.
Another issue I guess, would be the lack of a really good development environment. Firefox + Firebug + Web Developer toolbar is great, but I don’t think it currently competes with polished environments for mainstream languages, such as VC++ or KDevelop for C++, VS.Net for C#/ VB.net/ C++/cli etc.. However, when I started developing an application in Python recently, I found the adhoc text processor + IDLE setup to be beneficial to development, so perhaps this isn’t such an issue (for small projects, anyway).
Given the very Java/C-like grammar and syntax of Javascript, I image that wide-scale adoption will come much more easily than would wide-scale adoption of many of these other newer dynamic languages. Some of the available AJAX applications today really do demonstrate how effective Javascript can already be,so I can’t wait to see more..
“First, with JavaScript there isn’t a good way to avoid shipping source code. Sure, you an obfuscate JavaScript with various tools, but the results remains far for amenable to readable-source recovery than in a more traditionally compiled language.”
I’ve been under the impression that something like Rhino would be used to run javascript as a _server_ side language. If that were the case, you wouldn’t have to send the client _all_ the javascript. Just that that gets run for display purposes like we do now. I don’t see a problem there.
You can use threading with SpiderMonkey without problems, but the JSAPI-using C stubs also need to be thread-safe, obviously. I don’t think that exporting an API to allow JS scripts to control threading themselves would be impossible, but it’s generally not necessary (the C/C++ application can control threading and run concurrent user scripts).
I agree that JavaScript is an interesting language. In fact, some time ago I wrote a framework to easily code various applications on unix using it (http://mmondor.pulsar-zone.net/ has more information on it for those interested). The site itself is served by a test HTTPd that was written in JavaScript. The code is open under a BSD-style license. There were eventual plans to write a web development server-side framework with a custom JSON-based fcgi-like protocol but I couldn’t dedicate time to complete this lately. Maybe someday.
As for the furure planned features to JavaScript, I’m not convinced that creating a general purpose Java-like language from JavaScript is a great idea. I use it for things which don’t require the performance of C and which take advantage of its very dynamic nature (part of which is lost if using the class-based model rather than the protype objects one). But why not, since applications will be able to use both.
Javascript can potentially be pretty fast, considering it’s Self-heritage.
On top of it, MS has already shown how optional type annotations on JScript can make a language both dynamically and statically typed.
There are some pretty cool implementations of coroutines and tasklets on top of Javascript as well.
Rhino offers continuations, something Seasiders have enjoyed for years.