<%blogHomeDescription%>
If you enter Scripting News into Google, one of the top links is a temporary home page I put up on July 29, 2003. I've archived it in my public Dropbox folder, so you call can see it, and am redirecting from it back to the Scripting News home page. It's pretty weird that Google would give it so much prominence. There are quite a few other archived home pages at the top level of the site.
Anyway that little detour is gone now.
Why JavaScript I/O is so awkward
I remember well, the first moment I found out that you couldn't just make an HTTP request from a bit of JavaScript code in the browser.
It's something I had become accustomed to as being a simple procedure call:
xmltext = tcp.httpReadUrl ("http://scripting.com/rss.xml")
process (xmltext);
hello ();
That line of code returns the XML contents of my feed, in UserTalk, the language built into Frontier.
The interpreter makes the procedure call, and when it returns, the variable xmltext contains the contents of the feed. When hello is called, it can depend on xmltext having been set and processed.
It never occurred to me that any language could work any other way.
The equivalent code in JavaScript looks something like this:
Looks pretty similar, until you realize that the hello call will execute before xmltext is processed. How do you wait for the text to be read? Good question! There isn't really a good answer.
This means that some things are impossibly difficult to do in the browser that could be done in another language that imho worked more reasonably.
When you think about it, the whole mission of the browser is to read data over HTTP in multiple simultaneous threads! That this isn't trivially simple in the scripting language for the web, JavaScript, is costing us an enormous amount of time and money.
Unless I'm missing something obvious, which is why I'm writing this post (but I don't think I am).