department zed | ramblings from the great white north

As an experienced Javascript coder–which has always been more of a hobby for me, and (up until the past 2 or so years) not a major source of income–I have had the privilege of being around for both rounds of Javascript/DHTML/Ajax development. I get (and have participated in) quite a few debates regarding what to call language constructs, best practices, the desire by most to “extend the language” due to “inadequacies”, etc. etc.

So I thought I’d share some factoids with you. Bear in mind I’ve been creating highly interactive, Javascript-based applications since 1998 (and coding for the web since 1995).

1. I have never, ever had occasion to use the eval statement.

It’s true. If you’ve paid any attention to the plethora of articles on the web about Javascript, undoubtedly you’ve heard about the “evils” of the eval statement. I’ve yet to rely on it.

2. I have only once found a really good use for the Function() constructor.

Again, it’s true. In Javascript, there are 3 ways of defining a function, with the least common being the actual Function constructor (where you pass it a list of arguments, and the body of the function as a string). Only in one situation–which happened to be a server-side, classic ASP application–was the use of the Function constructor actually warranted, and worked very well for the need that I had.

3. Never, in all the programs I’ve developed in Javascript, have I had a need to reference a base constructor without first knowing what that actual base constructor was.

One very popular pastime these days seems to be using the flexibility of Javascript to create a hierarchical “class” structure, similar to the way Java or C# works–in that you can reference the “class” that something inherits from without having to know, at run time, what class that actually was.

What bullshit.

The reality is that Javascript’s flat runtime structure can–and does–handle every situation you’d need in that regard, particularly when you take into account the ability to define execution scope (i.e. the meaning of “this”) on the fly using function.apply or function.call. Speaking of which…

4. I’ve never had occasion to actually use the .apply method of a function object.

…though I wouldn’t be surprised if I ran across a situation at some point. Just like with point #3 above, the reality is that I’ve always known, at design time, what constructor or function I would need to actually use with a change of execution scope–and therefore already knew the arguments I’d need to pass to it. This clearly points at the .call form of the method. .apply is neat and nice but almost always (for me, anyways) has been unnecessary.

…

So…why do I bring this up? Because it seems to me like we are going in circles, yet again, with lots of things that have no business being applied to Javascript being applied to Javascript. Every language is ideally suited to be used in a particular way. When you start trying to apply concepts borrowed from another language simply because you don’t understand how the first language really works, you begin to apply abstractions that have no purpose other than to prevent you from trying to actually learn the subtleties of the language in the first place. You’d never try to implement Java constructs in LISP; why do so many want to do it with Javascript? In the end, you pay for it with both performance hits and with over-arching complexity (i.e. higher maintenance cost).

Always–always–we should strive to understand and take advantage of what the paradigm gives us. It’s more practical, it will always perform better, and it keeps things simple.