I’m going to warn you that this is a rant. I just can’t take it anymore. Microsoft is a great company but there are some things going on at Microsoft these days that are very, very unsettling, in my opinion. I am going to address one of those issues in as graceful and as courteous a manner as I can muster. At a minimum, I promise not to go all Bellware on them. Here it is.

JavaScript is arguably the most popular programming language on planet Earth. I’m not sure what the Alpha Centaurians code in but it probably looks a lot like JavaScript, too. JavaScript isn’t perfect but it’s deliciously dynamic and declarative and just as functional as most people really desire in a general purpose programming language. I totally appreciate the great things that Microsoft is doing on the client side to make JavaScript faster, more standards (meaning jQuery) compliant and to provide better tooling. But don’t we deserve the power and flexibility of JavaScript on the server side, too?

Back in the day, I coded using Server Side JavaScript (SSJS) on Netscape Web Servers running on Solaris. It wasn’t that great an experience as I recall. It was OK but the development tool support was pretty weak and the debugging story was just awful. But JavaScript has matured a lot over the past 15 years since control was handed over to ECMA. Development environment support for JavaScript is very good now, even from Microsoft which seemed to be doing everything possible to make the JavaScript experience for developers and end-users poor until a few years ago. After so much noise, I suppose they couldn't ignore us any longer. And it’s a good thing, too. Without a fast, highly-compliant scripting language in Internet Explorer 9, that browser version would be doomed to be Microsoft’s last, in my opinion. Microsoft really does get it now about JavaScript in the browser. Hiring someone like Rey Bango is a testament to their understanding. Microsoft simply must have an excellent JavaScript story to tell with IE9. It’s got to pass all the benchmarks and compatibility tests with the highest possible marks. And the Visual Studio integration has to be tight, especially with respect to debugging. I have no doubt that Microsoft will do everything that they need to do to make JavaScript a first-class citizen within Internet Explorer from now on.

Microsoft’s JavaScript story on the server side isn’t all that rosy, however. In fact, other than a nascent, very limited version that showed up in some DLR alpha bits, there is no SSJS story from Microsoft. My repeated attempts to get Microsoft programming language product managers to engage in meaningful conversation about SSJS have fallen on deaf ears. They usually just stare at me when I say that we really need a good SSJS story as if I’m speaking Alpha Centaurian. They usually nod and say something like, “Yeah, well that’s nice but um… I need to go. My little brother got his arm stuck in the microwave so my mom had to take him to the hospital… And my grandmother freaked out and hijacked a busload of penguins. So, it’s kind of a family crisis. Buh-bye.”

Unfortunately, this is pretty much in line with the dynamic language story that we’re seeing from Microsoft across the board. The IronPython implementation got just up to the point of near perfection and BOOM! They dropped it. I think it’s somewhat noble of Microsoft to turn support of IronPython and IronRuby over to the community as they did. They didn’t just abandon it. But let’s be honest. You don’t give control away to the community if you’re invested. The community will do good things with both of the Iron languages but some problems require a company at Microsoft’s scale to get the mindshare they need to succeed. Microsoft’s decision to give up (for all intents and purposes) on IronPython and IronRuby is just a bad business decision, in my opinion, no matter what other irons (pardon the pun) Microsoft has in the fire. I know that Microsoft has other priorities but they made a huge mistake within the developer community with those decisions.

When I first met Harry Pierson of Microsoft a few years ago, his enthusiasm for the Python language rubbed off on me. I already loved Python from having worked around the RocketMail guys many years before when I was at Intel (before the Yahoo! acquisition of RocketMail). I could tell after swapping ideas about IronPython and the DLR around for a few hours that Harry and I were kindred spirits. Harry’s love for the Python language is totally infectious. I’ve always had a penchant for dynamic languages and Python, in particular, really rung my bell, so to speak. Python’s syntax is so light and clean and fluent. There’s little or no ceremony required to get truly wonderful work done with a few lines of code. And the standard library is very rich: “Batteries Included” we say in the Python world. Best of all, Python has excellent support for my other language love affair: functional programming. So much so that when I started working with the F# language, it felt Pythonic to me. It’s no wonder that a couple of years later, Luke Hoban (from Microsoft’s F# team) revealed to me that the F# programming language was deliberately designed to attract Python developers. From a statically-typed versus dynamically-typed perspective, these two languages couldn’t be more in opposition to one another. But the feel of working in F# is authentically Pythonic. And according to Luke, that feeling was embedded there quite deliberately.

Recently, I’ve been thinking about the state of things in the language world. My one biggest regret is failing to tell Microsoft how important dynamic languages are to me. I blogged about IronPython a lot. I gave dozens of user group and Code Camp presentations on integrating static and dynamic languages using .NET technologies. I even have a book coming out this year called Metaprogramming in .NET from Manning that contains a hundred plus pages on the Dynamic Language Runtime and all the great metaprogramming things that can be done with it. The DLR is firmly in place in the .NET Framework so I’m not worried about that. But seeing what’s happened to IronPython and IronRuby over the past few months, I lay awake at night sometimes wondering what else I could have done to make influential fellows like Scott Guthrie and Scott Hanselman and Somasegar understand why they should be showing their support publicly and within Microsoft for dynamic languages. I honestly feel like I failed my developer colleagues by not being a better spokesperson for Python and Ruby on .NET. Moreover, my grief about the subject spills over into other languages that should have been. Those that could have been. Server Side JavaScript is chief among them.

My reasons for wanting Server Side JavaScript running on the DLR are pretty simple. Today, I write in a multitude of “languages”: C#, F#, T-SQL, PL/SQL, JavaScript, CSS, XHTML, XSLT and a handful of other XML dialects that come in handy on occasion. It’s all too much really. As I use each of these “tools”, I ponder why they fit well for solving particular problems. Each of these languages is appropriately domain-specific which then leads me to wonder why I work in so many domains. Setting that question aside for a moment, I can’t help but think that if all the genius floating about in Microsoft’s Building 41 were aimed at creating a world-class Server Side JavaScript implementation on the DLR, we could rest our heads on our pillows at night enjoying a common language between at least two of our important domains.

I imagine a world where I might write JavaScript to render an MVC application, for example. The tooling in the environment I envision is so tight that emitting JavaScript to run on either side of the “pipe” is simply a matter of choosing the correct namespace. Better still, the JavaScript I’m thinking of has a runtime engine that decides where the code should execute. On a slower connection, the engine might decide to remote some of the code to the client side to provide a better user experience. On faster connections, it might decide to generate more AJAX callbacks from the client and run more of the code on the server to speed up the application or to enhance security. Emitting minified or pre-compiled versions of types and functions in my library would also be totally invisible to me. It would be automatic. Intrinsic. Creating markup from this system would be completely integrated, too. Calling an application a web app or a desktop client would be a thing of the past. There would only be apps. Making mental distinctions about where or how code must run would seem totally foreign to developers in this environment. Code in this dream becomes pure intent: homogenized, universal and sufficiently abstracted from any implementation constraints to become properly focused on solving problems first and foremost. List comprehension and query comprehension would eventually give way to a fully declarative intent realization model, arguably the goal of any universal computer. I did say this was a dream, didn’t I?

I know it may sound crazy. Some of the things I envision probably won’t be achieved in my lifetime. But think for a moment about the kinds of innovations that would come out of the process if the languages team at Microsoft utterly embraced JavaScript on the server side. Think about the developer experience they would craft in Visual Studio. It would be no less than stunning. Think about the editor and debugger and designer experiences. Imagine how IIS would evolve to support such a unified JavaScript execution model. Ponder for a moment how the JavaScript language itself might evolve if Microsoft put all of their mental and marketplace muscle behind it as both a server and client language of choice. Over time, languages like Python and Ruby would actually suffer from that kind of dedication as developers flocked to JavaScript as the common language on both sides of the average Internet connection. Silverlight, as much as I admire it for what it needs to be in 2011, would simply evaporate if my vision were to become real. And in that sort of scenario, Silverlight’s retirement wouldn’t be seen as a bad thing at all. Rather, it would just be a natural part of the evolution toward a better, more unified web for everyone.

Justin Etheredge turned me onto node.js at CodeMash 2011. It does evented I/O on Google’s V8 JavaScript Engine. Extremely cool stuff for building web services and definitely a step in the right direction, in my opinion. Google is a great company but I wish it were my trusted friend and partner Microsoft taking this step with me. Say what you will about Microsoft but my corporate and government clients trust them. And that’s why I’ve invested so much of my career in making Microsoft technologies successful. If I have to start migrating toward other vendors, I will do so. But I lament that decision in my heart of hearts. I can only hope that some of you who read this will agree with me and echo my sentiments in your own way.