Weighing in at 140+ pages of content, JavaScript: The Good Parts [Douglas Crockford] cuts through the obscurities, pleasantries, and filler found in most technical books. Instead, this book dives straight into the heart of the JavaScript language. It presents the clearest comprehensive explanation of what makes JavaScript a great programming language that I've encountered to date. It nails the important concepts, like JavaScript's: object oriented nature, its classless (pseudoclassical) nature, and functional nature. While covering the fundamentals like JavaScript's: functions, lexical scoping, lambdas, prototypal inheritance, and functional inheritance.

This book's size makes it approachable for all audiences, its style is terse and concise. This book has the potential to do for JavaScript, what Richie's inspirational classic the C Programming Language did for the C language.

JavaScript is the programming language of the web (AJAX), and this book will guide you through the good parts of this often misunderstood language - while this book is an excellent reference, it is not intended to replace JavaScript: The Definitive Guide, you'll do best to have both these books on hand.

If you enjoyed (or are considering) this book then you may want to learn more of what Douglas Crockford has to say, check out his great JavaScript video series on the YUI Theater.

I highly recommend this book. View my review on Amazon.

There's no need to whip a dead horse (I've probably been griping about the ASP.NET AJAX Framework for too long), but... Jon Galloway and a group of other notable gurus (K. Scott Allen, Scott Koon, and Kevin Dente) have started a podcast, their latest segment sparked my interest since it covered ASP.NET AJAX and AJAX Libraries / Frameworks in general.

I share their sentiments so I thought I'd post a brief but choppy transcript:

[ASP.NET AJAX] ... does offer some some nice features, they did try to take some of the common pieces of the CLR that [.NET Developers are] used to working with and move that down into a JavaScript library. So you get classes like a WebRequest class that wraps the XMLHttpRequest ... and they have a StringBuilder, and they added methods that we're more accustom with ...

that's wonderful, but I don't find myself needing those extensions all that often. If you want to do strictly client-side programming then something like jQuery offers you a lot more capabilities to do things that you really want to do client-side like sorting and CSS selectors. ... That stuff is easy to do with an Update Panel and ASP.NET, but Update Panels aren't always the best solution to use. ...

the goals with ASP.NET AJAX was to integrate into the ASP.NET server-side model ... that's great for ASP.NET, but it needs more client-side features. ... It works if your thinking from the ASP.NET control perspective, but if you look at it outside the ASP.NET model there are a lot easier ways to do it. ...

ASP.NET AJAX [development] seems to have come to a standstill I'm not seeing a lot of development in that area and the rest of these [AJAX] Frameworks are doing monthly releases. Every month that goes by [the ASP.NET AJAX Framework] falls further and further behind ... it needs to evolve.

Listen to this great podcast here: Technology Round Table Podcast #2 - AJAX Frameworks

Back when the web turned 2.0, AJAX was all the rage, and gas was cheap, a Google recruiter contacted me. We worked through a couple screening interviews - I explained how I was a .NET / ASP.NET / C# developer with some experience with Java and PHP, I described how C# was somewhat similar to Java. Things went great, I moved on to the next step of the process - writing code (a JavaScript widget for Gmail) with a 2 day (weekend) hard deadline. At the time I was wearing JavaScript diapers, but tried the exercise anyways - I'm still convinced the recruiter confused my Java / C# experience with JavaScript. Anyhow...

The Google Web Developer Exercise:

Web Developer Exercise

Attached are three states of a new contacts widget. This widget will be used across Google and may be anywhere on the page. Designers will also use this in mocks for usability tests. Create the HTML, CSS, and JavaScript for the widget as described in the image. Your solution must work in Firefox v1.5+ and IE v6+. Bonus points for a solution that degrades nicely on older browsers.

After my first attempt, I concluded that:

1. My JavaScript knowledge was embarrassing
2. Dynamic programming languages like JavaScript using prototypical inheritance were awesome - as a monocultured .NET developer I had sorely been missing out
3. Framework Web Developers (ASP.NET, Ruby on Rails, and so on) aren't really Web Developers - we depend on a framework (an API) as a crutch, where the law of Leaky Abstractions is very real, and often when it rears it's head we use our golden hammer (our multipurpose language of choice), but there are better tools at hand
   
4. Web Developers claiming n years of experience need to at least know JavaScript, CSS, HTML / XHTML, a server-side language, and some XML / XSL - NOT just a single multipurpose language or framework
   
5. Innovation can only happen when you become one with the technologies surrounding your realm - for example: Jesse James Garrett probably would not have publicized AJAX had he been an exclusive ASP.NET developer, David Heinemeier Hansson would have never created Rails had he been an exclusive ASP.NET developer, and Scott Guthrie would never have developed ASP.NET had he been an exclusive ASP.NET developer. Diversity is essential for innovation
   

In retrospect this exercise is brilliant, it's a more complex derivation of a Fizzbuzz exercise, which effectively weeds out the knowledgeable candidates from the n00bs. JavaScript is notorious for being one of the world's most misunderstood language, many developer (and the ASP.NET Framework) still use JavaScript techniques from the old days of Netscape. For example: <a onclick="return false;" ..., or <a href="Javascript: do something;" ... are common DOM Level 0 inline techniques that should be avoided. These techniques have been replaced, but finding developer that use these JavaScript techniques can be hard.

By having a developer complete this exercise you effectively determine that the they understands these concepts:

• Cross browser compatibilities and work arounds for both JavaScript and CSS - with a preference given to feature detection (object detection) vs browser detection, an understanding of the different event handling models between browsers
  
• An understanding of the separation of concerns - JavaScript, markup, and CSS should be separate files, or at least separated within the document
  
• Event registration and listening - DOM events, the different browser event models, no inline level 0 event declarations, no pseudo JavaScript protocol inline declarations within markup
  
• An understanding of functional languages - closures, namespaces, lambdas, recursion where necessary
  
• Node manipulation - creating, swapping, removing elements
• Knowledge of non-obtrusive JavaScript techniques
• Importance of modular / compartmentalization of CSS and JavaScript - defensive programming techniques that minimize the risk of interfering with other scripts and elements within the page, part of the non-obtrusive techniques, how to avoid global variables
• An understanding on how to debug JavaScript from both IE (link) and Firefox (link)
• JavaScript code conventions - naming conventions, statement conventions
• CSS naming conventions
• General DHTML / AJAX techniques - showing and hiding elements
  
• A gauge on their attention to details and UI design intuition - what their gut tells them to do when things aren't spelled out

My latest crack at the Google Web Developer Exercise:

You'll have to visit my site (view this blog post outside a RSS reader) to view the code in action.

The code: GoogleExercise.js, GoogleExercise.html, GoogleExercise.css

Today I'm wearing JavaScript training wheels - feel free to comment on the code, I'm always looking for improvements and suggestions. I did take a couple shortcuts on the CSS / UI side of things as I was focusing more on the functionality.

Using one of the AJAX Libraries (like jQuery) we could certainly do this exercise in significantly fewer lines of code.

Beginning CSS: Cascading Style Sheets for Web Design by Richard York is a great book for any web developer looking to thoroughly understand CSS.

This book was required pre-reading for my latest Technical Editing task - I'm editing Mr. York's newest book. So in the spirit of spring, de-cluttering, and giving. I'd like to give this book away. This book is like new with a couple minor dings (from an airport fiasco), it is in full color (like all good design books should be), and it's free!

Contest Rules:

• Comment on this post.
• Leave a valid email in the email comment field.
• The winner will be chosen at random and notified through email on Canada Day (July 1st).
• I pay for shipping.

Good Luck!

The contest has ended and the winner is Devin Parrish!

The ASP.NET AJAX framework comes with a lot of baggage err... I mean... a huge learning curve when compared to other AJAX Frameworks like JQuery, YUI, Dojo, Prototype / Scriptaculous.

Here's a running list of the technologies, and concepts you'll encounter when digging into ASP.NET AJAX:

• ASP.NET
• The Page Life Cycle
• The Control Life Cycle
• Web Controls
• User Controls
• View State
• Session State
• Events
  
• .NET / Classical Language
  
• Interfaces
• Inheritance
• Delegates
• Multicast Delegates
• Assemblies
• Properties (Get / Set)
• Constructors

In addition to these, you also have the technologies universal to all JavaScript libraries:

• JavaScript:
• Closures
• Object Literals
• JSON
• Events
• DOM Manipulation
• Prototypical Inheritance
• Constructors
• XMLHttpRequest
  
• Cascading Style Sheets (CSS):
• Web Services

The ASP.NET AJAX Framework is more complex than other AJAX frameworks, I'm continually lost in it's ambiguity as it attempts to skirt around the JavaScript language - I think this learning curve (and all it's confusion) is precisely why Silverlight has so much potential.

I'm still diving into the low-level details, but my first impressions of the ASP.NET AJAX Framework are:

• Obscure, ambiguous, no clear vision - it offers multiple (resource intensive) ways to avoid writing JavaScript, but then requires that you write JavaScript anyways
  
• Too server centric
• Too heavy weight (I'm not appreciating how they're trying to turning JavaScript into a Java, C#, .NET clone, the overhead within the browser for these conversions seems like a huge performance bottleneck)
• Has the potential for poor performance

Most of the other AJAX libraries have been written with performance, browser responsiveness, and User Experience as their number one priorities - I'm still not sure about ASP.NET AJAX.

How many ways can we try to avoid writing JavaScript? If an AJAX library doesn't enhance the User Experience then why use it? Regardless, I'm still digging deeper.

A couple years ago I was thrown into a web application that made heavy use of ASP.NET Themes and Skins. Prior to this I depended exclusively on Cascading Style Sheet (CSS) for my web development / web design needs. A first glance at ASP.NET Themes and Skins looked promising, but a number of flaws surfaced - see the links and issues listed at the end of this post.

In addition to these issues, here are a couple other considerations when thinking about ASP.NET Themes:

• Themes do not adequately separate the levels of concerns within your application. When using Themes all design related files are baked into the application. From a maintainability standpoint, this doesn't bode well in large web applications. Hosting design related files on a single server or an external Content Delivery Network (CDN) is an effective way for managing site wide UI updates and increasing a sites performance, ASP.NET Themes works against this technique.
• Themes add unneeded complexity by obscuring the real technologies at work (CSS). Everything that ASP.NET Themes offer can be better achieved outside of the ASP.NET Theme Framework. Technologies like Cascading Style Sheets (CSS),  alternate Style Sheets, and JavaScript can achieve more than Themes can provide.
• Themes are a server-side mechanism. Themes become a nuisance in client-side dependent, heavily dynamic, Web 2.0, DHTML, AJAX type web applications.
• Themes discourage developers from learning more about web design and the technologies surrounding it. Themes offer a seemingly simple API, which shelters developers from the complexities of CSS and JavaScript, but sooner or later The Law of Leaky Abstractions comes into play and knowing the fundamentals of these technologies is a necessity.
• Professional web designers don't use ASP.NET Themes, CSS is the language of web designers.

Default Skins on the other hand can be useful for defining consistent CSS hooks into common ASP.NET controls. It's unfortunate that we can't use Skins without Themes.

Related posts:

• The Problems with Themes, Skins, and Cascading Style Sheets (CSS) - Where it all Falls Apart
• Excluding a CSS folder (Work Around #1)
• Defining a Media Type(s) (Work Around #2)
• Defining the Load Order (Cascades) for CSS (Work Around #3)
• Using Internal (Embedded) Style with Themes (Work Around #4)
• Creating Printer Friendly Pages (defining a CSS Print Media Type) with CSS While Using Themes (Work Around #5)
• A Resolution to The Problems with Themes, Skins, and Cascading Style Sheets (CSS) - Putting the Cascades back into ASP.NET 2.0 Themes (taking control over CSS Cascades / Load Order, Media Types, and Overrides)

JavaScript: The Definitive Guide by David Flanagan is a great book! When I began reading this book I was convinced that (like many technical books) the first couple chapters would contain the important stuff and the content would slowly digress into page filler, fluff, and the book would become just another monitor stand. But not this book! After finishing the formal chapters I started reading the references - YES, this book is so good I'm reading the references! Flanagan has raised the bar for all JavaScript books - this book is in its 5th edition, and reviewed by some of the greats in the Web Development / JavaScript world (Douglas Crockford, Peter-Paul Koch).

I often think of JavaScript as the assembly language of the internet - most of the current-generation web frameworks make heavy use of JavaScript, CSS, and AJAX. If you really want to understand how ASP.NET or Ruby on Rails really works, how AJAX works, how JavaScript libraries work. If you want to really understand how to push the web browser envelope, and how to really innovate, then this book is a required read. JavaScript (and other functional programming languages) present a different programming model. Once you grock the fundamentals of JavaScript you'll never be able to look at classical languages (Java, C++, C#, ...) with a straight face again. I highly recommend this book to ANY web developer from ANY web framework camp.

This book is now in my Recommended Reading section. View my review on Amazon.

Professional ASP.NET 2.0 Design: CSS, Themes, and Master Pages by Jacob Sanford is a great book for ASP.NET developers looking to expand their knowledge on the ASP.NET 2.0 Web Design front.

I've read this book, re-read it, edited it, and would like to give it away - I was the Technical Editor. The books is like new and (did I mention) it's free!

Contest Rules:

• Updated! Just Leave a comment with a valid email address!

• Post a 500 x 200 pixel image of something you're working on in the comments of this post - this image could be code, web design, or anything work related.
• Include an optional description of your work
• The winner will be chosen April 1st May 1st, they'll be drawn at random, and will be notified through email.
• I pay for shipping.

* I've included a sample entry in the comments. If you're looking for a great free photo editing application then try Paint.net. If you're looking to host your image you might want to consider Flickr or Photobucket.

Good Luck!

The contest has ended, and the winner is..... Andrew Hinde. Nice!

JavaScript is probably the world's most popular and misunderstood programming languages and for good reason - most developers will claim they know JavaScript even when they don't - I know I have!

When a developer claims to know JavaScript this generally equates to one or all of the following:

• "I know what JavaScript is, I can learn JavaScript in 30 minutes"
• "JavaScript is for kids, it's a toy language, it's easy"
• "I just copy and paste my JavaScript snippets / scripts from the internet"
• "JavaScript is just another programming language like C++, C#, VB.NET, or Java"

If thoughts similar to these have crossed your mind when sizing up your JavaScript knowledge, then you probably don't know JavaScript.

I would argue that if you've never programmed in a functional programming language (like: Lisp, Scheme, F#), never read a GOOD book on JavaScript, or never watched a video on JavaScript, then you probably don't understand JavaScript at all. JavaScript is starkly different than any other mainstream programming language.

When it comes to JavaScript, if you don't understand the fundamentals then you're only punishing yourself.

Here are some things every JavaScript developer should probably understand:

• JavaScript, Mocha, LiveScript, JScript, and ECMAScript are all essentially the same.
• JavaScript is a prototypically inherited (prototype-based programming) language which is very different than the classically inherited (class-based programming) languages like C++, Java, and most of the .NET languages - you know the difference between a prototype-based programming and class-based programming language.
• JavaScript is a loosely typed language - you know the difference between strongly-typed programming languages and weak-typed or loosely typed languages.
• JavaScript is a functional lambda language - you understand lambdas and that functions in JavaScript can be lambdas.
• JavaScript functions can be defined inside functions, inside functions, inside functions, and so on - you can demonstrate this.
• JavaScript uses function scope, has no curly brace '{}' block scope - you understand that this is common attribute of most functional programming languages.
• JavaScript has no private, public, protected assessors, no classes, no enums, no structs - you understand that all these language features can be achieved through objects and function closures.
• JavaScript is classless, but instead it uses objects as general containers.
• JavaScript makes use of garbage collection.
• JavaScript uses truthy and falsy values - you understand which values are truth and falsy.
• JavaScript makes use of the 'nan' (not a number) and 'undefined' values - you understand the difference between these values.
• JavaScript has pretty good debuggers - you understand how to debug JavaScript from both IE (link) and Firefox (link).
• You appreciate recursion, and understand that recursion is a useful technique in JavaScript.
  
• You understand that JavaScript Namespaces should be used - you understand the importance of namespaces, and know how to create one (Namespacing Your JavaScript).
• You know how to avoid the JavaScript pseudo-protocol (<a href="Javascript:alert('hello');"), and appreciate avoiding it.
• You know how to avoid embedding DOM Level 0 JavaScript events (<a onclick=''alert('hello');") in your mark-up / document structure, and appreciate this technique.
• You know that JavaScript can make use of two different event models (event capturing and bubbling), but we should only ever make use of bubbling.
• You understand what JSON is and how it's used.
• You know how to keep you JavaScript, CSS, document structure separate, and appreciate non obtrusive JavaScript.

If any of these points seem foreign, then it may be time to learn JavaScript. With all the hype and buzz around Web 2.0 and AJAX it could be a great way to augment your career while broadening your programming language vocabulary.

Great resources for learning more about JavaScript:

Videos:

• The JavaScript Programming Language: Part 1, Part 2, Part 3, Part 4
• An Inconvenient API: The Theory of the DOM: Part 1, Part 2, Part 3
• Advanced JavaScript: Part 1, Part 2, Part 3
• JavaScript: The Good Stuff: Link
• All these videos are available on the YUI Theater - all the videos are great, watch them all!

Books:

• JavaScript: The Definitive Guide (Paperback) by David Flanagan

Links:

• MDC: A re-introduction to JavaScript
  
• Code Conventions for the JavaScript Programming Language
• JavaScript: The World's Most Misunderstood Programming Language
• What ASP.NET Developers Should Know About JavaScript
• Best Practices: Implementing JavaScript for rich internet applications
• The seven rules of Unobtrusive JavaScript
  

Greasemonkey is an add-on for Firefox. Through JavaScript it allows anyone the ability to dynamically modify a page as, or after it's being rendered in the browser. This lets anyone trim the DOM, remove ads, and modify page in anyway they see fit (it also opens up some serious privacy concerns with XSS). Anyhow, I spend a fair time on the ASP.NET forums, but the advertisements have always made for a somewhat negative, but tolerable user experience.

Today I finally broke down and wrote my own Greasemonkey script - now formally known as "The ASP.NET Forums Beautifier" for lack of a better name.

The Script Before and After:

Before - usually the ASP.NET Forums look like this:

After - with my script running in Greasemonkey we get this:

note: the greasemonkey icon, and complete lack of fluff / advertisements on the second screenshot.

Creating this script was simpler than I expected. It was a matter of skimming through an article on How to write Greasemonkey scripts, using Firebug's JavaScript Console and Firefox's Error Console to test my code (after all, Firefox is the new IDE, Firefox as an IDE), and an hour later, Viola! No more ads.

The YUI blog and Douglas Crockford in particular, have inspired my JavaScript renaissance. JavaScript is really interesting, it's a functional, loosely typed programming language that uses prototype-base inheritance. Developing in JavaScript is a real treat from some of the more statically typed languages.

Download Greasemonkey and "The ASP.NET Forums Beautifier" for yourself. :)

ASP.NET 2.0 Themes have a couple design flaws, all of which center around the way Themes reference Cascading Style Sheets (CSS). I've been posting Theme and CSS related issues and work arounds as I encountered them, and in one of my first posts I outlined the possibility of using a VirtualPathProvider to ignore the CSS files within a directory. In this post I share David Marzo's implemented of this solution. This resolution resolves most of the issues surrounding Themes and CSS, and essentially puts the Cascades back into CSS.

The Problem / Question:
ASP.NET 2.0 Themes automatically includes all the Style Sheets (.css files) found in the active Theme (App_Theme) directory into the Head of the rendered document. This severely limits the robust CSS language, and works against the last decade of Cascading Style Sheet progress. For more specific details on the problems with ASP.NET 2.0 Themes start reading the articles found here.

A Solution / Work Around:
Add a custom VirtualPathProvider to ignore the Style Sheets (CSS files) found in the App_Theme directory. For more background on this solution see my article and David Ebbo's article titled Overriding ASP.NET combine behavior using a VirtualPathProvider.

An example of the problem:

The directory structure:

Notice all the Style Sheets (.css files), there are more in the Adapters directory too.

Before including the CustomVirtualPathProvider (code provided below) into the project's build - the XHTML rendered by Themes:

<html xmlns="http://www.w3.org/1999/xhtml" >
<head><title>
      The Problems With Themes and Skins in ASP.NET 2.0
</title>
<link href="App_Themes/Default/CSS/Adapters/ChangePassword.css" type="text/css" rel="stylesheet" />

... The other 17 externally linked Style Sheets go here, they were removed to improve readability ...

<link href="App_Themes/Default/CSS/PrinterFriendly.css" type="text/css" rel="stylesheet" />
</head>
<body>
The Style Sheets are automagically inserted into the Head tag from the active Theme directory. Keep in mind that Internet Explorer has a 30 Style Sheet limitation (see article Q262161).

After including the CustomVirtualPathProvider (code provided below) into the project's build - the XHTML rendered by Themes:

<html xmlns="http://www.w3.org/1999/xhtml" >
<head><title>
      The Problems With Themes and Skins in ASP.NET 2.0
</title>
</head>
<body>
Notice the complete lack of Style Sheets - ahhh simplicity is bliss, the very foundations of CSS Zen Enlightenment... :) Now we can manually include our Style Sheets, use Conditional Comments, and so on.

The source code for the CustomVirtualPathProvider provided by David Marzo in C#:

using System;
using System.Data;
using System.Security.Permissions;
using System.Web;
using System.Web.Caching;
using System.Web.Hosting;
using System.Collections;

namespace Arfila.Web.Logic {
 
    [AspNetHostingPermission(SecurityAction.Demand,
        Level = AspNetHostingPermissionLevel.Medium)]
    [AspNetHostingPermission(SecurityAction.InheritanceDemand,
        Level = AspNetHostingPermissionLevel.High)]
    public class CustomVirtualPathProvider : VirtualPathProvider {
       
        public static void AppInitialize() {
            HostingEnvironment.RegisterVirtualPathProvider(new CustomVirtualPathProvider());
        }
       
        public CustomVirtualPathProvider() : base() { }
 
        private bool IsThemeDirectory(string virtualPath) {
            String checkPath = VirtualPathUtility.ToAppRelative(virtualPath);
            return checkPath.StartsWith("~/App_Themes/",
                StringComparison.InvariantCultureIgnoreCase);
        }
 
        public override VirtualDirectory GetDirectory(string virtualDir) {
            if (IsThemeDirectory(virtualDir)) {
                return new ThemeDirectory(Previous.GetDirectory(virtualDir));
            }
            else {
                return Previous.GetDirectory(virtualDir);
            }
        }
    }
 
    [AspNetHostingPermission(SecurityAction.Demand,
        Level = AspNetHostingPermissionLevel.Minimal)]
    [AspNetHostingPermission(SecurityAction.InheritanceDemand,
        Level = AspNetHostingPermissionLevel.Minimal)]
    public class ThemeDirectory : VirtualDirectory {
 
        VirtualDirectory _toFilter;
        private ArrayList _children = new ArrayList();
        private ArrayList _directories = new ArrayList();
        private ArrayList _files = new ArrayList();
 
        public override IEnumerable Children {
            get { return _children; }
        }
 
        public override IEnumerable Directories {
            get { return _directories; }
        }
 
        public override IEnumerable Files {
            get { return _files; }
        }
 
        public ThemeDirectory(VirtualDirectory toFilter) : base(toFilter.VirtualPath) {
            _toFilter = toFilter;
            BuildChild();
        }
 
        private void BuildChild() {
 
            foreach (VirtualDirectory dirToFilter in _toFilter.Directories) {
                ThemeDirectory themeDir = new ThemeDirectory(dirToFilter);
                _children.Add(themeDir);
                _directories.Add(themeDir);
            }