> Node has always had a problem with favoring performance over robustness

I don't disagree with the gist of what you're saying, and I think you're correct. But the premise of Node being high-performance is perhaps more reputation than actual fact. I think it gets that reputation because it is higher-performance than some more popular options, but in the big scheme of things, it's but a medium-performance platform [1].

[1] http://www.techempower.com/benchmarks/#section=data-r9&hw=i7...

Agreed. I benchmarked Node/V8 vs. the JVM and while Node has lower memory usage, Java is as performant while being more reliable, with less variance in HTTP response times, due to the better garbage collector.

http://www.slideshare.net/olegp/server-side-javascript-going... - there are some graphs from slide 46 onwards.

There is no guarantee that a custom fork with fibers will be maintained and patched in the long term. Generators are a safer, forwards-compatible choice for doing async work. That's why there is little support in the community for adopting fibers.

The big issue with generators is making sense of stack traces while debugging. And due to the nature of how generators work we'll probably need an fairly creative solution here. I'm fine with generators today, but it would be better if await sugar landed sooner.

Fibers is a not a fork, it's a package that is included as a dependency with pre-compiled binaries for all the major platforms.

I stand corrected. However, the point still holds.

- It is outside the JS specification

- Needs to be updated for newer versions of node. Last commit says "Support for Node 0.11.10". Also, it needs to keep up specifically for every platform.

- Will never work in the browser, unlike yield which you can get working on current browsers using transpilers. Increasingly important, as we see more code sharing between client and server (isomorphic JS).

If you ask me, fibers are quite risky.

The JS spec says nothing about threads or coroutines, just like the C spec says nothing about them either. That doesn't mean that they are incompatible with the language. In fact, real multi-threaded JS code runs just fine on the JVM for example.

It works fine with the latest Node for me. Fibers relies on libcoro which has only had minor updates over the past four years.

I'm not sure where you're seeing this code sharing. In practice the only code that is shared is utility methods that don't do any I/O, so whether you use fibers or not makes no difference.

In fact, Meteor, being the framework that is pushing the boundaries of code sharing between client and server, uses fibers on the server.

I'm still curious about a js engine that supports coroutines better (fiber's stacks are pretty huge), it would be interesting to start fresh without all the legacy baggage that node has now.

One could fork fibers and have smaller stacks and even make their size dynamic, but actually the number of active fibers per process has been fairly low in all our use cases so stack size was never a concern. The more interesting problem is that of running multiple processes in parallel so you can saturate the increasing number of cores, while retaining low jitter and having a sensible end user API.

My co-founder alexlamsl and I are actually working on something akin to Scala actors for JS that is portable between the browser via Web Workers and the server using Node and Common Node (https://github.com/olegp/common-node). We'll blog about it at https://starthq.com/blog/ in the near future.

That actually can be easily fixed on top of V8 - as V8 already sprinkles stack overflow checks you can make actual fiber stack smaller and expand it on demand.

We might give this a shot with alexlamsl in a fork of fibers. Would you be able to help if we get stuck?

awesome!