Programming on Tectonic Shifts, and My Move to JavaScript

by Mike Levin SEO & Datamaster, 05/30/2009

NOTE: I ended up going with Python and not JavaScript. At the time I wrote this, there was no node.js. If there was, my decision might have been different, but in the meanwhile, I had totally fallen in love with Python.

I’m motivated to put a blog post together about a unique career-adjustment experience I’m going through, so that I can share it with any others who find themselves in the same boat.

I’m a casual-programmer who stumbled into the VBScript/IIS trap because it was so easy to get started. Low barrier to entry, experiential and code-base lock-in as they move you along the path to .NET, at which time I panicked and bolted. That was around 2005, and since then the only significant new programming I did was HitTail, which is ASP Classic tweaked to extraordinary levels of performance.

But professionally, it’s time to take the next step, but I’m not ready to blindly jump onto the LAMP-stack bandwagon, because “Fool me once, shame on you. Fool me twice, shame on me”.

After my first programming experience (or second, if you count AREXX on the Amiga), I don’t particularly trust my career to a cobbled-together open source accident, now with proprietary underpinnings, any more than I do Microsoft. What mistakes lie before me? Is the popular-wisdom PHP language really a good place to invest my career, even though Facebook was developed on it, and there’s a massive code-library that could accelerate projects? Now that Sun owns MySQL, will it still be free as in beer AND free as in speech? Why build on top of accidentially connected stuff that undergoes such tectonic shifts? Additionally, becoming a Unix-geek is a HUGE investment, and how much life is left in it with massively multi-core hardware on the horizon? Or am I thinking too far ahead for practial concerns?

THIS is what this blog post is about. Where to invest my precious discretionary after-work and weekend time where ACTUALLY learn to program? I’m nearly 40 and can only do this so many times. I want to make decisions that I will be happy with for the next 5 to 10 years, because re-learning EVERYTHING is not something you want to do more than once a decade.

So, I’m not really even a professional programmer, but I consistently pull off amazing things at the places I work. At Scala, I made a joyful agile programming framework back in like 2000 that used to run almost every aspect of their business shy of payroll. They’ve replaced the content-management side with Drupal and the order-management side with NetSuite. But they have yet to replace my sales-pipeline management and sales-lead development systems, because my solution is so incredibly keyed to their needs that switching risks losing the ability to easily manage their sales opportunities.

It’s fun to sit back and watch the years go by with no better solution surfacing. What I need to do now is reproduce everything good about a system like that, but on a better technological underpinnings than VBScript. Such joyful agile frameworks like the one I built are great for part-time programmers pulling off big projects like this. It’s what’s fueling a lot of the excitement for Ruby on Rails—less time managing code and more time managing real-world matters that the code happens to facilitate.

So is my new programming platform Ruby?

The answer was ALMOST yes. I love the elegance of Ruby. I love the shape-shifting self-describing uber-power of interpreted or compile-at-runtime languages that let you work a certain magic that compiled languages don’t (you can feed entire functions as parameters to another function and “yield” to those functions—FANCY stuff). I love the terse lines of code that are easier to write-from-scratch than keeping a code-reuse library. It’s easy to read. It’s got powerful built-in Regular Expression matching, and simple one-line looping constructs that are useful… well, just about everywhere! I love Ruby Gems, which are like community-fueled super-optimized class libraries. I love the attitude surrounding Ruby, the philosophy and writings of Matz, Ruby’s inventor. I love the fact that it’s the first place that a popular truly JOYFUL agile framework emerged from, and that it was extracted from a real-world project, and that David Heinemeier Hansson, the guy that did Rails, is as colorful and opinionated as Matz himself. Frameworks like this let you work a certain magic that appeals to me, although some system architects poo-poo the methods behind the magic for not addressing massive scaling.

Ruby (and Rails) appeals to me, because at heart, I’m something of a magician-style performance artist and inventor. I loved magic as a kid, and often cobbled together the props from reading about them in magic books. I rarely had the money or transportation to get the real equipment, but I could get balsa wood, glue and paint easily enough. I got a real kick out of performing magic with props I created with my own hands. It not only was more satisfying, but I could tweak them to perfection more easily, because I made them in the first place, and knew every detail about them. For example, I made my own Chinese Sticks with copper tubing and lead fish weights. The lessons I learned lasted all of my life. Even as an application developer, you have to understand everything that’s going on under your application—the entire stack, down into the framework, the language and execution environment, the class libraries and dependencies, the operating system, the hardware virutalization layer (if one exists), down to the hardware itself, including the details of the processors and storage. If it’s native hardware, I need to know. If it’s network storage, I need to know. Only by understanding every detail, can you minimize the amount of code that you write, and out-perform professional career programmers when you do get around to programming.

So Ruby is the obvious choice, right? It suits my personality. It’s got an agile framework better than anything I have the time to write. Why even hesitate?

Well, enter my career as a search engine optimizer (SEO). It’s my job to ensure that websites are doing everything they can to capture the Internet users who are searching on the terms related to the client’s business, for which Google is routing all the visitors. Get it? Search patterns are what search patterns are, and it’s the responsibility of the website owner to adjust their own site, turning it into a net, in order to get into the pre-existing path of these Internet users/searchers. That’s the game. And to facilitate playing that game, one must continually adjust, monitor, test, and adjust again. It’s like fishing with a shape-shifting lure, forever zeroing in on the ideal shape to attract the fish. But the fish themselves are evolving along with their affinity for certain lures

What?! Where am I going with this? What does SEO have to do with a programming choice?

The upshot of all this is that the programming iteration cycle in the field of SEO is so incredibly small, that the ability to adapt and respond quickly is the #1 criteria. I even have a vision for a self-describing ad hoc code system where I can rapidly code, test, code, test, right on my desktop without even a server in the picture.

And Ruby is server-based, meaning you can’t leverage the power of the computer that’s sitting right in front of you in the form of a Web-browser. For that, you would need JavaScript. But even with JavaScript in the Web browser, you have security restrictions known as The Same Origin policy that basically ruins the power of browser-based JavaScript for my purposes.

That boils it down to Ruby vs. JavaScript. Ruby’s limitation is that it’s not the lingua franca of the Web. That honor belongs to JavaScript, because it’s built into the browser, and EVERYONE has to deal with it, no matter what—especially now with the Ajax revolution, and JavaScript’s predominant role secured by Google jumping into the ring with the Chrome browser. Unfortunately on the other hand, JavaScript’s limitation is that it’s not a mature server language the way Java (and to a lesser-degree, Ruby) is, though there are tons of endeavors to remedy this. But only one has the distinction of being coupled to a virtual machine that’s popular and portable, ensuring some level of future-proofing. At the same time, it provides access to perhaps the largest collection of class-libraries in existence. I’m talking about Rhino, an open source project to port JavaScript to the Java virtual machine. And because another key are of interest to me is real real-time, my research repeatedly brings me back to AppJet, the people who created EtherPad, and do real-time right. THEY chose Rhino, and that’s really swaying me towards JavaScript.

On the server, JavaScript via Rhino gives you the future-proofing of a virtual machine, so operating systems like Unix or Windows can theoretically be swapped out for whatever is actually best in the future. But also, it means that you have access to an incredibly large set of canned capabilities in the form of the world’s largest class-library. But even better still, when you look BEYOND the server, it means that whenever you’re handling complex data structures like objects or database records, you can express them in JSON (JavaScript Object Notation), which is basically text just like XML, but which happens to ALSO be the syntax for populating objects and data arrays in JavaScript.

Think about that.

There’s no parsing XML, walking objects, looking at parents, grandparents, siblings and decendents. There’s no XPath nonesense or wayfinding instructions that would confuse Magellan. There’s just pure object dot notation access to values—that can be passed between the server and the Web-browser-based client with ease. For example, you populate a data object on the server. Send it to the browser over a simple HTTP request using the XmlHttpResponse object, which is a funny misnomer because it’s not exclusively for XML, HTTP or responses—and it’s instantly reconstructed and populated into an object in memory on the browser exactly as it existed on the server.

And THAT fact aids immensely in building a sort of server-proxy that I need to get around the browser same-origin policy. It will allow for the best, most elegant and future-proof system where code could execute client-side natively in the browser in some cases where same-origin is not an issue, or is somehow circumvented. OR the code can execute server-side where same-origin is not an issue, but the data can be passed back to the client seemlessly AS IF it executed natively.

Elegant, elegant, elegant!

The important point here is that your programming methodolgoy changes only minimally server-side vs. client-side.

Imagine that.

If you want more reading that has recently really catalyzed my thinking, there are two key articles. The first I came across in my research of how to properly do real-time. It’s this short page about ApJet, the engine behind EtherPad—one of the few non-chat/Mebo/GoogleTalk examples of browser-based real-time out there. And the other that I just discovered today which motivated me to write this article is a rant by Steve Regge who seems to have been going through a similar process as me, but only from a real career programmer point-of-view.

What do you think?