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.
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?
CHRIS: You have created aJAMES: 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.
Nice talk, Thanks
I quite recently stumble on to James blog and i was instantly taken back with his knowledge but also his writing style. I’ve been fumbling my way around the web for the last 10 years commercially and seeing the quality of James work i really wouldnt be shocked to see a book or two from James in the future.
Love you work James, keep it up ;)
Thanks for the First post out of 5 Chris! Great questions and answers and keep up the good work James
Thanks for this post, great interview. Discovered James’ blog, subscribed and looking forward to more!
thanks much :)
James is a “JavaScript Nerd”, I really enjoy his posts. Thanks Chris for this interview.
Subscribed. Great interview :-)
Great interview, learning to write code is something I’m learning to do myself and you just have to put the time in to nail it, like anything else.
I agree with learning raw JavaScript first. What if something goes wrong in the library/script itself? Then you’d either have to google information hoping to find something that works or you have to ask/pay someone to do it for you.
As an aspiring web application developer, I feel learning the core technologies are absolutely crucial when it comes to fixing bugs and errors that pop up out of nowhere.
Thanks for interviewing me Chris, some really great questions; I enjoyed answering them! :)
Thanks for the comments everyone!
Great interview. And thanks for the link to James’ blog – I may be spending more time there than I do at CSS-Tricks ;-)
I knew Jame is going to be interviewed for javascript part!!!
Cool stuff! I wish I had realized I would have had such a love for the web at that age.
Thanks for doing what you do :D
Great interview..some good points. I agree with the library part, they are making us lazy and killing our merit to learn raw javascript. Libraries are things in disguise…after few days you will learn what damage they cause to you. They are like arsenic, slow poison, will slowly kill your skill to write raw javascript.
By the way, I bet it will be David Walsh on Friday!
Great interview. I’m also glad you brought up using something like jQuery while not being to big on coding raw Javascript, because that’s exactly the boat that I’m in. Great at implementing and using jQuery, but pretty much can’t write raw JS. Good question!
Interesting read.
To have such a focused mind at such an early age is incredible. Plus ‘get a bit annoyed when having to work and collaborate with other people’ and wearing sunglasses reminds me of some ASD kids I know. I wonder if James is ASD?
wow! I was really inspired of James…. really a lot things to learn from his work….
Nice interview.
very nice interview, and James thanks for the words, and Chris it was a very nice idea posting these interviews, thanks a lot. Peace.
James, I think you’re jumping a bit too easily to ‘ought to be’ on the last question. That does indeed seem like one fine solution, but it might actually end up hurting overall load time. Including your js-specific CSS in your main style sheet, unless there’s just tons, will have an infinitesimal penalty on those who don’t allow Javascript, and (at least ‘potentially’, and probably ‘usually’) a larger one to your more significant user base, which may have just doubled their HTTP requests.