In the wonderful IE4 days when ActiveX was the big new thing, you could create an ActiveX control -- that is, a first class COM object - in full Visual Basic. In fact, Microsoft released a free version of Visual Basic just for creating ActiveX controls. It was ridiculously easy to create COM objects in this way.

Then you could instantiate the object in the browser scripting engine and do things like:

<script>
myActiveXObject.HtmlDocument = document;go
</script>

With that one line of code, (popping knuckles) the full-blown Visual Basic programming environment had access to the Internet Explorer web browser document object. There was no wrapper, just a COM interface!!

Visual Basic:

Call Me.HtmlDocument.window.eval("alert(""Hello from full-blown Visual Basic via the browser's Javascript scripting engine"");")

Me.HtmlDocument.body.innerHTML = "<h3>Muahahaha!</h3>" & Me.HtmlDocument.body.innerHTML
Me.HtmlDocument.body.style.backgroundColor = "#00000"
Me.HtmlDocument.body.style.color = "#ffffff"

Call Me.PlayVideo()

' etc.

Likewise, the COM interfaces of the ActiveX control were directly and effortlessly exposed to the browser Javascript runtime.

<script>
myActiveXObject.PlayVideo();
</script>

This opened all kinds of doors of opportunity. Event sinks and controllers could be dropped in every which way. Flexibility of writing code was virtually limitless.

This WAS doable before Microsoft abandoned Visual COM (Visual Basic 4/5/6). The ActiveX Script runtime engine was a marvelous invention. I'll admit that it's proprietary to Internet Explorer, though, but Mozilla has traditionally supported COM in some fashion. I don't know how Mozilla's plug-in and scripting runtime integrations work.

Fast forward to today. Rich client applications are now written in Javascript and AJAX, making use of only one specialized COM object (or other automation object, depending on the browser) now known today as XMLHttpRequest. Rich client apps also make heavy use of objects-based programming.

In order to create user experiences that are outside of the capabilities of Dynamic HTML, plug-ins are still used. This is where plug-ins like Silverlight come in. But those plug-ins, especially when they have broad and powerful runtimes like Flash (ActionScript) or Silverlight (CLR), need to be able to be interopable with the browser's script runtime in order for utilization to be fully realized. In the Internet Explorer world, the answer to this was simply IUnknown / COM / ActiveX.

ActiveX componentization is now virtually deprecated. Microsoft no longer sells nor supports Visual COM (Visual Basic 4/5/6, which was the only tool Microsoft ever created to allow users to be able to effortlessly create COM objects). ActiveX controls are also a security concern, and in Internet Explorer 7, users are discouraged from installing them.

But what I'm looking for is unwrapped interop support between the Silverlight CLR and the browser's runtime. Silverlight doesn’t have access to the Javascript DOM. It has access to a limited set of objects and properties of the HTML DOM using a wrapper API.

http://silverlight.net/QuickStarts/Dom/DomAccess.aspx

The CLR in Silverlight introduces a secure but powerful runtime engine to the web environment and an extent of sophistication that previously never existed, not even with old Visual COM (Visual Basic 4/5/6). Now that Silverlight 2.0 is coming out soon with a rich programmatic runtime like Visual COM (VB) used to have, I’d like rich COM automation back. The value is more fully realized when you can pass browser Javascript objects to the CLR or pass CLR-declared objects to the browser Javascript runtime.

(I'll post better examples of what used to work versus what doesn't work later this week. But yes, full COM interop was possible between VB and ActiveX Scripting, and yes you could pass objects back and forth. It even supported dynamically generated COM interfaces. For example, you could declare and instantiate a class in VBScript in the browser, pass the instance to a method on an ActiveX control written in VB where the VB OCX property expects a Variant, and then VB OCX could call upon the functions within that class.)

Obviously, what this means is that Safari, Mozilla, and Microsoft would have to agree on an interop strategy. I thought they had already accomplished this, but it'd be surprising to me if they didn't. It would, however, further cement my frustrations with Microsoft that they allowed too many years to go by without staying involved with the browser standards communities like W3C and ECMA to work those issues out.

ActiveX componentization is not deprecated because COM is a security concern. It is deprecated because the technologies that implemented ActiveX were not sandboxed like Java applets, Flash, and Silverlight are. The Silverlight CLR is neatly sandboxed--this means that there are no longer serious security concerns that developers otherwise had with the ActiveX plug-in support--so if security is a concern, it shouldn't be.

But, practically speaking, browser Javascript objects and logic need to be able to interact with plug-in runtime objects and logic and vice-versa. Put as succinctly as I can, if I cannot declare a function in the browser script with parameters, and call on it from the CLR while passing CLR objects, I feel stuck with preferring old ActiveX over the Silverlight CLR for dynamicizing HTML. The same is true going the other way. The way things are right now, it's an all-or-nothing deal--either you completely rewrite the AJAX web application so that it no longer users the browser Javascript and uses the Silverlight CLR, or you don't use the Silverlight CLR and stick with the browser Javascript. These two options are completely unrealistic, from a business perspective.

Microsoft's position on this matter has so far been that they think the "wish is valid, but it is challenging since we are dealing with a scripting world, a native world and a managed world all in one wish."

I'm sure it is challenging. But this and true DHTML are precisely why I thought Internet Explorer v4 was the greatest invention that came out of Redmond after the Windows NT kernel. It's why Internet Explorer had been Microsoft's preferred generic COM host for SDKs and development for many years.

I don't care if it is challenging. It was Microsoft who invented COM. It was Microsoft who implemented the ActiveX Scripting engine. It was Microsoft who invented the fully programmable browser DOM. It was Microsoft who invented .NET and the Visual Basic and C# languages. I have no doubt that the most profitable corporation on the planet can figure something out in this matter.

But this is an issue I have that goes beyond Silverlight, it is about Microsoft's leadership role in the Internet client software industry. It's like they fired their automation visionaries as soon as IE4 went gold.

Perhaps that isn't fair; the CLR is certainly quite visionary. It's just that the current state of things shows abandonment of the industry necessity to keep striving to bridge the gap between the browser script runtime and the plug-in runtime; this is a problem that has been around for over a decade, and that the industry leaders aren't still pushing for a cross-browser automation solution really befuddles me.

There is one "trick" that I can think of, though, to make window.eval() happen from Silverlight that may or may not work efficiently. Perhaps you can get Silverlight to change the text value of a hidden HTML element. This HTML element is strictly used for window.eval(). Javascript would need to be notified that the value changed. A setInterval loop? An onchange event hook? Dunno. But once it sees it it can fire it off and then populate some other hidden element for the eval result. I'd prototype this but I don't think onchange will work and a setInterval loop frightens me, not to mention only being able to use text (or XML) for params and return values. The whole idea seems terribly kludgy... Yuck.