4 ms·
Node.js is too opinionated about how to do things that it could ever replace anything on the server-side of things, be it PHP, Python, Ruby, Lua, whatever. Thei
by eriksank 13y ago
Node.js is too opinionated about how to do things that it could ever replace anything on the server-side of things, be it PHP, Python, Ruby, Lua, whatever. Their "event-driven, non-blocking I/O" experiment should be entirely optional, and for the afficionados only. Do you know of any other scripting engine that imposes that kind of experiments on its users?
I would be entirely ok with replacing mod_php or su_php with mod_js or su_js, but I am really not interested in joining their callback hell.
- scriptproof 13y agoEach asynchronous function has its synchronous counterpart, so you may choose the best option, each has its advantages.
- rubinelli 13y agoI'll add that Javascript programmers are more familiar with event-based programming; it's already how they work client-side.
- L0j1k 13y agoJust use EventEmitter to avoid callback hell. Or pubsub.
- L0j1k 13y agoThough I do agree that JavaScript needs an indescribable "something" to make it less formulaic and demanding ("opinionated" is good here but I don't want to steal your wording).
- VShell 13y agoIt's really not an experiment. Python's largest networking framework, Twisted, uses event-driven, non-blocking I/O with callbacks; however, Twisted implements a number of wrappers and patterns to make it a bit more usable. (There are also a number of other commonly-used libraries for all sorts of languages which follow a similar concept; thread-oriented network programming is now a bit of a rarity in new code for things outside the "old" one-way web.) Where in node.js, a vaguely procedural programming pattern is usually adhered to, Twisted uses a lot of objects with state to manage protocols and business logic. Many of these objects will adhere to various pre-defined interfaces within Twisted, especially when they are directly dealing with network protocols. This means that when you're implementing that new protobuf-based protocol, you will always subclass Protocol or one of the simple Protocol subclasses in twisted.protocols.basic, implementing dataReceived() (or the relevant message-oriented function for your subclass), then create a subclass of Factory to create these protocols, then, when you want to connect, you hook up the Factory to an Endpoint. "Callback hell" is thus mitigated by the fact that you will typically name every callback as a method on the object, and each callback can be as short as a few lines. You also don't tend to bury yourself 6 layers down waiting for a read; instead, you store a bit of state on the object, and wait for dataReceived() (or your buffer-emptying callback) to be called again. In cases where it's still hell, for whatever reason, the @defer.inlineCallbacks decorator will help by allowing you to write code like this: @defer.inlineCallbacks def foo(): result = yield somethingThatReturnsDeferred() result2 = yield somethingElse(result) defer.returnValue(result2) All in all, my proposal is that node.js's issue isn't that it's too opinionated; it's that it's not opinionated enough, implementing only the base layer of something which needs a lot of opinion to be usable.
- Offler 13y agoWithin a year ES6 will be shipping and available, already generators have been implemented in V8. Combine them with http://taskjs.org/ http://taskjs.org/ and you have callback hell relegated to a distant memory.