Wish List from https://twitter.com/kamiyam/status/797283775566618624
The Specification for ES Modules is undergoing changes to allow it to interact with other Module systems (notable Node's CommonJS Module system). This problem is in part due to ES Modules being developed without researching how other module systems can interact with ES Modules. Until those changes land both in spec and VMs it will not be possible to fully implement ES Modules in a spec compliant way. In addition, Node is waiting on VMs to finish their implementation of ES Modules under the current spec to begin implementation and benchmarking. The earliest release that Node could ship ES Modules is Node version 10 (late 2017).
There is an effort to keep Node's core as minimal as possible, until QUIC gains usage levels near HTTP it is unlikely this will be in core. That said, there are userland modules that implement QUIC and can be used.
There is a PR for an Enhancement Proposal to Node's core working on this nodejs/node-eps#38 . Due to the differences in protocol workflow, the API for HTTP/2 might be vastly different from HTTP/1.
I don't have any thoughts on this, but there is an open issue. It doesn't look like there are any major things holding it up. Let bradley.meck@gmail.com know if you want help writing this up. A PR would give this much more traction, but the process will likely take a few months to land in core since it is a breaking change.
Due to debugging/workflow problems the PR nodejs/node#5020 for supporting this is stalled an unlikely to continue. In short the following 2 points are the main blockers:
- The Promise API causes problems with debugging core dumps
- Promises are single value containers and some APIs produce multiple values
This is under a flag in v7 and should land unflagged in v8.
Using async_hooks this is now possible. However, core is waiting on Promise support to officially endorse anything. Part of the reason this has taken so long is fine tuning performance in a way that userland libraries can use async_hooks without catastrophic performance loss.
Starting in Node version 7 a warning will be printed if a catch handler is not attached in the same tick that a Promise is rejected. In the future, expect unhandled Promise rejections to abort the process at the first safe moment (when they are ready to be GC'd).
@jasnell is working on adding Error Codes to all Errors emitted by Node.js. Having consistent Error Codes will allow error messages to change without resulting in a semver major break. Using these codes, more flexibility in messages should be allowed and even the possibility of translated messages is opened.
Gabe Isenberg from GoDaddy has interest in taking up the Null Propagation Operator. Look forward to this going through the standards process in the next year. Some details of the initial thoughts were summarized recently on es-discuss.
Do expressions are listed as stage 0 for TC39 currently they do not have a champion. There is much interest in the topic, but it looks like there is not enough interest currently from TC39 members to land it into the JS standard. Maybe this will happen in the next few years.
With both Flow and TypeScript working on different type systems for JS this is an interesting topic. TC39 reserved : in various grammar locations unofficially while watching userland implementations. The recent talks I have heard do not indicate that JS will get types anytime soon, in part due to a lack of so-called "value types" (opaque types that do not have typeof x === 'object').
They are stage 2 as of the last TC39 meeting, some outstanding issues remain before they go to stage 3. Be wary of using decorators since they could still land breaking changes to the proposal.
This would be fantastic, however after this being discussed several times on es-discuss I feel it won't land until types land T_T. Enums are complicated. The difficulty of making memory and speed remain quick with enums in current JS would be difficult, especially if enum constructors/properties/methods are allowed.
NVM has been proposed and is on track to land in the Node Foundation. This is being held up for a couple of reasons, in part the need for the TSC (Technical Steering Committee) to finalize it. https://github.com/nodejs/version-management is the place to watch the progress of this.
This is unlikely from the official installation, however it would be great if a custom distribution of Node did this.
More Visibility for people involved (like https://github.com/martinheidegger)
I agree. There needs to be a better place for people involved in the community to discuss things and be visible. In fact, I am trying to find a proper place to put this list in the Node Foundation right now! The new inclusivity working group that is taking over from the previous one might be the place to talk about this.
WASM also has a vested interest in this. Every time it has come up in the past, there have been problems landing it in core due to concerns about performance and debugging. I am not heavily involved in this, but it seems possible to land in core once the ABI stability work is finished. Once there is a stable ABI, it should be possible to write FFI code that can work on multiple versions of node in the same way. For now, I recommend looking at node-ffi.
This is mostly going to be taken care of by decorators, however, for private state the Private Fields proposal is going through TC39. Sometimes people ask why # as the syntax and not use private. The answer is covered in the README and linked documents in depth.
We did not get time to discuss this in Node Discussion at NodeFest T_T. For now, I would recommend sticking to Modules as your DI system for Node. Due to the nested structure of node_modules and the evaluation of classes you can do some very expressive things:
/my_http_lib
/myapp
-/node_modules/http_lib -> /my_http_lib # symlink
-/server.js
// server.js
const http_lib = require('http_lib');
class HTTPSLibrary extends http_lib {
// ...
}If you are looking for something like Angular's DI container, this is unlikely due to the need for Zones to implement try/catch on all async calls.
We are working on it! I would love to find someone to help @jasnell and @srloomis and @srl295 who is not a native English speaker. Part of this work relies on a need for TC39 to enhance Ecma262 with things like a proper unicode segmenter (@littledan is working on this) and a need for a user exposed API that is suitable for providing translation (no work currently being done on this [yet]).
True concurrent array operations are not possible with arbitrary code in JS due to side effects. SIMD should alleviate some of the problems with processing large TypedArrays. In the far future I hope that TC39 eventually is able to create a pure specifier for functions that would be safe to execute concurrently. Until that time, there has been some talk about making Workers part of the spec on es-discuss. I don't think Workers would land in the language anytime soon, but they would certainly support in-process and out of process workers due to the variance in how Browsers work.
Shared Array Buffers and Workers! There is a huge outstanding PR on Node for in-process workers. With SharedArrayBuffer coming, it should be possible to have shared memory both in-process and out of process. Hopefully this will allow for some significant speed up when doing parallel computation. An interesting note on this topic: react is avoiding preemption concurrency when creating react-fiber and so is Mozilla while working on their new engine for FireFox due to atomic locking slowing things down.
This is under discussion for a variety of reasons: yarn, ipfs, seif, and npm. I can't say much except that Node would love to find a better distribution mechanism for people looking for decentralized registries.
There are discussions about this based upon some companies wanting code-signing and access privileges per module.
Existing work:
@bmeck will be working on this once ES Modules are done, unless someone else picks it up first.
This is unlikely to occur since symlinks already provide this behavior. Using a tool like npm link or linklocal might suit your needs.
We didn't get enough time to discuss this. However, it would be great if Node got to ship benchmarking tools directly in the tools shipped by the default installation. For now, Node version 6 and above have --inspect which will let you use Chrome DevTools without needing something like node-inspector to take memory and CPU profiles for your application. Work is being done to improve this experience like integration with async_hooks.