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.

The ideal

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.

How it works in JavaScript

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.

Why this is surprising

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).


Posted: Mon, 18 Nov 2013 16:01:40 GMT