4 ms·
Read the article again. The statement, in context, has nothing to do with async. The author is claiming that JavaScript forces users to only use the callback
by nonchalance 13y ago
Read the article again. The statement, in context, has nothing to do with async. The author is claiming that JavaScript forces users to only use the callback style, but that's not true (especially given the last few paragraphs, where the author explicitly points out synchronous code).
The reality is that you could build up a C-style flow (loops with select/poll/epoll/...) in JS if a javascript platform exposed those primitives (you would need something slightly lower than libuv)
- majke 13y agoIf I understand correctly you're saying that JavaScript is a neutral language. It's only a coincidence that in Browsers and in Node.js it heavily relies on the callback style. As a language itself, it could be synchronous. Well, my friend, with this logic I claim that C is purely functional (it's only a coincidence that some implementations use rw memory) and there's nothing stopping Lisp from having mutable data.
- nonchalance 13y agoYou can claim that there exists a subset of C that can be considered purely functional, and others have argued that (http://conal.net/blog/posts/the-c-language-is-purely-functional http://conal.net/blog/posts/the-c-language-is-purely-functio...), but the existence of standard library functions like strtok makes the general statement false. You can claim that nodejs HTTP module forces a callback style, and that is true given the implementation, but javascript spec doesn't force you to implement an HTTP server in that fashion. As I stated in both responses, the article claims that javascript forces you to use a callback style, which is not the case. It is Node that forces you to use callbacks.
- saraid216 13y ago> If I understand correctly you're saying that JavaScript is a neutral language. It's only a coincidence that in Browsers and in Node.js it heavily relies on the callback style. As a language itself, it could be synchronous. I remember that I once wrote a JS library that loaded another page in an iframe and simply polled it to see if it had the data I wanted soon. These days, I probably would have written the server to respond with 202 Accept and then just timeout and poll again in X milliseconds. Block until it was ready, if need be. It's not hard, and it's not even particularly frowned upon.
- kevingadd 13y agoUnfortunately such a claim is false. The event loop and callback oriented asynchrony model is baked into the ES spec itself; future ES features rely on it explicitly.
- esailija 13y agoYou are probably confusing ES spec with DOM spec, if not, at least I cannot find anything in ES spec even remotely related to how anything built on top would have to be asynchronous.
- kevingadd 13y agoThe concept of an event loop and event loop 'turns' is backed into ES promises the last time I read the draft spec and kept up with the spec discussions. It's not something you can polyfill in older versions of JS, it's a platform feature designed around how browsers work.
- mook 13y agoHmm, do you recall where the ES promises spec lives? I can't find it in the ES6 draft ( http://people.mozilla.org/~jorendorff/es6-draft.html http://people.mozilla.org/~jorendorff/es6-draft.html ), but it's in the DOM spec ( http://dom.spec.whatwg.org/#promises http://dom.spec.whatwg.org/#promises ). ES6 does end up having iterators, which does look useful for promises, though... see task.js.
- qwer 13y agoThere are javascript implementations that don't go asynchronous though. Take rhino for example: http://stackoverflow.com/questions/7249252/read-file-with-rhino http://stackoverflow.com/questions/7249252/read-file-with-rh... . Or check out the commonjs spec: http://wiki.commonjs.org/wiki/Filesystem/A#Files http://wiki.commonjs.org/wiki/Filesystem/A#Files .