Hacker News new | past | comments | ask | show | jobs | submit login
Joyent Moves to Establish Node.js Foundation (joyent.com)
215 points by nifoc on Feb 10, 2015 | hide | past | favorite | 153 comments

About a year ago I posted "node.js needs a new home" on the mailing list. It started a minor s### storm and a couple of local IBM guys went down to talk to Joyent, which eventually led to the whole advisory board / foundation initiative. Mostly it was all back-room discussions between companies taking place in private from the wider community. They're great people, but that isn't really what I had in mind.

IBM's cloud offering runs on the PowerPC architecture, and older versions of V8 won't run on it, so they can't offer Node hosting. They ported a private build of Node to run on PowerPC using a new version of V8, but Joyent has so far refused to upgrade V8 despite having a pull request with all the work done. It looks a lot like Joyent has been dragging their heels on V8 updates just to fend off an IBM cloud service for node.

The first five words of the announcement are: "Joyent, IBM, Microsoft, PayPal, Fidelity". That says a lot right there. StrongLoop, NPM and a bunch of others are excluded, the whole thing seems to have been baked up in private by people who aren't core contributors, and then sprung on the community like it's some great thing.

Maybe it's a step in the right direction, but as it stands I'd expect this foundation to be about as useful as another hole in the head. I've seen enough corporate bad behaviour from some of them to not care about their special little club right now, and I don't think it will win too many people over.

[Update: Fedor posted about it here https://medium.com/@iojs/io-js-and-a-node-js-foundation-4e14... ]

An interesting thing would be to look at the NodeJS issue tracker. I opened an issue in io.js and NodeJS at the same day - the io issue got several responses, was discussed between collaborators, a pull request was made and it is discussed in the next TC meeting for inclusion in the next version.

The NodeJS issue got exactly zero response.

It looks (at least from the outside) that io.js is a maintained project and NodeJS is not.

You didn't get response because all those 5 companies executives not sure about what you asked, rest who knows that moved to iojs.

GitHub's Pulse tab is a pretty good way to get a quick, high level comparison: http://i.imgur.com/zNWj776.png

io.js resembles node prior to 0.11 stalling out for over two years... Responsive community and core contributors. The inclusiveness seems to be much better than it has been under Joyent.

Short of the Node Foundation turning over operations to the io.js TC, I don't see Node remaining the choice platform within the next two years as they diverge farther than they have. I wouldn't mind seeing them re-join, and re-release io.js 1.x as "node" 1.x proper.

It's bad enough that we have to use transpilers (6to5/traceur, etc) for new feature support in the browser... having to use them on the server was a pain... co/koa and similar have been around for over two years waiting for 0.12 to come out of beta... Even then, they were significantly behind v8 and libuv.

If Node Foundation brings io.js back into the fold, great.. if not, I'm with io.js on this one.

Re: Being limited on non-x86 platforms with older versions -- IBM was interested in the work we've done to abstract away from the particulars of modern script engines. At Bloomberg we decided to forego Node itself for the time being and target engines directly. We built an abstraction layer that allows native modules to be completely isolated from the engine they're being attached to while still retaining performance as if they were using the engine API directly. While `nan` provides some abstraction to native module writers, it targets abstraction over `v8` rather than abstracting `v8` itself at a more basic level. I'm working on open-sourcing this layer right now, but even if it was up on GitHub, it doesn't mean the Node (or io.js for that matter) community would be interested in actually adopting it or something like it to not depend directly on `v8`. This was interesting for us and for IBM because Spidermonkey has a bytecode interpreter and does not require a platform JIT to work and we actively use it on both POWER and Sparc hardware right now. It might seem like that is less than ideal compared to building out a JIT backend for each platform, but we've found in practice that for most common tasks the performance characteristics aren't that different. Freely being able to swap out engine backends (we also have it targeting Lua just to prove it isn't tied to JS) also allows direct benchmark comparisons and could help ignite server-side benchmarks that aren't directly tied to browser performance. I'd love to see more people interested in divorcing Node from `v8`, but admit it's a tough sell.

I take it this is different from the NodeRED[0] thing IBM released a year or two ago? So, if node.js proper was closer to v8 HEAD, then they might find that the v8 team has recently been supportive of utilizing "precompiled scripts" (in v8 parlance). And I don't believe divorcing node from v8 is hard. Nobody is interested[1] (long term) in supporting such a divorce. For the most part, creating an API that would support both at the same time is maybe a month's worth of work at most.

[0] https://gigaom.com/2013/09/27/meet-node-red-an-ibm-project-t...

[1] https://github.com/zpao/spidernode

I don't know any details about NodeRED, so not sure how that factors in. All I know is IBM was interested in using Node in products, as OP mentioned and their involvement in the foundation shows. Agreed, divorcing Node from the underlying engine isn't hard -- the point was whether the community would accept such a fundamental change in the project or whether a hard dependency on `v8` forevermore and `nan` as a pill to ease the pain is "good enough". (The `spidernode` project was the work of an intern at Mozilla and really was more like the `nan` abstraction, shoe-horning SM into `v8`'s existing API and isn't the kind of fundamental abstraction I'm referring to.)

Why don't you just switch to io.js, then you won't be limited on platforms?

What did you actually gain by doing all of that work? I think it was a big waste of time.

You forego Node, does that mean you can't run Node modules installed with npm? Sounds like a very dumb decision.

sounds sweet. i'd love to see node decoupled from v8, maybe even get ASM support.

Thanks for the interesting perspective.

One of the things that has always bothered me was that in your thread Isaacs was adamantly against a foundation. Suddenly now he is all for it. Was he simply repeating the Joyent party line then, or has he since changed his mind?

I'm also disappointed about the lack of inclusion of StrongLoop and NPM, who both have key contributors to node.js among their ranks.

Basically anyone who has a business model related to the node.js ecosystem would benefit by not having development under the control of a single corporate entity. Isaac was in a tough place back then. I think spinning off NPM was a good move for him and it's great to see him on board with the community fork.

PS. A number of people were against it at first, including Nodejitsu guys and Michael Rodgers. I wrote that either a foundation or a community fork were inevitable. Eventually people realized it, and it turned out to be a community fork. If a meaningful foundation were to happen at this point it would have to be built around io.js in my opinion.

I agree: I would really like a response from Isaac on this.

Translation: io.js is what people want and Joyent feels threatened that they're not in control.

So, they're making noise and dropping names to try to reinspire confidence, without actually promising anything.

Joyent doesn't trade, but if they did they'd be losing a few percentage points today.

It baffles me how little they acknowledge io.js in their public communication. Node is a weirdly paradoxical community composed of a small, really smart core surrounded by a vast but shallow sea of lip service and hype. With this fork io.js has won pretty much all the mindshare of the small core, whereas Joyent is left with the hype, which is a house of cards waiting to fall. They ought to be chumming up to the really smart core if they don't want to fade into complete irrelevance soon.

> a vast but shallow sea of lip service and hype

This made water come out of my nose. You're absolutely right, and having spent the winter writing Go and not knowing about io.js (at least as "new node-forward"), it was instantly apparent to me that io.js has all the important mindshare, and now Joyent will be struggling.

Serious question re: With this fork io.js has won pretty much all the mindshare of the small core

Who and how many of the earlier Node.js core developers are still developing for Node.js, how many are developing for io.js, and how many are developing for both?

Clicking on those links, I was surprised to discover io.js commits from as early as 2009.

Some of us not following too closely, may have been under the wrong impression about io.js being a new initiative.

io.js is a fork of node.js, so the commit histories are the same prior to io.js becoming a thing. it is a new initiative.

Ahh, that makes more sense, tnx for clarifying (:

I had no idea that's how GH designed the commit history UI.

Also, it might be a nice bonus, if there was an indication of the fork, somewhere on the graph timeline.

Depends on what you mean by "still developing for Node.js" which is subjective. Going strictly off activity, the graphs on github[1][2] show node trending ever downward from a high back in early 2012, and iojs significantly spiking upward within the last few months, approaching 2012 levels. (Obviously all but the extreme right edge of both graphs share the same data.)

[1] https://github.com/joyent/node/graphs/contributors [2] https://github.com/iojs/io.js/graphs/contributors

Before 11 July/23 Nov both repo share the same graph, depending on if io.js fork is started by Mikeal Rogers, or Fedor Indutny

Reminds me when all of the original Hudson developers more or less left Oracle and founded the Jenkins project. Yeah, how many people you hear of using Hudson now a days?...

IBM does, don't ask me why.

If anything it feels like io.js might make it out alive if Node turns into something akin to jQuery.

Could you clarify this? Have we stopped using jQuery? Actually I find myself switching back and forth between io and node with little trouble. If that becomes untenable, one might have to make choices, but we're not there yet.

Mostly in regards to pace of progress. Whenever the bureaucracy is smaller you can get more done faster. jQuery is just a good example of something that has become relatively bloated with time, with almost no real hope of ever improving to the point that it's not one of the first things you micro optimize out of your libraries.

Of course jQuery is bloated, but of course jQuery would be bloated by this time. The only way to have avoided that would have been to split out the compatibility layer and let people just load whatever portion of it they want. Then you'd have people complaining that when they load enough to support ie8 it seems bloated. b^) Also that architecture probably would have been an ongoing annoyance for jQuery maintenance. (EDIT: yes I know about v2, I'm just saying that what jQuery would become was pretty much decided, architecturally, long before that release.)

It isn't clear that node had to go that direction, or even that they can't change course now.


jQuery 2.x dropped support for <= IE8.

Can you explain the comparison to jQuery? I wasn't aware that jQuery was dead.

It's not dead, people have just taken to talking about Angular and React more.

While all the new stuff has value, to me the value of frameworks will always lie in prototypes and small projects, with big production projects needing the flexibility of libraries.

I don't think jQuery will be going anywhere until the DOM itself evolves past a need for it or we evolve past a need for the DOM

That is total hyperbole. There are almost no PaaS that offer io.js hosting for production deployment. io.js is also beta, which is not a good idea to run production code. Node's community is much, much larger than HN's echo chamber.

io.js kept mum until the last moment before their release, with an invite-only codebase. io.js also took quite a while (> 6 months, far longer if you count the first fork attempts) to get to the first release and actually open their community -- turns out that producing a stable runtime is harder than it looks!

Let's call a spade a spade -- io.js is a great way to test out new functionality, but node.js is the stable, trusted version. io.js is the hype.

It remains to be seen whether io.js will prove itself profitable for adoption.

I don't see a single factual statement here.

io.js spent part of December in a rapid incubation, and released in early January.

It's stable for me on several production applications, but what does 'stable' actually mean, vs 'beta'.

Their community started open, and remains open, and has a larger contributing base than node by more than triple. They have an open technical committee, with meetings that anyone can attending (and I have).

Here's the spade: You're wrong. Actually do your research, have facts that you can back up, and try again. Your tune will be very different when you have the facts.

io.js is not stable. Despite claiming the 1.x for semver, they have not reached their stated goal, which is to be 100% compatible with the node module ecosystem. Therefore countless modules which are stable on production Node, are broken on io.js [1]. Doesn't get much more clear than that. Hype.

For example, there is no "build passing" badge on the io.js github, because the tests aren't passing [2]. Even if they were, no CI service is yet available -- so how can the community at large reliably test against it?

[1] https://github.com/search?q=io.js&type=Issues&utf8=%E2%9C%93

[2] https://jenkins-iojs.nodesource.com/

You are running a circular argument. What determines stability for a programming language. Running code? I've got plenty of that. Not crashing? I've seen no more crashes on 1.1 of io.js than I have on 0.10 of node, which I also consider to be perfectly stable for production applications, as I run several. So I say again, for what values of stable? Failing tests only indicate a change. Is something broken for you?

Please cite your io.js source for their statement of maintaining 100% compatibility with all node modules. I can't find any reference to that anywhere. NPM is certainly usable, as I use it daily with io.js, which fits their websites statement of "This project began as a fork of Joyent's Node.js™ and is compatible with the npm ecosystem.".

Still nothing credible in this thread, move along.

From their front page:

> io.js is an npm compatible platform originally based on node.js™.

Sorry, they were aiming for 100% tests passing [1], I would assume for npm compatibility which is their primary goal.

A stable API means that dependent packages don't have to change to stay compatible. Tests are failing because they change things that broke packages:

* Node-inspector does not work with io.js! How is anyone supposed to debug their code? [2]

* Fibers do not work [3]

* msgpack does not work [4]

* sqlite3... there is a long list [5]

There is no CI, no debugger, tests aren't passing, major modules don't work. I absolutely cannot go to my CEO and make a bet on that for my company.

I think io.js is great! But the amount of misinformation about the state of Node is staggering. Let anyone with proof otherwise also cite their sources.

[1] http://blog.izs.me/post/104685388058/io-js

[2] https://github.com/node-inspector/node-inspector/issues/523

[3] https://github.com/laverdet/node-fibers/issues/203

[4] https://github.com/msgpack/msgpack-node/issues/20

[5] https://github.com/iojs/io.js/issues/456

You're quite active in spreading FUD in this thread. Please stop.

Node 0.12 was released and ships with v8 3.28.73. Most (if not all) of the bug reports you cite refer to needing NAN 1.5 which fixes issues with v8 > 3.28. NAN is used by both io.js modules AND node.js modules.

Both io.js and node.js 0.12 have a v8 > 3.28. All those modules are also broken in Node 0.12 because the underlying v8 API changed.

As pointed out by others, the node.js tests are only passing because some last minute shenanigans so they could claim all their tests were passing "but io.js' tests are not."

Well, sqlite3, as an example didn't work for node 0.11.x either... and they had no intention of supporting it until 0.12.x, and not sure if they're even there yet...

Compiled modules are generally more tied to the version of V8 that node/iojs is bound to, depending on that library's interface needs. This is why many libraries are written, rewritten and using javascript-only, so that they can run everywhere. For that matter, many compiled modules didn't work right in windows until well after 0.10 was first released, and some still don't.

Node v0.12 only passes tests because of this: https://github.com/joyent/node/pull/8689

io.js does not contain this commit, or any of the changes from this commit: https://github.com/iojs/io.js/search?utf8=%E2%9C%93&q=%22PAS...

Heroku supports iojs, but I suppose that meets the definition of "almost no one" when you scope it to all available PaaS options worldwide.

> io.js kept mum until the last moment before their release, with an invite-only codebase.

This is factually inaccurate. Fedor Indutny created the iojs fork on November 26th. The 1.0 release came out on January 13th, significantly less than 6 months. The iojs repo was always public.

The project you're referring to was the node-forward/node repo, which was initially public and forced to be made private due to Joyent's trademark.

This history is all fully documented here: http://blog.izs.me/post/104685388058/io-js

From your own link:

> On July 11, Mikeal Rogers created a private node-forward repository under his personal GitHub account to discuss the future direction of Node.js.

> Io.js continues the work that was previously being done by Node Forward in the node-forward/node repository. We hope to merge with the original Node.js project at some point in the future.

The "fork threats" started in 2013. [1]

It would have been simple to rename node-forward and keep it public, odd to blame Joyent for their choice to continue trademark infringement in private?

Previous to its release, io.js supporters spammed HN with multiple contentless links about its release. [2] No explanation to the community, raised a ton of questions and did not provide answers except within their insular circle.

Everyone is trying so hard to be part of something new and trendy, that they are blind to the facts in front of them.

[1] http://venturebeat.com/2013/09/18/can-this-startup-steal-nod...

[2] https://news.ycombinator.com/item?id=8700554

You put an interesting spin on reality.

I don't know the exact history of node-forward, but node-forward/node was only a piece of the node-forward repository. Early on it was my impression was that node-forward was just about collecting pain points in the node ecosystem and working towards those pain points (technical or not). The fork came later.

The fork threats you mention don't seem to have anything to do with node-forward. In addition, the article clearly states that "Roth told VentureBeat his company does not intend to fork Node" so these fork threats were not reality.

As for why they didn't rename node-forward/node? Well the previously linked article explains it quite well "We agreed to make the repository private in order to show our commitment to working with Joyent on improving Node.js."

I should clarify, there are lots of smart people using and occasionally contributing to node outside the inner circle of core contributors, many of whom will be using node (i.e. not io.js) for a long time. I was wrong to suggest otherwise.

I agree io.js has generated some of its own hype; that's why I'm surprised Joyent has distanced themselves from it. Node is coasting on a lot of previous hype, but io.js is poised to steal the proverbial thunder. "Node is stable," AKA "Node isn't going to change or disrupt anything," is meanwhile a powerful argument, maybe especially to Joyent's customers, but that isn't always a good thing (think IE6), and it definitely isn't a good way to build hype.

I'll take another step towards fixing that https://github.com/sturadnidge/iojs-buildpack

Heroku supports io.js

As does the Google Cloud Platform.

It's kind of like when a kid has something taken away for being an asshole, the apologies and promises come quick and fast but you know they are disingenous.

I can't imagine Joyent doing anything in good-faith, they are scared of losing relevancy and are looking to protect their interests, they don't give a flying cow about anything else but themselves.

This would not have happened if io.js was not on the scene, call me cynical but I don't trust them.

They bought Node on the off-chance it would be as big a cultural phenomenon as Rails, and they would own it and have control, rather than losing their golden blessing to Engine Yard back in the day.

What golden blessing would that be?

The "Official Ruby on Rails Hosting Provider", that they had back in the day, before it went to Engine Yard.

That's pretty much how I read this. I don't see anything about them actually doing anything. Establishing a foundation? Why? "To get together!" To do what? "Partner with leaders in the industry!" No I get it, but what are you going to do, what is your trajectory? "Just ask these top names..."

> So, they're making noise and dropping names to try to reinspire confidence

Have to say, the names they're dropping do not inspire confidence in me. Nobody on that last is well known for their stewardship of open source projects, to say the least.

and they say all this without mentioning io.js...

Betamax is technically better than VHS.

I realize this is biased, but for me Joyent's involvement in anything is reason to be suspicious. Back in 2004 me and several hundred others fronted the money to get Joyent (aka TextDrive) off the ground. The marketing was fabulous, they had A-list blogger Dean Allen as founder and spokesperson, and Jason Hoffman as CTO spouting off an unending stream of pie-in-the-sky ideas about how awesome the tech was going to be.

Over several years it became clear that Jason was only interested in playing with cool technologies and a lot of public self aggrandizement in the process. However, never did they seem to deliver any stable game changing technology to the level they had hyped. It seems like they eventually they sort of limped out with an alternative platform that could be competitive if you squinted hard enough, and then sold it by means of aforementioned marketing skills. But for those of us who got the company off the ground, we basically all got screwed. And even though Jason has left Joyent, to me their DNA is suspect, and I would never trust them as stewards of an open source project.

Oh man, I'd forgotten all about the fiasco. Wikipedia has a nice roundup of the lifetime hosting shitstorm: http://en.wikipedia.org/wiki/TextDrive

Damn. I was already a bit skeptical of Joyent, but this doesn't inspire more confidence.

Some interesting things.

Note that nowhere do they mention io.js--that's just kind of classy, right?

Second, their tone seems aimed at reassuring senior-level folks that might have heard murmurs of dissent from underlings about node--this release doesn't feel like it's targeted to developers at all.

Lastly, notice Microsoft being on board. I do wonder if they'll push for movement off of V8 and onto a better-documented, better-maintained platform.

Call me cynical, but I feel like this:

1. Shows that the io.js people correct when they identified the problem

2. Doesn't solve the problem

Prior to this announcement you could say "the io.js people are crazy; just trust in Joyent". (Not saying you'd be right, just that you could say it and no be obviously wrong. Isaacs, for example, was a proponent of this view.) Now, even Joyent is admitting that there's an issue. But it's pretty damn hard to see how the issue could be solved by this specific proposal. Joyent, IBM, Microsoft, PayPal, Fidelity? Right, that totally solves the worries about stagnation, corporate control, or excessive Joyent influence.

Hey, there's an idea! I wonder if anyone ever proposed this to Joyent... over and over and over again.

It certainly looks like both parties have desires to reunite with a new understanding of what it means to govern Node.


This would be my wish.

The wording there was so polite and inspecific, and the issues at hand so long in the tooth, I seriously doubt it. That ship sailed long ago.

This move surprises me, because Bryan Cantrill doesn't seem to like governance and foundations for open-source projects. I wonder if he was overruled on this.

That's a very fair question. When I first presented my corporate open source anti-patterns talk at FISL in 2012[1][2], I closed by saying that I was certain that we (Joyent) were making mistakes, and that they would have to come back in 2022 to hear what they were. Suffice it to say that after the developments of the last year -- which include not just the io.js fork but also us open sourcing our entire stack[3] -- I'm really looking forward to doing that update, and hope to do it much earlier than 2022. ;)

To answer your question: no, I was not overruled -- it's been clear to me for quite some time that node.js would be best served by a foundation. That said, getting the mechanics of that foundation established has taking (is taking) a long time (and, it must be said, involves a lot of hard, thankless work from a lot of people). Foundations might feel "easy", but they aren't: 501(c)(3) organizations are highly regulated entities that require not just a lot of groundwork and forethought but extensive maintenance. Fortunately, we have made great progress (and we have built a terrific collection of founding members), and we are getting the node.js community what it needs: a foundation that can assure the consensus-driven advancement of the technology, in perpetuity.

[1] http://www.slideshare.net/bcantrill/corporate-open-source-an...

[2] http://www.youtube.com/watch?v=NhgXQFk9noI

[3] https://www.joyent.com/blog/sdc-and-manta-are-now-open-sourc...

I'm waiting for this new foundation to have their moment where they call a core developer an asshole in public, throw him under a bus, and say that if he was an employee, he'd be fired rather than retrained... all while talking about the importance of empathy.

Regardless of the event itself, that was an exceptionally poor handling (soapboxing?) of the situation, and didn't speak much of ability to mediate a heated situation. A foundation born from this management style? Doesn't sound encouraging.


I was wondering if anyone would bring that one up. For me, that was the moment I stopped having vague concerns about Joyent and Node, and realised "wow, these people can't be trusted to run a project".

Not the first time Bryan Cantrill has done that:


    or: http://www.cryptnet.net/mirrors/texts/kissedagirl.html

I completely agree. I hesitate to say this because it might come across too much as 'gut feeling' (and I apologize in advance), but Joyent seems to be somehow too lopsided towards the 'public relations corporate' side of things over developing and maintaining something valuable.

It's not so much to do with my opinion of the specifics of the situation with Noordhuis, or the announcement that is the object of this conversation, but rather the vaguer feeling that they feel way too much like a 'company' acting in its own interest for me to trust them.

wow, hadn't read the post. that alone puts me firmly rooting for the io.js camp.

Yeah, because you should chose your software based on your dislike for some community members, not because of real technical facts.

While I understand... plenty of people have chosen "not windows" for server-side projects for just that reason.

When a project has questionable or poisonous leadership, it's technically wise to steer clear.

Bryan Cantrill is the CTO of Joyent, not the leader of the Node.js project.

And what company owns Node.js again?

No company owns Node.js.

Node.js is a Registered Trademark owned by Joyent... even after releasing to the newly started Node Foundation, I'm guessing there may well be some tight reigns here.

The schizophrenic open source ideals of Sun continue to live on at Joyent. It's funny that Oracle is called out many times (which they deserve), and yet, there is a failure to acknowledge that other open source projects under Sun's stewardship did a lot of mistakes that ended up killing them (OpenSolaris and OpenOffice, to name a few). In any case, as much as corporate America wants to be seen as a faceless entity, Sun was made of its employees and so is Joyent.

Meh, I'm not buying this "yeah, we were going to make node belong to the community all along" when there are lawsuits threats over trademarks and what not.

Bryan, your long-winded reply basically says you always wanted a foundation? Really? Well, where were you in November??

This announcement feels like hurried back-room politics, and your reply is reinforcing that impression.

I'm interested in Bryan's view on this as well. He's given talks on open-source governance in the past.

This is the closest entry I could find on his blog regarding node.js and its governance: http://dtrace.org/blogs/bmc/2014/06/11/broadening-nodejs/

Weird that Google isn't a founding member being that V8 is their creation. But I guess the reasoning is that Node isn't used internally at Google as they favor Go for server side code.

Google is working in coordination with io.js and have expressed that they believe it is the future. They're moved their integration and effort from Node to io.

At least from what I've seen publicly on v8-users list, that is not true. Google has not, and seemingly, will not pick a side. Or, if you must, they've picked Chrome/Chromium and its 6-week version/development cycle. The v8 team has always been clear on this. Their primary (only?) customer for v8 is Chrome.

Hi, can you point to where on v8-users you got this impression? In general we are much happier with how io.js aligns with supported V8 versions.

Here's an example [0] where Googles showed they preferred their ICU implementation over system, in effect, remaining self-sufficient & neutral of the embedder's concern. And as an independent embedder with a non-public project (as of yet), I prefer that neutrality.

For other embedders, however, like TeaJS, SilkJS, v8-juice/cvv8, narwahlJS, this was probably their undoing, at least in my opinion. Stephen Beal considered it lack of documentation & support [1]. I have seen a concerted effort over the past 12 months to improve that.

[0] https://groups.google.com/forum/#!searchin/v8-users/support/...

[1] https://groups.google.com/d/msg/v8-users/MUq5WrC2kcE/Z3LyOmE...

The other reply you got is from someone working for Google on this by the way.

I'm pretty sure Google favors Java and C++ above all else. I could be wrong but I don't think Go has taken off inside Google.

>I don't think Go has taken off inside Google

That's consistent w/ what I've heard (whatever thats worth)

(A bit) off-topic, but imagine if Google is working on a from-scratch brand new javascript runtime engine.

v8 master (what's in iojs and Chrome) is a new JavaScript runtime engine. It's a pretty fast moving project.

If you mean a JS replacement, they unveiled Dart in 2011 and it's not particularly popular.

No, I guess s/he means SoundScript


Lol can't wait for the next iteration 'use strickest;' then what? 'use strickester;'?

Would you prefer a Python scenario?


node.js and io.js really need to merge or one has to die. I can't see this turning out well unless one or the other happens.

io.js is trying to push the envelope by supporting ES6, more APIs, etc while node.js isn't focusing on that. This eventually means if I write my module for node.js it should still work for io.js but if I write it for io.js, even if it does take advantage of better performance, ES6 syntax, etc, it won't work for node.js.

I can't imagine anyone wants that kind of fragmentation.

If you write your code for node.js, it should work on io.js. Fragmentation is good, it stimulates the eco-system for better products.

That isn't true for native module writers. `nan` is not an entire solution because it doesn't abstract away `libuv` versioning as well. So when I had to get my native module working, I had to support the ancient `v8` in 0.10, the moving target in the 0.11.x series (breakage in 0.11.13 & 0.11.15 -- semver anyone?) and the even newer `v8` in io.js.

The more native code you write for this ecosystem the more you realize there needs to be a complete abstraction away from the JS engine and event loop to allow for the core to upgrade as fast as possible and module writers to ease into the newer versions. This is one of the reasons why the version of `v8` in Node proper lags behind so much -- it breaks the native module ecosystem every time there is an upgrade.

> If you write your code for node.js, it should work on io.js.

Yes, this was one of the points I mentioned however this precludes me from using newer and possibly better APIs and syntax in io.js. If that's the path to take what is the point of io.js if everything will be written to the lowest common denominator?

> Fragmentation is good, it stimulates the eco-system for better products.

Maybe? I'm not sure. It certainly hasn't looked very rosey from Android's point of view but has it worked for other things? I'm skeptical.

> Fragmentation is good, it stimulates the eco-system for better products.

I'm skeptical too. Maybe fragmentation isn't always bad, but flat out "good"? I've also done Android development, and the fragmentation makes developing for the platform more expensive and time consuming. I don't know of any "good" that comes of it.

io.js is pushing the envelope in terms of supporting up to date/still supported versions of V8, all the other stuff is just gravy.

It's sad, too, that Joyent and/or moderator Forest Norvell are rejecting posts to the Google Groups which are non-supportive of the new "Foundation". Doesn't seem like they really have the interests of the "community" in mind, IMO.

While I am responsible for moderating the [nodejs] Google group, I'm not the only moderator, and have been too busy to spend much time on it recently. It's not my intention to squelch discussion, and I'll touch bases with the other moderator to make sure that we're at least being consistent.

At the same time, one of the primary reasons for moderating the list in the first place was to ensure that the group is constructive and useful, and not just a venue for flamewars. This has been a problem when discussions around foundations, Joyent, forks, and the like have happened in the past. In fact, it nearly killed the group last time this discussion happened (a lot of longtime community members with a lot to contribute gave up on it in disgust), so I'm not going to claim that we're not going to step in if things get overly heated.

I did reject two particularly snarky, otherwise contentless messages today. Otherwise I've let nearly everything through.

I guess io.js forced their hand.

I think this is what IO.js wanted right? What were their other demands? It would be cool to see Node.JS and IO.js unified again and moving quickly forward.

(I'm self interested because we essentially bet our company on Node/IO.)

Unlikely to happen. NodeJS has gone the enterprise way, which is to say that from now on it'll only receive bug/security fixes. It'll stay at the v8 version it is at today, so no new JavaScript features will be added to it (ie. no ES6/7). That's fine, apparently some people prefer that. Everybody else can switch to io.js and enjoy regular updates.

I don't think so. Io.js isn't a hand forcing - it's a horse bolting.

Joyent's hand has been 'forced' to shut the barn door.

Well, 0.12 has finally been released (after what, two years?) - so there's that.

> What were their other demands?

The trademarks should be given to the foundation, like they are with, say Python and the Python Software Foundation.

You bet your company on a single product that is 5 years old? :/

Just like Facebook bet the company on PHP, not quite but you choose technologies and tend to stick with them for a while.

What are you using?

Hopefully they'll spoon io.js back into the node fold.

I would rather like to see them continue operating like "be different, but together" so as to give a choice to users to either use the most cutting edge APIs or more stabler versions. Node.js could be like RHEL/Ubuntu LTS, where as IO.js could be like Fedora/Ubuntu Latest.

Exactly, I recently heard the nodeup podcast where it was said that io.js is beta and don't expect rc-1 or beta tag, just plain semver, but said that eventually both forks should unite again. That plus update-on-release V8s are incompatible with Joyent's "enterprise grade tested" releases.

I like the two different ideas living together.

A bit like:

- Node.js: LTS

- X: Public release

- io.js: Beta/Canary

The only way that this will realistically work is if it falls under a single project. But hopefully the formation of this foundation will lead to a cohesive platform. Its fine if a small team or single developer runs a canary setup; at larger scale development it becomes very difficult to coordinate when its right to run LTS versus not. You'll always default to running what's on production.

That's what's happened with Scala. Official Typesafe Scala is for enterprises and the fork by Typelevel is for faster development and experimentation, with a goal of contributing the things that work out back to main Scala (if Typesafe accepts the pull request).

(Hi, Scala Tech Lead at Typesafe here.)

The Scala landscape is pretty far off from the node/io fork, I think. First of all, we are keen to keep Typelevel Scala and the official Scala distribution in synch. We're also seeing a healthy acceleration in contributions (proposed & merged) over at https://github.com/scala/scala#welcome -- all contributions welcome!

In any case, we're happy to see experimentation over at Typelevel. If you're interested in this kind of stuff, I'd recommend also taking a look at https://github.com/non/cats.

[edited for clarity]

I'm completely clueless about Scala's ecosystem. Do you know which is used more generally and which used more by startups?

Thank you

I think most people are using the main Typesafe Scala, but people who really want to probe the depths of what Scala can do are using Typelevel's fork. As far as startups they are probably using regular Scala unless they've found something in Typelevel's fork that they need.

Unlike the Node / IO situation Scala has always been run by a foundation and continues to have key players on both the main branch and fork.

Why all the negativity for Node? Seriously, lots of good developers have spent their time developing this project and all these comments are just about how io.js is so great or node failed at x. As far as I can see this looks like good news:

"... to establish the Node.js Foundation, which will be committed to the continued growth and evolution of Node.js, while maintaining a collaborative environment to benefit all users."

An open source project is getting a stable backbone. Come on people, this is great news for developers.

This attitude is tiresome. Maybe, some of the negativity is coming from people who have a reason to be negative.

I don't like the idea that accomplishments mean a force-field against criticism. (Actually, I hate it.) Plus a lot of the negativity is not about the work itself but about how the project structure prevented work from happening.

Isn't that why io.js exists, because of the critisim? Its a fork and now the io.js community can do things the way they want, I don't see why people still need to continue criticising node.

The list of names in the foundation doesn't exactly inspire confidence.

Many of those good Node developers now work on io.js. They're voting with their feet.

I think for quite a lot of time Node wasn't doing much. The rebellion formed IO.Js. But what they forgot is still IO.JS is fork of Node. Only people like us who follow Node closely aware of IO.js thgh. Node is still preferred everywhere. It can still catch up with all the new features like ES6/7.

node remains in the name. community cares only about code. IO.JS is gone forward, we are moving with io.js.

The problem (for node) is that the kind of developers who would node.js at this point are exactly the kind of developers who are aware of io.js, at the very least, and quite possibly aware of the reasons for its existence (which don't paint node and its steward in a positive light).

Listening to panel discussion at Node Summit now, it was discussed by Scott Hammond that Node.js Foundation corporate membership costs $5k to $250k, vague on individual membership

Too little, too late.

Give them a chance. They haven't outline their policy on gender neutral pronouns yet.

Is it? How many companies have moved off of node onto io.js? I don't mean an oft repeated list, but the hundreds and thousands of apps currently running on > node 12

People has to pick a side. It makes no sense supporting two 'compatible-ish' platforms going forward.

Please get tj https://github.com/tj to node.

He's not as active, but he's still around...

What if Hitler finds out about io.js? ;P


That's epic. We do all the hard work of fending off the hipsters with their "pull requests".

It's pretty great...at the same time, some of the points are pretty fair--especially about the enterprise customers.

"The enterprise begged us to slow down the rate of change and we obliged!"

"Try not to raise your voice or Walmart might hear you..."

"Walmart was never going to be a big buyer, they're as cheap as their stores!"

I really hope that somebody at Joyent gets catharsis from watching this.

This is funny ever..thanks for posting

node has to act fast..IO.js is fast catching up..it already supports most of ES6 parts..

catching up? io.js is waaaaay ahead of node both in terms of features and community engagement

io.js was "caught up" from day 1, that's the nature of a fork.

Anyone who thinks io.js has "won" is a) living in the tech bubble and b) missing the point of the fork.

The community at large is unconcerned about io.js, they are developing for node.js because that's how they (we) all make money. Node was in no danger for that fact alone.

The winner here is the open source community. We now have 2 excellent options: a beta for the bleeding edge, stability for the enterprise, and forward progress for both.

ES6 is great, but for anyone who wants to write isomorphic code without a lot of pain in compilers, is limited by browser adoption. Expect that to be at least 3 years out, during which node will continue to succeed.

It's very difficult to unpack this, just so much wrong.

First let's start with the misconception that io.js is "bleeding edge" or that it is any less stable than node. This is 100% factually incorrect, hundreds of open tickets have been closed with io.js that have not for node. It is tenfold more stable, and it's trajectory has already outpaced in two weeks what nodejs has in a year and a half.

Second, this is not a win for either party or the community. For the community, you'll get people like you who now think node.js is somehow automatically more stable and reputable because they have a fancy big-wig 'foundation'. For io.js team, it now shows Joyents true colors that they are stubborn and wish to continue down their path and are now unlikely to merge at all in the future. For the node.js team, it now means they are just prolonging their decline. They still have not a single full time node developer, and have lost almost all of the developers who actually made node.js with 0% chance they'll ever come back (the governance will never be compatible with Joyents new corporate dictatorship model).

Finally, the choice to use io.js should not be ES6, it should be the fact it's a more stable, secure, and actively developed project, plain and simple. It does not force you to use ES6 so I don't know why you're talking about browser adoption at all. I have io.js running in production right now and I didn't change a single line of code when 'porting' my codebase from an old node.js installation.

This. I love it when people think io.js is less stable. I mean, how hard would it be to think about it: one of them has half a year of open v8 bugs that the other has closed. One runs on actively maintained v8 and the other does not. One has all the core contributors and the other does not... doesn't sound like hard math to me.

> a beta for the bleeding edge, stability for the enterprise

And yet, Node.js is using unsupported versions of V8 and libuv, whereas io.js is on supported ones. I'm not sure that's exactly enterprise stability.

Actually, it's pretty much exactly my understanding of the phrase "enterprise stability".

You're entirely missing the point if you think this is just about ES6 or even a better v8.

There are a number of core contributors to Node.js that are unhappy with Joyent's stewardship of node.js. The core contributors want to work on the node.js core and provide new features. Joyent has not enabled these core contributors to make these improvements, and have seemingly alienated some great developers like Ben Noordhuis for political reasons.

Hence the io.js fork.

It's been clear from the beginning that the io.js folks are willing to work with Joyent and node.js, if Joyent is willing to give up its iron fisted control of the project.

This is one of the greatest attributes of open source; the ability to fork. Both io.js and Node.js can succeed independently of each other. The server side javascript community is as vibrant as ever -- with adoption ramping up exponentially among big enterprises and startups alike.

The foundation itself is a great step forward for Node.js, and will result in much needed enterprise investment in the runtime.

Browser adoption, really? Why would you care about that on the server side.

Yea, Node would have landed a lot more patches if they didn't have that pesky IE9 compatibility requirement.

> for anyone who wants to write isomorphic code without a lot of pain in compilers, is limited by browser adoption

Are you confused? "isomorphic" doesn't mean what you think it means ...

Applications are open for YC Summer 2021

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact