From ac56a114ad7c8eff4da13e7ab10ff98ddcc3d03e Mon Sep 17 00:00:00 2001 From: Michael Dawson Date: Mon, 27 Sep 2021 14:55:36 -0400 Subject: [PATCH] doc: add initial list of technical priorities MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Jean Burellier Signed-off-by: Michael Dawson PR-URL: https://github.com/nodejs/node/pull/40235 Reviewed-By: James M Snell Reviewed-By: Matteo Collina Reviewed-By: Tobias Nießen Reviewed-By: Colin Ihrig Reviewed-By: Gireesh Punathil Reviewed-By: Voltrex --- doc/guides/technical-priorities.md | 123 +++++++++++++++++++++++++++++ 1 file changed, 123 insertions(+) create mode 100644 doc/guides/technical-priorities.md diff --git a/doc/guides/technical-priorities.md b/doc/guides/technical-priorities.md new file mode 100644 index 00000000000000..924572b206df2f --- /dev/null +++ b/doc/guides/technical-priorities.md @@ -0,0 +1,123 @@ +# Technical Priorities + +This list represents the current view of key technical priorities recognized +by the project as important to ensure the ongoing success of Node.js. +It is based on an understanding of the Node.js +[constituencies](https://github.com/nodejs/next-10/blob/main/CONSTITUENCIES.md) +and their [needs](https://github.com/nodejs/next-10/blob/main/CONSTITUENCY-NEEDS.md). + +The initial version was created based on the work of the +[Next-10 team](https://github.com/nodejs/next-10) and the +[mini-summit](https://github.com/nodejs/next-10/issues/76) +on August 5th 2021. + +They will be updated regularly and will be reviewed by the next-10 team +and the TSC on a 6-month basis. + +## Modern HTTP + +Base HTTP support is a key component of modern cloud-native applications +and built-in support was part of what made Node.js a success in the first +10 years. The current implementation is hard to support and a common +source of vulnerabilities. We must work towards an +implementation which is easier to support and makes it easier to integrate +the new HTTP versions (HTTP3, QUIC) and to support efficient +implementations of different versions concurrently. + +## Suitable types for end-users + +Using typings with JavaScript can allow a richer experience when using Visual +Studio Code (or any other IDEs) environments, more complete documentation +of APIs and the ability to identify and resolve errors earlier in the +development process. These benefits are important to a large number of Node.js +developers (maybe 50%). Further typing support may be important +to enterprises that are considering expanding their preferred platforms to +include Node.js. It is, therefore, important that the Node.js project work +to ensure there are good typings available for the public Node.js APIs. + +## Documentation + +The current documentation is great for experienced developers or people +who are aware of what they are looking for. On the other hand, for +beginners this documentation can be quite hard to read and finding the +desired information is difficult. We must have documentation +that is suitable for beginners to continue the rapid growth in use. +This documentation should include more concrete examples and a learning +path for newcomers. + +## WebAssembly + +The use of WebAssembly has been growing over the last few years. +To ensure Node.js continues to be part of solutions where a +subset of the solution needs the performance that WebAssembly can +deliver, Node.js must provide good support for running +WebAssembly components along with the JavaScript that makes up the rest +of the solution. This includes implementations of “host” APIs like WASI. + +## ESM + +The CommonJS module system was one of the key components that led to the success +of Node.js in its first 10 years. ESM is the standard that has been adopted as +the equivalent in the broader JavaScript ecosystem and Node.js must continue to +develop and improve its ESM implementation to stay relevant and ensure +continued growth for the next 10 years. + +## Support for features from the latest ECMAScript spec + +JavaScript developers are a fast moving group and need/want support for new ES +JavaScript features in a timely manner. Node.js must continue +to provide support for up to date ES versions to remain the runtime +of choice and to ensure its continued growth for the next 10 years. + +## Observability + +The ability to investigate and resolve problems that occur in applications +running in production is crucial for organizations. Tools that allow +people to observe the current and past operation of the application are +needed to support that need. It is therefore important that the Node.js +project work towards well understood and defined processes for observing +the behavior of Node.js applications as well as ensuring there are well +supported tools to implement those processes (logging, metrics and tracing). +This includes support within the Node.js runtime itself (for example +generating headumps, performance metrics, etc.) as well as support for +applications on top of the runtime. In addition, it is also important to clearly +document the use cases, problem determination methods and best +practices for those tools. + +## Permissions/policies/security model + +Organizations will only choose technologies that allow them to sufficiently +manage risk in their production deployments. For Node.js to +continue its growth in product/enterprise deployments we need to ensure +that we help them manage that risk. We must have a well-documented +security model so that consumers understand what threats are/are +not addressed by the Node.js runtime. We also need to provide +functions/features which help them limit attack surfaces even if it does +not result in 100% protection as this will still help organizations +manage their overall risk level. + +## Better multithreaded support + +Today's servers support multiple threads of concurrent execution. +Node.js deployments must be able to make full and efficient +use of the available resources. The right answer is often to use +technologies like containers to run multiple single threaded Node.js +instances on the same server. However, there are important use cases +where a single Node.js instance needs to make use of multiple threads +to achieve a performant and efficient implementation. In addition, +even when a Node.js instance only needs to consume a single thread to +complete its work there can be issues. If that work is long running, +blocking the event loop will interfere with other supporting work like +metrics gathering and health checks. Node.js +must provide good support for using multiple threads +to ensure the continued growth and success of Node.js. + +## Single Executable Applications + +Node.js often loses out to other runtimes/languages in cases where +being able to package a single, executable application simplifies +distribution and management of what needs to be delivered. While there are +components/approaches for doing this, they need to be better +documented and evangelized so that this is not seen as a barrier +for using Node.js in these situations. This is important to support +the expansion of where/when Node.js is used in building solutions.