[tcaudilllg]

The wrong way to do async javascript is the way it's done now. A million patches and workarounds to make simple filehandling work on terms a few people who are in position to make major software decisions impose upon us. We are told we don't want to wait while a 1gb movie is loaded from an SD card. I agree. But did they ever think of suspending execution of the script itself in leu of that request? That doesn't mean tying up the operating system... far from it. Instead you let other tabs do their thing and even let events keep progressing. But that particular script thread you keep locked until it returns a value. It might require a rewrite of the javascript engine... that might cost money... oh wait, the lead javascript engine programmer at Mozilla ALREADY HAS a rewrite of the whole thing planned, allegedly to improve performance (the Pale Moon team has expressed skepticism). I think they could make the changes, saving many programmers lots of effort. They might allege its a security risk, but that's a big fat lie.

[Ninkazu]

What are your thoughts on the upcoming feature of futures? Or Crockford's promises pattern?

[tcaudilllg]

Promises don't do it. At the end of the day, the costs of async are just too great. Most humans think linearly. While the async favorers are apparently able to cope with the fragmentation, there is an inexorable cost in async of code reusability. This is what I've discovered in the course of porting Gamestar to Mozilla Addons SDK.

The port is dragging on five weeks now. The task is simply so complex that at times I just don't have an answer as to how to go forward. Promises won't work because I need the information requested in the next line of code.

For example, to load full games I first have to load the project file in which defines the game boards. From this file I have to read the starter map filenames from the definition. The definition must, of course, be parsed, tokenized, and processed. Inside the map files are the names of tileset definition files that must be parsed. What this means is that you have to request the game be read; wait for the callback; process the game definition; request the map be read; callback; process the map; request the tileset definition be read; callback; process the tiles. All this for multiple map files, so you have recall the game processor at the end of the sequence, and start the process over. It's not impossible, but it requires significantly more planning and many more elements than the async method. This is the problem with asynchronous programming: everything takes more. I've had to integrate a state machine to direct the data received from a read, because the message listener captures every single message sent from the main module (which under the SDK is the only script capable of using SDK functions themselves) to the web page. Every additional purpose I have for file reads means a further expansion of the machine.

It's been alleged that Javascript is single process... that's not true. SetTimeout and SetInterval can modify a global variable even as another event processes. I know because I've faced bugs on account of it before. They can, in fact, even overlap. That's why you have to use ClearTimeout, because otherwise you'll end up with multiplied counters. Well maybe not... maybe they are just arranged in sequence and execute one right after the other. But it should be possible to make a multi-process version of Javascript regardless, because breakpoints in Firebug use the exact same techology.

It can be tempting to rely on existing technology to develop solutions (or rely on tools provided by others for those solutions), but sometimes you just have to develop new technology from the ground up for efficiency's sake.

[tcaudilllg]

I threw in the towel on trying to get by with a generalized file interface and moved some of the app-specific code into the extension module. I floated the idea around Mozilla's JS engine people and they said it'd be too much work to complete anytime soon, so I didn't really have much choice. I stand by my position on async implementation, however, because synchronous async is feasible and would make code easier and faster to develop. As it is I have to parse any and all scripts I load files from twice, once to find the file names and load them from the extension module, and again to process the rest of the script. Actually I probably could pass the parsed scripts back over to the app, but this is something I only see in hindsight. Which is the whole problem: async programming ends up being wasteful and redundant, more work for nothing.