This repository was archived by the owner on Nov 9, 2017. It is now read-only.
Repository navigation
This repository was archived by the owner on Nov 9, 2017. It is now read-only.
Discussion: v8 / nodejs relationship - The way to constant improvment #100
Description
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?
- performance
- code size
- release cycle sync
- goal disparity elimination
- build & deployment
- GYP / GN headaches
- time to port beneficial changes
- Our weight in TC39
- relationship with Google
- relationship with Microsoft
- ABI / API / A*I
/cc @nodejs/ctc @nodejs/v8
Activity
mscdex commentedon Apr 12, 2017
Huh? I think you're 11 days too late.
MylesBorins commentedon Apr 12, 2017
@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
Details
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 commentedon Apr 12, 2017
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 commentedon Apr 12, 2017
@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 commentedon Apr 12, 2017
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 commentedon Apr 12, 2017
@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...
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.
[-]Pull a webkit=>blink on v8[/-][+]Discussion: pull a webkit=>blink on v8?[/+]refack commentedon Apr 12, 2017
I would like to get back to the original discussion:
@MylesBorins I thought this was more political/organizational discussion rather than an EPS, even I'm not sure it's an Enhancement
@mscdex in what sense? ChakraCore-wize?
@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)?
@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 commentedon Apr 12, 2017
@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 commentedon Apr 12, 2017
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.
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)
I'm don't have anything clear but maybe all the points I raised together have enough weight:
gibfahn commentedon Apr 12, 2017
@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:
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.
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 commentedon Apr 12, 2017
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 commentedon Apr 12, 2017
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 commentedon Apr 12, 2017
@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.
19 remaining items
refack commentedon Apr 14, 2017
I'm assuming V8 does it better, and is de-facto spearheading language innovation. All those tools would greatly benefit from opening this API, not having to play catch up.
addaleax commentedon Apr 14, 2017
It seems to me like userland tools are usually ahead of the JS implementations, and based on my understanding of the TC39 process that’s both by design and unavoidable: Language features are usually implemented using tools like Babel before the engines do that.
refack commentedon Apr 14, 2017
🤔that is true... I need to think about what it means...
refack commentedon Apr 14, 2017
Discussion point: Maybe nodejs should embed
Babel?MylesBorins commentedon Apr 14, 2017
Hey all. I'd like to suggest that we open another thread to discuss this, I for one have been thinking for a while about more standardization around AST / intermediate representation and would be glad to discuss
refack commentedon Apr 14, 2017
nodejs/CTCor wait fornodejd/Contributors, or should we open it tonodejs/node?refack commentedon Apr 14, 2017
Can we call it "AST, IR, bytecode and friends"? 😉
MylesBorins commentedon Apr 14, 2017
nodejs/ctc should be fine
refack commentedon May 1, 2017
I wanted to ask the
V8and @nodejs/v8 people couple few questions:Thank you.
addaleax commentedon May 1, 2017
@refack That might be easier to discuss on the corresponding issues? (For source map support that’s nodejs/node#6471, btw)
refack commentedon May 1, 2017
I thought the general agreement was that we could use this as a tracking issue 🤔.
Some of the V8 people explicitly said before they would be happy to answer questions.
MylesBorins commentedon May 2, 2017
@refack in general for new ideas it is better to start new threads... reopening large threads with lots of embedded context makes it easy to be distracted
refack commentedon May 2, 2017
Gotcha 👍