Skip to content

Commit 2d53b68

Browse files
committed
doc: update technical priorities for 2023
1 parent 56ccd59 commit 2d53b68

File tree

1 file changed

+52
-36
lines changed

1 file changed

+52
-36
lines changed

doc/contributing/technical-priorities.md

Lines changed: 52 additions & 36 deletions
Original file line numberDiff line numberDiff line change
@@ -14,8 +14,12 @@ on August 5th 2021.
1414
They will be updated regularly and will be reviewed by the next-10 team
1515
and the TSC on a 6-month basis.
1616

17+
Version from the [mini-summit](https://github.com/nodejs/next-10/issues/1) on October 1st 2022.
18+
1719
## Modern HTTP
1820

21+
_Present in: 2021_
22+
1923
Base HTTP support is a key component of modern cloud-native applications
2024
and built-in support was part of what made Node.js a success in the first
2125
10 years. The current implementation is hard to support and a common
@@ -26,6 +30,8 @@ implementations of different versions concurrently.
2630

2731
## Suitable types for end-users
2832

33+
_Present in: 2021_
34+
2935
Using typings with JavaScript can allow a richer experience when using Visual
3036
Studio Code (or any other IDEs) environments, more complete documentation
3137
of APIs and the ability to identify and resolve errors earlier in the
@@ -37,6 +43,8 @@ to ensure there are good typings available for the public Node.js APIs.
3743

3844
## Documentation
3945

46+
_Present in: 2021_
47+
4048
The current documentation is great for experienced developers or people
4149
who are aware of what they are looking for. On the other hand, for
4250
beginners this documentation can be quite hard to read and finding the
@@ -47,20 +55,24 @@ path for newcomers.
4755

4856
## WebAssembly
4957

58+
_Present in: 2021_
59+
5060
The use of WebAssembly has been growing over the last few years.
5161
To ensure Node.js continues to be part of solutions where a
5262
subset of the solution needs the performance that WebAssembly can
5363
deliver, Node.js must provide good support for running
5464
WebAssembly components along with the JavaScript that makes up the rest
5565
of the solution. This includes implementations of “host” APIs like WASI.
5666

57-
## ESM
67+
## ES Modules (ESM)
5868

59-
The CommonJS module system was one of the key components that led to the success
60-
of Node.js in its first 10 years. ESM is the standard that has been adopted as
61-
the equivalent in the broader JavaScript ecosystem and Node.js must continue to
62-
develop and improve its ESM implementation to stay relevant and ensure
63-
continued growth for the next 10 years.
69+
_Present in: 2021_
70+
71+
The CommonJS module system was one of the key components that led to the
72+
success of Node.js in its first 10 years. ESM is the standard that has
73+
been adopted asthe equivalent in the broader JavaScript ecosystem and
74+
Node.js must continue to develop and improve its ESM implementation
75+
to stay relevant and ensure continued growth for the next 10 years.
6476

6577
## Support for features from the latest ECMAScript spec
6678

@@ -71,6 +83,8 @@ of choice and to ensure its continued growth for the next 10 years.
7183

7284
## Observability
7385

86+
_Present in: 2021_
87+
7488
The ability to investigate and resolve problems that occur in applications
7589
running in production is crucial for organizations. Tools that allow
7690
people to observe the current and past operation of the application are
@@ -80,38 +94,10 @@ the behavior of Node.js applications as well as ensuring there are well
8094
supported tools to implement those processes (logging, metrics and tracing).
8195
This includes support within the Node.js runtime itself (for example
8296
generating heap dumps, performance metrics, etc.) as well as support for
83-
applications on top of the runtime. In addition, it is also important to clearly
84-
document the use cases, problem determination methods and best
97+
applications on top of the runtime. In addition, it is also important to
98+
clearly document the use cases, problem determination methods and best
8599
practices for those tools.
86100

87-
## Permissions/policies/security model
88-
89-
Organizations will only choose technologies that allow them to sufficiently
90-
manage risk in their production deployments. For Node.js to
91-
continue its growth in product/enterprise deployments we need to ensure
92-
that we help them manage that risk. We must have a well-documented
93-
security model so that consumers understand what threats are/are
94-
not addressed by the Node.js runtime. We also need to provide
95-
functions/features which help them limit attack surfaces even if it does
96-
not result in 100% protection as this will still help organizations
97-
manage their overall risk level.
98-
99-
## Better multithreaded support
100-
101-
Today's servers support multiple threads of concurrent execution.
102-
Node.js deployments must be able to make full and efficient
103-
use of the available resources. The right answer is often to use
104-
technologies like containers to run multiple single threaded Node.js
105-
instances on the same server. However, there are important use cases
106-
where a single Node.js instance needs to make use of multiple threads
107-
to achieve a performant and efficient implementation. In addition,
108-
even when a Node.js instance only needs to consume a single thread to
109-
complete its work there can be issues. If that work is long running,
110-
blocking the event loop will interfere with other supporting work like
111-
metrics gathering and health checks. Node.js
112-
must provide good support for using multiple threads
113-
to ensure the continued growth and success of Node.js.
114-
115101
## Single Executable Applications
116102

117103
Node.js often loses out to other runtimes/languages in cases where
@@ -121,3 +107,33 @@ components/approaches for doing this, they need to be better
121107
documented and evangelized so that this is not seen as a barrier
122108
for using Node.js in these situations. This is important to support
123109
the expansion of where/when Node.js is used in building solutions.
110+
111+
## Serverless
112+
113+
Serverless is a cloud computing model where the cloud provider manages the
114+
underlyinginfrastructure and automatically allocates resources as
115+
needed. Developers only need to focus on writing code for specific
116+
functions, which are executed as individual units of work in response to
117+
events. Node.js is one of the main technology used by developers in
118+
this field therefore it is crucial for us to provide a great solution.
119+
120+
## Small footprint
121+
122+
Small software footprints refer to software that has a minimal impact on
123+
system resources such as memory and processing power. This can be achieved
124+
through various methods such as optimizing code, reducing the number of dependencies, or using lightweight frameworks. Smaller footprints can lead to faster startup times, reduced
125+
memory usage, and improved overall system performance. This is fundamental
126+
for Node.js to be a lightweight proposition inside the ecosystem as it is
127+
used across a wild variety of projects, from web application to IoT and
128+
serverless.
129+
130+
## Developers-first DX
131+
132+
Developer experience (DX) refers to the overall experience a developer has when
133+
working with a software development platform, framework, or tool. It encompasses
134+
all aspects of the developer's interactions with the system, from installation
135+
and configuration to writing code and debugging. A good DX prioritizes ease
136+
of use,efficiency, and productivity, and can lead to faster development times,
137+
higher quality code, and greater developer satisfaction. Factors that can
138+
impact DX include documentation, community support, testing tools,
139+
and integration with other systems.

0 commit comments

Comments
 (0)