In most cases The Same Origin Policy is desirable. It helps to prevent malicious code that could potentially reveal sensitive information from being run on arbitrary website. However, the same origin policy also makes it difficult to share resources within a common root domain, or run external widgets on your site (like displaying The Project Badge within your site). There are a couple ways to circumvent The Same Origin Policy, but I focus on JSONP and the document.domain property in this post.

Ways to circumvent the Same Origin Policy

1. JSONP
2. Modifying the document.domain property
3. Creating a server side web proxy

JSONP (JSON with padding)

How it works: JSONP dynamically creates a script element in the head of your HTML document which then requests data from outside your domain. JSONP exploits a loophole in the Same Origin Policy that allows JavaScript from an external sites to be run within your site (much like how web analytic tracking works). The JSON response, when returned, is executed within your browser at which time the JavaScript can manipulate your HTML page / DOM.

An Example Using JSONP with jQuery:

Note the callback=? at the end of the URI, in jQuery this indicates a JSONP call.

Pros

• Lets us make external calls to any endpoint that supports JSONP
• Lets us make external calls from HTTP to HTTPS
• Supported by all major browsers

Cons

• A bit more complex upfront, but most server side technologies support JSONP, browsers are natively supporting JSON, and JavaScript libraries like jQuery continue to abstract away most of the complexity.

The document.domain property

How it works: the document.domain property contains the domain of the server from which the page was loaded. For example, the domain for http://adam.kahtava.com/ would be adam.kahtava.com whereas the domain for http://kahtava.com would be kahtava.com. The Same Origin Policy restricts resource access from kahtava.com to adam.kahtava.com unless we set the document.domain property to the root domain (in this case I'd want it set to kahtava.com to share resources with http://adam.kahtava.com).

An Example using the document.domain property:

Pros

• An easy way to access resources within our root domains
• Supported by all major browsers

Cons

• Prevents us from making external calls outside a root domain
• Prevents us from switching between HTTP and HTTPS
• Kind of a hack - technically, the document.domain property is supposed to be a read only property, but most browsers also provide set access

JSONP vs document.domain isn't a cut and dry comparison. JSONP lets anyone consume and share data, whereas overriding the document.domain lets you share resources within a common root domain. In simple cases where your only concern is sharing data within a single domain (exclusively on HTTP or exclusively on HTTPS), then overriding the domain works well, but in cases where you want to share or consume external data that may be passed over HTTP or HTTPS you'd probably want to stick with JSONP.

The Project Badge makes use of JSONP so it can work on your website. Most of my publicly available web services also make use of JSONP through a WCF JSONPBehavior.

The Project Badge displays your GitHub and Google Code projects in a badge that can be displayed on your site. This widget was built on the data being returned from my Open Source Service.

View this post outside your RSS reader to see it in action or view it here.

The source for the Project Badge can be found here and the source for the accompanying service can be found here. A list of all my publicly available web services can be found here.

Using The Project Badge On Your Website or Blog

1. Add The Asset References

Add the following asset references, and a reference to jQuery (if you don't have one already).

2. Configure Your Accounts

Set your project accounts (it's OK if you only use one host) then optionally set the appropriate filters - in my case my Google Code projects were prefixed with adamdotcom and I had duplicate projects on both GitHub and Google Code. By specifying remove:adamdotcom,remove:duplicate-items in my filters I filter out the duplicates and removed adamdotcom from the project name.

3. Add The Widget Hook
Add an element to your site or blog with the id of project-badge.

That's it!
If you have any issues, use the the working example as a reference, or send me a message.

I did the exercise yet again (the third time) because my last attempt needed some improvements:

• it suffered from chronic classitis and divitis (too many classes, ids, and divs were making me itchy)
• it wasn't really using semantic / structural markup (all the extra divs etc... cluttered my markup, and some of my class names like container-borders are non-semantic altogether)
• it performed poorly and wasn't accessible (everything was being rendered in the DOM, there was no immediate rendered markup which kind of violated the idea of unobtrusive JavaScript, nor was it screen reader friendly)
• it wasn't making use of any JavaScript libraries to abstract browser inconsistencies out of the code
• it suffered from my software ethnocentrism (my variable and object naming like GoogleExercise was mirroring statically typed languages and not the native language they were being written in)

Here's my latest Google Exercise (addressing all the above concerns):
View this post outside your RSS reader to see it in action or view it here.

This attempt makes use of jQuery and uses 57 lines of JavaScript (almost 200 lines less from my last one).

You can view the code for this attempt here: google.contact.widget.js, index.html, google-contact-widget.css.

You can view the old code here: GoogleExercise.js, index.html, GoogleExercise.css.

If you think I can improve on my code then let me know. Oh yeah, and if you're a recruiter from Google then hire me! :)

Don't write frameworks for dummies. [Frameworks designed by organizations] that assume some developers are not smart enough ... are likely to fail because they underestimate the difficulty of ... development. ... This attitude also poisons the relationship between [the developers and framework designer]. - Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software

Evans goes on to make the point that there's a fine line between designing for dummies, and providing useful encapsulation / abstraction. I found this advice interesting because I had been wrestling with whether the ASP.NET AJAX Framework is for Dummies.

Like a horse with blinders on, avoiding some degree of Big Design Up Front (BDUF) can force your team and project into tunnel vision, because... If you don't look at what you're building in its entirety, it is harder to see the big picture, to have to that ah-hah moment that leads to a break through, to maintain conceptual integrity, or have a successful project.

I worked on a project where we attempted evolutionary design (avoiding Big Design Up Front) while taking an Agile approach. We used Continuous Integration, and Test Driven Development. Looking back, our attempt at trying to avoid Big Design Up Front was fatal for our project's success and probably our biggest mistake. The funny thing is, the only reason we avoided BDUF was because it seemed non-Agile (note the capital 'A' in 'Agile' read Yegge's post Good Agile, Bad Agile for the reference). As a development team we were inexperienced Agile (eXtreme Programming) teenagers and somewhere along the way we exchanged our brains for dogma.

eXtreme Programming [is at odds with] "Big Design, Up Front" (BDUF) _ Because "Ya Ain't Gonna Need It" (YAGNI) ... [but this is often] taken as permission to not do any planning - Gerard Meszaros' Alberta TechFest slide deck '07

In the past Big Design Up Front (BDUF) was associated with large inflexible architectural solutions that are designed upfront (before development begins) - like the waterfall methodology. However; BDUF (like most techniques / methodologies / tools) are quite useful when used with a sprinkle of common sense and moderation. BDUF can be a productive lightweight tool for fleshing out the high level overview of a system. It is important to note that I'm not advocating Big Architectural Design Up Front which is often composed of reams of documents, UML, ERDs, diagrams, and other unneeded artifacts. Instead I'm advocating for paper based story boards, wire frames, paper prototypes, user stories - anything that is easy to create, destroy, and recreate. These techniques provide the foundation of the final product, they start to verbalize the common product goal and can start to draw out the language, metaphors, and model that will eventually compose the project.

Avoiding some Design Up Front was a mistake for our project. As a team we were trying to cope with the complexities of our domain under very tight deadlines. Our code became increasingly brittle, we had overlooked obvious shared functionality that a high level overview would have fleshed out. At the same time we had segregated our application into sprint sized silos with no clear relationships - each sprint was essentially a two week tunnel, and disconnected.

Without some form of BDUF it was difficult to:

• maintain conceptual integrity, a common goal, a consistent user interface
• estimate the whole product cost
• have a successful project

We should have headed Steve McConnell's words:

people were claiming,  "I don't have to do requirements or design because I'm using object-oriented programming." That was just an excuse. Most of those people weren't really doing object-oriented programming-they were hacking, and the results were predictable, and poor. Right now, people are saying "I don't have to do requirements or design because I'm doing agile development." Again, the results are easy to predict, and poor - Steve McConnell, Code Complete

Or perhaps Martin Fowler's suggestion:

the planned design approach has been around since the 70s, and lots of people have used it. It is better in many ways than code and fix evolutionary design. But it has some faults. - Martin Fowler, Is Design Dead?

Not doing some Design Up Front is probably another excuse for being sloppy, but what do you think?

Microsoft is looking to make jQuery part of their official development platform ... jQuery will be distributed with Visual Studio
- jQuery, Microsoft, and Nokia

Other links of interest:

• Scott Hanselman: jQuery to ship with ASP.NET MVC and Visual Studio
• Scott Guthrie: jQuery and Microsoft

I was completely blindsided by this decision.

Now, developers can be pretty skeptical, and getting them to agree has been likened to herding cats, but a couple core considerations / values seem to surface when the decision is being made.

Considerations for choosing a JavaScript / AJAX Framework:

• Transparency - Who are the framework's development team and why should we trust them? Do these developers blog? Attend conferences? Are they featured on podcasts / videos? Is there a high or low turnover within the team? What are their passions? Is this just a job, do they like what they're doing, are they a cog on a wheel? Are they experts in their field?

• Competency - Based on the information gathered in the consideration above (transparency), how competent do we feel the development team is?

• Community Support - How well is the framework supported on forums and blogs? If something were to go wrong can we gain access to the framework's development team? Are there widespread experts using this framework readily available?

• Reputation - How popular is the framework in the industry? Who uses it? Are there any white papers, success stories, case studies available?

One of the easiest ways for a developer to choose a framework is by looking at the developers that built it (and talking with those that are using it). As developers our day job will be stepping into someone else's code for the duration of the project, working with a framework created by competent developers makes our jobs easy. Frameworks without transparency don't allow us to gauge the competency of the developers or the framework.

Transparency is essential for JavaScript / AJAX Framework teams, JavaScript itself is open and transparent (not compiled yet), it follows that JavaScript / AJAX Framework along with their teams should also be transparent. When the decision for choosing a JavaScript / AJAX Framework is placed in the hands of developers the frameworks that don't meet the above criteria sink to the bottom of the list.

The only way to succeed now is to be completely transparent, everything is exposed, everything you do - Gary Vaynerchuk 

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.

What's really wrong with ASP.NET AJAX?

• It doesn't plan for performance from day one
• It treats AJAX as a classic computer science problem
• It tries to turn JavaScript into a classical language which works against JavaScript's dynamic, prototypical nature
• It feels like a framework that was written for dummies (Don't Write Frameworks For Dummies)

A Case Study: Why Plaxo.com Almost Failed

In the video: High-performance JavaScript: Why Everything You've Been Taught is Wrong (YUI Theater) Joseph Smarr discusses the challenges and lessons learned while developing Plaxo.com. While developing this AJAX centric application, the Plaxo team decided to include everything they could think of into their application. They created a framework to treat JavaScript as a classical language, they gave priority to features over performance, and... the project ALMOST FAILED. They were able to salvage their application by diverting their development efforts, making performance one of their top priorities, by unlearning everything they'd been taught about classical applications (instead embracing JavaScript), jettisoning unneeded framework bloat, and more.

Some of the points made in this video were:

• Plan for performance from day one
• AJAX is not a classic problem
• JavaScript is not a classical programming language
• User experience and a responsive application can make or break an application
• Unneeded bloat in a framework, and an obtuse approach to using AJAX (treating AJAX and JavaScript as a classical language or classic computer science problem) has the potential to cripple your application

This Channel 9 video also mirrors these sentiments: Douglas Crockford, Alex Russell and Joseph Smarr: On the Past, Present and Future of JavaScript

How ASP.NET AJAX Failed: What can we learn from Plaxo?

The way the Plaxo team approached their application development is similar to how the ASP.NET AJAX Framework has been designed. Like Plaxo's initial attempt ASP.NET AJAX attempts to mold JavaScript into a classical language, and attempts to treat JavaScript and AJAX as a classic computer science problem by heaping on more abstractions. Like Plaxo's initial attempt ASP.NET AJAX also gives a low priority to performance. Plaxo was able to change their direction and salvaged their application, but the ASP.NET AJAX Framework is not in a position to make any sweeping changes - ASP.NET AJAX is going down the wrong path and it's too late.

The ASP.NET AJAX Framework is probably another exercise in Framework Architecture (demoware) and a failure in practice. Its lack of use in the wild attests to these shortcomings - contrast the sites using ASP.NET AJAX with the sites using jQuery (Actions Speak Louder Than Words). Furthermore the places that ASP.NET AJAX does thrive (the small internal ASP.NET business apps that need some bling-bling) will also be the areas that Silverlight shines - Silverlight offers a better Microsoft centric programming model (less leaky Win Form / Web Form abstractions) that most Microsoft developers will embrace. Silverlight will probably divert the developers that currently embrace ASP.NET AJAX.

I don't recommend the ASP.NET AJAX Framework and won't be contributing to the AJAX Control Toolkit. My time is better spent elsewhere.

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 podcast here: Technology Round Table Podcast #2 - AJAX Frameworks

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. 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, index.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.

Interesting observations:

How many applications explicitly state that they use the ASP.NET AJAX Framework?

• 25, this includes sites like DotNetNuke (with a reputation of being slow), view the list here.

How many of these applications are relatively high-traffic?

• None. ZERO!

How many applications explicitly state that they use the YUI library?

• 89, view the list here and here.
  

How many of these applications are relatively high-traffic?

• Quite a few. A couple notable sites: Flickr, Slashdot, Linkedin, Paypal, O'Reilly, My Opera.

How many applications explicitly state that they use the jQuery AJAX Library?

• 516 and growing, view the list here.
  

How many of these applications are relatively high-traffic?

• Many. A couple notable sites: Twitter, Digg, Dell, Slashdot, BBC, Netflix, Technorati, New York Post.

If no high-traffic application uses the ASP.NET AJAX Framework then why would you? Actions (or lack of action) often speak louder than words, and it appears that the ASP.NET AJAX Framework is not suitable for the real world.

The ASP.NET AJAX Framework is an embarrassing server-side centric approach to DHTML / AJAX web development. While most programming languages and frameworks come with both good and bad parts, the ASP.NET AJAX Framework is an example of a bad part - on the contrast the ASP.NET MVC Framework looks to be a good part.

What's wrong with the ASP.NET AJAX Framework?

1 .NET Developers are DUMMIES!
The ASP.NET AJAX Framework appears to have been designed under the assumption that .NET developers are dummies and can't learn or don't want to learn JavaScript. That .NET Developers would rather hobble along with their familiar languages, then to learn something new. I understand that the ASP.NET community's only real problem is education, so let's ask: What is wrong with the ASP.NET Community? Then educate ourselves rather than becoming the .NET Developer statuesque. It's patronizing to use a framework that assumes learning a new language is beyond our capabilities. Many of these other programming languages are more expressive than statically typed languages like most of the .NET languages. 

2. The "don't write a line of JavaScript" abstraction leaks like a sieve
The Framework is intended to shelter .NET Developers from the JavaScript language. Which, like driving a car across North America without knowing how to pump gas, stops you dead. Either you depend on someone to pump your gas - depend on a 3rd party (vendors or the ASP.NET AJAX Control Toolkit) and their many authors to write your JavaScript - or you stop moving. As Web Developers, sooner or later learning how to pump your own JavaScript becomes a mandatory skill.

3. Client-side programming from the Server-side is a absurd
The AJAX Framework does back flips to translate server-side code into JavaScript, and then requires that you write JavaScript anyway. Save yourself the pain, learn JavaScript. One day The Law of Leaky Abstractions comes into play, the gas station attendant fills your gas tank with diesel - the AJAX Control Toolkit blows requires debugging and you have to learn JavaScript anyways.

4. Bloated, poor performance, bad user and developer experience
The AJAX Framework extends many of the native JavaScript objects as it attempts to turn JavaScript into a staticly typed programming language, and tries to hook into the ASP.NET life cycle, but all these features are unneeded as they are ALL already achievable through the native JavaScript language - if it walks like a duck and quacks like a duck, then... err... could someone remind me why we need typed languages in a web browser? Anyhow; all these object extensions, enhancements, and upgrades, contribute to more scripts that need to be downloaded and increases the number of scripts running in your browser. Then there's partial-page rendering and Update Panels which do full page post backs under the guise of AJAX. BAD! Client-side scripting is supposed to enhance the user experience not make it worse. Other AJAX Frameworks are built with performance as their number one goal, but in the ASP.NET AJAX Framework adding more widgets to JavaScript seemed to be the first priority, and performance an after thought.

5. Working against the grain is a waste of time
The AJAX Framework works against the grain, it would be nice if it embraced the JavaScript language. Very few of the concepts and metaphors used in the ASP.NET AJAX Framework transcend AJAX techniques or frameworks - your time is probably better spent learning how JavaScript works or how the other AJAX frameworks work.

6. Disconnected from the ASP.NET MVC Framework
The ASP.NET MVC Framework throws the ASP.NET life cycle away leaving more dead weight ASP.NET AJAX Framework script and rendering many of the AJAX Framework techniques moot.

7. The ASP.NET AJAX Framework almost over looks the 'J' in AJAX - 'J' stands for JavaScript (that's GOOD)
JavaScript is the glue of the web, even the ASP.NET Framework depends heavily on JavaScript, it is not something to shy away from.

8. Aside from local intranet sites, no one really uses the ASP.NET AJAX Framework.
The AJAX Framework isn't widely used. The ASP.NET AJAX site showcases 25 sites using ASP.NET AJAX. None of these applications appear to be high-traffic or moderately high-traffic applications. On the other hand, the YUI site showcases 89 sites, out of these sites, 6 sites (flickr, Slashdot, Linkedin, Paypal, O'Reilly, My Opera) could be considered high-traffic. Other AJAX libraries like jQuery, and Dojo compare similarly. Your time might be better spent learning one of the other AJAX frameworks.

If we (as .NET Developers) are going to claim we know AJAX, then let's focus on the core of AJAX (JavaScript) and stop obscuring it in poor frameworks. Frankly the ASP.NET AJAX Framework is embarrassing, the web development community is laughing at the ASP.NET AJAX Framework and the Developers touting it.

Comments like "we recommend that...", "because it makes no sense...", "you must rely on a special method...", "you must understand X,Y,Z to run complex client-side code without writing a single line of JavaScript" were discouraging. Many of the "whys" were left answered and the technical inner workings of the framework often trivialized. Don't get me wrong, writing a book is incredibly time consuming, but if you're an author, presenter or the like, and you don't fully understand something then admit it. Do some research, provide some links, or move on. Consistently making comments like these bring the integrity of the whole text into question.

The ASP.NET AJAX Framework itself is technically flawed, bloated, and almost entirely impractical. I was disappointed with the server-centric approach that both the book and ASP.NET AJAX Framework takes. I was disappointed that the book continually pushed JavaScript under the carpet as magic and at the end of the book I was pleased to see the promise of making "the JavaScript code disappear" never was  fulfilled. JavaScript is the very most important part of AJAX, without the 'J' in AJAX, we're left with nothing - just 'Asynchronous', 'And', heaps of more ugly 'XML'.

When reading this book, take the contents and the ASP.NET AJAX Framework with a grain of salt, if you're really serious about learning AJAX then read JavaScript: The Definitive Guide by David Flanagan.

I typically only contribute positive reviews, but I don't agree with the majority of reviews found on Amazon and hope this review provides some objectivity. I commend the authors on their hard work, I'm probably being too harsh with this review - I know it's tough to write a book, and imagine they made many sacrifices as they worked towards tight deadlines.

View my review on Amazon.

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.

JavaScript is 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 itching to push the web browser envelope, to really innovate, then this book is a required read. In addition if you're coming from a staticly type background like Java or .NET, then JavaScript (a functional programming language) will open your eyes to a different programming model. Once you grock the fundamentals of JavaScript you'll never be able to look at classical languages (Java, C++, .NET, ...) with a straight face again. I highly recommend this book to any web developer from any web framework camp.

View my review on Amazon.

Why Namespaces? Well... :) When a browser loads a document, it loads ALL the JavaScript into the browser. Objects that are not enclosed within a Namespace are Global, and Global Variables are Evil because they run the risk of interfering / overriding / clobbering previously defined objects (variables, functions, etc...). The JavaScript language, in its current form does not have native support for Namespacing . So, as pragmatic developers we realize the need to "Program Into [Our] Language, Not In It" - Steve McConnell, Code Complete 2nd Ed, Chapter 34.4. In the JavaScript language we use Objects to achieve Namespacing - we'll cover this closer to the end of this post.

Don't limit your programming thinking only to the concepts that are supported automatically by your language. The best programmers think of what they want to do, and then they assess how to accomplish their objectives ... - Steve McConnell: Code Complete 2nd Ed, Chapter 34.4 

An example of when Namespaces could be used: Let's say, we're working on a team of 3 developers, each developer is working on a different widget / component for the same page. So inside our HTML / XHTML document we define and load three different JavaScript files and inside these files we have something like:
In someObscureWidgetJavaScriptFile1.js have:

  helloWorld = function(){ alert('hello world'); };

In someOtherObscureJavaScriptFile2.js we have:

  helloWorld = 'hello world';

In someOtherObscureJavaScriptFile3.js we have:

  helloWorld = { hello: 'hello', world: 'world' };

All these JavaScript files get loaded into the browsers global calling object (window), and each assignment of helloWorld interferes with the previous. When we attempt to reference helloWorld we'll be depending on the order in which the JavaScript files were loaded - if the first file was loaded we'll be able to display the alert, if the later file was loaded first we'll be able to reference a string, and so on.

Back to the topic at hand, How do I create a Namespace in JavaScript.
Note: this approach to Namespacing was recommended and referenced in JavaScript: The Definitive Guide by David Flanagan, other methods of Namespacing can be found on the web (Namespacing your JavaScript by Dustin Diaze outlines an alternate approach). For me, the following seems more intuitive, and is recommended in Flanagan's book - probably, the best JavaScript book written to date.

Ceating a Namespace in JavaScript:

// Create the namespace object. Error checking omitted here for brevity. 
 var myNameSpace;
 if (!myNameSpace) myNameSpace = {};
 myNameSpace.myPseudoClass = {}; 
 //JavaScript doesn't support classes,
 // so let's avoid confusing people and call this a Pseudo Class  

 // Don't stick anything into the namespace directly. 
 // Instead we define and invoke an anonymous function to create a closure 
 // that serves as our private namespace. This function will export its 
 // public symbols from the closure into the myNameSpace object 
 // Note that we use an unnamed function so we don't create any other 
 // global symbols.
 (function() { // Begin anonymous function definition  

   // Nested functions create symbols within the closure 
   function displayMyMessage() { alert(myMessage); }

   // Local variable are symbols within the closure. 
   // This one will remain private within the closure 
   var myMessage = 'Hello World';

   // This function can refer to the variable with a simple name 
   // instead of having to qualify it with a namespace 
   function getMyMessage() { return myMessage; }

   // Now that we've defined the properties we want in our private 
   // closure, we can export the public ones to the public namespace 
   // and leave the private ones hidden here. 
   var ns = myNameSpace.myPseudoClass;
    ns.displayMyMessage = displayMyMessage;
    ns.getMyMessage = getMyMessage;

 })(); // End anonymous function definition and invoke it

Then outside our namespace we can invoke our methods like this: myNameSpace.myPseudoClass.displayMyMessage();

Read Chapter 10, Modules and Namespaces in JavaScript: The Definitive Guide for a deeper dive into Namespaces and Modules in JavaScript!

If you're still not convinced you need Namespaces and are interested in reading more about the issues surounding Global Data, then you may be interested in reading Chapter 13.3 (Global Data) in Code Complete.

JavaScript is probably the world's most popular and misunderstood programming languages and for good reason.
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 by David Flanagan
• JavaScript: The Good Parts by Douglas Crockford

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

The error messages read:
Parser Error Message: Unknown server tag 'atlas:ScriptManager'. 

Source Error:  <atlas:ScriptManager id="ScriptManager" runat="server" />

This message occured for a number of different reasons, this brief checklist should resolve your parse errors.

1) Ensure that the following assemblies are in your bin directory:
AtlasControlToolkit.dll
Microsoft.AtlasControlExtender.dll
Microsoft.Web.Atlas.dll

2) Ensure that the following has been added to your web.config file

<pages>
  <controls>
    <add namespace="Microsoft.Web.UI"
         assembly="Microsoft.Web.Atlas" tagPrefix="atlas"/>
    <add namespace="Microsoft.Web.UI.Controls"
         assembly="Microsoft.Web.Atlas" tagPrefix="atlas"/>
    <add namespace="AtlasControlToolkit"
         assembly="AtlasControlToolkit" tagPrefix="atlasToolkit"/>
  </controls>
</pages>

Related links:
Data Binding in an AccordionPane in a Repeater
Atlas Control Toolkit: Unknown Server Tag

Ajax, shorthand for Asynchronous JavaScript and XML, is a web development technique for creating interactive web applications. The intent is to make web pages feel more responsive by exchanging small amounts of data with the server behind the scenes, so that the entire web page does not have to be reloaded each time the user makes a change. This is meant to increase the web page's interactivity, speed, and usability. - Wikipedia: AJAX