5 ms·
One of the many things about Node that Dahl explicitly wanted to "fix"* when building Deno was that the global namespace should be `window`, because that's what
by favorited 5y ago
One of the many things about Node that Dahl explicitly wanted to "fix"* when building Deno was that the global namespace should be `window`, because that's what it is in JavaScript's natural habitat.
*scare-quotes because the reader might feel strongly opposed to the term, not because I have an agenda
- danbolt 5y ago> that the global namespace should be `window`, because that's what it is in JavaScript's natural habitat. Oh wow, I had no idea. That rules!
- afiori 5y agoecmascript now has both `globalThis` and `self` that can act as global namespace (they all point to the same object except in workers as window and globalThis cannot be used in workers)
- moron4hire 5y agoNo, `globalThis` is available in workers. It points to `self`. On the page, `globalThis` points to `window`. `globalThis` thus becomes the one, safe, global reference you can make for code that runs in both pages and workers.
- tshaddox 5y agoThat does seem like it will break a common pattern in web app code that runs both in browsers and on a server (such as a React app with server-side rendering) to determine whether you’re on the browser or the server, which is to check if typeof window === “undefined”.
- treyhuffine 5y agoA lot of the time that pattern is written, it's because the APIs from the web and Node are different and will break if you call something that's not isomorphic. Perhaps Deno fixes that as well and the pattern isn't needed in the first place. Obviously not every case though.
- deckard1 5y agoIn my experience, I've never seen that used just because the API is different. There are polyfills for fetch and other things, to align node and the browser. When I've seen that check, it's been entirely because the DOM API was needed. Or fetching was required on the client-side only.
- mediumdeviation 5y agoI'm surprised nobody else has called this out - implementing browser APIs in a non-browser runtime seems like a really bad idea. Take a look at https://developer.mozilla.org/en-US/docs/Web/API/Window https://developer.mozilla.org/en-US/docs/Web/API/Window - the submitted article seem to have demonstrated literally the only APIs that make sense to implement in a terminal. What would happen when a library tries to call window.location or window.history? Almost none of these map neatly to any possible implementation on the server or in a scripting environment.
- sjnu 5y agoDo you have a reasonable example of why a library that would call location or history? All I can think of is "using query string as getenv() for random debug hacks" or "using history as a hack to synchronously reach the structured clone algorithm", neither of which a library should do (but both easily emulatable).
- giaour 5y agowindow.location could be repurposed as a way to get or change the current working directory? Though the idiom of "window.location = <other path>" as a navigation mechanism would not really be portable. That said, there are other browser APIs that I would love to see available elsewhere: - window.crypto as an interface over libcrypto - window.localStorage and window.sessionStorage as an abstraction over temporary files and an in-memory key/value store, respectively - window.indexedDb for an in-runtime DB à la Erlang Term Storage or MUMPS - window.opener, window.parent, window.open(), window.postMessage() for inter-process communication There's a lot to work with here if you get creative.