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:
myActiveXObject.HtmlDocument = document;go
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!!
Me.HtmlDocument.body.innerHTML = "<h3>Muahahaha!</h3>" & Me.HtmlDocument.body.innerHTML
Me.HtmlDocument.body.style.backgroundColor = "#00000"
Me.HtmlDocument.body.style.color = "#ffffff"
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.
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.
(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.
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.