JavaScript Frameworks for Modern Web Dev

JavaScript Frameworks for Modern Web DevI am thrilled to announce the publication of my newest book, JavaScript Frameworks for Modern Web Dev, available now from APress!

A year ago my friend and former co-worker Tim Ambler approached me with a project: a list of strong frameworks and libraries in the JavaScript space that can each be effectively introduced in a single chapter. Over the last twelve months we wrote numerous drafts and revisions, and created a somewhat frightening amount of source code for these sixteen topics:

  1. Bower
  2. Grunt
  3. Yeoman
  4. PM2
  5. RequireJS
  6. Browserify
  7. Knockout
  8. AngularJS
  9. Kraken
  10. Mach
  11. Mongoose
  12. Knex and Bookshelf
  13. Faye
  14. Q
  15. Async.js
  16. Underscore and Lodash

Obviously, the scope of each topic is greater than its chapter, but the book’s goal is to be a quick but thorough introduction to the core concepts in each framework and library. The source code is non-trivial and executable, so a reader can see concepts in action while following along in the text.

Some of the technologies covered have aged (like fine wine!), and some are much younger, but we believe that each has staying power and stands well among its peers. Between us we have used all of these technologies in our own projects and in production deployments, and while we cannot claim complete expertise, we humbly submit that, to the best of our knowledge, the information here is both sound and practical.

We sincerely hope that this book brings much value to you and your team!



Browsers on Twitter

I combined screenshots of the four major browsers on Twitter.  The results are very interesting from a social media perspective:

  • IE tweets the most (followed by Firefox, which tweets about 1/3 less than IE)
  • Firefox by far follows the most tweeps
  • Firefox has the most followers (followed by Chrome and IE, which are comparably close)

Browsers on Twitter

(Click on the image for a hi-res version.)

Debugging client-side ASP.NET validators

I used this JavaScript snippet to debug an ASP.NET page that was swallowing client-side validation errors (in an UpdatePanel *gag*). I would click a button to submit a form, and nothing would happen — no visual indication of which validators were failing — so I opened the Chrome console and quickly iterated through the validators to locate the offender.

for(var i in Page_Validators) {
  var v = Page_Validators[i];
  if(v.isvalid) {

If you want it on one line (easy to paste into Chrome), refer to my github gist.

If you want to read more about ASP.NET client-side validators (I dunno, maybe you have insomnia), check out the official MSDN documentation.

The One True Browser

For a long time, I believed that Firefox was the One True Browser.  And for a long time it was.  The competition consisted of IE, Opera, Chrome, and Safari.  IE is… well, all web developers know that Microsoft has spent the last few revisions of IE making up for the sins of IE6; sins which have provoked the ire of web developers (myself included) for many years.  IE7 supported basic web development tools, but no version of IE to date has supported cross-computer synchronization, and the user interface of IE has always been a pain.  Opera has always been fast, but was late to the game with good developer extensions, and has always had some rendering “quirks”.  Safari for Windows has traditionally been clunky and slow, which detracts from the experience even though Webkit is a very nice rendering engine.  Like Opera, it also lacked good developer extensions at launch.  Chrome was promising–very fast, lightweight, fault tolerant, and used the Webkit rendering engine, but its extension pool was initially thin.  Firefox has always been a memory hog, but of all browsers it had the most robust developer tools available and a decent rendering engine, which were my primary needs.  The FoxMarks/XMarks extension provided browser synchronization between computers, and now that functionality is supported with a Mozilla plugin (I believe this will be a native feature of Firefox 4).

A few months ago I started using Chrome at work for a different browsing experience, and it has grown on me.  I have been exploring Chrome extensions, which, much to my delight, now include tools that are roughly equivalent to the developer tools I have been using in Firefox.  Chrome also supports native bookmark, browsing history, form data, and extension synchronization across computers.  It is faster than any other browser I have tried (including IE9 beta), and is just pleasant to use.

I don’t know if Firefox 4 will reclaim the coveted title, or if IE9 will actually redeem Microsoft’s tarnished brand.  But I hereby announce that Chrome is now the One True Browser.  For what that’s worth.

IE does something better than Firefox, hell freezes over

Like most web developers, I write markup and Javascript that will work on both IE and Firefox, and if I’m particularly ambitious, Chome and Safari.  I’ve been writing a lot of Javascript lately, which has been a good learning experience but frustrating at the same time.  I don’t have the luxury of using jQuery on my current project — I am pretty much restricted to Prototype for legacy reasons.  I was in the throes of reconciling a piece of code that copied values from one set of input fields to another, then accessing the innerHTML property of the target fields’ containing div.  I was doing simple value assignments ($(“textBox1”).value = $(“textBox2”).value), and in IE everything worked like a peach.  Then I tested in Firefox and, to my amazement, the target input fields remained blank, even though FireBug assured me that the values were in fact being copied.  I was certain I was making a mistake somewhere in code, and spent an hour or so meticulously pouring over every line of Javascript, attempting to find the roadblock.  In desperation, I turned to the Google in search of an answer.  What I found surprised me enough that I felt compelled to write this post.

Firefox does not reflect dynamic DOM changes in the innerHTML property of a given DOM element.

This means that if you set the value of a text box to “123”, then call the innerHTML property of the DOM element that contains the text box, the value of the text box according to innerHTML will appear to be whatever it was prior to your alteration.  In practice, when the page posts back to the server, the value will actually be “123” and not what innerHTML reports, but the fact that Firefox ignores the change gives me yet one more gray hair.

To get around this glaring oversight, I had to use the setAttribute() method on the DOM input element:

$(“textBox1”).setAttribute(“value”, $(“textBox2”).value);

This accomplishes both tasks — updating the actual input value and changing the innerHTML property accordingly.

You’ve won this round IE… you’ve won this round.