I like Web Parts, really I do. Their functionality is great, but I find them a bit heavy; the HTML they generate isn't great and some of the customisation is dated now that Ajax is popular. In fact, I can't help feeling that if the ASP.NET team had to write Web Parts from scratch now, they certainly wouldn't take the same route; they'd be Ajax based all of the way.
There were many ways in which I could have improved the existing functionality of Web Parts, but it just didn't seem sensible given that the things I don't like about them are inherent in the framework. I'd also proposed a session for ASP.NET Connections where I'd compare and contrast WebParts and Ajax, and it seemed contrary to the idea of the talk to change the server-side functionality, when I should be looking client-side.
So I decided to create a client-side framework, and spend a bit of time playing around with ideas until I found a good base to build on - Rick Strahl's wwHoverPanel. Rick is a fellow MVP and conference speaker and has a great set of Ajax controls; server controls that are just containers for a small amount of content and that emit JavaScript to encapsulate the client side functionality. Rick's framework has a drag panel, which supported close, but not other things that I feel are needed; minimise and maximise, state persistence, connections, etc. So, as his source code is available, I started hacking. I got the min/max and persistence (to the ASP.NET Profile) working before the conference, but hadn't really done much in regard to connecting the parts together. I started telling Alex about this in the bar one night and we argued for a day on how to do it; I'd started off thinking in the same way as Web Parts, but registering both a provider and a consumer to allow data to flow. Alex, who has been writing a log of documentation for the Microsoft Patterns and Practices group, suggested a form of the observer pattern would be better, given that it more naturally fits with developers used to subscribing to events. So I tried it and it worked well, with a consumer part registering to receive data; the registration uses a key to identify the sort of data (ZipCode, Address, etc) and is not type related - it can be a simple type (a string) or a complex JavaScript object, there is no restriction. Any other part, or any client script in fact, can just send data using this key to identify the targets. It doesn't know what the targets are, just the key.
The project is available on the Ajax Web Parts page on my site and is free to download and use as you see fit. It's very raw at this stage and there are things I intend to do to improve it, such as cleaning up some of the code, removing some hard coded names, fixing some bugs and adding features.