doc: add initial list of technical priorities

Co-authored-by: Jean Burellier <sheplu@users.noreply.github.com>

Signed-off-by: Michael Dawson <mdawson@devrus.com>

PR-URL: #40235
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Tobias Nießen <tniessen@tnie.de>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
Reviewed-By: Voltrex <mohammadkeyvanzade94@gmail.com>

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.