Discussion: v8 / nodejs relationship - The way to constant improvment

[refack]

With the knowledge that "miscommunication and wrong expectations" (e.g. The Software Crisis) is the bane of most software projects, how do we keep improving our relationship with the v8 team?
My previous thought, that we should consider spinning off v8 has been rejected. So I'd like to suggest we higher-prioritize the communication channel with the v8 team. I would like this thread to be a place to raise ideas, and share experiences with the goal of achieving a more fruitful collaboration.

Maybe it's time to decide we are a mature enough project, with enough dev power, and spin-off v8 into node v8... Thoughts?

• Are there obvious parts we can refactor out?
• Do we have dev critical mass to take it from here?
• What are the benefits? What's the downside?

1. performance
2. code size
3. release cycle sync
4. goal disparity elimination
5. build & deployment
6. GYP / GN headaches
7. time to port beneficial changes
8. Our weight in TC39
9. relationship with Google
10. relationship with Microsoft
11. ABI / API / A*I

/cc @nodejs/ctc @nodejs/v8

[mscdex]

Huh? I think you're 11 days too late.

[MylesBorins]

@refack this isn't really far along enough to bring to the CTC.

Please feel free to follow the process on https://github.com/nodejs/node-eps if you are serious about this.

I recommend that you consider that many collaborators have been working together to get node running on various vms... it would seem like a step backwards to maintain our own. While I can appreciate your enthusiasm I think it might be better directed at the abi-stable-node project

Also, if you are trying to rally up support for an effort of this magnitude you are going to have an awfully hard time getting it by saying stuff like `decide we're big boys now`. Gender / binary stuff aside, it demeans the work that we are currently doing.

[hashseed]

The people working on blink have contributed heavily to WebKit for years prior to the fork. If forking V8 is indeed a long-term option to consider, I suggest starting to contribute to V8. Otherwise the fork will simply stagnate.

[jasnell]

@refrack,

We won't be forking V8 now or at any point in the foreseeable future. It simply is not something that is worth our time. The current efforts to work in close collaboration with both the fantastic V8 and ChakraCore demonstrate that there is absolutely zero need to even remotely consider the idea in any serious way.

That said, the suggestion of what to do vis a vis V8 aside, the content of your post here is rather unacceptable per our conduct guidelines. We are most certainly not "big boys now". It is quite possible to raise discussion topics around the future of V8 in Node.js without genderizing the discussion. Please do so in the future.

[refack]

This issue is meant as a discussion starter. I do have my own opinion but I really would rather hear y'all's opinion, and make sure this was given serious thought.

[refack]

getting it by saying stuff like decide we're big boys now. Gender / binary stuff aside, it demeans the work that we are currently doing.

@MylesBorins Again me with my foot in my mouth 😔. I meant it as "Decide we are a mature enough project, with enough dev power"

I changed the wording, but now I feel ganged up upon...

We are committed to providing a friendly, safe and welcoming environment for all, regardless of level of experience, gender identity and expression, sexual orientation, disability, personal appearance, body size, race, ethnicity, age, religion, nationality, or other similar characteristic.

IMHO "safe and welcoming environment for all" should cover me too. The phrase "I'm a big boy now" has been used frequently in family friendly culture products, and has been considered benign by most.

Anyway I'm sorry if I offended anyone.

[refack]

I would like to get back to the original discussion:

1. Please feel free to follow the process on https://github.com/nodejs/node-eps if you are serious about this.

@MylesBorins I thought this was more political/organizational discussion rather than an EPS, even I'm not sure it's an Enhancement

2. Huh? I think you're 11 days too late.

@mscdex in what sense? ChakraCore-wize?

3. The people working on blink have contributed heavily to WebKit for years prior to the fork. If forking V8 is indeed a long-term option to consider, I suggest starting to contribute to V8. Otherwise the fork will simply stagnate.

@hashseed That's a point I agree with strongly. Do we have enough devs with hand-on V8 experience? If not, maybe that should be a CTC goal (recruiting / encouraging people to take part)?

4. We won't be forking V8 now or at any point in the foreseeable future. It simply is not something that is worth our time. The current efforts to work in close collaboration with both the fantastic V8 and ChakraCore demonstrate that there is absolutely zero need to even remotely consider the idea in any serious way.

@jasnell I feel your comment was a little dismissive of my original point. Is there really "zero need to even remotely consider the idea in any serious way", IMHO it should be something to be seriously considered constantly, and then acted upon according to our best interests (which probably are not not fork). That was exactly my original intention, to be convinced this was a conscious, logic choice. and not a default.

[MylesBorins]

@refack I think the simple summary in regards to this thought experiment is that "we have nothing to gain". Implementing and managing the VM would take quite a bit of effort and resources. With our current path towards vendor neutral support on VMs managing our own fork would prove a waste of resources imho.

Taking the current discussions around TF + I, it is pretty clear that the V8 team is willing to collaborate with us, so I'm not sure why we would need to go thermonuclear on the relationship.

What clear benefits do you think a fork would offer?

[refack]

@refack I think the simply summary in regards to this thought experiment is that "we have nothing to gain". Implementing and managing the VM would take quite a bit of effort and resources. With our current path towards vendor neutral support on VMs managing our own fork would prove a waste of resources imho.

I'm not convinced that "vendor neutral" is a benefit in itself, unless we help break the "monopoly" of V8 and help "open the market" for VMs, where they strive to outdo each other, thus benefiting all.

Taking the current discussions around TF + I, it is pretty clear that the V8 team is willing to collaborate with us, so I'm not sure why we would need to go thermonuclear on the relationship.

I'm not suggesting to go "thermonuclear", AFAIK blink has contributed to webkit, and the spin-off was done in good spirits. If you look at my original points relationship with Google is obviously a consideration. But I do think we are on par with V8 (in terms of market significance, and obviously not with the whole of Google), and should not think of ourselves as "just another client of V8". It's was actually #99 (and words like "willing to collaborate") that made me think of raising this issue. Your wording made me feel like we are chasing them, and have had the need to figure out how to accommodate their timeline, and adapt to their decisions e.g. nodejs/node##12243)

What clear benefits do you think a fork would offer?

I'm don't have anything clear but maybe all the points I raised together have enough weight:

1. performance: maybe there are big parts that could be eliminated/refactored/optimized as V8 is built for a browser, with the main use case of multiple small'ish fast'ish changing code, while node runs bigger+modular+longer running code.
2. code size: could significant parts be eliminated?
3. release cycle sync + goal disparity: maybe the biggest issue. seems to me we are chasing their timeline. (So maybe the conclusion is that we should sync our release schedule with theirs?)
4. build & deployment + GYP / GN headaches - Has been discussed ad nauseum (no offence intended)
5. Our weight in TC39 Having our "own" major engine would increase our weight in TC39, in the least by impacting the "TC39 Proposal Stages" Process
6. relationship with Google Make them know we're not exclusive, and not just a silent client
7. relationship with Microsoft Make them know we're not exclusive with Google ;)
8. ABI / API Might be easier to achieve stability, or at least semver sync

[gibfahn]

We won't be forking V8 now or at any point in the foreseeable future. It simply is not something that is worth our time

@jasnell that seems a little strong/abrupt/final. I agree that it seems very unlikely, but I think we should at least give reasons.

IMHO:

Basically for a change of that size we'd need at least:

1. Really strong reasons to maintain our own engine rather than using one of the existing ones.
2. A large number of core collaborators willing to maintain/integrate it.
3. A working prototype that demonstrates 1.

The way to start would be to start by forking V8 and getting something working that had advantages over V8. The next step would probably be to simply contribute said changes back to V8, it's an open-source project...

The only reason I could see for maintaining a fork of V8 is that there were changes that the V8 team were unwilling or unable to accept that would really benefit Node.js, so maybe if there was some key difference between Node workloads and browser workloads that meant we could get some really big wins or something.

I'm not convinced that "vendor neutral" is a benefit in itself, unless we help break the "monopoly" of V8 and help "open the market" for VMs, where they strive to outdo each other, thus benefiting all.

There is work to make Node less coupled to a specific V8 version, see n-api and chakracore, which should make it easier for people to try other JS engines going forward.

tl;dr if anyone thinks that there are improvements to be gained from forking V8, then fork it and we'll find out, that's the point of open-source!

[hashseed]

TBH the time we chose to launch TF+I was with Node.js' LTS in mind. The original assumption was that Node 8 does not want the new pipeline, which is part of the reason why we waited till 5.9. V8 5.8 is the perfect candidate for a last release with the old pipeline. Issues brought up in #99 only surfaced later, which is why the discussion is taking place.

It's not as simple as "Node chasing V8". The current situation may be owed to some miscommunication and wrong expectations, but we are improving on that.

[refack]

It's not as simple as "Node chasing V8". The current situation may be owed to some miscommunication and wrong expectations, but we are improving on that.

As a newcomer to the "inner-circle" that was exactly my trigger. Can we afford to be sensitive to "miscommunication and wrong expectations" with such a critical part of our platform?
Maybe we just haven't prioritized this critical communication channel enough over the years?
(#99, nodejs/node#12243, nodejs/node-v0.x-archive#8476, nodejs/node-v0.x-archive#8134, nodejs/node#5221, nodejs/node#12184, just a few examples)
Unfortunately "miscommunication and wrong expectations" is the bread and butter of software projects

[MylesBorins]

@refack I'm missing to see the pattern in the listed pr's / issues. Yes things may have broken over time... but there is no guarantee that if we manage a VM it would be bug free.