What is your biggest pain point w/ Node?

[mikeal]

What is the biggest pain point right now using Node?

This doesn't have to be specifically related to Node core.

Please refrain from suggesting features yet.

Please include a little bit about your background and what you're doing with Node.

[trevnorris]

There's too much surface area to the API that's tightly coupled with the internals. By writing a lower level binding (what @domenic has dubbed "libuv.js") that much of the current API can be implemented on top of, Node can allow developers to implement their own interfaces.

There's sentiment from one group that Node should have full support for Promises. While at the same time another group wants generator syntax support (e.g. var f = yield fs.stat(...)). It seems these parties miss the fact Node can't simultaneously support all syntaxes for all upcoming features.

That's why I believe core code needs to minimize the API and allow these parties to implement the interface of choice. These are easily enough installed via a module, and it reduces the surface area core maintainers have to maintain. This will lead to more secure and stable code from core, while also allowing interface implementors to 1) iterate faster than core releases occur; 2) bypass the current overhead of needing to implement any other interface on top of the current EventEmitter/Streams model.

[trevnorris]

Heh, seems I didn't make it to point #3 in the OP.

[jonathanong]

btw generator support === promises. if they ask for something different, they don't know what they're talking about.

i'd be pretty interested in libuv.js.

my biggest issue is right now is that it seems as though the node lead only spends a single day out of the month to work on node.js _

[bodokaiser]

I think the biggest problem with node is that it lost a lot dynamic. Just look at the release cycle: We are more or less waiting (or using) 0.11 for a year now and for me it does not look as 0.12 will be released 2014. I understand that the core team wants to ship a product enterprise ready by freezing apis and rejecting any major changes but in the long term a lot of people will loose interest as PRs get rejected and bad api decisions maintained.

Regarding libuv.js I see potential to decouple dependency from the nodes api decision but am not sure if the community is able to support various architectures in terms of documentation and reliability.

[feross]

I agree with @jonathanong and @bodokaiser - node 0.12 is way past overdue. The goal of shipping an "enterprise ready" product is laudable, but having 0.12 be in a perpetual "right about to be released" state actually hurts credibility way more than releasing 0.11 right now as 0.12 would.

[juliangruber]

I'm listing my 2/3 points without thinking about whether they make sense to be fixed in node:

• not having several call stacks / threads: you can't just let a block of execution crash, knowing safely that you don't need to crash the process. like: each http request is completely independent and a crash like an uncaught "error" event somewhere wouldn't affect the other requests
• versioning of node core modules, i want readable-stream style versioning for every core module. that would also help with release cycles
• too long release cycles, when I need change X i need to use unstable node

[Qard]

I'd like to be able to use es6 tech with core.

Streams could be simpler:

var upcaseStream = passthroughStream(function* (read, write) {
  var bytes = 1024
  var chunk
  while ((chunk = yield read(bytes))) {
    yield write(chunk.toString().toUpperCase())
  }
})

process.stdin.pipe(upcaseStream).pipe(process.stdout)

Servers could be simpler:

// textual interface (get foo, set foo bar)
tcp.createServer(function* (read, write) {
  var auth = yield read()
  if ( ! (yield db.auth(auth))) {
    return
  }

  var message
  while ((message = yield read())) {
    var match = message.match(/^(get|set) (\S*)( (\S*))?$/)
    var command = match[1]
    var key = match[2]
    var val = match[4]

    if (match) {
      yield write(yield db[command](key, val))
    }
  }
})

At the same time, I agree with @trevnorris that this sort of concern of promises vs generators should probably not be directly in core. However, having some of these features enabled by default in V8 would promote wider acceptance of their use--I think co/koa would be a lot more popular if you didn't need to use a special flag on an unstable build.

I really like the libuv.js idea. As someone whose job is instrumenting node, having deeper access into the guts of it would be really valuable. I'd really like to see visibility into uv_check_t, uv_prepare_t and uv_idle_t at JS level.

Having something like Zones in core would be great. Perhaps with libuv.js we could store file descriptor references directly on JS objects so cleaning up file descriptors of things in a zone could be as simple as socket.fd.destroy().

I'd also love to see core facilities designed in a way that they are more pluggable. For example, with browserify you can use transforms to make require('./path/to/template.jade') return a compiled jade template function. Also, monkey-patching require() behaviour is currently rather difficult to do while retaining correct path resolution--it'd be good if there was a way around that.

My biggest gripe, however, and the reasoning for my strong desire for generator-based streams is the fragility of event emitters propagating error events. Having to special case error events is kind of obnoxious. With generators, you can simply let the user try/catch it, or leave it to throw in normal JS fashion.

Cleanup also kind of sucks. If you forget to end a stream, bad stuff can happen. With the generator example above, you can simply assume that reaching the end of the generator function means the stream is done, since there is no longer code to operate on it.

[rvagg]

@Qard your streams suggestion is absolutely something that should be experimented with in user-land in order to prove its utility. Major departures like this should never again be dumped straight into core without having a long burn-in time in user-land where they can be embraced or rejected by a wider group.

Easy to put together a wrapper, then promote it and see if you can get any traction. Personally I'd like to see core streams stripped back even further to something like what http client is now such that its a logical choice to add an abstraction over the top of it to get real work done. Then we avoid lock-in, complexity in core, and allow the ecosystem to come up with the best patterns rather than having it forced on them.

[Qard]

@rvagg Yep, I totally agree that is a userland thing. I feel like the need for a harmony flag and unstable build currently is holding people back a bit from experimenting with it though. I'm more just advocating for at least a stable release at some point with the harmony flags, though I'd prefer to see some features on by default.

As @mikeal put it, I'm not suggesting we start implementing my pet feature ideas. I'm just sharing my views. I do think the whole error event thing still kind of sucks though. Generators may be a possible solution, but, as you say, it's yet to be seen as the solution.

In line with what you are saying, and the libuv.js discussion, stripping core down even further would be really cool. I think sometimes core does too much. Having lower-level control of things would be great.

[rvagg]

Agreed on the special-case 'error' event, I just don't see a good solution to that in Promises or Generators yet, but I'll try and reserve too much judgement. In short, Promises treats errors like a second-class citizen which is exactly the 'error' event problem so it buys you nothing, Generators takes us back to codebases littered with try/catch which I certainly don't want to see become an idiomatic Node style. But, I look forward to being convinced of a great new pattern that someone clever comes up with to solve all our woes.

[Qard]

I certainly prefer manual try/catch to promises just eating errors. It is a bit verbose though. A rescue expression, like ruby, would be really nice.

[calvinmetcalf]

@Qard https://github.com/calvinmetcalf/es6-stream

[Qard]

Nice. I actually have an implementation of my own half done. I'll probably finish it on the long bus ride I'll be on tonight. Mine includes readable and writeable streams too. :)