Uphill, Both Ways
I got interested in JavaScript when it arrived to the world as Netscape LiveScript. It came in two distinct flavors: client-side JavaScript running in the browser, and not many people remember, Server-Side JavaScript for writing the back-end logic. I believe back then it was called LiveWire.
Next to client-side Java, client-side JavaScript didn’t look like much. DHTML was nice, but nothing compared to the promise of mobile agents roaming around the Interwebs doing all sort of fancy tasks on your behalf. If you knew how to develop — back then JavaScript was marketed for the more casual programmer — you ought to be looking at Java Applets.
Then we let a big company full of engineers perched atop their X Server workstations to manage the UX for Java. We know how that turned out.
On the server-side, JavaScript was limited by a crappy standard library, a sluggish implementation, and the cost of a Netscape Enterprise license.[1] Contrast with Java, which came with a rich standard library, adequate performance, and you could either get an open-source server or were busy developing one.[2]
It’s been longer than a decade since I stopped caring about server-side JavaScript. Now I’m rebooting that passion. So what changed since?
Stuff Got Better
JavaScript is still the same ill-designed language, best known for its high density of “surely this was designed to confuse” language elements. Then again, nothing interesting happens around pure and perfect languages, at best, they evolve into text editors. Fortunately, we’ve got CoffeeScript, a dialect that mixes the better part of Python with the better part of Ruby, and compiles into straightforward JavaScript. It’s incredibly fun to use.
The library situation has improved tremendously. I remember searching for JavaScript code, only to find snippets of badly written DHTML code. Today? Take a look at this incredible list of Node.js modules. Need a Web server framework? Dropbox API? More uptime? Real-time monitoring? Asynchronous BDD? Web scraping?
I went looking for database drivers and found one for MySQL, one for MongoDB and three for Redis. Oh, and a JavaScript implementation of Redis called Awesome.[3]
We’ve got three runtime platforms for choose from: the insanely fast Node.js, the JVM-based Rhino and it’s C-based sibling SpiderMonkey. Competition is healthy. Then again, I’m betting on Node.js. It’s brilliantly fast, fun to use, got a story to tell (everything is asynchronous), but mostly, you can choose from a variety of hosting solutions.[4]
Yeah, we also got push-button hosting for JavaScript.
Looking for a chance to exercise your JavaScript-fu and prove you understand why 0 == []? You can start by writing a Web application using one of many cool frameworks. Or you can package your HTML-based UI into a standalone or mobile application (thanks, Webkit). You could be writing server-side code, or scripting your database: CouchDB and MongoDB both use JavaScript for user code. You can run cronjobs in JavaScript, replace make or managed your EC2 instances.
Better libraries, better performance, and more places to run your code.
It’s A Start
It’s not all peaches and roses though.[5] Most of the libraries out there are young, buggy and incomplete. I got Node.js to segfault a few times. There’s no killer framework on the same caliber as Rails, nor anything that comes close to ActiveSupport and a decent standard runtime library (hmm … that gives me an idea). But then, it’s not much different than what Ruby was five years ago, or Java back in the late 90′s. We’ve all got to start somewhere.
I know I’m going to be doing a lot more JavaScript in 2011. And much of it will come at the expense of what I currently use Ruby for. I already shifted the balance towards applications that use more client-side JavaScript and less server-side Rails. How did it work out? better performance and just as easy to maintain. Next, I’m moving the test suite over to JavaScript thanks to Zombie.js.
So that’s my plan for 2011, and you should follow me on Github and Twitter to find out what happens.
[1] Netscape actually compiled server-side JavaScript into bytecode, so it wasn’t all slow. Back on ’95 hardware it felt slow for what little it did. Java Servlets weren’t speed demons either, but on ’97 hardware and with much more promise, they felt fast enough.
[2] Remember when Java was 10x slower than C, but the language of choice for productive developers? Good times.
[3] I didn’t mention jQuery since this post is about server-side JavaScript. But jQuery did show the world JavaScript code can be clean, simple and productive. I think it deserves credit in changing people’s opinion, including of JavaScript as a server-side language.
[4] Node.js is not the first platform to have a good asynchronous story, it’s just the first platform that many people care to use that has a good asynchronous story. And it’s not so much about the asynchronous part as it is about a good, compelling story. Rhino’s story is “we’re JavaScript only in Java” and SpiderMonkey’s story is “we’re not Rhino”.
[5] Bet you didn’t know JavaScript™ is now trademark of Oracle Corp.
2011? ??? IT?? ??? -Javascript- « iphone blar blar
links for 2010-12-30 – The 5th incarnation of Elmer’s blog
JavaScript Magazine Blog for JSMag » Blog Archive » News roundup: Zombie.js, evil.js, and even more JavaScript game engines
SitePoint Podcast #94: Appy New Year! | Food Science and Technology
SitePoint Podcast #94: Appy New Year! | PHP Podcasts
Getting up to speed with JavaScript | Tom de Koning