Counting Keystrokes in Code

I can’t tell you how much this irks me:

$A(someNodeList).each(function(node) { alert(node.nodeName + ': ' + node.innerHTML); } );


This is a horrible style of code being popularized by the very trendy Javascript library, Prototype.

Let me say that I am absolutely thrilled to see an army of smart people really going to town with Javascript lately. I mean it really seems that there isn’t a single nook or cranny that hasn’t been fully explored and documented by someone out there somewhere. Javascript is coming into its own as a real development language thanks in part to some folks showing the world that it’s not just for “scripts” and “glue code”, but in fact is probably the new user interface language for the Web, and it’s here to stay. We’re seeing whole toolkits and class libraries coming out in Javascript. Great stuff.

But this syntax is terrible. It pretty well guarantees that the code is unreadable by someone that has not taken the time to sit down and learn Prototype first. It makes the library noticeably less accessible to the intermittent developer who needs to quickly get in, understand a piece of code, fix a bug or make a quick change, and get the heck out.

Here are just some of the problems:

1. Guess how long it will take you to forget what $A('') does? Not very long. Did you know there is also $R(''), $F('') and about 3 other one letter function names too? What do you suppose they do?
2. Some languages have had iterator functionality built into their grammar, with phrases like “for/each/do”. Prototype tries to add this as a method call on a collection. Why? To save the 2 extra lines of code it takes you to write out an explicit FOR loop and to make using nested statements and function literals easier to use. And the benefit of that is? Minimal at best. We’re talking handfuls of keystrokes per block of code.
3. One of the things that fueled the adoption of Web technologies like HTML, CSS and Javascript in the first place is that they were EASY and ACCESSIBLE – therefore everyone adopted them. We collectively chose a verbose text format for all of these protocols and languages versus MUCH more efficient binary alternatives. We did this because they were human readable and the benefit of that out-weighted the cost of the extra size. The barrier to entry for developing apps dropped significantly and we have all benefitted from that. There’s far more exposure to function literals, closures and class prototypes than there needs to be for the overwhelming majority of developers today.
4. With a loosely typed, interpreted language, the only clue you have as to what you’re supposed to pass into method calls is the verbosity and/or naming conventions of the methods! And we’re using single letter function names?! This feels like a giant step backwards, and very exclusionist. Like “if you don’t know our syntax, you’re too dumb to play with us.”

This reminds me of the old C++ days when developers proudly demonstrated how much code they could cram on one line. People scratching their heads trying to figure out what the difference between b = b++ * 5 and b = ++b * 5 was.

Then one day the development community realised that code readability and maintainability was far more important to the business than saving a number of keystrokes. People starting writing more explicit code again.

Then came Intellisense which pretty much banished the practice of writing terse code. You could actually only type req.wr("hi"); and the dev studio would actually write out for you Response.Write("hi");. You saved the keystrokes, and everyone else knew what the hell you wrote. Even if you didn’t even know the language too well, you could stumble along and understand what was going on.

Even better, you actually LEARNED as you coded, because drop-downs were popping up and getting auto-dismissed as you typed, so that you were seeing property and method names flash in front of you as you typed. It was a sort of learn as you go method.

I learned C# about 2 years ago and have never picked up a book, simply because the dev studio has Intellisense.

As far as I can tell, the only pseudo-legitimate reason for developing a library with as terse a syntax as Prototype is that in large code files, you do save some bytes which can be a little bit of an issue since we’re throwing Javascript libraries across the wire with each page load. (By the way, most browsers and web servers support GZIP’ing the Javascript files on the fly so that you’re really not saving many bytes at all by using short identifiers).

But it’s only a matter of time before someone comes up with a great Javascript dev studio that gives us Intellisense so we can save those keystrokes and yet still produce readable code. Someone else is going to come up with a reliable (and automated) way of packing our Javascript so that redundancy is compressed out and we no longer have to choose between the readability of AsArray(someNodeList) and the small size of $A(someNodeList).

When that day comes, will all of these new fangled Javascript libraries be re-written so they are actually readable and maintainable by someone that does not live in them every single day?

I think that while there’s some really good work going on in the Prototype (and other library) teams, the terseness of the syntax could spell its own doom as soon as someone comes along with a library that does just as much, but with an easier syntax, Intellisense for “keyboard efficiency” and packing for “over the wire” efficiency.

Somehow feels like we’ve learned this lesson before… Seems very familiar indeed…