Second, JRuby 1.1b1 has been released and as expected is considerably faster (see item #5 in this link) than the standard “MRI” runtime. JRuby joins Jython and Rhino in providing a JVM-based runtime for a dynamic language, with features designed to help developers mix and match the dynamic language code with Java code.

See the trend here? Python, Ruby, and JavaScript are emerging as the dynamic languages of the future for .NET and Java developers.

The hard work done by Sun and Microsoft to make their VMs work well is being leveraged by the next wave of languages. Threads, high performance I/O, memory management, and portability are all features that are quite expensive to get right, and the .NET and Java platforms have pretty much achieved that at this point. (Piggybacking newer, higher-level languages on these mature runtimes means that you get a mature new language runtime faster than if each language’s runtime were built from scratch and painstakingly debugged in isolation from the others.)

There are still some hurdles (performance, type safety fears, lack of mass market acceptance, ECMAScript 4 standardization and adoption, etc.), but in 2 or 3 years, things are going to change dramatically in the web application development world. The seeds of this change are already sown, and it’s just a matter of time. Threads, SQL, OOP, and garbage collection are all features of web application architectures that were initially controversial, but have now met with general acceptance. Dynamic languages are clearly the next step.

Obviously, Java and C# are far from dead, and in 10 years people will still be coding in Java and C#, because as with other languages like C and assembly, the newest and highest-level language isn’t automatically right for every project. But if you’re building web applications, most of what your code does falls into the categories of string manipulation, collection operations, or file and socket I/O. Image processing, crypto, full text search, and other CPU-heavy, byte-twiddling features may be part of your application, but you’re not writing the image scaler, RC4 cipher, or inverted index yourself; those are done in a library, probably written in C, and you’re just calling it. So your needs are likely to be similar to the sweet spot of dynamic languages: maximum expressivity and the fancy features to let you write clever code, making you productive and making the code as clean and elegant as possible. In other words, they put developer productivity first (lower labor cost and shorter development schedules) at the expense of runtime performance. Since hardware gets cheaper over time but code gets uglier over time, this is probably the right choice to make for most web application projects.

Another interesting benefit of layering instead of starting over is that the integration between dynamic languages and Java or CLR languages is much nicer than managed vs. unmanaged code in .NET or, even worse, JNI in Java. That is, it won’t be a bloody mess to mix and match code, from a technical feasibility standpoint. This matters, because The Big Rewrite is among the Things You Should Never Do. But little bitty rewrites are fine, especially if you have a thorough test suite to help you avoid breaking things. (By the way, dynamic languages are great for writing automated tests.)

Which of these three (JavaScript, Python, or Ruby) is going to be dominant 5 years from now? I don’t think any of them will be. The dynamic language community is fragmented, and the various vendors and big sponsors of these three languages are fairly entrenched already. Microsoft is investing in all three; Google has standardized on Python and JavaScript to the exclusion of Ruby; Sun has hired the JRuby team; Mozilla is heavily invested in JavaScript; Adobe supports JavaScript in AIR but not Ruby or Python, etc.

In fact, if you encapsulated the glue code sufficiently well, you could mix and match JavaScript, Python, and Ruby in your application, and port your hideous hydra between the JVM and .NET. You would be wasting a lot of effort since the three languages are largely similar, but you could do it. Alternatively, you could create a portability layer between the DLR and the JVM a la WxWindows, and write-once-debug-everywhere in a more productive language than Java.

These are all repugnant ideas, but only because as I write this and as you read this, we probably realize that to attempt this today would be a huge task. But what about in 2010? Probably not so gross. What about an application that could be executed on Silverlight, AIR, Firefox, SWT, and Mono, unmodified? How about a mobile app that runs on smartphones regardless of the runtime (.NET vs. J2SE)? Not gross at all, and not unthinkable if your app is written in JavaScript using some kind of portability layer that doesn’t exist yet.

In the longer term, JavaScript (a.k.a. ECMAScript 4) is likely to become extremely popular. As far as I know it’s not quite a perfect fit for Steve Yegge’s The Next Big Language, but it’s the closest thing there is, and it has two critical advantages over Ruby and Python that will make it successful: C-family syntax (which makes development tools cheaper to build) and effectively unanimous buy-in from vendors and developers.

So, what about the other dynamic languages that people are using in large numbers today? What’s going to happen to ActionScript, CFScript, PHP, and VB?

ActionScript and CFScript are pretty close to JavaScript by design; I’ve read that ActionScript 3 is actually compliant with the ECMAScript 4 draft specfication. It’s pretty clear that Adobe is betting on JavaScript. In the near future (2 or 3 years) I predict that Adobe will rev its products and support ECMAScript 4 across the board.

PHP and VB.NET/VBScript will hang around for a long time because they’re approachable and already very popular, but they’ve already peaked, and will steadily decline as developers switch to C# (on the .NET side) and Rails (on the Linux side), and then JavaScript as soon as a serious web app framework and an ISP-friendly runtime exist. Microsoft will keep investing in VB to keep customers happy; Yahoo will keep investing in PHP because it is so heavily invested in PHP already; new developers will find PHP to be an easy starting point for light duty web development, with tons of documentation and free applications that they can download and hack. But PHP will not inherit the kingdom from C# or Java, and the languages which do achieve mainstream success after C# and Java will do everything that PHP does language-wise, and the market momentum around those languages will make them better than PHP at what PHP does. Developers will ask themselves why they would write the client side and server side in two different languages, especially when the server-side language is more expressive and has better portability and libraries. That’s not true yet, but it will be in a couple of years. In 5 years or so PHP and VBScript will go the way of Perl CGIs: still used, but by a community a tenth of the size it is today.

What about the new Java-based dynamic language, Groovy? Groovy is interesting, but it’s too late. The Java mainstream of vendors and developers only recently managed to convince the world of “serious” C++ developers that automatic garbage collection and JIT compiled bytecodes can actually work in a high traffic context. The next battle, to promote the dynamic language features that Java lacks but which Groovy brings, will take years to fight. Once a developer makes a decision to not use standard Java, Groovy is on a more or less level playing field with the JVM-hosted versions of Python, JavaScript, and Ruby, but each of those languages has far greater adoption than Groovy, and each of them has greater opportunity for leverage on other runtimes than Groovy. For a Java developer, once the door is opened to other languages, the only advantage Groovy has is that its syntax is familiar. Compare this to JavaScript which web developers also need to know how to use; why learn a third language (Groovy) in addition to Java and JavaScript? Over time the simplicity of coding and debugging in JavaScript on client and server, together with dynamic-language productivity, will overcome the momentum of the Java standard, and web developers using server-side Java now will gradually replace it with JavaScript on the JVM. Conservative attitudes in the mainstream Java community (including Fortune 500 companies and the many offshore development firms that write code for them) will make this take quite a while – probably 5 years before JavaScript becomes a common part of the architectures that currently use J2EE, and 10 years before Java goes the way of COBOL (maintained forever but not used for new projects).

So in conclusion, keeping an eye on the future value of a technology, including who’s investing in it and who’s talking about investing in it, is critical to making your own investments today. In five years you’re not going to be using the same technology stack that you are today, and your project’s success and your own salary will be tied in large part to how well you invested today.

Hell no. Firefox and Thunderbird are built using an incredibly complicated set of tools and technologies created by the Netscape and Mozilla folks, specifically for the purpose of building Firefox and Thunderbird.

Low-level stuff is written in C++, but if you know C++ already you still have to learn their coding standards and class libraries. Yeah, it’s great that they have coding standards and libraries; I’m just sayin’, that’s more stuff you have to learn in order to write a single line of low-level code.

High level stuff is in a combo of JavaScript and XML. Of course you have to learn the XUL platform stuff, so just knowing JavaScript and XML isn’t sufficient. You’ll also probably need to learn to use the low-level classes from the XUL side, so that you can get anything done.

Now if you want to actually build it, you’ll also need to understand their build system, and maybe their installer. You might need to learn how their help system, documentation system, internationalization sytem, etc. etc. work.

Now, I’m in awe of the monumental amount of new and working code that the Mozilla community has created. But the problem is just that: they built this huge application stack, and in order to get working on Firefox or Thunderbird, you have to learn a big chunk of that stack.

In theory, this wouldn’t be any more of a barrier than if they had coded to a single platform’s GUI widget set, class library, etc. But if I were to learn .NET and Visual Studio, or Cocoa, or GTK+, I would then have skills that I could use to work on thousands of other applications, either open source or commercial. That’s because those technologies are designed for general purpose application development.

The Mozilla application platform, however, has no life of its own outside of Mozilla. There’s an effort to extract it and make XULRunner a viable standalone platform that you could build your own XUL applications on, but that’s currently just a “stable developer preview”. What that means is that it’s still not suitable for use if you wanted to, say, build your own iTunes killer with it. It’s almost there, and maybe if you throw a lot of effort at it you could hack it so it’s usable, but as-is, it isn’t readily useful.

So, when a developer (such as myself) looks at this technology set, they ask themselves the question, “can I justify spending this much time learning all this stuff just to fix a little annoying bug?” If you spend a week or two downloading and learning and hacking and that gets you a certain amount of skill with the technology set, was it worth it? Maybe you could go get a job working with this technology set, except almost no one else is using it, not even open source projects.

When a corporation looks at this technology set, they have to ask a similar question: “is this the platform that will give me the best bang for my developer buck?” If they invest the time and money in hiring developers to work on this mostly-complete platform, so that they can then build an application with it, will it pay off? What about alternatives? Will the pool of available developers be so small that the project will fail before it starts?

These are not insurmountable barriers; some folks know some of these technologies already or only want to work on a corner of the application, so the overhead is smaller. Or, they may really want to work on Firefox or Thunderbird very badly. For an employer or open source project, their goals may match the goals of the original platform designers very well, in which case the payoff of using the Mozilla platform would be much higher than if you were (for example) making a Windows-only IM client.

But the barriers do exist, and they discourage the platform and the applications built with it from being improved. Developers don’t want to spend all that time learning things they can’t use elsewhere, and employers don’t want to pay developers to fix the platform so that other projects could find it useful. A few projects do exist and obviously somebody somewhere is working on Thunderbird bugs, but for a platform this sophisticated with this much mindshare (via Firefox), it’s remarkably unsuccessful in terms of adoption by developers.

All it would take to fix this would be some cash. Somebody could donate (or spend, in pursuit of a business goal) money toward the completion of XULRunner for general use, and toward clear and useful beginning developer documentation for the rest of the Mozilla platform.

Any takers? I could thrown in a hundred bucks or so, but I have a feeling this is more like a $50,000 undertaking. Otherwise we’re stuck waiting for Joost and a handful of others to slowly move it along.