As someone who started out doing JavaScript in the 1990s, I’ve been through the dark ages of debugging. Alerts, logging application data into DOM elements, etc. After having been through all that doom, I’m clearly a fan of console.log. I use it all the time. I bet you do too. It’s super useful.
The one downside? Leaving calls to console.log into code that’s being tested (as in, QA) or is destined for production (as in, emergency bug fix.) With Firebug or a similar tool running, you’re fine. Without it?
I’ve been busy (day job x spending a lot of time outside because it’s summer = less time for writing)
Anyway, it’s really good. It’s short, but well-written and focused so it’s an easy book to dive into, digest and integrate into your day-to-day.
One of the things I liked about it is that the topics cover enough ground that even as an experienced/expert developer you can learn some things that you’ve probably never run into in a production environment. Maybe you haven’t dealt with a lot of heavy-duty string manipulation and regular expressions or possibly you haven’t done a ton with build systems. They’re covered here, by experts. You might not be an expert after reading it, but you’ll definitely have enough to go on to start working in some solid enhancements into your own code.
All in all, this is a recommended book for all intermediate to expert JavaScript developers. It will get you thinking about your own code, about convenience and about JavaScript performance in a very fundamental way. That’s good for you, for your users and for the web as a whole.
After relaunching my personal site and realizing all my other sites are in pretty good shape for the first time in forever, I’ve suddenly found myself with plenty of free “tech time” to mess around with whatever I want to mess around with. Which is cool, because, while I appreciate being able to tinker in a very practical manner on production sites and learning from what what works now, I really miss being able to mess around with the newness out there. Sometimes, like with the HTML5 work I’ve been doing, the two can meet, but more often than not the brand new stuff needs to sit on the burner a little bit before it’s ready for prime time.
You’ll see where all of this is going when you see the first topic in this month’s recent reading roundup. Read the rest of this entry »
Rob Larsen will lead an interactive session outlining the basic steps to getting started with using JavaScript using modern techniques. For the beginner it will serve as a road map to using JavaScript with confidence. For the more advanced user it will serve and a forum to discuss fundamental best practices as Rob will be soliciting feedback and discussion throughout.
It’ll be basically a step by step on getting JavaScript onto a page, in a modern, “best practices” way. Starting with attaching the script to the page using the script tag all the way through writing a function and attaching it to an element. Each step will be split into three levels of discussion:
For the beginners each will simply be presented as “this is how you do it”
For the intermediate user it will be “this is why we do it this way”
For the advanced user it will be a question- “where does this fall apart and how can we make it better”
Don’t ask why I’m poking around the wayback machine (that would spoil the surprise,) but if you’ve been around as long as I have and want to reminisce, or never got to experience Web 1.0 as a developer and want to see what all the complaints are about, you should really take a look at Netscape’s JavaScript documentation from 1999.
Here’s one that will confuse the hell out of anyone who started doing this after maybe 2003: Read the rest of this entry »
Conditional Compilation is a handy, Internet Explorer specific method for forking bits of JavaScript. The nice thing about it is that real browsers don’t notice it at all. It just looks like a comment block to any non-IE browser. Which saves the rest of the world from even having to if (IE) { } else { } . I like that.
Anyway, we use it to fix some of IE’s shortcomings. One standard pattern is using it to fake the :hover pseudo-class on inputs in IE6. Something like this:
//IE6 HOVERS simplified//
//this would be a bit different in protection
//but you can see the idea
/*@cc_on @*/
/*@if (@_win32)
var inputElements = document.getElementsByTagName("input");
var test = inputElements.length;
for (var i=0; i<test; i++) {
if (inputElements[i].getAttribute("type") == "submit"){
inputElements[i].onmouseover = inputElements[i].onfocus = function(){
addClass(this, "hover");
}
inputElements[i].onmouseout = inputElements[i].onblur = function(){
removeClass(this, "hover");
}
};
};
/*@end @*/
//END IE6 HOVERS//
I saw this tweet yesterday and was reminded , once again, of how misunderstood the return value of a DOM method like document.getElementsByTagName is. Normally, it doesn’t matter that folks don’t really understand the return value fully, because most of the time the code just works. Where it breaks is interesting, so it’s worth taking a look at it in a little bit of depth.
Typically people do things like this:
var anchors = document.getElementsByTagName('a');
for (var i = 0; i < anchors.length; i++) {
anchors[i].addEventListener("click", beAwesome, false)
}
Common pattern. Get a list of the anchors on the page, loop through and add an event to each.
If asked, I’d be willing to bet most people would assume that the list they’re interacting with is an Array. It’s got a length and you can index it- that’s got to be an Array, right?
