Node.js future directions - any interest in online or in person summit?
mhdawson opened this issue · 28 comments
Given that we've just closed out 10 successful years of Node.js and are starting a new decade I'm wondering if there is any interest in a team/online/in-person session to strategize on what we think is important for the next n years of Node.js.
We did have a vm summit a number of years ago which was somewhat along these lines and have have some diagnostics summit's since then. I've been thinking it might be a good time to have a more general vm summit again or perhaps an on-line equivalent.
@nodejs/tsc any interest?
I'd be interested (if it'll be open for non-TSC members as well)
I'm interested as I've found the diagnostics and vm summit extremely productive.
I think a "future of Node" summit would be nice, trying to define some sort of vision for the next 10 years.
@MylesBorins my only thought on having it be separate is that we will get more/better focus on the one topic. The collaborator summits have so much going on it would be hard to dedicate enough time to this one topic while not preventing people being part of other important sessions.
@mmarchini I do think it would be open to all project members who are interested, just seeing what kind of interest we have at the TSC level to start.
Very big +1 from me. I think a focused summit on this topic would be very productive. Ideally it's in person much like the diagnostics summit.
(Ideally it would involve V8 folks too.)
If we decide to do it in person, Netflix might be able to host it, depending on the dates and number of attendees.
Ideally it would involve V8 folks too
Agreed. Maybe npm folks as well?
We have some interest, I'm going to tag for discussion at the next meeting to see if we can get more thoughts/input.
For this topic I think an online summit or an in-person summit colocated with a Node.js/OpenJS event would be nicer so that we can have more people chiming in.
@joyeecheung, the Node.js/OpenJS event is already so packed I'm not sure we could fit in a full day for something like this. I'd also be concerned that people will not have enough energy left over even if we can. I'd lean towards trying a full day online summit (maybe 2 half days to try to cover timezones) for this one.
Some initial thoughts on an agenda
-
Retrospective (1-2 hours?)
- What were the key things that made Node.js successful in the last 10 years
- What were the key values that supported that success
- What worked in the management of the project, what did not
-
Looking Forward
-
Key technologies/trends that will influence what we should do in Node.js (0.5 to 1 hour per)
- Types, type definitions
- Package managers
- Http evolution (QUIC, HTTP3 etc.)
- Promise Based APIs
- Production qualities of service
- Diagnostics
- Monitoring
- Cloud Deployment
- Kubernetes
- Function as a Service (FaaS, Knative etc.)
- APIs for domains (ex tooling team activities)
- WASM
- ESM Modules
- Build/dependencies
- Feature requests (review requests in the repo)
-
Technical Management of the Project (0.5 to 1 hour per?)
- Key values going forward
- Standards
- Should the project define standards in some areas (for example package managers, package.json) ?
- Requirements for core collaborator
-
Capture and Document Looking forward
- Document key agreements from other sessions
- Define key next steps along with champions for those or "help" wanted.
-
[not sure whether this is a strict tsc discussion or not]
some more (with some probable overlap)
- node.js as a language
- retrospective - adoption, consumption, user experience
- prospective - use workload data and field experience to feed / influence language feature decisions
- node.js as an JS platform
- retrospective - scope in the JS spectrum
- prospective - ironing out feature definitions for the backend
- node.js as an open source project
- retrospective - where are we matured, where are not
- prospective - setting standards, show exemplary behaviors of an open source community
- node.js as a github org
- retrospective - health of resident repos
- prospective - efficient balancing of backlog with available members
- node.js as an (event driven) architecture
- prospective - better integration with heterogeneous workloads
- prospective - influence evented architecture in relevant use cases
Another topic we can discuss is Native build toolchain for Node.js core and native modules, since any big shifts in that space would probably stay with us for the next 5-10 years.
- Production qualities of service
- Diagnostics
- Monitoring
- Cloud Deployment
- Kubernetes
- Function as a Service (FaaS, Knative etc.)
All of these are also related to another topic we could discuss: "Node.js readiness as an enterprise-grade runtime."
I also have some more controversial topics in mind, which could be classified as "revisiting the status quo":
- Future of native modules and V8 updates:
- With N-API and WASM, maybe we got to a point where V8 headers are not necessary for most use cases
- Should we stop shipping V8 headers, in favor of being able to upgrade V8 more frequently?
- As of right now, Node.js doesn't have a roadmap. Should we? What would be the benefits of a roadmap? What would be the downsides?
- Introducing new API/modules in core: considering we don't usually remove modules (even APIs are unlikely to be removed), the trend is for our API footprint to keep growing in the next years. With that in mind, how do we decide what should be included? How do we decide what should stay out of core? Should we be more strict moving forward? Or should we be more flexible?
I don't have strong opinions on any of these yet, but I think it's important to revisit current assumptions to make sure they'll still make sense in the future.
@mmarchini thanks for the suggestions. I'll let people comment for a while and then try to pull all of the suggestions/comments together.
Another topic:
- Improving our test suite so it's less flaky-prone
(or maybe: how to keep our test infrastructure healthy as we move forward)
I don't know how, but I think that's something worth discussing. Restarting the CI several times to land a simple PR can be a real burden for Collaborators today, alongside navigating the CI results, searching each failure to check if it is a flaky, etc.
Related: nodejs/node#31955 (comment)
@mmarchini +1 great idea, green CI is important and I've heard a number of people comment on that.
@nodejs/tsc pulled this together based on the suggestions made:
https://docs.google.com/document/d/1O4qk5iPN9_8ICJbk4svjnUnDoMcZtoUn8pMSkOHcVDk/edit?usp=sharing
Please comment. A few key things to think about
- Any missing topics
- Too much ? 10 sessions at 1.5 to 2 hours each would probably take 2 weeks if we did 1 session day.
- Is this close enough to ask for input from all collaborators more directly (we've mostly been talking among TSC members so far).
See this related comment on how we might schedule across time-zones: #836 (comment)
LGTM!
Any missing topics
I don't think so, looks like a good coverage
Too much ? 10 sessions at 1.5 to 2 hours each would probably take 2 weeks if we did 1 session day.
I don't think so, all are great and valid topics
Is this close enough to ask for input from all collaborators more directly (we've mostly been talking among TSC members so far).
I think yes. Role in Package management, should we have more influence on Package.json? - will this cover the ongoing need / choice of default package manager discussion as well?
A few more for the "revisiting the status quo" bucket:
- should we drop CommonJS eventually?
- Should we drop callback based APIs eventually in favor of Promise based APIs?
- For APIs that get standardized elsewhere, should we drop our implementations in favor of the standards?
I'm not thinking none of this for the next year or so, but for 10 years from now: are those set in stone assumptions, or given enough time are we considering revisit those? I'm also not saying I'm in favor or against any of these, but I do believe it's worth discussing.
Also, if we decide to discuss those, we might want to coalesce all related topics into one (and maybe there are other topics we can do that to).
Misclicked :(
@mmarchini merged your suggestions into https://docs.google.com/document/d/1O4qk5iPN9_8ICJbk4svjnUnDoMcZtoUn8pMSkOHcVDk
think yes. Role in Package management, should we have more influence on Package.json? - will this cover the ongoing need / choice of default package manager discussion as well?
I'd say yes.
Given the current environment and the logistics as discussed in: #836. These are some options we can consider:
- Decide we don't need to do anything on this front, close
- Pause idea for 3 months, and then revisit to see what makes sense
- Try to do over longer time period (say 2 hour session per week or every other week with rotating time slot) over a number of months
- Plan for virtual sessions in early June over 1 week
- Plan for virtual session in late July over 1 week
- Plan for virtual sessions at some point later in the year over 1 week
- Plan Retrospective section (maybe 1-1.5 hours?) for upcoming virtual OpenJS World summit and then decide from there.
- Plan Retrospective section and initial Looking forward session for upcoming virtual OpenJS World summit (maybe 3 hours ?) and then decide from there.
- Plan Retrospective section and initial Looking forward session for upcoming virtual OpenJS World summit (maybe 3 hours ?) and then plan for 2 hour session every other week to continue working.
There are many more variations, but this gives some concrete options.
My first choice would be to try to make it more concentrated, but since it seems like now is not necessarily a good time for that I might suggest this one ?
- Plan Retrospective section and initial Looking forward session for upcoming virtual OpenJS World summit (maybe 3 hours ?) and then plan for 2 hour session every other week to continue working.
- Plan Retrospective section and initial Looking forward session for upcoming virtual OpenJS World summit (maybe 3 hours ?) and then decide from there.
- Plan Retrospective section and initial Looking forward session for upcoming virtual OpenJS World summit (maybe 3 hours ?) and then plan for 2 hour session every other week to continue working.
I like these two.
Issue to propose summit topic at OpenJS World: openjs-foundation/summit#279
Next-10 effort is up and running - see https://github.com/nodejs/next-10. I think we can close this.
@qtencent7 This is not the right place to start such a discussion. FWIW, multi-threading won't magically solve bad error handling by the developer. Feel free to open an issue in nodejs/help if you need help with proper error handling.