-
-
Notifications
You must be signed in to change notification settings - Fork 32k
feat: update technical priorities for 2023 #47523
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -14,8 +14,13 @@ 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. | ||
|
||
Version from the [mini-summit](https://github.com/nodejs/next-10/issues/1) | ||
on October 1st 2022. | ||
|
||
## Modern HTTP | ||
|
||
_Present in: 2021_ | ||
|
||
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 | ||
|
@@ -26,6 +31,8 @@ implementations of different versions concurrently. | |
|
||
## Suitable types for end-users | ||
|
||
_Present in: 2021_ | ||
|
||
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 | ||
|
@@ -37,6 +44,8 @@ to ensure there are good typings available for the public Node.js APIs. | |
|
||
## Documentation | ||
|
||
_Present in: 2021_ | ||
|
||
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 | ||
|
@@ -47,20 +56,24 @@ path for newcomers. | |
|
||
## WebAssembly | ||
|
||
_Present in: 2021_ | ||
|
||
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 | ||
## ES Modules (ESM) | ||
|
||
_Present in: 2021_ | ||
|
||
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. | ||
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 | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think we should leave this one in. Just because it was not in the current brainstorm does not mean it's still not important to the project. I believe this one will continue to be important almost forever :) |
||
|
||
|
@@ -71,6 +84,8 @@ of choice and to ensure its continued growth for the next 10 years. | |
|
||
## Observability | ||
|
||
_Present in: 2021_ | ||
aduh95 marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
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 | ||
|
@@ -80,24 +95,14 @@ 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 heap dumps, 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 | ||
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 | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This one seemed to be mentioned quite a bit in the Community survey so may be worth leaving in. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @sheplu I don't think this comment was addressed. Can you take another look. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. good catch ! |
||
|
||
_Present in: 2021_ | ||
aduh95 marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
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 | ||
|
@@ -121,3 +126,37 @@ 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. | ||
|
||
## Serverless | ||
|
||
Serverless is a cloud computing model where the cloud provider manages the | ||
underlyinginfrastructure and automatically allocates resources as | ||
needed. Developers only need to focus on writing code for specific | ||
functions, which are executed as individual units of work in response to | ||
events. Node.js is one of the main technology used by developers in | ||
this field therefore it is crucial for us to provide a great solution. | ||
|
||
## Small footprint | ||
|
||
Small software footprints refer to software that has a minimal impact on | ||
system resources such as memory and processing power. This can be achieved | ||
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 memory usage, and improved overall system | ||
performance. This is fundamental for Node.js to be a lightweight proposition | ||
inside the ecosystem as it is used across a wild variety of projects, from | ||
web application to IoT and serverless. | ||
|
||
## Developers-first DX | ||
mcollina marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
Developer experience (DX) refers to the overall experience a developer has when | ||
working with a software development platform, framework, or tool. It encompasses | ||
all aspects of the developer's interactions with the system, from installation | ||
and configuration to writing code and debugging. A good DX prioritizes ease | ||
of use, efficiency, and productivity, and can lead to faster development times, | ||
higher quality code, and greater developer satisfaction. Factors that can | ||
impact DX include documentation, community support, testing tools, | ||
and integration with other systems. | ||
As TypeScript usage continues to grow and gains more prominence in the | ||
ecosystem, enhancing its support is essential for delivering an improved | ||
developer experience for newcomers and experienced users alike. |
Uh oh!
There was an error while loading. Please reload this page.