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.

[ljharb]

I'd be willing to bet that Google spends more money and time on v8 than the node foundation will be able to even come close to supporting.

[refack]

@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.

Trying to point out "miscommunication and wrong expectations". 😳I'm trying to gently pivot the discussion towards: "So let's make sure the communication channel is super high bandwidth"

I'd be willing to bet that Google spends more money and time on v8 than the node foundation will be able to even come close to supporting.

@ljharb I'm not so sure (not to belittle their effort), I'd estimate it's on par... https://github.com/nodejs/node/graphs/code-frequency https://github.com/v8/v8/graphs/code-frequency

[refack]

I think we can all agree that "miscommunication and wrong expectations" are bane of most software projects, how do we manage this in relation to v8?

[refack]

Re-titled and added interim conclusions into description.

[MylesBorins]

I think that we should stop the discussion on here if we are pivoting towards a general discussion of the relationship. Tldr, it is better than it ever has been.

If you have particular thoughts or concerns around it we can discuss this in a new issue on the main repo, although I'm not really sure what the goal of the discussion would be

[Trott]

@refack The communication and expectation-setting between Node.js and V8 is vastly improved over past years and getting better.

• We have V8 team representation on the CTC.

• We have people (like @MylesBorins) working hard (and with success, IMO) to actively connect LTS WG and V8 team, CTC and V8 team, etc.

• We have periodic and highly productive conference calls (organized by @hashseed) where V8 representatives and CTC representatives discuss important challenges and try to make decisions to move things forward.

I (and others, no doubt) could go on. But basically, I'm pretty pleased with the trend of the relationship and communication between Node.js and V8. It's not perfect. But it's pretty good and getting better. Past friction and challenges have definitely not gone ignored.

There are definitely external projects/entities with which I wish we had a better relationship and better communication. But V8 isn't anywhere near the top of that list.

[Trott]

(Also, just to be clear: @refack Totally understandable that you might not know a lot or even all of the stuff in my previous comment. There's a ton of stuff to keep track of in Node.js and no one can track it all. It's especially hard for people relatively new to the project to know about stuff that has been evolving over many years.)

[MylesBorins]

I'm going to be explicit here. I don't think that the continuation of this discussion will result in anything positive. I've locked the issue.

[jasnell]

Oy... My apologies. I'm currently quite a bit distracted this week with new employer business and I've missed a great deal of this conservation. My initial comments were not meant to be dismissive in any way, they were just rushed, and for that I apologize. I forgot to couch the language in terms that made it clear that I was simply offering my own personal opinion and I forgot to reread and self edit for tone. Please do accept my apology on that. Let's get the conversation back on track.

The technical challenges around forking a project like V8 are immense. The level of technical expertise required in compilation, optimization, garbage collection, and so on is tremendous. We do have people working on core (my amazing former colleagues from IBM for example) who absolutely have this depth of knowledge, but there would be extremely little or no real benefit that I can see to forking V8 or any separate VM effort given the amount of work that would be involved -- given the history, and given the relationship we've built with the existing VM teams, it's far more effective (in terms of cost, time, benefit, and ecosystem stability) to continue working with and within these existing teams while focusing other efforts on stuff like the stable add-ons API.

Sure, things like the mismatched shipping schedule give headaches, but they're manageable given the benefits.

Regarding the suggestion that we work to give higher priority to working with the V8 team, I'd just like to point out that we already have extensive connections built with both the V8 and ChakraCore teams at several levels throughout the project. The open and productive communication channels are there, and both teams are quite responsive and willing to work with anyone of us here.

Again, I apologize for the abrupt tone in my previous message.

[refack]

I have a question, actually two:

1. bytecode caching: could we do it vis a vis current V8 (if we wanted, I assume the pros and cons were discussed)
2. Access to the AST, is it in the API? (I went looking for it today but took a breather after reaching V8::interal::Compiler::GetSharedFunctionInfoForScript)

[addaleax]

bytecode caching: could we do it vis a vis current V8 (if we wanted, I assume the pros and cons were discussed)

Yes, and to some degree we already expose that. Depending on what exactly you want, https://github.com/nodejs/node/issues/11842 might be what you are looking for. :)

Access to the AST, is it in the API?

No, it’s not exposed through V8’s public API.

[hashseed]

Aside from size and content, caching bytecode is not much different than caching unoptimized JIT code. The cache data is platform-dependent in both cases because it contains more than just code/bytecode.

V8 will probably never expose the AST in the API, since it's an implementation detail. You don't want to worry about API/ABI compatibility when you change the parser.

[refack]

@hashseed

Aside from size and content, caching bytecode is not much different than caching unoptimized JIT code. The cache data is platform-dependent in both cases because it contains more than just code/bytecode.

What your saying obviously makes sense. But nodejs/node#11842 also makes sense.

V8 will probably never expose the AST in the API, since it's an implementation detail. You don't want to worry about API/ABI compatibility when you change the parser.

IMHO that's something you (all) could reconsider. Maybe even splitting the 2 (or 3 parser-compiler-VM) into lightly dependent products, like javac/JRE, C#/CLR, JQuery/sizzle, and the list goes on. Obviously the transpiler ecosystem would rejoice, and also this may lead to independent optimizations or enhancements. Found a respectable reference PEP511

[hashseed]

Writing a JS parser is a manageable task, and many already exist. Tools that do source-level transformations also exist, e.g. Uglify.

Personally I don't think AST-level optimizations are as powerful as for example on an SSA. And making the compiler extensible to third-party extensions is certainly a non-goal. V8 is not LLVM. A big difference is that parsing/compiling happens at runtime, on the critical path to execution.

[refack]

Personally I don't think AST-level optimizations are as powerful as for example on an SSA. And making the compiler extensible to third-party extensions is certainly a non-goal. V8 is not LLVM. A big difference is that parsing/compiling happens at runtime, on the critical path to execution.

No judgment, I totally understand your POV, but IMHO this is a node/v8 goal disparity. (feeeew I feel relieved we found one 😌 now I know my original premise wasn't totally off base)

[refack]

Writing a JS parser is a manageable task, and many already exist. Tools that do source-level transformations also exist, e.g. Uglify.

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]

assuming V8 does it better, and is de-facto spearheading language innovation

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]

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.

🤔that is true... I need to think about what it means...

[refack]

Discussion point: Maybe nodejs should embed Babel?

[MylesBorins]

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]

nodejs/CTC or wait for nodejd/Contributors, or should we open it to nodejs/node?

[refack]

Can we call it "AST, IR, bytecode and friends"? 😉

[MylesBorins]

nodejs/ctc should be fine

[refack]

I wanted to ask the V8 and @nodejs/v8 people couple few questions:

1. code map callback (nodejs/node#12471) can we have a "code map" resolution callback on creation of a stack trace?
2. Promise and post-mortem (nodejs/post-mortem#16) is there a way to help the post-mortem scenario in V8. Something like hanging the call-stack on the promise chain just for the case of an unhandled rejection?

Thank you.

[addaleax]

@refack That might be easier to discuss on the corresponding issues? (For source map support that’s https://github.com/nodejs/node/issues/6471, btw)

[refack]

@refack That might be easier to discuss on the corresponding issues? (For source map support that’s nodejs/node#6471, btw)

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]

@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]

Gotcha 👍