A few months back, I had a bit of an epiphany. I suspect I was about 5 years too late with this epiphany, but nevertheless here it is: Microsoft, Sun, and Adobe all have these virtual machines that they want everyone to develop on top of. For Microsoft it's the CLR, for Sun it's the JVM, and for Adobe it's AVM. The problem that each of them have is that not everyone goes out of their way to install all of these VMs, so each vendor only has a subset of the entire computing space.
My epiphany was that there is one VM which nearly every modern computer has access to. It's JavaScript. Every browser developed in the past 10 years ships with some variation of it, and some systems even come with it as a command-line option. Whilst they do have a big problem in terms of standardization (or lack thereof), there is certainly a lowest common denominator that could be useful for writing apps on top of.
That being the case, why don't we see more language implementations on top of JavaScript? There is Processing.js, a port of the Processing programming language. There is also Objective J and Cappuccino, a port of Objective C and Cocoa, respectively. Each of those language implementations have received quite a bit of attention (both positive and negative, mind you).
So why don't we see Ruby, Python, or other languages implemented on top of JavaScript? For that matter, why don't we see more ports of apps to JavaScript? I know that in the Python world, PyPy has a JavaScript backend, but to the best of my knowledge that backend has been all-but-abandoned. I think it would be really cool if we were to see more applications and programming languages targeting the most widely adopted virtual machine ever: JavaScript.
Everyone has had the experience of hearing about something new and thinking: "That makes so much sense! Why didn't I think of that?" For programmers that keep up on open source software, new projects that fit the previous description attract not only our admiration, but we want to be a part of this new idea. We become involved and contribute and try to push that new software into any new direction that we can; learning from it and evolving it along the way.
One such idea that fits my description perfectly is Processing.js. Not to belittle John Resig's hard work in actually developing the initial codebase, but the idea is what is so much more important. Thousands of developers knew of both the Processing language and about the canvas tag which is coming to prevalence, but it was a revolutionary idea to notice that the pairing of the two was "both possible and desirable to do in the first place", as Reddit commenter MarshallBanana pointed out.
As a community we need both the revolutionary ideas and the evolutionary changes so that we get great software that solves problems in new and innovative ways, but also that doesn't have bugs and provides a polished experience. But I think that we've become too bogged down in the evolutionary. We get so wrapped up in others' ideas--so interested in polish and shine--that seldom few think outside the boundary of the incremental. I won't claim to be the exception here, and rightly can't claim to be, but it's something that's worrisome nonetheless.
I think that a big part of it is that the open source community has gotten so wary of experimentation with well-established applications. Why can't a development version of Firefox include a Python or Ruby interpreter alongside a JavaScript interpreter? Why can't CSS directives for reflections be explored, or animations be built into the rendering engine? I think that a big part of it is because we've spent so long talking about validation and standards that we forgot about that sense of wonder; that feeling of anything being possible with a bit of code and enthusiasm.
Processing.js, and projects like it, give me hope that revolutionary ideas are still out there. They rekindle that sense of wonder in me. They make me think about other things that are possible. They make me excited about open source again. Let's foster more and greater and better ideas, and just once in a while, eschew the incremental.
All Content
