Simplify globals (tech debt)

[bartlomieju]

Currently Deno maintains two sets of globals - one set is “Web native”, available to user code, the other is “Node native” and available to npm dependencies.

This leads to several problems:

• the setup is very complex and requires non-trivial solution at the V8 level
• the performance is absolutely horrible - on each access of a global a stack trace gets collected (most often only a single frame) to determine which global should be used - this causes huge overhead, eg. using performance.now() in a tight loop causes lookup of the global to take more time then actually benchmarked code
• it’s a mental overhead to figure out which global is gonna get used depending on the code location

Currently the list is as follows:

• Buffer (npm, feat: make 'Buffer' and 'global' available as globals #29416)
• clearImmediate (npm, feat: make setImmediate and clearImmediate as globals #29877)
• clearInterval (both, but different implementation)
• clearTimeout (both, but different implementation)
• global (npm, feat: make 'Buffer' and 'global' available as globals #29416)
• performance (both user and npm, but different implementation, feat: use a single 'performance' global #29323)
• process (the availability in Deno depends on project creation time in Deno Deploy)
• setImmediate (npm, feat: make setImmediate and clearImmediate as globals #29877)
• setInterval (both, but different implementation)
• setTimeout (both, but different implementation)
• self (Deno, fix in fix: remove self from global middleware #29734)
• WorkerGlobalScope (Deno, fix in fix: remove WorkerGlobalScope from global middleware #29543)

There are some easy solution here:

• make Buffer, clearImmediate, global, setImmediate always available to all code
• merge performance global to only use “Node” version (which has additional properties compared to the Web one)
• make clearInterval and clearTimeout work with both Web (number) and Node (object) timeouts

And there are hard problems related to setTimeout and setInterval APIs that changing them will lead to a huge breaking change, while leaving them as is will maintain the complexity.

• Priority: 4
• Technical complexity: 5

[dojyorin]

I understand that there is still demand for Node in the world, but I am worried that the simplicity of web standards that we have gained with Deno will be lost "again."
I like the simplicity of Deno now.

[bartlomieju]

@dojyorin can you please expand on it? As it stands having two different sets of globals depending what kind of code (user code or dependency code from npm) is an exact opposite of "simplicity".

[dojyorin]

@bartlomieju
Sorry, that wasn't clear enough.

I'll speak from the perspective of a Deno user.

Currently, almost only web-standard objects exist in the global space, and all non-standard objects are grouped in the Deno namespace.

In this way, having a clear separation between the locations web standards and non-standard objects is what I consider to be "simplicity," and I like this separation.

And when I say "worried about losing simplicity," I mean that non-standard objects will be proliferated in the global space, and the meaning of grouping non-standard objects in the Deno namespace will be diluted.

On the other hand, from the perspective of Deno internal, I can understand that having to branch the context every time would certainly be a burden.

I think this is a difficult problem.

[KnorpelSenf]

I agree with @dojyorin.

Web standards are one of the big reasons for Deno. A number of people I know already did not like the whole npm compatibility story, but it has so far been isolated to the compatibility layer, so I was fine with it. Today, when you use Deno, you can still essentially ignore that npm and Node exist and live in a—forgive me my wording—pure world.

Only when you really need an npm package, you can't rewrite it, there's nothing in std or on JSR, only then you need to use an npm: or a node: import. Those not only serve as a way to make things compatible, they also isolate the legacy world to those imports only. Everything that happens in my own code is sort of free from the npm stuff.

So by merging the globals between both worlds, this barrier is broken down and the Node things spill over into the very place that was kept free of the weird things like Buffer etc.

But then again, the above paragraphs are using the product vision argument and that is a bit ideological. I completely understand that maintaining all the complexity is a problem and nobody likes slow code anyway. Soooo while I really wish this issue was not necessary, it's hard to argue with reality.