Five Questions with David Walsh

Avatar of Chris Coyier
Chris Coyier on (Updated on )

There is probably a good chance if you read this blog that you also know David Walsh. David and I hail from the same hometown (Madison, Wisconsin) and have been friends for years. We’ve worked on a few projects together and have written a bunch of double-posts together. Mostly I just bug him with questions I have about PHP and JavaScript and he always is there to help me out. I’m finally getting around to grilling him on a few questions. Read on to hear about client work, pet peeves, and the classic jQuery vs MooTools debate.

Chris: Let’s have your take on this jQuery vs. MooTools debate. You know them both very well, so your opinion matters a little more than someone like me who uses jQuery primarily because it’s the only one I know.

David: This is a very touchy subject for many people but I’ve always been blunt (to a fault sometimes) so I’ll just shoot from the hip. Before I explain my position I’ll disclose that I’m a Core Developer for the MooTools javascript framework.

The jQuery vs. MooTools debate is one that’s oftentimes shrouded by extreme opinions, outright lies, and archaic myths. Unfortunately these views persist so my goal with the answer to this question is to bring everyone back down to earth and get people to set their emotions aside and think objectively about the two javascript frameworks. The same thoughts can apply to Dojo, Prototype, YUI, etc.

The biggest myth about these two frameworks is that the developers and the communities don’t like each other. From my perspective, this couldn’t be further from the truth. I’ve exchanged friendly emails with John Resig with regard to Sizzle, occasionally tweet jQuery’s Karl Swedberg, and never hesitate to throw a friendly jab at Rey Bango when he jazzes me. Relations between our frameworks are in good standing.

Another myth about the jQuery vs. MooTools debate is that a designer/developer needs to pick one and stick with it. This couldn’t be further from the truth and I contend doing so is outright foolishness. Since when was not knowing a programming language/framework a badge of honor? Imagine how many more options are available to a developer that knows both frameworks! I’d go so far as to say that any respectable designer/developer would try other frameworks at the very least. Learning jQuery made me love MooTools even more. To each his own.

The biggest difference between the two frameworks (for 90% of designers/developers, at least) is probably the different syntax. In the end it comes down to personal preference. As a “classically trained programmer”, I much prefer MooTools’ object-oriented approach to jQuery’s structure. I prefer myElement.setStyle() better than myElement.css(). I prefer MooTools’ var request = new Request({options}) to jQuery’s $.ajax({options}). I would also argue MooTools is more modular but we could all go on all day about the different advantages each framework/library has. In the end, they’re both outstanding codebases.

As a member of the MooTools Core Development team though, I have no reservations in saying that jQuery is a nice library. I admire the jQuery team’s organization and the library’s perceived easy learning curve. “jQuery” seems to be the biggest buzzword in javascript right now so cheers to the jQuery team and its community for cultivating that perception.

As a MooTools “insider”, however, I’m excited for what the MooTools team will bring to the table during 2010. We’ll be launching the Forge (our public plugin repository), releasing MooTools 2, continuing to grow MooTools More, featuring more community work, and much more. MooTools FTW!

In the end though, my advice is to make sure you try multiple javascript libraries and drop any negative misconceptions you may have about other javascript communities. You may end up liking one over the other, love your preferred framework even more, or simply bask in the knowledge that you know more than one.

I think Dojo’s Peter Higgins says it best: It’s just javascript!

Chris: You work at a company who works on lots and lots of sites for lots and lots of clients. Do you like it this way? Or would working on a single giant project be better for you?

David: I think the best word to describe my day job would be “unpredictable.” My employer has approximately 100 active web clients which means that on any given day I could get a phone request for support, new features, etc. from 100+ people. Obviously not everyone calls on the same day but planning my schedule can be hectic to say the least. It can be hard to focus on a given task when just the threat of getting a bunch of phone calls slows me down. I’ve had many days where my scheduled tasks don’t start until 2:00 pm (5 hours into the day) because of emergency support calls or client meetings. Sometimes the thought that anything can happen on any given day can be paralyzing and frustrating.

The advantage to working in that type of environment is that I’m exposed to many types of clients, businesses, and technical requirements. I’ve picked up a bit of ColdFusion, jQuery, SQL Server, ASP, IIS trickeration, and many other skills I wouldn’t have dreamed of knowing (or wanting to know). I’m proud of the knowledge I’ve picked up, albeit begrudgingly many times, by being exposed to so many websites.

Ideally I’d like to become more focused on around a dozen clients. Doing so will allow me to more closely build client/vendor relationships, take more time to improve code quality, and better (and more frequently) analyze the client’s website. As you can probably tell with my blog, I’m obsessed with continually improving a website. I ask myself questions like: “How can we make this better? What can I add to take this site to the next level? Which pages are getting the proper attention? What pages do we need to get more traffic to and how can we accomplish that?” It’s very difficult to keep that mindset when working on several dozen websites due to varying time constraints, budget constraints, and trying to coordinate with so many different people. Unfortunately with working on so many websites I feel as though I have a lot of “unfinished business.”

Hopefully I can get start to focus on fewer websites soon.

Chris: What is your biggest pet peeve in web design? I know there is one thing you always get on my case about… any others?

David: My biggest pet peeve is when designers and developers don’t give clickable elements the “pointer” cursor. Labels, buttons, and elements with javascript click events should all be given the pointer cursor. TELL the user they can click on something! It bugged me so much that I wrote javascript custom events in both jQuery and MooTools that automatically gave elements with a click event the pointer cursor.

Here is a brief list of other web design habits that bug me:

  • Using javascript to fix a server side issue.
  • Using AJAX just to use it.
  • All-Flash websites.
  • Multi-line CSS (CSS files shouldn’t be hundreds of lines!)
  • Complete disregard for IE6 (It’s not dead yet, even if you want it to be!)
  • Links that say “click here”. (If you’re descriptive with your link text, you shouldn’t need to say “click here”)

Obviously each of the above peeves have their place. If you’re coding a website for an older demographic, “click here” links are like gold. My blog’s traffic is ~1% IE6 so I don’t spend too much time making my site friendly to those people. Not supporting IE6 on a client website with a much broader audience is sinful and lazy, in my opinion. Don’t cost your clients business just because you have an IE6 complex!

Chris: We’ve talked a few times about a strange phenomenon in blogging. If you spend 20 minutes on some dumb easy post, it ends up being far more popular than a post you worked for 8 hours over the weekend working on. What’s up with that?

David: I think a lot of factors come into play here. First, most designers and developers have really busy days and choose to pass on reading (and sharing) novel-length posts. Second, I think that we (as blogging developers) tend to fall in love with our own rhetoric and get too detailed with our posts. Another reality is that readers tend to want the “quick fix” or “snippet” that will take their websites from a 3 to an 8; we all know that a long post wont keep the attention of those people.

What’s really important is that we not write simply to please the masses – we write what interests us and what we hope others may like. From there we get feedback (or flamed), begin discussions for improvement, and hopefully come out of each post with a better product than we had originally. All that said…it still sucks to spend a long time on a post and watch it struggle to find an audience!

Chris: If you couldn’t use PHP for a server side language on a project, what would you pick?

David: It really depends on the scope of the project, the budget, and future maintenance considerations. Any good developer really does what’s best for the project regardless of personal preferences. If I were starting a small personal project and couldn’t use PHP, I’d likely use Python. Python is fast and becoming more popular with mainstream websites. Google uses Python quite a bit. If I were starting a huge project I would likely choose Java or Ruby. Both boast large, passionate communities and have been proven reliable.

One exciting server side technology gaining momentum is our favorite client side technology: javascript. MooTools has a server side build and MooTools contributors Jabis Sevon and Mark Obcena are developing a MooTools server side framework called Raccoon. I’m excited for the future of server side javascript!