“…I feel it in the water, I feel it in the earth, I smell it in the air…”
Like you, I have a wide range of development experience. In the past 20 years, I’ve been a huge fan of Java, C#, Flex (Actionscript), ColdFusion, F#, Ruby and Python. In fact, a few years ago in my last job, myself and some colleagues spent a significant amount of time and effort convincing everyone to migrate to Flex-based applications (they have since decided to migrate yet again to .NET). At the time, it was the right move.
Now I would never suggest such a migration
Feel free to disagree with the following opinion, but from what I’ve been seeing over the past couple of years is…
JavaScript is going to be the virtual machine that drives the next 10 years of software evolution.
Not all software, mind you. I’m talking about the revolution that’s going on in mobile, cross-platform, cloud-based computing and development.
Now, what exactly do I mean by that? JavaScript itself is not a virtual machine, it’s simply a programming syntax, right? Well, that’s true, but remember that the companies writing JavaScript engines are making virtual machines – such as Google’s V8 – that parse and execute JavaScript… and they’re fast. In fact, they are becoming so fast, that JavaScript is slowly, but surely, becoming a ubiquitous language that not only builds the logic and validations of an application, but is now building the actual user interface, and the brains behind it (see server side JavaScript).
We’ll get into that later, but I want to start off with a statement to all the legion .NET, Java, Actionscript, Ruby, Python, {insert language here} developers who look with disdain, or even confusion at JavaScript. You’re missing it. You’re missing what’s going on around you, and for anyone who’s been in software for even a short amount of time, you learn that you adapt or you risk becoming marginalized.
Let’s start off with the trends that I’ve been seeing, and also some nice links that really show off the power of these JavaScript virtual machines. Some are obviously impressive, some are subtly so, but all of them give a taste of what’s coming.
Start off by checking out Fabrice Bellard’s PC emulator with the Linux 2.6.20 kernel on it. That’s right, an operating system running inside a browser.
Imagining the possibilities of utilizing this kind of tool is exciting. Are you an android developer? Imagine writing your code and then being able to emulate the browser-based version of your program and the mobile version in the browser – side by side.
Imagine having a RAM based file system running in the background behind your web application, and using Web Storage to make the environment and experience different for each user – while never having to communicate with a central server.
How about running a dynamic P2P server inside your browser using WebSockets?
All written with JavaScript. Impossible? We’ll see.
Yes, the LOTR references will continue to pile up as this article goes on, just accept it!
Some months ago (oh about 6) I stumbled across this tool called Titanium. The only reason that I learned of its existence is because the developers of my favorite tool – Aptana IDE – were acquired by the company Appcelerator. I blithely browsed their web site that day thinking they were just another software development company. However, by the time I was done reading their technology road map, my brain had changed. A light had turned on that hasn’t been shut off since.
JavaScript can be used to design entire applications, and then be compiled into almost every operating system using the standard SDKs! How is this possible? So if I want to write an application that can be deployed on the desktop (Windows, OSX, or Linux) and also be deployed to mobile devices as native applications (Android, iOS, Blackberry), I only need one source code library?
The world is changing, indeed.
What can I say about Node.js that hasn’t been said already? Well, for the uninitiated, Node.js is a program written in C++ that allows you to author server-side services in JavaScript. It is entirely event-driven, on a single thread, and is designed to be a non-blocking I/O framework.
I will not go into any details on it here, but for those who have investigated it, I believe it’s the tip of the iceberg, and for those who have not, well, then you need to spend a couple hours this weekend going down the rabbit hole.
Node.js still has a long way to go (Windows support *cough*), but since its introduction to the world in November of 2009, there are now hundreds of modules written for it that will cover most of your interests and needs.
Most impressive so far is a module called Now.js. It allows you to have real-time communication between your server and your clients with one simple JavaScript file. If any of you have ever tried to implement message queues in the .NET or Java environments, you know how many hoops you have to jump through, how it affects performance and your system architecture. This module is so easy and painless to implement, it almost made me laugh when I first saw it work.
If you’re interested, here’s the original presentation given by Ryan Dahl at the JSConf in 2009.
Given these two tools, you can now write your secure, server logic and the entire customer facing application in one language and have it interpreted to any platform. That’s exciting!
I’m sure that’s how many software developers would term the desire to write a program in Java or C# and then run it through a compiler to generate JavaScript! Gasp! How plebian… how absurd!
Yet these companies (little ones named Google and Microsoft, respectively) have written these compilers because there’s a need. First, there’s the Google Web Toolkit for Java and, secondly, there’s Script# for the .NET folks.
I have to give a lot of credit to this evolution to Google. Their brilliant engineers have shown us time after time after time that almost anything you think can’t be done with JavaScript, they have done it. Perfect example. Someone (with an apropos name of Putrid Polecat) commented on Ars Technica story about Windows 8 (see link below) with the following uneducated comment.
Serious applications simply cannot be written in HTML 5 and JavaScript. Continued support for C#/c++/Java must, and therefore will, continue. Can you write adobe illustrator in html5? Blender? AutoCAD? A virtual machine emulator? Device drivers? A compiler?
Cmon guys.
Let’s see…
A virtual machine emulator? Well we covered that.
A compiler? They’re working on it with getToken(). Also, I suppose you could just write your own with JS/CC.
AutoCAD? This one’s probably right with JavaScript in its current state. Its floating point calculations might not be able to support the precision needed by a CAD program. There’s hope for the future, though.
Adobe Illustrator? There’s plenty of online image editors available, but nothing yet as comprehensive as Illustrator. However, with the HTML5 Canvas, I’m betting that it’s coming soon.
Speaking of Google, how about a word processor, or spreadsheet application, or database tool in the browser with JavaScript. Google Docs.
However, I agree with his core point about there always being a need for compiled, strongly typed languages. I just want people to understand that JavaScript is as powerful as any other language, and used properly, can achieve mind-blowing results.
It is not the Gollum of programming languages, but as these tools show, it is the Gandalf. The one language that can somehow bring all the pieces together in order to develop and distribute applications as quickly and as powerfully as possible.
Windows 8 APIs are going to be HTML5 and JavaScript? Well, I don’t believe that for a second, and the article even ends saying that there’s more to it and Microsoft will give us more details as time goes by. However, given that a monster, a juggernaut, with the development and marketing power of Microsoft comes out and says that it’s banking on the latest round of W3C specs for HTML, CSS, WebSockets, Web Storage and JavaScript speaks louder than most everything else.
I think this is a great move on their part. Having C#, C++ developers working hand in hand with the JavaScript developers to build the communication and business layer that will feed the presentation layer is probably how it will all end up (viz Appcelerator above). But that’s just a guess.
** Update (09/15/2011) Here’s a great article that describes Metro Plugins (or, more specifically, the lack thereof) in more detail, and some basic info on the Metro style browser that will be in Windows 8 and why JavaScript and HTML are the basis of that experience.
Raise your hand if you remember the hoopla in the late 90′s about Java being the write once, run anywhere platform that would liberate us all!! Go on, raise your hand, no one will notice. Ok, we all remember, and it failed.
Now, raise your hand again if you remember Adobe, and then Microsoft, saying that compiled, vector-based browser plugins are going to allow us to write once, and run anywhere, and it will liberate us all!! Ok, you don’t need to raise your hand this time, but we all remember (it was just a handful of years ago). It also failed.
Is it possible that, like the gorgeous girl in the movie that no one noticed because she wore glasses and had her hair in a pony tail, the answer was right in front of us and no one saw it? Perhaps Google was the catalyst needed, like the movie bet where the jock dares to turn the nerdy girl into the prom queen, to let us see the true beauty and power of this little toy language written by Brendant Eich – who just so happens to be a native Yinzer (look it up) – way back in 1995.
The most beautiful thing about it is that JavaScript will be the glue that can tie all of the tools together. You can utilize Java programs and C# assemblies from your Node server, integrate a Flash movie or communicate with a Silverlight application in your UI, and then, just for fun, execute a command on your local, browser-based operating system.
My inspiration for this article is a conference call I had today with some teammates on a project at work. As usual, there’s a couple application developers, the project manager, throw in a couple QA folks, a BA, etc.
This is a complementary article to Antipimp’s “I could care less what they say.”. Read that first if you have a moment, then come back here and finish up. Take your time, it’s worth it.
.
.
Now, let’s talk about the other side of the fence.
Once you get the awesome job that Asshat Antipimp lined up for you, trust me when I say that no one gives a flip how many lines of code you wrote, or what awesome application framework you used. They care that you solved their problem and that it won’t break in a month.
Software folks are notorious for their.
My least favorite trait of many of my colleagues is their mistaken belief that other people give a shit about the technology. Well, actually, they do, but only when it doesn’t work. Things can be sunshine and roses and kisses and hugs for years, but trust me, when you write an application that doesn’t work, then be prepared to kiss your technology goodbye – or end up on the street.
The 99% of the world that doesn’t know how to write a ternary operation sees software as a means to an end, and that’s it folks. Writing software is “magic” to them and I hate to see application developers exploit that fact.
They aren’t amazed by your ability to use an ORM package.
They don’t care that you squeezed a few more cool aspects into your IoC architecture.
Then even don’t care that you’ve taken the painstaking effort to apply industry-standard usability practices to make it easier for them to work with it.
They. just. want. it. to. work.
Therefore, if you find yourself taking 20 minutes to explain to the eyes-glazed-over, bored-beyond-tears business folks how awesome you are, then it’s time to shut the hell up, sit down, and let them bicker about the fact that you used the wrong shade of blue in the application header.
Your job is to solve problems and make the lives of other easier. They don’t understand what you do, and no matter how long you try to explain it to them, they’ll still only care about having a picture of their dog on their web site.