Closed vvo closed 9 years ago
I should not that next-tick
is suffering from the same problem as process.nextTick here.
Now that next-tick
has fixed that issue, is it reasonable to put this back in?
Currently the nextTick
implementation relies on setTimeout(fn, 0)
.
This has significantly better compatibility then next-tick and intentionally has no deps so works without any sort of builder, it also works in some situations that next-tick doesn't yet such as when test runners stub out global methods we use and it handles multiple arguments being passed to nextTick (which next-tick hasn't been updated to handle).
I'd also point out that this only relies on setTimeout on the first call but not recursive calls so this implementation likely has much lower latency if you were to bench mark it.
Thanks! It's somewhat difficult to read so I appreciate this overview. I absolutely understand not wanting to introduce dependencies.
I ran into issues as well as #37 and #38 and was wondering if we should switch to https://github.com/medikoo/next-tick?
It's a dedicated next-tick project with clear goals (in term of what to use as nextTick).
Thoughts?