3 ms·

Server-side Javascript, in particular Node, is much better suited to event-driven applications (e.g. web servers) than a lot of other languages out there, inclu

by tg3 13y ago

Server-side Javascript, in particular Node, is much better suited to event-driven applications (e.g. web servers) than a lot of other languages out there, including Ruby (and dare I say Python?).

mwcampbell 13y ago
This time I'll argue the other side. A lot of web applications routinely do many I/O operations per request handler. For example, do a DB query, then do something with that data, then conditionally do another DB query based on the results of the first, then do something with that data, then query a REST Web service, and so on. Blocking APIs make this very natural; add high-level abstractions such as an ORM, and you don't even think about the fact that you're doing I/O. With something like Node, application code of this sort degenerates into callback spaghetti, unless you use something like the fiber module, or a compiler that transforms the natural, straight-line code into continuation passing style. Though I've previously argued for the potential advantages of using the same language for both the client and the server, I fail to understand why something like the fiber module isn't standard in Node, or why the kind of compiler I described isn't more popular. Perhaps that's just dogmatism or a cargo-cult mentality. An event-driven system might be good for "real-time" applications where many clients connect and wait to have things pushed to them. Even then, I think coroutines or lightweight threads would be fine, as long as they're the norm for a runtime environment and its standard library (e.g. Go, and Haskell IIUC) and not bolted on (e.g. Python's eventlet and gevent).
- tg3 13y ago
  The fact that most web applications do many I/O operations per request handler and the Blocking API's make it very natural so that "you don't even think about the fact that you're doing I/O" is precisely the problem. I/O is an eternity compared to computing cycles, and to have the entire thread blocked while waiting for I/O to complete means that you can have exactly one concurrent client. Node can easily degenerate into callback spaghetti, that's true. But I think that has more to do with the paradigm being new to a lot of developers. Using promises and similar constructs are a very natural way to deal with callbacks, and reduce the spaghetti significantly. Unfortunately, they won't be baked into Node's core. Even for a standard CRUD app, you can get way more performance out of Node than you can out of, say, Rails, precisely because it is highly concurrent.

by tg3 13y ago

Server-side Javascript, in particular Node, is much better suited to event-driven applications (e.g. web servers) than a lot of other languages out there, including Ruby (and dare I say Python?).

mwcampbell 13y ago

This time I'll argue the other side. A lot of web applications routinely do many I/O operations per request handler. For example, do a DB query, then do something with that data, then conditionally do another DB query based on the results of the first, then do something with that data, then query a REST Web service, and so on. Blocking APIs make this very natural; add high-level abstractions such as an ORM, and you don't even think about the fact that you're doing I/O. With something like Node, application code of this sort degenerates into callback spaghetti, unless you use something like the fiber module, or a compiler that transforms the natural, straight-line code into continuation passing style. Though I've previously argued for the potential advantages of using the same language for both the client and the server, I fail to understand why something like the fiber module isn't standard in Node, or why the kind of compiler I described isn't more popular. Perhaps that's just dogmatism or a cargo-cult mentality. An event-driven system might be good for "real-time" applications where many clients connect and wait to have things pushed to them. Even then, I think coroutines or lightweight threads would be fine, as long as they're the norm for a runtime environment and its standard library (e.g. Go, and Haskell IIUC) and not bolted on (e.g. Python's eventlet and gevent).

tg3 13y ago
The fact that most web applications do many I/O operations per request handler and the Blocking API's make it very natural so that "you don't even think about the fact that you're doing I/O" is precisely the problem. I/O is an eternity compared to computing cycles, and to have the entire thread blocked while waiting for I/O to complete means that you can have exactly one concurrent client. Node can easily degenerate into callback spaghetti, that's true. But I think that has more to do with the paradigm being new to a lot of developers. Using promises and similar constructs are a very natural way to deal with callbacks, and reduce the spaghetti significantly. Unfortunately, they won't be baked into Node's core. Even for a standard CRUD app, you can get way more performance out of Node than you can out of, say, Rails, precisely because it is highly concurrent.