• Home
  • Line#
  • Scopes#
  • Navigate#
  • Raw
  • Download
1# Technical Priorities
2
3This list represents the current view of key technical priorities recognized
4by the project as important to ensure the ongoing success of Node.js.
5It is based on an understanding of the Node.js
6[constituencies](https://github.com/nodejs/next-10/blob/main/CONSTITUENCIES.md)
7and their [needs](https://github.com/nodejs/next-10/blob/main/CONSTITUENCY-NEEDS.md).
8
9The initial version was created based on the work of the
10[Next-10 team](https://github.com/nodejs/next-10) and the
11[mini-summit](https://github.com/nodejs/next-10/issues/76)
12on August 5th 2021.
13
14They will be updated regularly and will be reviewed by the next-10 team
15and the TSC on a 6-month basis.
16
17## Modern HTTP
18
19Base HTTP support is a key component of modern cloud-native applications
20and built-in support was part of what made Node.js a success in the first
2110 years. The current implementation is hard to support and a common
22source of vulnerabilities. We must work towards an
23implementation which is easier to support and makes it easier to integrate
24the new HTTP versions (HTTP3, QUIC) and to support efficient
25implementations of different versions concurrently.
26
27## Suitable types for end-users
28
29Using typings with JavaScript can allow a richer experience when using Visual
30Studio Code (or any other IDEs) environments, more complete documentation
31of APIs and the ability to identify and resolve errors earlier in the
32development process. These benefits are important to a large number of Node.js
33developers (maybe 50%).  Further typing support may be important
34to enterprises that are considering expanding their preferred platforms to
35include Node.js. It is, therefore, important that the Node.js project work
36to ensure there are good typings available for the public Node.js APIs.
37
38## Documentation
39
40The current documentation is great for experienced developers or people
41who are aware of what they are looking for. On the other hand, for
42beginners this documentation can be quite hard to read and finding the
43desired information is difficult. We must have documentation
44that is suitable for beginners to continue the rapid growth in use.
45This documentation should include more concrete examples and a learning
46path for newcomers.
47
48## WebAssembly
49
50The use of WebAssembly has been growing over the last few years.
51To ensure Node.js continues to be part of solutions where a
52subset of the solution needs the performance that WebAssembly can
53deliver, Node.js must provide good support for running
54WebAssembly components along with the JavaScript that makes up the rest
55of the solution. This includes implementations of “host” APIs like WASI.
56
57## ESM
58
59The CommonJS module system was one of the key components that led to the success
60of Node.js in its first 10 years. ESM is the standard that has been adopted as
61the equivalent in the broader JavaScript ecosystem and Node.js must continue to
62develop and improve its ESM implementation to stay relevant and ensure
63continued growth for the next 10 years.
64
65## Support for features from the latest ECMAScript spec
66
67JavaScript developers are a fast moving group and need/want support for new ES
68JavaScript features in a timely manner. Node.js must continue
69to provide support for up to date ES versions to remain the runtime
70of choice and to ensure its continued growth for the next 10 years.
71
72## Observability
73
74The ability to investigate and resolve problems that occur in applications
75running in production is crucial for organizations. Tools that allow
76people to observe the current and past operation of the application are
77needed to support that need. It is therefore important that the Node.js
78project work towards well understood and defined processes for observing
79the behavior of Node.js applications as well as ensuring there are well
80supported tools to implement those processes (logging, metrics and tracing).
81This includes support within the Node.js runtime itself (for example
82generating heap dumps, performance metrics, etc.) as well as support for
83applications on top of the runtime. In addition, it is also important to clearly
84document the use cases, problem determination methods and best
85practices for those tools.
86
87## Permissions/policies/security model
88
89Organizations will only choose technologies that allow them to sufficiently
90manage risk in their production deployments. For Node.js to
91continue its growth in product/enterprise deployments we need to ensure
92that we help them manage that risk. We must have a well-documented
93security model so that consumers understand what threats are/are
94not addressed by the Node.js runtime. We also need to provide
95functions/features which help them limit attack surfaces even if it does
96not result in 100% protection as this will still help organizations
97manage their overall risk level.
98
99## Better multithreaded support
100
101Today's servers support multiple threads of concurrent execution.
102Node.js deployments must be able to make full and efficient
103use of the available resources. The right answer is often to use
104technologies like containers to run multiple single threaded Node.js
105instances on the same server. However, there are important use cases
106where a single Node.js instance needs to make use of multiple threads
107to achieve a performant and efficient implementation. In addition,
108even when a Node.js instance only needs to consume a single thread to
109complete its work there can be issues. If that work is long running,
110blocking the event loop will interfere with other supporting work like
111metrics gathering and health checks. Node.js
112must provide good support for using multiple threads
113to ensure the continued growth and success of Node.js.
114
115## Single Executable Applications
116
117Node.js often loses out to other runtimes/languages in cases where
118being able to package a single, executable application simplifies
119distribution and management of what needs to be delivered. While there are
120components/approaches for doing this, they need to be better
121documented and evangelized so that this is not seen as a barrier
122for using Node.js in these situations. This is important to support
123the expansion of where/when Node.js is used in building solutions.
124