BeckleyWorks

OPJ: Other People’s JavaScript

I had been writing JavaScript for years and making things work. Although I remember reading some books along the way, a great deal of what I knew came from looking at OPJ and figuring out how their code worked.

I thought I had a pretty good handle on it. I could make anything in my apps work, and what I didn’t know, I’d Google, study some OPJ and invariably get the job done. If I understood the OPJ, I assumed I had just learned a new thing and thereby understood JavaScript even more.

JavaScript is a language that people don’t bother to learn before they use.Douglas Crockford

I knew there were parts of JS I didn’t know very well. I didn’t think I had much use for them. I’d get around to them eventually. I used JavaScript for specific tasks and my toolset seemed more than adequate.

I was shocked then to learn that there is much about JavaScript I didn’t know I didn’t know and there can be big problems with learning from OPJ:

Often OPJ is written by well-intentioned people who haven’t learned the language.

OPJ comes from people from all walks of life, knowledge and ability. A lot of code out there is outdated or poorly written or both. They might use eval() or document.write(). They might use single-letter variables everywhere and like to forgo brackets. They might not know that’s terrible practice because they too learned from OPJ.

Bad OPJ looks the same as good OPJ.

There’s no way to tell if OPJ is bad by how it looks. It all looks like JavaScript, and if it works, how do you know what’s bad about it? No one adds a comment saying “Don’t ever use the awfulness I did here, and here’s why: blah blah blah”. Very likely, they’re happy with the fact that it works.

Bad OPJ can look like other languages are supposed to look.

Often, OPJ is written by someone who’s really good in another language. In PHP, for example, there are religious bracket style wars. Whether the preference is K&R, GNU, Allman, or something else, in PHP, agreeing on a style allows groups of coders to more effectively work on each other’s code. It has nothing to do with whether the code works or not.

In JavaScript, if someone uses Allman instead of K&R, their code might look fine and work, but that style can also break your program. There’s no way to know by looking at their code that JavaScript interpreters can add semicolons to line endings and cause catastrophe.

Man up and learn the language.Crockford

So say you discover this mess and decide to really learn JavaScript. Do you go get a book or scour the web?

Books can be hit or miss. The web is even worse.

There are hundreds of books on JavaScript and thousands of sites. It’s a minefield. Depending on when the info was written and by whom, they can range from best to worst. Again, unless you know beforehand what’s good and bad practice, it can be very hard to tell the difference.

How do you start to really learn JavaScript?

IMO, a good place to start is to watch Douglas Crockford’s talk called, “JavaScript: The Good Parts”. If, like me, there are things in that one-hour talk you didn’t know, then read his short book. He calls it a “cranky pamphlet”.

A much more complete book is JavaScript: The Definitive Guide by David Flanagan. Crockford calls all of the other JS books out there “terrible”. He calls this one “less terrible”. Quite the comedian.

Once you start learning more “good parts”, you’ll gravitate to good sources. You’ll also see how awful some of OPJ (and your own code) is. It’s painful. Eventually though, JavaScript becomes a much better language than you didn’t know you didn’t know it was.