

JXCore – A Multithreaded Node.js Fork - notduncansmith
http://jxcore.com/home/

======
gargantian
This is a tragedy of a product being developed for an audience of zero.

All of these problems have acceptable, established, and time-tested solutions
using Node.js itself, without the crippling caveat of lock-in to a new and
unproven platform. And yes, despite the copy trying to distract from this
fact, this is very much a case of lock-in, because built-in multithreading is
_not_ a Node thing. None of the mountain of Node code out there works on that
expectation. Furthermore, JX seems to have its own proprietary packaging
solution, SQL database, memory store, monitoring, and more. This isn't a point
in its favor; it's just more lock-in.

These new features might be great and well-implemented, but if I'm going to
benefit from them, I'm leaving Node.js behind and trusting that JX will be
supported as well as Node itself is. I have no faith that will be the case.
It's (perhaps unfortunately) and self-fulfilling prophecy: I doubt I'm alone
in my thinking, and that feeds back into lack of a community coming together
to support this fork.

My advice to the developers (who are clearly talented if they can put together
something like this) is to refocus your energies on building stuff with (and
on top of) Node.js instead of forking it.

Source: some hard-learned lessons

~~~
jonpress
A lot of wisdom there. I had similar experiences with SocketCluster.

It used to be a full-stack framework (with a heavy, opinionated client-side
part) but I was the only one working on it and when Meteor, SailsJS etc came
along, I understood it didn't stand a chance so I pulled out the realtime and
clustering features and used them to focus on just the realtime part and it
picked up!

What I noticed is that the more opinionated (and more complete) your framework
is, the harder it is to build a community around it.

Developers like to use custom combinations of small, SPECIALIZED tools that
only handle a SMALL part of the big problem.

... Unless you're a HOT startup with crazy funding... In this case, developers
will trust your product by default. Developer trust is hard to gain - If
you're small, you have to play for the long term and keep reinventing and
rewriting parts of your project over and over as technologies change.

------
jonathannorris
Can't you just do this yourself with the clustering already built into Node...
you can manage the clustering yourself
[http://nodejs.org/api/cluster.html](http://nodejs.org/api/cluster.html), or
use a tool like pm2 to manage your cluster for you
[https://github.com/Unitech/pm2](https://github.com/Unitech/pm2).

------
jonpress
Another alternative is to use process-based concurrency with SocketCluster
[http://socketcluster.io/](http://socketcluster.io/) \- It runs on top of
plain Node.js (or io.js) - It's just a module.

------
sctb
[https://news.ycombinator.com/item?id=7333337](https://news.ycombinator.com/item?id=7333337)

------
tedunangst
Is a multithreaded io.js fork in the works?

------
shubhamjain
Doesn't Node already have a Cluster API?

