8 ms·

Ask HN: Who built XMLHttpRequest at Microsoft in 1999?

176 points by donohoe 14y ago

The person (or persons) deserve a medal. All I can find is it was built for Outlook Web Access. Nothing more. No names, no nothing. Who's idea was it, and who built it? Anyone know? http://programmers.stackexchange.com/questions/123475/who-first-created-or-popularized-the-original-xmlhttprequest-msxml http://en.wikipedia.org/wiki/XMLHttpRequest

BarkMore 14y ago
It was Adam Bosworth's idea. People on Adam's team built it. Edit: I recall seeing Bosworth's auction demo in late '97 or early '98. This predates Hopmann's timeline. Perhaps my memory is faulty.
- corin_ 14y ago
  Slightly different story at http://www.alexhopmann.com/xmlhttp.htm http://www.alexhopmann.com/xmlhttp.htm with an update regarding Bosworth: Adam and his team (especially folks like Rod Chavez, Michael Wallent and many others, as usual I'm probably forgetting to mention some of the key people) invented the Dynamic HTML part which was miles beyond what Netscape was doing at the time. I just filled in the XMLHTTP piece, and collaborated with many others to do the first major app that tied it together (Outlook Web Access). Without the earlier contributions of the Trident/IE teams, it wouldn't have been possible, and its absolutely true that Adam and many folks he worked with had the conceptual vision for tying it together (he called it weblications at the time). Note to OP: this blog was reference 6 in the Wikipedia article you linked to.
  - donohoe 14y ago
    Much obliged - totally missed it
  - deleted 14y ago
    [deleted]
  - daigoba66 14y ago
    I feel that I want to now use the term "weblications".
    - chris_wot 14y ago
      Feel free to use it in the blogosphere.
Arjuna 14y ago
It would be remiss to not mention Shawn Bracewell in the discussion. According to Alex Hopmann, Shawn was responsible for adding asynchronous support: "Step one was to bring the code up to production quality so we got Shawn Bracewell, one of the devs on the OWA team to take it over. Being a smart guy he promptly threw away all of my code and rewrote it in a more solid fashion, adding async support, error handling and more." [1] [1] http://www.alexhopmann.com/xmlhttp.htm http://www.alexhopmann.com/xmlhttp.htm In addition, Jim Van Eaton wrote: "XMLHTTP was born and implemented by the OWA dev effort of Shawn Bracewell. Exchange funded the effort by having OWA development build XMLHTTP in partnership with the Webdata team in SQL server. XMLHTTP changed everything. It put the "D" in DHTML. It allowed us to asynchronously get data from the server and preserve document state on the client." [2] [2] http://blogs.technet.com/b/exchange/archive/2005/06/21/406646.aspx http://blogs.technet.com/b/exchange/archive/2005/06/21/40664...
- ttrreeww 14y ago
  http://www.linkedin.com/pub/shawn-bracewell/9/b23/a4 http://www.linkedin.com/pub/shawn-bracewell/9/b23/a4
- kragen 14y ago
  Sounds like Shawn Bracewell is the person to really credit — non-asynchronous XHR is unusable, and unused. Jim's remarks here are a little over the top. At KnowNow in 2000 we were asynchronously getting data from the server and preserving document state on the client by implementing Comet in in Netscape 4 (and IE 4), by using a frameset with zero-height frames. These days long-polling frames that finish loading when there's an event are more common, but we were using endless HTML documents that would get a <script> tag added when there was an event. The <script> tag would invoke top.somethingorother(data). A second invisible frame was used to send data back to the server as HTTP POSTs. We had a bunch of bodgy code to handle the case where you have several windows open doing Comet to the same server, ensuring you only ever have one persistent connection; otherwise the two-connections-per-server limit kicks in, and the page stops loading forever. It's more sensible to use wildcard DNS to circumvent this restriction. XHR is a much saner way to do AJAX, and Websockets are a much saner way to do Comet, but you can do AJAX and Comet without them. XHR didn't "change everything" and "put the 'D' in DHTML". It just made it more convenient.
Thiz 14y ago
I'd like to know the first guy to send json over the wire starting the ajax craze.
- niggler 14y ago
  I think Crockford (http://crockford.com/ http://crockford.com/) -- he is mentioned in the RFC: http://www.ietf.org/rfc/rfc4627.txt?number=4627 http://www.ietf.org/rfc/rfc4627.txt?number=4627
  - DigitalJack 14y ago
    More specifically, he wrote the RFC.
- jdminhbg 14y ago
  Douglas Crockford, as that was the first thing JSON (as a data format) was used for: http://en.wikipedia.org/wiki/JSON#History http://en.wikipedia.org/wiki/JSON#History
  - udp 14y ago
    Well, it's possible an object was transmitted as JavaScript source (to be decoded using eval) before the JSON spec existed.
  - chubot 14y ago
    Crockford has said that people were using JSON before he "discovered" it. That's why he says he discovered rather than invented it. Unfortunately I don't remember who those people were, but anyone who used XmlHttpRequest, which was apparently there in the 90's, could have used it.
    - rsl7 14y ago
      I made up and used something similar to JSON in 1996. It's not difficult to think up if you're trying to find the simplest possible text-based hierarchical data format. There were a lot of variations on this idea.
corresation 14y ago
Who's idea was it, and who built it? While history generally gets rewritten towards a simplified, single-victor model (e.g. Edison and electricity, Ford and assembly lines), there is no simple answer to this because the need for a scripted way to load and consume content was very widespread. There were a number of solutions at the time. The most prevalent was simply having a hidden iframe (which actually worked quite well, with the biggest downside being a loading event noise it would fire in Internet Explorer). In Internet Explorer you could also take advantage of any Safe-For-Scripting marked ActiveX control (yes, ActiveX was the foundation upon which XmlHttpRequest was possible, adding binary extensibility to the browser), which at the time included a large number of third party tools and libraries for doing calls to web services, and a lot of hand-rolled solutions, pre-XmlHttpRequest. The problem, of course, is that your users had to have those same components installed which could be an issue. Which was why it was a great convenience when Microsoft started releasing mostly unnoticed XmlHttp components in the MSXML parser library. It was a fragile, memory-leaking beast, but it had the benefit of starting to be packaged in other Microsoft installs, so it was increasingly likely to exist on your client's PCs. The TLDR; is that it was inevitable, and it is unfair to the truth to attribute such a progression to one person. EDIT: To why I know this, at the time '99/'00 we were building a rather innovating web application to monitor and control distributed power generation units across the continent. We used the iframe approach, and then an HTTP component included with a Delphi component suite (name escapes me right now), and were then one of the first beta testers of XmlHttp.
- hna0002 14y ago
  Yeah, dont credit Apple for ipod, iphone or ipad, dont credit Mark Zukerberg for social networking, Bill Gates to bring philanthropy to main stream, a government to find the terrorist of Boston attacks, It was all inevitable!
  - corresation 14y ago
    This childish, sarcastic style of response is increasingly common on here. That isn't a good thing. If you want to specifically address something I've said, stick to that.
g8oz 14y ago
XMLHttpRequest was the critical piece in enabling proper browser applications. If it had come from Firefox and the functionality it made possible was not available on IE the uptake would have been minimal.While is has been beyond fantastic for the world, the results have been terrible for Microsoft and key to the diminishing importance of Windows. I would thus count XMLHttpRequest as an own goal.
MatthewPhillips 14y ago
I love getting history like this. I'll add to the question if any Microsoftians are around: who decided to call it XMLHttpRequest?
- alexhop 14y ago
  I did (Alex Hopmann). The easiest way to ship it in IE5 at that relatively late stage (right before IE5b2) was to put it in msxml.dll so we had to put the XML twist on it for that to make sense.
pbreit 14y ago
I'd like to know...so I could ask him/her why the heck a data format was melded to an Http client!
ExpiredLink 14y ago
BTW, XMLHttpRequest was a big mistake with significant consequences from Microsoft's point of view. It opened the door to Web applications an ended the age of desktop applications and thereby Microsoft's dominance. If MS managers had understood the technology they would have never let it escape into the IT world. Without IE's accidental support other browsers (Netscape, Firefox) would have been unable to establish the technology.

nobodysfool 14y ago

JSON is great for sending javascript objects over the network. However, the way most people use it, they'd benefit from switching to CSV files instead. JSON has a lot of overhead (each instance of each object has to have a name), but it's better than xml.

Stratoscope 14y ago
That's true, but the JSON data is sent over the wire with gzip compression. All those repeated names compress out very nicely. CSV is still probably more compact than JSON even when compressed, but the difference isn't nearly as much as you'd expect from the raw textual version. Of course it gets expanded back to the full text in the browser, but that gets parsed and discarded right away. When I read CSV in JavaScript, for convenience I usually end up converting it to in-memory objects that resemble the JSON object that I would have downloaded otherwise. So at least in that case there isn't much difference in memory use either.
- mpyne 14y ago
  Also browsers are much more likely to be able to optimize the parsing of JSON back into a DOM than they are to be able to optimize the JS that would be used to parse the CSV.
iso8859-1 14y ago
CSV files are simply lists of tuples. You can do lists of lists in JSON. Your overhead will be two characters (opening/closing braces) per tuple (one if you skip the newline, which you can't skip in CSV), plus a dozen characters for the whole file. I don't think that's a lot of overhead, seeing that you get the benefits of a format that is actually standardized. Example (CSV): name,age James,32 Nina,10 Helga,90 JSON: {"fields":["name","age"], "content":[ ["James",32], ["Nina",10], ["Helga",90] ]} Don't tell me it's harder to parse, cause you'd have to do the index→fieldname conversion in CSV too.
- teyc 14y ago
  CSV isn't standardized. http://en.wikipedia.org/wiki/Comma-separated_values#Lack_of_a_standard http://en.wikipedia.org/wiki/Comma-separated_values#Lack_of_... There are a lot of questions regarding use of quotation, new lines etc. JSON's standard is that it should be able to be eval'd by javascript interpreter. Even then, date handling is less than ideal.