it can be used instead of boilerplate main function
Why not use globalThis?
globalThis is a reference to a global variable, not some sort of code that is run when something is bootstrapped. Deno already aliases the global scope to both globalThis and window to make it easier to make transportable code.
One consideration would be how far we go in supporting some of the DOM events. While there might be code out there that uses window.onload, I think the more modern pattern for browser code would be something like:
window.addEventListener("load", (event) => {
/* ... */
});
If the intent is just to provide something that is more aligned to a browser, then just supporting window.onload would work, but to really make code more isomorphic, then we should consider support the DOM event listeners. We have some of the foundations there to do this, but lack a centralised event dispatch engine at the moment.
Maybe it's better to use globalThis rather then window.
globalThis.addEventListener( 'load', callback );
globalThis === window in Deno (for main thread code) and will always be that way (see #650).
@yuu2lee4 @Fenzland you can use globalThis if you prefer. As @kitsonk pointed out, globalThis and window point to the same object so everything that will work with window in Deno will also work with globalThis.
So you can do:
window.addEventListener('load', callback);
globalThis.addEventListener('load', callback);
const x = window; x.addEventListener('load', callback);
(a => a.addEventListener('load', callback))(globalThis);
Function('return this')().addEventListener('load', callback);
The way to get the global object is irrelevant but once you get it, it should support the 'load' event - this is the idea behind this issue. Personally I like window because it's most compatible with frontend code (as I explained before) but in your code you can use what you prefer.
I second the idea to stick to globalThis and globalThis only. ECMAScript offers a standard mechanism to access the global this now, and deno supports it (because its V8 supports it). There's an opportunity here to get rid of the now-redundant window in deno. (Of course, if portability is a goal then that's an argument in favor of keeping window, although that only really works if deno implements everything one could expect to be present on window in a web browser, which I don't think should be a goal.)
What about the corresponding window.onbeforeunload and window.onunload? Similar to process.on("beforeExit", ...) and process.on("exit", ...) in Node.
There is a problem with this feature at 0.17.0:
addEventListener( 'load', ()=>{ /* do something */ } );
It should be the same as:
globalThis.addEventListener( 'load', ()=>{ /* do something */ } );
But the call without globalThis or window throws that:
error: Uncaught TypeError: Cannot read property 'Symbol()' of undefined
â–º file:///home/travis/build/denoland/deno/js/event_target.ts:129:27
at addEventListener (file:///home/travis/build/denoland/deno/js/event_target.ts:129:27)
at file:///tmp/test.js:1:1
Most helpful comment
I second the idea to stick to
globalThisandglobalThisonly. ECMAScript offers a standard mechanism to access the globalthisnow, and deno supports it (because its V8 supports it). There's an opportunity here to get rid of the now-redundantwindowin deno. (Of course, if portability is a goal then that's an argument in favor of keepingwindow, although that only really works if deno implements everything one could expect to be present onwindowin a web browser, which I don't think should be a goal.)