Anne 2.0 posted a short note about .Net Framework 3's launch and include the short phrase:

"XBAP = next-generation ActiveX?"

I ended up typing a quick reply in comments...but I figured it was worthy of a post.  I am too busy to tweak it so it is perfect...I'll post now and adjust based on comments and further thinking...

Are XBAPs next generation ActiveX?

That is an interesting way to think about them.  I hadn't heard that comparison before.
Clearly we are trying to enable some similar things...and luckily we realize many of the problems of ActiveX.

So, maybe that is a valid way of thinking of them...but read the details below...

ActiveX Problems

ActiveX allowed web sites to take advantage of Windows and the power of Win32. It had a few problems:
1) once installed, activeX controls could do anything, even things the user might not want you to do - like delete files...
2) activex controls, because of 1, required a user prompt. Many developers weren't excited by that...or the complexity of installation that users had to go through.
3) activex controls only worked in IE based browsers

XBAP Comparison

XBAP powers that are shared with ActiveX
XBAPs have some of the positives that ActiveX controls had:
1) they can do powerful things more easily than they could be done in DHTML.

XBAPs fix some of the Cons of ActiveX controls:
2) XBAPs run in a sandbox, and can't do things like delete files.
3) since there is a sandbox, that limits the power of what XBAPs can do to the local machine. that means we don't need to prompt for approval to run the app...giving the user a better experience.

XBAPs go beyond ActiveX controls:
4) XBAPs can use all (or 98.2%) of the power of WPF to build great user experiences.

XBAPs add one CON over ActiveX controls:
5) xbaps must live inside of a Frame/IFrame or top level window...so the incremental addition to an existing web page is not as strong as activex controls enable. we know of this limitation and would like to fix it in the future...
6) becuase the hosting strategy is currently a DocumentObject application, instead of an activex control, the granularity of communication from a hosting web page into the XBAP is weak. You can communicate via querystring.  This area has a bunch of room for improvement
[thanks to Footballism for calling out this point in comments...this list wasn't complete without it.]

XBAPs share this con

7) XBAPs today only run in IE6 or IE7 (or in other browsers that host IE technologies: netscape, firefox...but that isn't as great as native support).  This is not a technologically blocked...as long as .Net Framework 3.0 is installed on a machine, other Browsers should be able to support XBAPs...if you want those browser vendors to enable that, please ask them to enable it
[Thanks to Logan for calling out this issue in the comments]

Related Posts/Information

• Karen Corby is the Program Manager that drove much of the SandBoxing (security) work that enable XBAPs to do so much, in a secure way.  In WPF Internet Sandbox Feature List (XBAPS & Loose XAML) she lists everything that runs in the sandbox and she links to a few whitepapers that are helpful.
• Karen Corby has posted a description of XBAP and Trust Levels that I often point people to.
• Charles Petzold wrote a post describing Converting EXE Projects to XBAPs.

Thoughts?

Updates:
November 13, 2006 - added bullet 6 and 7 and the links to Karen Corby and Charles Petzold.
July, 2007 - added the link to Karen's XBAP and Trust levels