The html times

Elegantly Powered by Google

Javascript: Frameworks, Idioms, and Idiots by Joshua Clayton March 31st 2009 Delicious

Relevant Links

Javascript: The Good Parts

The Great Debate

There’s been a debate recently over Javascript frameworks. Prototype, jQuery, MooTools, JS.Class… the list goes on. The options are seemingly endless, and there are some that I feel are better than others. What I’m more concerned with these days is not what the frameworks can do (because they can all essentially accomplish the same thing) but how the syntax feels and how it encapsulates Javascript in general.

Java in Ruby

Chris Wanstrath (one of the authors of Github) posted some Ruby code a few months back that really encapsulates my problem with most Javascript frameworks nowadays.

  1. def try; end
  2. def catch(*args) end
  3. def RuntimeException(*args) end
  4. def re; end
  5. class Anything; def method_missing(*args) end end
  6. def getDialog; end
  7. def WebResponse(*args) end
  8. def atUrl; '' end
  9. def assertEquals(*args) end
  11. # now for the fun part
  13. try {
  14. beginAt(atUrl);
  15. }
  16. catch (RuntimeException re) {
  17. log.warn("Cant assert 503 response, using crude websphere workaround");
  18. assertTrue(re.getMessage().contains("IOException"));
  19. assertTrue(re.getMessage().contains("503"));
  21. return;
  22. }
  23. WebResponse webResponse = getDialog().getResponse();
  24. assertEquals("expected service unavailable response for url: '" + atUrl + "'", 503, webResponse.getResponseCode());
  25. assertEquals("should be no content for this url: '" + atUrl + "'", 0, webResponse.getText().length());

Here, he’s able to warp Ruby into what syntactically looks like Java. Gross, huh?

Most developers, when learning a new language, take prior knowledge and, regardless of idioms, apply familiar coding styles to the language they’re learning. I wouldn’t consider this necessarily a bad thing, as long as developers are able to eventually adopt the best practices of that language. For example, it doesn’t follow convention within Javascript to underscore variables (unless they’re “constants”). Method names and variables in Javascript are camel-cased throughout the language and convention hints to us that we should follow this. The inverse applies for Ruby; method names are lower-cased and use underscores to separate words.

Learning Idioms

Once a C# developer transitions to Ruby and has lived within only Ruby for a few months, it’s pretty likely that camel-cased method names will be a thing of the past and dynamically-typed languages will feel… natural. Until then, it’s a lot of trial and error, banging your head against the desk, and cursing the gods. Does the path from one language to the other mean you shouldn’t learn the idioms of the new language? I think not.

So, if a Ruby developer or a Java developer starts programming Javascript, should he take the best practices from his server-side language and apply it? This question is where things get tricky.

Stop Being Lazy

Instead of using a framework to create a class, why not do it yourself? Many “Javascript” programmers don’t really understand how to create objects with private instance methods, static methods, etc. but relying on a framework (Prototype, JS.Class) to encapsulate that logic is downright lazy. These “gimmes” deter the programmer from learning how closures work, how to use anonymous functions, and the other idioms of Javascript that are essential to using the language well. There’s a reason that Ruby doesn’t act like Java just like there’s a reason Clojure doesn’t act like Ruby. They are different languages targeting different purposes and different programming styles. Pure Javascript developers (I would hope) scoff at frameworks like JS.Class and Prototype (at least, the aspect of trying to make it a classical-based inheritance structure) because they morph the language into something it’s not.

What Does All This Mean?

I encourage you to learn Javascript and then make your decision on a framework. Javascript: The Good Parts is an excellent read and gets into some of the nitty-gritty of how to achieve some of the same object models as you would expect any object-oriented language while still preserving the language itself. Once you’ve lived in Javascript for a while (outside of a framework like jQuery or Prototype), you’ll be able to more easily judge what framework feels better.

My Background

I started fiddling with HTML about 12 years ago; after that, I rewrote the game “Drug Wars” on my TI-83+ graphing calculator, and learned VB4 before I graduated high school. I’ve written classic ASP, VB.NET, and C#. I now “live” in Ruby but delve into CSS (with the Blueprint CSS framework) and Javascript every now and then. I prefer jQuery now, but I used (and loved) Prototype after I started playing with Ruby on Rails. What made me switch? I read that book and started to understand what Javascript was really about (instead of molding it into with what I was comfortable). Since then, I feel I’ve become a much better Javascript developer because I actually took the time to learn the language and not just the framework.