Five Questions with James Padolsey

Avatar of Chris Coyier
Chris Coyier on (Updated on )

If you are like me and commonly find yourself Googling around for JavaScript solutions to coding problems, there is a good chance you’ve come across James Padolsey’s Blog. James is a prolific blogger with a clear teaching style I think we all appreciate when looking for solutions. I’ve referenced his articles many times, for example, when needing to dynamically resize textareas, shuffle DOM elements, or animate to a particular CSS class. All this, and James is an eighteen year old kid!

CHRIS: In the mini-profile on your site, you list your age as 18. That’s a typo right? You know far too much about web development to be green out of High School.

JAMES: Yep, it’s true! I was first introduced to the world of website-building at an even more surprising age of 9, when my dad introduced me to NetObjects and then later, Dreamweaver. Ever since then it’s been a constant learning experience; everyday I learn something new! I guess I should state it more explicitly on my site so there’s no confusion in the future! ;)


CHRIS: JavaScript is clearly the main focus of your personal blog. Is that because JavaScript is what you enjoy writing the most?

JAMES: Yes, definitely! I didn’t actually start with JavaScript though. After, HTML and CSS I slowly picked up PHP and after a while I realised that JavaScript used a similar syntax so I decided to learn it; it was curiosity that led me to JavaScript. I eventually realised that this was no regular “scripting language”, it was a fully featured programming language, capable of pretty much anything.

There’s not any particular feature of JavaScript that makes me like it, it’s just the fact that it allows me to build stuff, from the ground up. I’m normally not happy googling for a solution and then throwing the code in hoping that everything will work together; I prefer being able to create all aspects of a solution so that I get a clear picture of exactly what’s going on. Unfortunately, this is a bit of a weakness of mine, I get a bit annoyed when having to work and collaborate with other people because everybody has varying approaches. No two people will solve a problem the same way; this is both a good and bad thing.

I love programming but I am not a fan of the extreme learning curve involved with many of today’s languages, some of them seem so strange and complicated to me, yet others are perfectly fine. find JavaScript to be a logically structured language, in fact, it’s one of the few technologies I like working with. So, yes, out of all things I have ever written, JavaScript has been the most rewarding and fun.


CHRIS: In a recent review of the book Learning jQuery 1.3, you put forth a scenario of a hotshot interface designer who starts learning jQuery, but never learns “raw” JavaScript, and that this is a serious problem. This is pretty close to my own experience, yet I seem to truck along in my work just fine. Am I ultimately doomed?

JAMES: No, not doomed, but it wouldn’t hurt to learn JavaScript. You’ve probably already picked up a massive amount since you’re using jQuery, which is after all, JavaScript. It’s not that I’m against learning jQuery before JavaScript, it’s just that doing so isn’t ideal. It’s exactly the same as using a CSS framework before you know how to write CSS. Yes, you’ll get the job done, but, will it be as good a job as possible? That’s up to the individual.

My guess is that most people that use jQuery are primarily web designers. They don’t have the time to deal with “raw” JavaScript… Apparently it’s too complicated and it creates more headaches than solutions. Quite a lot of the negativity currently surrounding JavaScript, I feel, was put there to market these new-wave JavaScript libraries, all claiming that JavaScript and the DOM API weren’t up to scratch, plus, JavaScript wasn’t really considered a real programming language until “Web 2.0”, by which I mean the collective realisation that JavaScript can be used to create awesome web applications, not just to make snow appear on the screen!

I’m astounded and impressed at the continual adoption of jQuery amongst web professionals but I am also concerned at the negativity produced. JavaScript is actually a wonderful and powerful language. A large chunk of its bad reputation is due to its evil cousin, the DOM, although most of the DOM’s follies are not its own, but crazy browser implementations of a mostly respectable W3C standard.

jQuery is merely an abstraction, and like all abstractions it will sometimes break or it won’t do something you’re after – when this happens it’s helpful to know exactly what you’re dealing with and how to fix it.

So, you don’t need to learn JavaScript before jQuery, but I wholeheartedly suggest doing so. If you learn JavaScript first then picking up jQuery will be a piece of cake, plus you’ll have the benefit of knowing what’s going on under the hood! It’s only after learning JavaScript and having to mess around the DOM API that you’ll fully appreciate what these abstractions provide.


CHRIS: You have created a URL shortening service. There is a lot of talk recently about how these can be “bad for the internet”. For example, not getting search engine credit for links and unresolved URLs when they close down. What are your opinions on this?

JAMES: I actually agree, they are bad for the internet and popular sites like Twitter don’t help – creating a demand for these services. I only created it as a learning experience. I wasn’t expecting it to be used a lot but surprisingly, even with already existing services like TinyURL, it’s become quite a heavily-used service.

The core of the internet is in the fact it links a bunch of documents together. A URL is the most important indication of where you’re going to end up, so, to the average internet-user, meaningful URLs are invaluable. I’m not against short URLs because of what technical problems they produce (e.g. unresolved URLs) but more the usability side of things. These short-URL services will eventually die, it’s just a question of when…


CHRIS: Unobtrusiveness is a big deal in JavaScript. It seems like the best JavaScript developers spend a great deal of time on this subject. How do you feel about the subject? Do you have any common/favourite strategies you use for making your JavaScript unobtrusive?

JAMES: I feel that buzzwords like “unobtrusive” get thrown around far too much nowadays; many people will just stick it in a blog post title to try and gain popularity. The fact is, it’s not all that complicated: The basic premise is that JavaScript should not be embedded within your HTML; it should all be held within external files that reference your HTML and manipulate it using hooks like a class or an ID. Libraries like jQuery and MooTools can make this process a little easier, but note that using a library won’t guarantee anything.

The line between what is obtrusive and unobtrusive fades massively though; sometimes people can go a little too far in either direction… Having to use classes or IDs at all might be considered quite obtrusive, especially if you’re only using them for the benefit of the behavioural layer (i.e. JavaScript). E.g. having <a href=”#” id=”openNewWindowLink” </a>

A frequently overlooked aspect of unobtrusive JavaScript is the CSS and how it relates to the JavaScript enhancements. If you have an element that is generated via JavaScript then the corresponding CSS should not be in your main StyleSheet. The correct way of doing things in this situation is to use JavaScript to dynamically load a separate StyleSheet, containing all CSS required for the JavaScript enhancements. While this may seem illogical there is a reason behind it; users without JavaScript available to them should not have to waste bandwidth by downloading resources they’re not going to use.

Another aspect is the JavaScript code itself. A change in a website’s content shouldn’t necessarily require a change to the behavioural layer. Your JavaScript should be flexible and capable of checking for multiple scenarios and then adapt accordingly. Additionally you should always integrate error-checking and throw meaningful exceptions. This probably isn’t classed as part of the “unobtrusive” paradigm but is definitely important nonetheless.