Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Just as this story came up I was watching the video of Ryan Dahl explaining Node.js (someone had shared this link in the recent thread about the event loop)

    http://developer.yahoo.com/yui/theater/video.php?v=dahl-node
In it, Ryan makes an important point about JavaScript being a natural fit because it was designed for a constrained environment. In particular, there is no way of doing I/O in JavaScript's traditional browser environment without providing a callback argument (I'm not counting interacting with the DOM as I/O here, and a couple of pedantic exceptions pointed out by judofyr below), and for the way in which the browser guarantees that only one callback will be executed at a time.

I think this idea of a constrained environment is very important. If blocking I/O functions are strewn about the APIs you have at your disposal, then programmers tend to default to using them.

The other point he makes is that often evented APIs are just missing from the underlying platform. Does every way of doing some sort of I/O in the universe of Python APIs have variants that take callback arguments? Even if the answer is 'yes' (which would surprise me) there is a minefield of blocking calls one would need to avoid in a disciplined manner.

...which may not be easy. Tell me: does myAwesomeFunction() do some blocking I/O under the hood? You can't tell from the name. Do the docs always make that clear, and provide an alternative with a callback?

Edited to include judofyr's exceptions — which bolster rather than undermine the point, because note that window.prompt's raison de'etre is to block for user interaction, and document.write is a RAM operation rather than disk or network I/O.



    There is no way of doing I/O in JavaScript's traditional browser environment
    without providing a callback argument.
What about `window.prompt`? Or `document.write`?


http://www.boctaoe.com/

(Man, I just learned about this site five minutes ago and it's already useful!)


I would hardly call window.prompt and document.write i/o since they never hit disk or network (to over-simplify). They're more like manipulating an object in memory.

For real i/o in JavaScript, look at AJAX: Callback based.


Conversely, some might say that input from the user and output to the user are really the only important i/o.


You are entirely right. In my mind use asynchronous for what it is good for, but use as little as possible. Delegate app logic to a synchronous threaded worker pool unless you absolutely cannot.


In my mind it's the other way around: Use asynchronous as much as possible. Delegate app to synchronous threaded worker only if you can't.




Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: