Is Node viable in its current way of development and maintenance?

[gplusdotgr]

UPDATE: Please dont focus on fetch, this is not the reason for this thread, it's supposed to be more of a birds-eye view on how the project is going, point to useful Public Working Groups, Roadmaps etc.

I would like to open a no-agenda thread which was epidermically discussed in #19393 .

With the current number of active maintainers, the current project management (if any), the current funds and sponsorships, is Node a project where the community and maintainers, as well as potential corporations interested to use it, a project which has a future (adoption rate, new apis, maintenance), or are there changes needed in order to improve both the workload of the maintainers, as well as the quality of the API, or tackle the 950+ open issues in the issue queue? How does Node compare with the release cycle of other server/frameworks?

[benjamingr]

I mean, I think Node.js still has very high velocity IMO with multiple (large) things shipped in the last year (cancellation in all APIs, QUIC, policies, unflagging ESM, promise UX improvements, big native API changes, new timer promises APIs, worker improvements, making core tamper safe with primordials sourcemaps and a ton more).

It's just that people here don't particularly care that much about fetch in core enough to invest a ton of time in doing it right. It's still progressing. The 955 open issues compare to over 11000 closed ones, ditto for PRs.

[benjamingr]

How does Node compare with the release cycle of other server/frameworks?

And Node has much higher velocity and much finer grained releases with release lines compared to most other platforms I'm aware of. There is a lot that can improve and a lot Node.js can do better.

You are welcome to get involved in the "Next 10 years" initiative for example :]

[gplusdotgr]

How does Node compare with the release cycle of other server/frameworks?

You are welcome to get involved in the "Next 10 years" initiative for example :]

See this is why it's good to bring these things to the surface, I didn't even know this existed - I just discovered the repo. Isn't it invite only though?

[Trott]

The short answer is (IMO) "Yes, broadly speaking, the current way of development and maintenance is more than viable."

Of course, there are areas for improvement. That will always be true.

I think the fetch discussion and a few other things could benefit from a bit of a more formal process around it and there's some discussion of that in nodejs/TSC#962.

I don't think our velocity is slow at all, especially considering the size of our user base, diversity of supported platforms, and scope/variety of use cases in the community. Our release pace and support cycle is something we do well.

And while I'd love to see the number of languishing open issues and pull requests decrease, I don't find the number of open issues and pull requests to be a cause for any significant concern about the viability of the project, especially when compared to other projects that have similarly large user bases and/or code bases.

Python currently has 1440 open pull requests compared to our 251.

tensorflow has 3773 open issues compared to our 979.

redis has significantly more open issues and pull requests than we do.

PowerShell has approximately 3000 open issues.

aspnetcore has approximately 2500 open issues.

electron has approximately 1500 open issues.

react-native has more open issues and more open pull requests than we do.

And so on. In terms of the number of open issues and pull requests being a source of 😱, I'd say we can and should try to do better. But in terms of it suggesting a threat to our viability, counterexamples are everywhere.

That said, it's frustrating for people to have their issues and pull requests languish. Aside from the RFC issue linked above, I think our most recent experiment in addressing this is the creation of a Triagers team. If curious/interested, see https://github.com/nodejs/node/blob/master/doc/guides/contributing/issues.md#triaging-a-bug-report for information on how that works, how to join, etc.

[Trott]

See this is why it's good to bring these things to the surface, I didn't even know this existed - I just discovered the repo.

Repository fragmentation is an issue we need to address. There are good reasons for it in a lot of cases, but it hampers discoverability of information.

[benjamingr]

See this is why it's good to bring these things to the surface, I didn't even know this existed - I just discovered the repo. Isn't it invite only though?

You are welcome to open an issue to ask how to engage - and ask to be included. There is a good chance you'll be able to contribute. Not sure though - pinging @nodejs/next-10 -> is the initiative currently only open to people inside the org?

[gplusdotgr]

Thanks, this thread is already bringing more info than I hoped :) looking forward for more insights. I think a good way to start contributing is by answering pure support questions in the issue tracker.

[mcollina]

Regarding fetch, the reason why fetch has not happened in core yet is because node-fetch gives 80% of the feature needed. From talking to companies with budget to invest in this, there is no business case in adding fetch to core.

As for the rest, very few have the interest in adding something non-spec compliant to core that we'd have to maintain for a long time. It'd be hard work that few volunteers will be willing to take on.

If you are interested in what next-gen http clients will look like, take a look at https://github.com/nodejs/undici - it's likely going to get a fetch-like implementation soon from @Ethan-Arrowood.

[gplusdotgr]

update from my side, just discovered some of the Node working group meetings are on Youtube: https://www.youtube.com/c/nodejs-foundation/videos

[Qard]

Expanding on what @mcollina said, fetch might look simple on the surface, but following the spec there's a bunch more depth than is immediately obvious, with a bunch of different interconnected types that also need to be implemented to follow the script exactly. Some of those have been introduced recently, such as AbortController and Blob, but there are many more yet which have not like FormData, and some of which are in direct conflict with core APIs like ReadableStream (The ecma spec streams, not Node.js streams). I would think it's not impossible that core may eventually gain fetch support, but there are many prerequisites and someone needs to build those first.

[jasnell]

@Trott:

I think the fetch discussion and a few other things could benefit from a bit of a more formal process around it and there's some discussion of that in nodejs/TSC#962.

I have to disgree there. I don't think we need more formal process at this point. It would be pointless. The reason we don't have XYZ (where XYZ is whatever feature someone may want) is that existing contributors have not prioritized doing it and new contributors have not yet contributed it. Adding formal process won't change that fact.

[benjamingr]

but there are many more yet which have not like Blob

Fwiw blob landed #36811 🎉

[Qard]

Ah, missed that one. Cool. 🎉

[jasnell]

Well, let's say partial blob support landed. I'm still working on the async blob backend.

[Trott]

The reason we don't have XYZ (where XYZ is whatever feature someone may want) is that existing contributors have not prioritized doing it and new contributors have not yet contributed it. Adding formal process won't change that fact.

@jasnell Maybe fetch is no longer a good example because consensus has gelled. But I think it still applies to arbitrary feature XYZ.

By "formal", I don't mean "heavyweight". I mean a clear and efficient mechanism for Node.js as a project to say "Yes, that's a feature we want", or "No, we would not welcome such a feature." We have a mechanism for these things. It's not efficient. And it burns people out. (That's the problem a lightweight decision-making mechanism would be trying to solve, not the problem of "Why don't we have feature XYZ implemented yet?")

I'll make the counterpoint argument to what I'm saying, just to save others the trouble: It's possible that long and often-frustrating conversations are necessary to make these decisions. There's a lot to consider sometimes and you have to talk it over, sometimes multiple times.

I hope there's a not-onerous way to reduce the friction. If other projects/organizations have found a solution that works, perhaps we should consider what they do. Perhaps the reason we have punishingly long conversations around certain things is exactly because we have no good process for making decisions around whether or not features should be implemented.