why not medikoo/next-tick?

[vvo]

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?

[vvo]

I should not that next-tick is suffering from the same problem as process.nextTick here.

medikoo/next-tick#3

[STRML]

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).

[calvinmetcalf]

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.

[STRML]

Thanks! It's somewhat difficult to read so I appreciate this overview. I absolutely understand not wanting to introduce dependencies.