The Main Reason For JavaScript Unreadability

One of the things that I have noticed about JavaScript is that there are many ways to solve the same problem (sometimes I even think of it like perl’s answer to browser-side scripting); one one side, this is definitely a good thing.

However, not only are there many ways to solve the same problem, but everyone that tries to solve that same problem produces JavaScript code that is so radically different from any previous attempt at the problem that it makes these problems seem more difficult than they really are.

What do you mean?

After poking around with raw JavaScript enough and looking at other people’s raw JS code, I can see that not many people have any clue what the best-practices and coding styles are.  This means that a huge percentage of the JavaScript code out there is just a bunch of hack.

Hack? Who said anything about hacking?

Not “hacking”, silly…

In modern computer programming, a “hack” can refer to a solution or method which functions correctly but which is “ugly” in its concept, which works outside the accepted structures and norms of the environment, or which is not easily extendable or maintainable (see kludge)Wikipedia

If you come from a software development background, you know what hack code looks like and how fun it is to try and read it or learn anything of consequence from it. So?  So what? Read on.

The Root of the Problem

Why doesn’t this problem exist as much in languages like Java/C++ and other Object-Oriented languages. Well I think that it’s due to the nature of the JavaScript language; it’s inheritance pattern is prototypal and not object based.

As we said in another article ‘JavaScript Is Not “Truly” Object Oriented‘, the difference between prototypal and object-based inheritance is the same difference between a “HAS-A” relationship versus a “IS-A” relationship.

Anyways, since there are no definitive classes, there is way less enforced structure on coding styles and conventions; there is a reason for this though, keep in mind that JavaScript is a scripting language!

Yeah, we all know that when the JavaScript language was developed they might not have expected it to be used so much; however, in today’s world, JS is used very heavily.  Many applications are written entirely in JS!

Wouldn’t it be nice if a newer version of JS supported classes? It would give programmers a way to funnel their JavaScript coding styles! However, crap-in always equals crap-out.

JavaScript Libraries – A Partial Remedy

Thank God that someone had an idea a while ago to make a sensible collection of JavaScript code into what we now know as today’s Javascript Libraries and Frameworks!

This helped out somewhat. People started to use these libraries to un-compicate their coding lives by not worrying about browser differences or making ugly calls on the ‘document‘ object to manipulate and query the DOM.

Libraries like GWT, YUI, Mootools, JQuery, Dojo, Prototype, and any of the other tons of JS libraries out there do different things to make your coding lives easier and more readable. Google Web Toolkit (GWT) is a java based HTML/JS generator where you write all of your interface code in Java using AWT and Swing-like coding convention; mootools has a simplified “Class” object that you can “extend”.

Quit Complaining if You Don’t Have a Solution

Ok so my proposed solution is for everyone that’s not using a JS framework or the framework doesn’t support some type of code organization to use the Douglas Crockford’s JavaScript Module Pattern. It gives you a way to organize your code into something that may make a little more sense.

Leave a Reply

