globalThis shim

[bung87]

Can't assuming users using no-ie and node version >= 12.

[ringabout]

For reference:
globalThis could be used in most of browsers(91.23%) except IE.
https://caniuse.com/?search=globalThis

And globalThis is introduced to nodejs v11 which is not LTS version and V10 won't be maintained after 2021-04-30

https://nodejs.org/en/about/releases/

[bung87]

web developers dont want this tiny change breaking their code. company dont want lose their clients.

[Araq]

When would this not be true? You start with var globalThis;

[bung87]

var a; typeof a == "undefined";

[Araq]

Exactly, you just wrote if (true). I think in order to emulate globalThis you must not predeclare it at all.

[bung87]

a= 1; var a; typeof a == "undefined"; it's not like you think.

[bung87]

declare it here just note it as global variable, this line can be safely delete.

[ringabout]

Related docs about globalThis
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/globalThis
code from https://github.com/paulmillr/es6-shim/blob/master/es6-shim.js

  var getGlobal = function () {
    /* global self, window */
    // the only reliable means to get the global object is
    // `Function('return this')()`
    // However, this causes CSP violations in Chrome apps.
    if (typeof self !== 'undefined') { return self; }
    if (typeof window !== 'undefined') { return window; }
    if (typeof global !== 'undefined') { return global; }
    throw new Error('unable to locate global object');
  };

[metagn]

As far as I can tell, Nim only uses globalThis when generating {.global.} variables. I don't think this polyfill needs to be in every single Nim JS output. Why can't we have templates/macros/whatever that emit polyfills when people need them? Those Int*Array definitions are pretty jarring already, it's even worse that "hello world" is now above a kilobyte

[ringabout]

As far as I can tell, Nim only uses globalThis when generating {.global.} variables. I don't think this polyfill needs to be in every single Nim JS output. Why can't we have templates/macros/whatever that emit polyfills when people need them? Those Int*Array definitions are pretty jarring already.

Unfortunately, there is one or more variables labeled as threadsafe in system module(namely localRaiseHook_33557682). So globalThis will be shipped with Nim v1.6.0 (but I think it is acceptable). If people need old JS stuff, just stick with old Nim versions(for example Nim v 1.4 ). Since most of browsers and nodejs versions(and V10 won't be maintained after 2021-04-30), it may be unnecessary(increase a bit more code sizes).

[ringabout]

Unfortunately, there is one or more variables labeled as threadsafe in system module(namely localRaiseHook_33557682).

I will make a PR to undefine some stuff in JS backend(which is unnecessary for JS backend). Then I guess globalThis won't be shipped with the generated JS code.

Edited:
See PR #16070

[ringabout]

Those Int*Array definitions are pretty jarring already.

99.22% browsers support Typed Arrays, it's the time to remove them all.

https://caniuse.com/?search=Typed%20Arrays

I will make a PR, at least we could remove them eventually in the future.

[timotheecour]

we should instead have a module std/jspolyfills that can be optionally imported by users, instead of defining it in jsgen

there are more use cases of polyfills besides globalThis

links

• https://forum.nim-lang.org/t/7693
• std/jspolyfills timotheecour/Nim#509