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
"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
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/40664...
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.
I wouldn't say this at all. We could have gone in a completely different direction with Javascript, even back then: spawning numerous lightweight processes running userspace code which then sit in a blocking "receive" state whenever they want to wait for the result of an XHR. In other words, Javascript could have been Erlang for the browser, instead of the odd OS7-like cooperative-multitasking abomination we have now.
(What we did get are Web Workers, which are full OS threads you can't even message if they're doing something synchronous. What's even the point of these?)
It's great that somebody made XHR asynchronous, but it was just going with the flow of everything else in IE-land.
Edit: I recall seeing Bosworth's auction demo in late '97 or early '98. This predates Hopmann's timeline. Perhaps my memory is faulty.
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.
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.
It's a dreary business trying to analyze humor, even more so to analyze what kind of humor plays well at Hacker News, but I'd say the more original the joke, and the more the joke makes you think afterward, the better it will do.
As an aside, my goodness, this is such an HN comment.
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.
Example (CSV):
name,age
James,32
Nina,10
Helga,90
{"fields":["name","age"],
"content":[
["James",32],
["Nina",10],
["Helga",90]
]}
JSON's standard is that it should be able to be eval'd by javascript interpreter. Even then, date handling is less than ideal.
The Ajax craze was, of course, with XML (ie, the X in Ajax). JSON is certainly a more pleasant format to work with but not a huge leap over XML. But it was lame that XML was melded on such as it was.
Douglas Crockford's brilliant move was to create the web site http://json.org/ By putting the ".org" at the end he tricked the world into believing it was an accepted standard.
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.
Getting an attractive UI was rough going, but I wasn't much worried about that at the time...
An applet could also make JavaScript calls, so it was also possible to pass data back into JavaScript on the page. That was a technology that came from Netscape, but MS copied -- so (strangely enough) there was a Java package included in Microsoft's jview distribution that had "com.netscape.livescript" (something like that) in the name.