Microsoft's original JavaScript implementation also had some interesting characteristics. Bear with me a moment as I describe why. Back in 1987, Bill Gates wro

Microsoft's original JavaScript implementation also had some interesting characteristics. Bear with me a moment as I describe why. Back in 1987, Bill Gates wrote an article for a Byte Magazine special edition in which he described a kind of system-wide scriptability as a next step beyond the simple macro languages common at that time. The general idea is that there would be a single 'macro language' that would have the ability to reach into and automate multiple different applications at the time. Maybe the easiest way to describe his vision from the article is to point to mid-90's VBA. Whatever else you can say about VBA, it represented the culmination of a strategy that Gates had been pushing for 10 years or more. I've always looked to that as an example of the value of long-term thinking in terms of technical strategy. (Even if I do rather dislike the result.) From the point of view of JavaScript, it's the technology that underpinned VBA's cross-application capabilities that's the most interesting. Sitting at the heart of OLE 2.0/ActiveX was the COM object model, and its late binding support in the form of IDispatch. Without going too far into the details, VBA was able to manipulate COM objects directly. But to do so meant it had to play by COM's rules - reference counting, specific supported data types, etc. Where JavaScript in the browser comes into the picture is that Microsoft's first JavaScript implementation was just another COM-compatible scripting language, and the IE 6 DOM was exposed as a set of COM objects. This meant that in addition to whatever slowness you had from the JavaScript interpreter, you also had to cope with the COM overhead involved in method calls to DOM objects, as well as the fact that DOM objects in IE6 were reference counted and not traditionally garbage collected. (I was involved in at least one mid-2000's-era project where we spent a bunch of time breaking cycles in DOM/COM object graphs to prevent memory leaks.) The 'upside' to this approach? Because the DOM was exposed via COM, you could also script your web pages in VBScript.... which was very much in keeping with Microsoft's vision and history, but almost nothing else. --- One other sidenote, while I'm wandering down memory lane. While OLE _2.0_ was the version that stuck, there was also an OLE _1.0_ that was totally different in implementation. Unlike OLE 2.0, which was based on an actual object model, OLE 1.0 was based on DDE (and shipped in Windows 3.1). DDE was the original MS Windows mechanism for dynamically sharing data across applications, and was heavily based on sending windowing messages from application to application (in the single shared address space common of the time.) IIRC, DDE 1.0 also had the ability to invoke macro commands in other applications, but it was not nearly as developed. (One of the initial challenges OLE 2.0 faced was that due to the fact it was branded so similarly to the radically inferior OLE 1.0, many people initially missed the value in COM.)