7 ms·

One of the things I love about Deno is that since it implements standard web APIs, many libraries built for the browser just work. For example, I recently made

One of the things I love about Deno is that since it implements standard web APIs, many libraries built for the browser just work. For example, I recently made a simple static site generator with Deno to make my blog, and I found that I could use Marked for markdown support simply by importing it like this: import 'https://cdn.jsdelivr.net/npm/marked@3.0.7/marked.min.js'; // now I can use window.marked()

colejohnson66 5y ago
That just seems worse than what npm/yarn have. Despite Node's flaws, at least those have a hash check on the downloaded package against what's in the lock file. EDIT: I was wrong. See @spoiler's reply.
- spoiler 5y ago
  So does Deno: https://deno.land/manual/linking_to_external_code/integrity_checking https://deno.land/manual/linking_to_external_code/integrity_... It's not part of a package manager, because there isn't one, though.
  - colejohnson66 5y ago
    Ah. I stand corrected.
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 ago
    ecmascript 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 ago
      No, `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.
      - afiori 5y ago
        Thanks, I misunderstood this.
      - jahewson 5y ago
        ‘self’ works on pages too.
- tshaddox 5y ago
  That 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 ago
    A 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 ago
      In 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 ago
      I'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 ago
        Do 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).
galaxyLogic 5y ago
> import 'https://cdn.jsdelivr.net/npm/marked@3.0.7/marked.min.js https://cdn.jsdelivr.net/npm/marked@3.0.7/marked.min.js'; Doesn't this mean your code won't run if the website https://cdn.jsdelivr.net https://cdn.jsdelivr.net goes down? In Node.js you download modules you need, to a local folder under you dev-folder. So you can run and develop and test your code whether you have internet connection or not.
- int_19h 5y ago
  In Deno, you use vendoring. https://deno.land/manual@v1.20.1/tools/vendor.md https://deno.land/manual@v1.20.1/tools/vendor.md
  - nightski 5y ago
    Is this really a better workflow? I mean it works, but now you do not have a central list of all your external dependencies. Sure they recommend you just do all your imports in a single file and re-export them. But that sounds very tedious and at the end of the day to what advantage? I'm really struggling to see it.
    - zarzavat 5y ago
      It seems like a feature that would be better implemented at the IDE/editor level. Paste in a URL and it asks you if you want to add it to package management.
    - binarynate 5y ago
      For scripts, it's pretty sweet to be able to import dependencies directly via URL without needing to do an `npm init` and `npm install`. For larger projects (like my static site generator), I didn't find it tedious to import from a central deps.ts file, although I admit that importing from a relative path like '../../deps.ts' is not as quite as nice as importing by package name like in Node. I'm OK with that the tradeoff, though, especially since it matches the way imports work in the browser.

colejohnson66 5y ago

That just seems worse than what npm/yarn have. Despite Node's flaws, at least those have a hash check on the downloaded package against what's in the lock file. EDIT: I was wrong. See @spoiler's reply.

spoiler 5y ago
So does Deno: https://deno.land/manual/linking_to_external_code/integrity_checking https://deno.land/manual/linking_to_external_code/integrity_... It's not part of a package manager, because there isn't one, though.
- colejohnson66 5y ago
  Ah. I stand corrected.

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 ago
  ecmascript 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 ago
    No, `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.
    - afiori 5y ago
      Thanks, I misunderstood this.
    - jahewson 5y ago
      ‘self’ works on pages too.
tshaddox 5y ago
That 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 ago
  A 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 ago
    In 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 ago
    I'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 ago
      Do 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).

galaxyLogic 5y ago

> import 'https://cdn.jsdelivr.net/npm/marked@3.0.7/marked.min.js https://cdn.jsdelivr.net/npm/marked@3.0.7/marked.min.js'; Doesn't this mean your code won't run if the website https://cdn.jsdelivr.net https://cdn.jsdelivr.net goes down? In Node.js you download modules you need, to a local folder under you dev-folder. So you can run and develop and test your code whether you have internet connection or not.

int_19h 5y ago
In Deno, you use vendoring. https://deno.land/manual@v1.20.1/tools/vendor.md https://deno.land/manual@v1.20.1/tools/vendor.md
- nightski 5y ago
  Is this really a better workflow? I mean it works, but now you do not have a central list of all your external dependencies. Sure they recommend you just do all your imports in a single file and re-export them. But that sounds very tedious and at the end of the day to what advantage? I'm really struggling to see it.
  - zarzavat 5y ago
    It seems like a feature that would be better implemented at the IDE/editor level. Paste in a URL and it asks you if you want to add it to package management.
  - binarynate 5y ago
    For scripts, it's pretty sweet to be able to import dependencies directly via URL without needing to do an `npm init` and `npm install`. For larger projects (like my static site generator), I didn't find it tedious to import from a central deps.ts file, although I admit that importing from a relative path like '../../deps.ts' is not as quite as nice as importing by package name like in Node. I'm OK with that the tradeoff, though, especially since it matches the way imports work in the browser.