Javascript: Viewing Source and Understanding Source
Posted by Maciek Fri, 18 Aug 2006 14:17:08 GMT
Did an entire generation of Javascript programmers learn from viewing source?
In my last Javascript article I argued that Javascript has historically lacked good online resources for programmers who wanted more information, examples and design patterns for the language. Jeff Atwood at Coding Horror has written an insightful piece about the importance of being able to view source, and in particular credits Javascript’s rise in popularity to being able to view the source code (while right in the browser). While I have never really given much thought to this idea, he gives a convincing argument. It would certainly represent a powerful (if at times crude) alternative to comprehensive documentation and literature.
I would like to add some more to this line of thinking, however…
Is viewing source really enough to grasp the internals of the language? Can we learn by limited and often flawed examples alone? I’ve seen the same bad piece of code, flaws and all, copied and pasted across thousands of sites without anyone giving a second thought to whether the code they are pasting is really well-written. I would argue that while it may have been enough to fuel the surge in Javascript usage, viewing source would not necessarily give us well-informed Javascript programmers. Atwood provides a clue to why the quality of Javascript seen in the wild has improved over the years: “Code Darwinism”. Heck, I’ve never heard of Javascript being taught anywhere formally (except perhaps as a side note to the teaching of other languages), so this sounds about right. Think about this for a moment, though: Your bank’s website uses Javascript. Can you stomach the thought of financially critical code having come about through Code Darwinism? Lucky for us, Javascript doesn’t power the whole thing, but still..
Javascript has had a rather ragtag rise to prominence and validity. Only recently have we seen some good tools appear to help Javascript programmers understand why their programs act the way they do, to figure out why the “this” keyword is acting the way that it does, to catch that pesky undefined value, etc. At a teleconference at work we recently had a client ask us whether we had something against Bill Gates (we were giving a demo of our product using Firefox rather than Internet Explorer). While our actual response was diplomatic (something about making it look right in Firefox first, adjusting for IE, and then being able to support a wider range of browsers as a result), to myself I was thinking:
It’s the development tools! It is no longer enough – and we can’t develop complex applications – simply viewing source and using alert().
As far as I know, to this day IE remains an almost hostile development environment to Javascript programmers. Trying to debug misbehaving Javascript code with it, even if one has access to Microsoft’s “debugger”, is pretty awkward and clunky. If there are any commercial tools for IE that solve this, well, that’s hardly widely available and well-known, and I would put money on it that they are not cross-platform.
Until recently, Venkman was the only interesting Javascript debugging/reflection tool available, and while pretty amazing in its own right was rather tricky to use and difficult to understand (due to, again, lack of really good documentation and support). Most people using Mozilla or Firefox probably still use a combination of alert() and the javascript console to catch errors and inspect code up close. Safari has gained some nice debugging features as of late, and Opera’s console has improved slightly as well (though it needs better-phrased error messages). The best tool available at writing for this task is Joe Hewitt’s Firebug, which in recent revisions goes so far and beyond other tools that it might as well be considered a quantum leap.
Or should I say evolutionary leap?
