Live data from Hacker News

Ask HN: Who built XMLHttpRequest at Microsoft in 1999?

news.ycombinator.com

51–59 of 59 posts

Re: Ask HN: Who built XMLHttpRequest at Microsoft in 1999?

#51
post #24

Earlier quoted context omitted.

Douglas Crockford, as that was the first thing JSON (as a data format) was used for: http://en.wikipedia.org/wiki/JSON#History

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.

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.

Re: Ask HN: Who built XMLHttpRequest at Microsoft in 1999?

#52
post #34

Earlier quoted context omitted.

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…

A comet server I work with still supports foreverframe for browsers without websockets or multipart-replace because for fast updating data, it's actually much more performant than long polling.

Sure, it performs better, but apparently there are a lot of network environments where long polling works and forever-frame doesn't.

Re: Ask HN: Who built XMLHttpRequest at Microsoft in 1999?

#53
post #50
post #34

Earlier quoted context omitted.

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…

> non-asynchronous XHR is unusable, and unused. 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…

Sure, non-asynchronous XHR could have been usable. Opera at the time actually did give you multiple JS threads, but no locks or other synchronization primitives, so it was effectively unusable. We complained and, perhaps coincidentally, they "fixed" it by making it work like IE and Netscape.

Re: Ask HN: Who built XMLHttpRequest at Microsoft in 1999?

#54
post #9

I'd like to know the first guy to send json over the wire starting the ajax craze.

I don't know if it was JSON that started the ajax craze... I remember it being Google Suggest that brought the potential of Xmlhttprequest in to the mainstream (and there being a brief period thereafter where no one could decide whether to call the technique "xmlrpc" or "ajax"). JSON sprung up in a mainstream way a year or so after all that (or my memory is crap... which is quite possible!).

Re: Ask HN: Who built XMLHttpRequest at Microsoft in 1999?

#55

Earlier quoted context omitted.

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.

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 JavaScrip…

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.

Re: Ask HN: Who built XMLHttpRequest at Microsoft in 1999?

#56
post #9

I'd like to know the first guy to send json over the wire starting the ajax craze.

I'll take credit for that one. In the mid 90's at Nombas we created what we called DSP (Distributed Scripting Protocol) that serialized data (and functions) into js objects (now known as JSON) to be both human- and computer- readable and solve a lot of other problems (one of them being the danger of IBM's XML-hell, or Microsoft's DCOM or Suns's i-forget-what-it-was-called-java-thing taking over). We showed it doing super-duper cool stuff at ECMA committee meetings, and to the magazines and trade shows of the day, and filed patents for just about everything now seen as "AJAX" or "dnode"--had a lot of fun, but also A LOT of trouble getting people to use it because they saw it as weird.

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.

Re: Ask HN: Who built XMLHttpRequest at Microsoft in 1999?

#57
post #52

Earlier quoted context omitted.

A comet server I work with still supports foreverframe for browsers without websockets or multipart-replace because for fast updating data, it's actually much more performant than long polling.

Sure, it performs better, but apparently there are a lot of network environments where long polling works and forever-frame doesn't.

True. That's why polling is also supported as a fallback. Although with fast updating data, there's practically no difference between long polling and simple polling.

Re: Ask HN: Who built XMLHttpRequest at Microsoft in 1999?

#58
post #5

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…

Starting with IE4, Internet Explorer provided an asynchronous interface for fetching URLs. If I recall correctly, you had to go out of your way to use the synchronous interface.

It's great that somebody made XHR asynchronous, but it was just going with the flow of everything else in IE-land.

Re: Ask HN: Who built XMLHttpRequest at Microsoft in 1999?

#59

Earlier quoted context omitted.

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.

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:…

CSV isn't standardized. 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.

Post reply on HN