I am not confident that anyone could successfully abstract away all the myriad of differences between the browsers. All it takes is on compatibility issue and you are digging through not only your own code but that of the much more complicated parser/abstraction layer.

This is why I shirked even looking at any of the Java-based JS generators (such as Google’s library and DWR). Narrative JS is fun to read about but wont make it out of my sandbox at this stage.

I’d just rather not do it through sleight-of-hand that simply masks what ends up being actually async code. I’d rather there were a different threading model or a non-blocking sleep() function in Javascript or a synchronous XHR call with more control over timeout and connection parameters and better error trapping so you can actually make synchronous calls without consigning yourself to lockups.

In the meantime, I’d tend to want to avoid code that pretends to be something it’s not.

Gotta thank you for the pages you put up covering JSRS all those years ago! Just a comment on this post – I do think that if you dig a little into what Harry is saying in his article there is a greater pragmatism there than you may have initially realised.

I am working with a team on a project which has required alot of javascript event-driven development. This work made it clear to me that event-driven, whilst initially fun, is extremely hard to debug (and often hard to follow).

I think Harry was looking for ways to ‘change the game’ and make the code more the descriptive of what happens rather than have the logic spread amongst your event handlers.

I certainly am a proponent of ’simplicity begets stability’. As Harry admitted – the systems he described in his article may not be ready for prime-time – but consider if Javascript had the blocking abilities built into the core. To simplify the permutative nightmare that can be event-driven programming would also satisfy your credo.