The cross site scripting restrictions imposed by the browsers are both very important - for security reasons, and very frustrating - for the limitations they impose. If your not familliar with the single origin restrictions on XHR (XMLHTTPRequest object - the backbone of Ajax), they basically say that all requests must go to the same domain as the page that's requesting them.

For security, this is a very good thing.  Otherwise hackers could set up web pages with JavaScript that could steal all the info from sites you had logged into - such as your bank information, and the prescription for your herpes medication. Adobe's Flash Player has implemented a method of securing a domain, but opening it up to trusted domains using a cross domain policy file. Alas, no such thing exists for the browsers yet.

But let's say that there is some data you want to get to using XHR that isn't private - like search results, stock quotes, news about your favorite reality TV show. Along comes JSONP (padded JSON) to the rescue.

JSON, if you don't know is a data format for passing along well formed JavaScript objects. It happens to be very terse (tends to be smaller than XML), and much easier for the browser to parse than XML. JSONP is an unofficial standard where the JSON is sent back to the browser wrapped in a function call.

Using JavaScript, the clever coder creates a script tag node, set's the url to the service that passes back JSONP, and adds a unique tag (usually a timestamp) to prevent caching. The function call that wraps the JSONP is mapped to a callback which then cracks the data and does brilliant things with it.

It's great

I should repeat, however, that this format is not secure. It basically opens this data up to anybody - so personal or private data should NEVER be passed this way. You are also trusting the data source not to pass malicious code back to the page. You should be OK to grab search results from Yahoo or Google, but I wouldn't be pulling down script from any colleges in Russia.

I have a problem with design patterns. I know - I should be thrown out the window by the development police. Design patterns are there to help developers use tested and appropriate ways of building software which includes tasks that are common to many programs. In that respect - they are just super.

My problem is that they are often, like many technologies, inappropriately applied. I was recently reving some javascript code which did a simple Ajax call to get some JSON data and stick it into a list. The developers (and yes there were more than one) built a complex, difficult to debug MVC (Model View Controller) framework for this task.

"Oh yes," I can hear you say, "but now that component can be reused and it has a known interface...etc...etc...etc." Sure, but I could have built a reusable component that did the same thing, with a known interface, with aboout 1/10th of the code. It would be easier to maintain, and it would perform better.

I can't tell you how many conversations about Flex I've had that began with someone asking me about PureMVC or Carngorm. They are both great frameworks, but they are not meant for every Flex application.

The wrong way to apply design patterns is to look for opportunities to apply them. You can honestly figure out how to apply almost any design pattern to any problem. The one and only right way to apply a design pattern is to start with a problem and find the best way to solve that particular problem. If the design pattern is the best way - then it's good. If it can be simpler, easier to maintain, requires less code, and more performant - then fantastic.

I personally find that a lot of MVC frameworks get totally out of hand and, rather than reducing complexity, make applications more complex.

Understanding design patterns is an impotant part of a devlopers knowledge set. Knowing when to apply them is wisdom. 

With so many RIA options out there, many people get confused about which technology to hitch their wagon to in order to build an RIA. Unfortunatley many RIAs are built with the wrong stuff. Here are some general guidelines to help you make better choices.

1. Performance is still important. Consumers are even less patient now with poorly performing web sites. Just because a lot of people have broadband-speed Internet access is no excuse for building poorly performing web sites.
2. Maintainability is important. The more complex your technology the higher the risk and cost of maintainability.
3. Most applications need to support multiple platforms. IE, Firefox, Safari, Opera, the iPhone, Windows, Mac, Linux - are all major market segments. Understand which platforms you ned to support.
4. Accessibility is important and may be legally mandated for your RIA.
5. Re-use may be important from a cost management perspective.

Taking these things into account I try to use the strategy of choosing the simplest technical solution, with the least amount of code to maintain, that works on most browsers, that will support my requirements.

My technology ladder usually looks like this:

1. Plain Old Semantic HTML (POSH) +  JavaScript
2. Hand written DHTML / Ajax
3. Flash
4. Some Ajax toolkit (like Dojo, or Prototype)
5. Flex
6. A custom plugin (which I have never done)

Even though Flex is #5, it's sometimes the best solution for dynamic charting. Even though the toolkits like Dojo handle Ajax beautifully, I don't always want that much code to do a simple XHR. Flash is great for a lot of controls, and some charting applications.

I sometimes find that developers choose a technology merely because they are more comfortable with it. That is a compelling reason, however it doesn't lead to the best technology decisions.

There is a lot of debate about the definition of Web 3.0. there's still debate about what Web 2.0 means. Some proposals include: 3d browsing, increased bandwidth, and artificial intelligence. There seems to be consensus that Web 3.0 will include the semantic web.

The word semantic here refers to the idea that stuff on the web will have meaning whether a person looks at it or not. Instead of just a web of human-readable pages of text, imagine if the info on the web could also be easily parsed for meaningful data. The data could be both human and machine readable, with meaningful relationships easy to discern.

Microformats are one way this is already happening. The technology for using semantic web data is still in its infancy, and more standards need to be developed.

As an example, imagine a standard way of tagging medical research on the web. An application could be quickly developed to look for patterns in large amounts of research. Organizations like the CDC could use such a tool to keep ahead of emerging epidemics.

I have had the unique opportunity recently to participate in several "proof of concept" tests building essentially the same application in Flex and in Silverlight. What I found were some interesting distinctions, rarely discussed, that should be helpful when choosing a technology.

One of the main advantages Silverlight has over Flex is that it is multi-threaded (note that this could be a disadvantage if you don't code properly). This means that highly performant web applications that rapidly update and receive tons of streaming data may perform better in Silverlight than in Flex.

Most web applications do not update quickly enough that this would matter, save for real time stock or news tickers.

With the same speed of data streaming in, Silverlight was able to update faster, and with less taxation on the CPU. Both Flex and Silverlight can handle a huge number of updates per second, and of course updates to the display are ultimately limited to monitor refresh rate and human perception.

One of the major advantages Flex has over Silverlight is visual display. Flex descended from Flash, an engine built for animation and graphics. It's animation smooth, graphics clean, and gradients smooth.  I personally find Flash CS3 to work a lot smoother than Expression Blend 2.5 March 2008 Prieview Edition. However, Blend 2.5 is still in Beta, so I will judge when I see the release edition.

JavaFX is severely lagging behind all engines.  You also have to be a Java programmer to design apps, because no good visual tools exist (although there is a declarative language for UI so one may not be far behind). However, a friend who just returned from JavaOne 2008 gave me some the lowdown on a very cool feature of JavaFX: With JavaFX, you can write an app that lives in a browser, can be torn-off onto the desktop, the browser can be closed, and the app is still running. This is a pretty impressive feat, that could have many uses.  I'd like to see it in action.

I should note that Flash Player 10 has just been released in Beta. It incorporates a lot of cool things including hardware based graphic acceleration. I haven't tested it yet. Also look for the project codenamed Adobe Thermo - which will help with the design of Flex applications. It's not yet in Beta.