Thoughts on JavaScript: The Good Parts

At a friend’s recommendation, I recently picked up Douglas Crockford’s classic book, JavaScript: The Good Parts:

Most programming languages contain good parts and bad parts. I discovered that I could be a better programmer by using only the good parts and avoiding the bad parts. After all, how can you build something good out of bad parts?

— Chapter 1

The book only has a first edition, published in May 2008 – five years ago. Obviously, with the ES5 and forthcoming ES6–7 standards, several things have changed:

  • Globals, much bemoaned by Mr. Crockford, are now universally regarded as poor form. A few solutions for avoiding the problem exist today, and ES6 modules provide a good pattern for the future.
  • ES6’s let allows for block scoping.
  • Modifying built-in objects’ prototypes is quite common in the book. For example, from Chapter 4:

      String.method('trim', function () {
          return this.replace(/^\s+|\s+$/g, '');
      });
    

    This inserts a trim method on the String’s prototype through a previously defined method function. Developers frown upon this sort of behavior because it modifies the runtime, leading to potential bugs. Libraries like Underscore.js are preferred.

  • All examples physically output to the DOM because console.log() didn’t exist at the time. Yikes.
  • The fifth chapter examines inheritance. I don’t fully understand all the patterns discussed, mostly because I see and use the constructor-prototype pattern most:

      var Mammal = function (name) {
          this.name = name;
      };
      Mammal.prototype.sayName = function () {
          return this.name;
      };
    
      var dog = new Mammal('fido');
      dog.sayName(); // fido
    

    ES6’s class provides syntactic sugar for this pattern, thus encouraging it. However, in a recent presentation, Mr. Crockford admits that he doesn’t use this or Object.create() at all, instead showing this example:

      function constructor(spec) {
          var that = other_constructor(spec),
              member,
              method = function () {
                  // spec, member, method
              };
          that.method = method;
          return that;
      }
    

    It seems rather theoretical to me: I don’t understand its practical applications. But, I’m relatively new to the language.

  • The seventh chapter, which covers regular expressions, is the best source on the subject that I’ve read. It proves extremely informative to JavaScript’s often mysterious implementation.

JavaScript is in a far better place today, undoubtedly in part from this book. Yet, much has changed over the last five years; the book’s content shows its age. There are new good parts and new bad parts. I wish a second edition were in the works.

There’s still something to be gained: Mr. Crockford’s experience and critical approach on the subject is the best part. I highly recommend it for anyone who’s new to JavaScript.

Grooveshark

Dear music fans,

Today we are shutting down Grooveshark.

Thus began a message on the music streaming website on the morning of Thursday, April 30th. I remember listening to Andrew Bird’s Useless Creatures late Wednesday evening.

I must have heard about Grooveshark back in 2009. I started using it seriously in 2010, when I worked with Dave. We’d put on some rap – Deltron 3030, MF DOOM, Madlib – and listen to it all day long. It quickly became one of my most visited and most used websites.

When coworkers asked what music service I used, they’d give me a baffled look when I responded “Grooveshark.” Perhaps its interface wasn’t as good as Rdio’s; maybe its music selection wasn’t as good as Spotify’s. But, it was the thing I knew. I mastered its sometimes odd behaviors, understood where to find select tracks.

It was all so sudden. Typing “groo” into an address bar and awaiting auto-fill is still a strong reflex. A reddit user commented:

Whelp, there goes 5 years worth of playlists :/

Grooveshark faltered after a long legal battle with record label companies. Thousands, if not millions of people actively used the site. One can’t help but think of other high-profile web services that were shut down for one reason or another. Google Reader comes to mind. It’s the ephemeral nature of the web. Data is backed up. Servers can withstand thousands of connections. But can this thing withstand time itself?

It’s tough to come to terms with, especially as someone who makes websites for a living. Seeking permanence may be a bit conceited. I suppose positively impact people’s time on the web, in whatever small way, is what we should strive for.

Iterative Design

A lot of my day-to-day production work involves coding up designs into living HTML, CSS and JavaScript. Portland Cafés, my little side project with David, is different.

We initially focused on a working web app; it must function to be of any use. I began with Bootstrap, which was an easy way to throw together some markup and styles. As the site grows it becomes apparent that Bootsrap doesn’t solve our UI problems. Its design doesn’t fit the site’s content, too. But, there’s tests to write, performance to improve, and features to polish.

It’s an exercise in patience. I was finally able to roll out a new menu design last week, which improves navigation particularly for mobile visitors. Baby steps. It’s a new kind of challenge, but a rewarding one.

Commit Messages

Fellow Needmore alumnus Dan Manchester recently wrote about the importance of good commit messages. He provides some quality pointers that seem subtle but significantly improve a project’s history.

Rule 2: Commits should start with a verb.

Specifically, every commit message should start with a present tense action verb. If we think of a commit message as a sentence with the implied subject of “This commit…” , it is our role to write the rest of that sentence…

Having these verbs at the start of commits not only makes them grammatically uniform, it also makes scanning through commit logs easier.

Looking back on a few recent projects, I realize I don’t author commits consistently. Version control is tangential to the task at hand; using it well requires thoughtful communication and constant vigilance. I’m sure current and future teammates will be thankful for seeing even some of Dan’s techniques into practice on our projects.