FazBrowse GitHub Viewer | Trending |
URL:
| Home
Tools: [Download Repo ZIP]   [Original HTTPS Page]

doc: add initial list of technical priorities · nodejs/node@429915a · GitHub

/ node Public

Commit 429915a

Browse files
mhdawson
authored and
targos
committed
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>
1 parent 5b08e90 commit 429915a

1 file changed

Lines changed: 123 additions & 0 deletions

File tree

‎doc/guides/technical-priorities.md‎

Lines changed: 123 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,123 @@
1+
# Technical Priorities
2+
3+
This list represents the current view of key technical priorities recognized
4+
by the project as important to ensure the ongoing success of Node.js.
5+
It is based on an understanding of the Node.js
6+
[constituencies](https://github.com/nodejs/next-10/blob/main/CONSTITUENCIES.md)
7+
and their [needs](https://github.com/nodejs/next-10/blob/main/CONSTITUENCY-NEEDS.md).
8+
9+
The 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)
12+
on August 5th 2021.
13+
14+
They will be updated regularly and will be reviewed by the next-10 team
15+
and the TSC on a 6-month basis.
16+
17+
## Modern HTTP
18+
19+
Base HTTP support is a key component of modern cloud-native applications
20+
and built-in support was part of what made Node.js a success in the first
21+
10 years. The current implementation is hard to support and a common
22+
source of vulnerabilities. We must work towards an
23+
implementation which is easier to support and makes it easier to integrate
24+
the new HTTP versions (HTTP3, QUIC) and to support efficient
25+
implementations of different versions concurrently.
26+
27+
## Suitable types for end-users
28+
29+
Using typings with JavaScript can allow a richer experience when using Visual
30+
Studio Code (or any other IDEs) environments, more complete documentation
31+
of APIs and the ability to identify and resolve errors earlier in the
32+
development process. These benefits are important to a large number of Node.js
33+
developers (maybe 50%). Further typing support may be important
34+
to enterprises that are considering expanding their preferred platforms to
35+
include Node.js. It is, therefore, important that the Node.js project work
36+
to ensure there are good typings available for the public Node.js APIs.
37+
38+
## Documentation
39+
40+
The current documentation is great for experienced developers or people
41+
who are aware of what they are looking for. On the other hand, for
42+
beginners this documentation can be quite hard to read and finding the
43+
desired information is difficult. We must have documentation
44+
that is suitable for beginners to continue the rapid growth in use.
45+
This documentation should include more concrete examples and a learning
46+
path for newcomers.
47+
48+
## WebAssembly
49+
50+
The use of WebAssembly has been growing over the last few years.
51+
To ensure Node.js continues to be part of solutions where a
52+
subset of the solution needs the performance that WebAssembly can
53+
deliver, Node.js must provide good support for running
54+
WebAssembly components along with the JavaScript that makes up the rest
55+
of the solution. This includes implementations of “host” APIs like WASI.
56+
57+
## ESM
58+
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.
64+
65+
## Support for features from the latest ECMAScript spec
66+
67+
JavaScript developers are a fast moving group and need/want support for new ES
68+
JavaScript features in a timely manner. Node.js must continue
69+
to provide support for up to date ES versions to remain the runtime
70+
of choice and to ensure its continued growth for the next 10 years.
71+
72+
## Observability
73+
74+
The ability to investigate and resolve problems that occur in applications
75+
running in production is crucial for organizations. Tools that allow
76+
people to observe the current and past operation of the application are
77+
needed to support that need. It is therefore important that the Node.js
78+
project work towards well understood and defined processes for observing
79+
the behavior of Node.js applications as well as ensuring there are well
80+
supported tools to implement those processes (logging, metrics and tracing).
81+
This includes support within the Node.js runtime itself (for example
82+
generating headumps, 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
85+
practices for those tools.
86+
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+
115+
## Single Executable Applications
116+
117+
Node.js often loses out to other runtimes/languages in cases where
118+
being able to package a single, executable application simplifies
119+
distribution and management of what needs to be delivered. While there are
120+
components/approaches for doing this, they need to be better
121+
documented and evangelized so that this is not seen as a barrier
122+
for using Node.js in these situations. This is important to support
123+
the expansion of where/when Node.js is used in building solutions.

0 commit comments

Comments
 (0)
Back | FazBrowse Home | New Git URL