Closed icoderMonkey closed 2 months ago
You can test that yourself in any REPL. A delay of 0 milliseconds just pushes the callback into the next call stack of the event loop without additional delay. The setImmediate function does the same thing without any delay specified.
https://developer.mozilla.org/en-US/docs/Web/API/Window/setImmediate
If after testing one of those methods is always faster than the other there is some performance consideration happening in V8. I would suggest testing these scenarios in a micro benchmark. These methods are common to both the browser and Node as they come from the language run time, V8 so you can even test this in your browser. I like https://jsbench.github.io/ for micro benchmarks.
You can test that yourself in any REPL. A delay of 0 milliseconds just pushes the callback into the next call stack of the event loop without additional delay. The setImmediate function does the same thing without any delay specified.
https://developer.mozilla.org/en-US/docs/Web/API/Window/setImmediate
If after testing one of those methods is always faster than the other there is some performance consideration happening in V8. I would suggest testing these scenarios in a micro benchmark. These methods are common to both the browser and Node as they come from the language run time, V8 so you can even test this in your browser. I like https://jsbench.github.io/ for micro benchmarks.
Without setting anything, as the website says, you can set the type in package.json to module after npm init -y and then execute the above code several times to see the specific print
It seems there has been no activity on this issue for a while, and it is being closed in 30 days. If you believe this issue should remain open, please leave a comment. If you need further assistance or have questions, you can also search for similar issues on Stack Overflow. Make sure to look at the README file for the most updated links.
It seems there has been no activity on this issue for a while, and it is being closed. If you believe this issue should remain open, please leave a comment. If you need further assistance or have questions, you can also search for similar issues on Stack Overflow. Make sure to look at the README file for the most updated links.
Version
18.16.1
Platform
Darwin xxxMacBook-Pro.local 21.5.0 Darwin Kernel Version 21.5.0: Tue Apr 26 21:08:22 PDT 2022; root:xnu-8020.121.3~4/RELEASE_X86_64 x86_64
Subsystem
No response
What steps will reproduce the bug?
Create a new index.js and write the following code, using npm init -y, to run it using commonJs (default) and esModule (type = "module") respectively
How often does it reproduce? Is there a required condition?
No response
What is the expected behavior? Why is that the expected behavior?
No response
What do you see instead?
In the current version of the environment, I created index.js and said, if it's in commonJs Modularity, that's what it says on the official website, but in the esmodule modularity specification, setImmediate is always done first, which is new feature, or bug, If instead of writing both in the I/O callback, can I determine that setImmediate under esModule has higher priority
Additional information
No response