8 ms·

A lot of people seem to think the difference between Deno and Node is trivial, but having actually used Deno, I think they're wrong. Here's why: - Typescript

A lot of people seem to think the difference between Deno and Node is trivial, but having actually used Deno, I think they're wrong. Here's why: - Typescript as a first class citizen - An actual `window` global with familiar browser APIs - Sandboxing w/ permissions - URL-based imports (no need for NPM) - Bundling into self-contained binaries - Things like top-level-await which Node.js still treats as experimental. - Better-designed APIs than the Node standard lib (esp. when it comes to promises instead of callbacks) To me, those aren't just minor details. This has the potential to create a new epoch in server-size JavaScript.

ivan888 6y ago
> URL-based imports (no need for NPM) What happens when there is the next Codehaus-like shutdown, and so much source code just won't work? Or when a bad actor takes control of a domain that commonly hosted packages (perhaps through completely legitimate means, such as registration expiration), can get a completely legitimate SSL certificate for it, and responds to requests for packages with malicious code? I think the abstraction, and to some degree the centralization, of package management is generally a good thing
- pknopf 6y ago
  There will likely be some kind of npm at some point.
  - jhgb 6y ago
    If the goal is to get rid of NPM, why would you add another one in the future?
    - afiori 6y ago
      The goal is not to eliminate npm, but to decouple it from the runtime itself
  - forty 6y ago
    Yes, i think recreating an npm kind of central place for your project dependencies seems almost required if you want to avoid depending on a different version of a lib in each file of your project. I cannot understand the benefit of this scheme honestly. I would have preferred they fix something npm is lacking, like adding the ability to sign packages
- searchableguy 6y ago
  deno has a lock file like other package managers. If you use a lock file, deno will refuse to run if the file has been modified. Deno caches everything offline and only reloads if you use --reload flag. I would recommend going through the manual to learn more about deno workflow. https://deno.land/manual https://deno.land/manual
- jansommer 6y ago
  "Deno can store and check subresource integrity for modules using a small JSON file." - https://deno.land/manual/linking_to_external_code/integrity_checking https://deno.land/manual/linking_to_external_code/integrity_...
  - ivan888 6y ago
    Unfortunately this won't help those who add dependencies based on shared snippets, without the context of a project. Or the innocent mistake (or choice?) of not checking the lock file into version control. But yes good point, existing projects that have checked in the integrity file will be safe against future malicious modifications of the resource
    - searchableguy 6y ago
      > Unfortunately this won't help those who add dependencies based on shared snippets, without the context of a project Could you expand on this? Any examples would be appreciated.
      - ivan888 6y ago
        Code examples abound on Stack Overflow, GitHub Gist, blog posts, etc. These may contain direct URL dependencies. Example guiding users to include a Maven dependency: https://www.baeldung.com/guava-mapmaker#map-maker https://www.baeldung.com/guava-mapmaker#map-maker There is some degree of assurance that this dependency won't last long in the Maven central repo, or any other user configured repository, if it contained malicious code. Obviously it is not foolproof and incidents happen, but without a centralized authority for package management, there is much less assurance that a package is not malicious
        searchableguy 6y ago
        I find your concern valid. Deno makes it easy to import from temporary places. However, this wouldn't be solved by having a centralized registry or a package manager like npm. Npm can install from git repos and registries other than npmjs. Having a package on npm by its own doesn't make it any less malicious. A solution would be to enforce registries you can import from and fail if it's outside that.
- sod 6y ago
  Answered in https://deno.land/manual@v1.8.2/linking_to_external_code#but-what-if-the-host-of-the-url-goes-down-the-source-won#39t-be-available https://deno.land/manual@v1.8.2/linking_to_external_code#but... Also: Nobody prevents you from using a package manager anyway. Just because you can use urls in imports doesn't mean you have to. But it is very convenient that deno downloads exactly the code that is imported. A package manager will always just throw everything at you. Some packages in node.js try to fix this by splitting the project into submodules like @babel/core, @babel/env, .... But that made installing dependencies worse. Just let deno figure out what is required is way more elegant IMO.
  - nawgz 6y ago
    Not sure I understand, are you implying Deno does automatic tree-shaking on package imports? If not, how does "deno download exactly the code that is imported" and not just a whole package? Also, from your link: "In Node this is done by checking node_modules into source control. In Deno this is done by pointing $DENO_DIR to some project-local directory at runtime, and similarly checking that into source control:" I disagree with this. In my opinion, this is done by using a pull-through cache that caches every package developers request and so inherently has a cache of the packages that will go to production. Is it possible to do this in deno today? I don't really get that sense.
    - WorldMaker 6y ago
      > Not sure I understand, are you implying Deno does automatic tree-shaking on package imports? If not, how does "deno download exactly the code that is imported" and not just a whole package? npm install copies in to your node_modules an entire zip/tarball package. Deno uses ES2015+ module syntax and it's only going to grab the JS files that are imported (or imported by imports). So it "naturally" tree shakes at the file level, and doesn't have a concept of a "package" in the same way. It's not directly going to tree shake inside of single file boundaries in the way that a major bundler/packager might (though the V8 JIT should still sort of indirectly compensate). So yeah, if the package is published as just a single (M)JS file it will still get entirely downloaded by Deno, but if the modules are split across multiple files, Deno will only download the ones that are directly or indirectly imported (and will have no idea of the remainder of the files in the "package"). > I disagree with this. In my opinion, this is done by using a pull-through cache that caches every package developers request and so inherently has a cache of the packages that will go to production. > Is it possible to do this in deno today? I don't really get that sense. Yes, because URLs are just URLs, you could always have a Proxy service running at a URL that knows how to request the packages from upstream. https://jsproxy.mydomain.example.com/lodash/v1.1/module.js https://jsproxy.mydomain.example.com/lodash/v1.1/module.js could be simple caching proxy that knows how to get lodash from upstream if it doesn't have the requested version cached (or sends a 404 error if it isn't allowed to cache a specific version or whatever).
- goodoldneon 6y ago
  URL-based imports aren't less secure. They just make an existing attack vector more obvious. Is NPM really keeping you safe? What happens if a package maintainer is compromised and the attacker adds malicious code? The fact that URL-based imports make you uncomfortable is good. Let that discomfort guide you to adopt some extra security measures to protect yourself from third-party dependency exploits
  - Normal_gaussian 6y ago
    a note for many: yarn v2 provides '0-config' fully cachable dependencies (zips in lfs). This makes it possible to fully vet dependencies and enforce change approval and analysis in CI/CD.
    - mkranjec 6y ago
      Exactly. Not to mention installs being insanely fast.
    - gervwyk 6y ago
      I must chime in here. Yarn 2 is a fantastic experience!
    - xrd 6y ago
      I didn't know about that regarding yarn 2. Is there a good link to read about this? I did a search for yarn 2 and didn't find that immediately.
      - Normal_gaussian 6y ago
        https://yarnpkg.com/ https://yarnpkg.com/ They don't do a great job of advertising the changes; take a look under features/zero-installs. The common practice is to still use yarnv1 as your global yarn, just do "yarn set version berry" inside your project to use v2. 0-config can be a breaking change - though I haven't had problems in a long time.
  - ivan888 6y ago
    I would argue that NPM and other centralized package managers have the ability to add security: if npm made 2FA a requirement (or publicized the status of a package maintainer having 2FA enabled like GitHub does, which is perhaps a security concern itself), there would be some assurance that a maintainer is not compromised. If we are using URL-based imports, the scope of security assurances are much broader: an SSL certificate doesn't say anything about whether the current owner of a domain was the owner at the time of a dependency being safe. There is no one authority who we can expect to take swift (or even slow) action to remove malicious packages from being available on the myriad hosting protocols that are accessible through an environment like Deno
Already__Taken 6y ago
I was just looking for git tooling and found a few node base projects with npm-install instructions. I thought deno is going to eat these things up for teams. We don't want C++ devs to need a node tool-chain for one tool.
ericlewis 6y ago
- AFAIK - it still compiles into normal JS nor does the TS team work on deno (hope I am wrong) so it's not really FCC as most would think - this doesn't make sense, its bad API design and shoe horning in a completely different paradigm is not a good idea, it should have moved somewhere less familiar and more oriented to the environment (I know that sounds weird but giving a quick answer, there are better solutions and this aint a browser) - not bad, but seems odd to me as a language feature in some ways, there are plenty of ways to achieve this. (macOS will do this to your node scripts even itself, why do we need more of it) - this is subject to the same problems NPM could have, but I guess it is easier? Now you have to lexically parse all files to determine an import and you also have to remember where you keep your 3rd party packages without a centralized way to know it (edit: this seems to harm the previous point) - bundling isn't that interesting in this context as it just bundles the whole runtime with the package, which is terrible for size of packages and doesn't net a lot of benefit since they are also now tied together - if there is a security flaw you now must fix the entire binary and hopefully it still compiles. (edit: technically swift did this a long time too... but they also were reasonably sure they could include their runtime with the OS itself once ABI was stable, I am not sure if Deno has a path for this or if we just get fat binaries forever) - top level await is a weird one to me, there are valid reasons its not in node currently. but yeah- no one likes having to write janky init code to work around this final edit: I have a lot of opinions on this and would love to learn more about why deno is great. from what I can tell, its just a faster language of js which, imo, is great. But the points drawn from GP are just bizarre to me.
- seer 6y ago
  While I also think url based imports are a weird idea, it might just stem from the fact that I haven’t used it much, it might be wonderful, who knows. But what I’d like to question is why the idea of parsing everything is considered bad. Semver itself, while miles ahead of what came before, is still just lies we tell the compiler. You can never actually rely on the fact that a miner fix will not be a breaking change and the like. Rich Hicky had a great talk on the subject of imports and breakage, and the conclusion that I agree with was to actually load and check every function in all the libraries you use, so that if there is an incompatible change you will not be none the wiser. I’m glad people are trying to experiment here, as package management is far from a solved problem and issues with it cause sweat, tears and blood to most devs during their careers.
hombre_fatal 6y ago
Those still are all trivial in the "too little too late" sense. URL-based imports are already something you can do in package.json if you really thought that was great. Top-level await really is trivial. The permissions system does very little for you since they are process-level permissions when I'm scared of transitive dep attacks. Typescript in Node is good and Deno has to catch up in tooling. If Deno was where it is today but like 8 years ago, it would have made a splash. Now it just looks like someone made a few creature comforts to Node.
- ericlewis 6y ago
  top-level await isn't really trivial implementation or action wise. But as a feature it seems obvious until you step into all the edge cases it can create.
  - hombre_fatal 6y ago
    It's cute for scripts. Otherwise there's the trivial top-level wrapper runProgram.catch(console.error) entry point. It's just not a detail that does much to sell Deno. Though I admit it's not that fun for me to come in here to poopoo Deno.
    - ericlewis 6y ago
      I am not trying to do that either - I think the work they're doing is great and important, but the reasons listed above ain't it.
  - ravenstine 6y ago
    Care to share some examples of said edge cases? I write a lot of short JS files that aren't part of a big cohesive backend, and little things like top-level await make the code somewhat easier to read. Yes, you can just do an async IIFE, but that's just another thing for the eye to parse and feels quite vestigial. EDIT: And since I can't respond to your other comment, I'll ask this here; what do you consider great and important about Deno that doesn't fall under the bullet-points I listed? I'm simply curious.
schnable 6y ago
> An actual `window` global with familiar browser APIs This doesn't seem good?
- ericlewis 6y ago
  it's not. actually I would argue any sort of global state like this should go away.
  - ravenstine 6y ago
    Well, okay, but it's pretty much here to stay and doesn't have that great of a drawback that it's worth breaking any cross-compatible code that currently exists. If there is going to be a global object, then it might as well be the same one used in the browser, which everyone who writes JS is familiar with.
  - kinjba11 6y ago
    I agree with the spirit of what you're saying, but there billions of lines of JavaScript code that can't "just go away". Being able to use e.g. 'window.crypto' without worrying about whether I'm in Node, Deno, some other runtime or a browser is great news for reusing huge amounts of code.
    - cpcallen 6y ago
      I'm in favour of compatibility and against a global named 'window' in a non-browser JS implementation, and I don't understand why the former necessitates the latter. Since window is the global object, why not just refer to crypto? Then you don't care what the global object is named.
      - afiori 6y ago
        It is relevant to this that ecmascript specifies `globalThis` as the global object (the one pointed by this outside of functions in non-strict mode), all js environments have it and simiply globalThis === window || globalThis === global
hctaw 6y ago
My personal view is that syntactic debate over imports (including whether it's in an import/require/url/package.json/whatever) are basically meaningless except for surface level debate. How "nice" it is to write imports is pretty worthless to me. The structural and semantic differences between imports are a much more important discussion. Import syntax is the front end to the languages meta programming semantics. It's meta programming in the sense that your code and other code is the data, but what you're really programming is a task runner with specific instructions about how to find and satisfy the requirements to build and/or run the software. Integrating package resolution into the language itself is a really important distinction for contemporary designs - passing that buck to external tools but simultaneously coupling them to the runtime is a mistake that I think we should learn from. Deno is a good step in that direction.
LunaSea 6y ago
Highly disagree on the impact of those points. > - Typescript as a first class citizen This doesn't seem to add much besides having to install `tsc` or `ts-node` and also not having the choice of the TypeScript compiler version you use. - An actual `window` global with familiar browser APIs Node.js has a `global` global object and the only API I would understand having in common with the `window` object is the `fetch()` API. - Sandboxing w/ permissions Sandboxing is so basic that any large project will have to enable all permissions. - URL-based imports (no need for NPM) I would consider this a disadvantage. - Bundling into self-contained binaries Again, I would say that this is rarely useful in a world where a lot of operations use container technology. - Things like top-level-await which Node.js still treats as experimental. This is trivially solved by anonymous self-executing functions - Better-designed APIs than the Node standard lib (esp. when it comes to promises instead of callbacks) I think that this is the strongest advantage, however I would argue that this is not a reason to start a completely new backend platform. Also, I think that it might be a disadvantage in some high performance scenarios because Promises are much, much slower than callbacks currently.
- ravenstine 6y ago
  > This doesn't seem to add much besides having to install `tsc` or `ts-node` and also not having the choice of the TypeScript compiler version you use. Depends on your point of view. With TypeScript being built in, you don't have to think about using tsc or whatever version of TypeScript you have. It's just what version of Deno you use. If someone doesn't like that, then they still can have the option of using TypeScript by itself. > Node.js has a `global` global object and the only API I would understand having in common with the `window` object is the `fetch()` API. It also supports `addEventListener`, which is commonly used by browser code on the window object. Just the existence of something defined as `window` makes more sense than a `global` which never existed in browsers in the first place. > Sandboxing is so basic that any large project will have to enable all permissions. That's pretty dismissive. Why should an app that doesn't interact with the file system be allowed to write or even read from it? I don't know how this feature can be considered a drawback. Don't like it? Don't use it. I don't see how it detracts objectively from Deno. > I would consider this a disadvantage. Then you can still use NPM. Others of us get the option to just import packages from a URL instead of publishing it to a central repository. > Again, I would say that this is rarely useful in a world where a lot of operations use container technology. Why? Building Docker images requires extra software, Linux images, time spent running apt-get or apk, time spent downloading and installing your runtime of choice, and so forth. Having Deno build a binary can give you a bit of a shortcut in that you have one tool for running and bundling code, and you don't need to deal with as many OS-level nuances to do so. Docker and k8s are there for anyone who needs something beyond that. > This is trivially solved by anonymous self-executing functions That's your opinion. Just promise me you don't go on to say that JS is a bad language, because people keep saying that yet are opposed to reducing complexity they consider "trivial". If using IIFE for the mere purpose of accessing syntax makes more sense to you than making `await` syntax available, then I really don't know what to tell you. What exactly is the argument for not implementing this feature besides "all you have to do is type some extra characters", to loosely paraphrase you. > I think that this is the strongest advantage, however I would argue that this is not a reason to start a completely new backend platform. Also, I think that it might be a disadvantage in some high performance scenarios because Promises are much, much slower than callbacks currently. > I think that this is the strongest advantage, however I would argue that this is not a reason to start a completely new backend platform. Also, I think that it might be a disadvantage in some high performance scenarios because Promises are much, much slower than callbacks currently. I honestly have to wonder if you are joking. This is exactly why people invent new backends, new libraries, and new languages. My only response to your point about Promises is that perhaps one shouldn't be using JavaScript if Promises are that much of a bottleneck. What you're saying is totally valid, though.
dmux 6y ago
First class in all but its REPL.

ivan888 6y ago

> URL-based imports (no need for NPM) What happens when there is the next Codehaus-like shutdown, and so much source code just won't work? Or when a bad actor takes control of a domain that commonly hosted packages (perhaps through completely legitimate means, such as registration expiration), can get a completely legitimate SSL certificate for it, and responds to requests for packages with malicious code? I think the abstraction, and to some degree the centralization, of package management is generally a good thing

pknopf 6y ago
There will likely be some kind of npm at some point.
- jhgb 6y ago
  If the goal is to get rid of NPM, why would you add another one in the future?
  - afiori 6y ago
    The goal is not to eliminate npm, but to decouple it from the runtime itself
- forty 6y ago
  Yes, i think recreating an npm kind of central place for your project dependencies seems almost required if you want to avoid depending on a different version of a lib in each file of your project. I cannot understand the benefit of this scheme honestly. I would have preferred they fix something npm is lacking, like adding the ability to sign packages
searchableguy 6y ago
deno has a lock file like other package managers. If you use a lock file, deno will refuse to run if the file has been modified. Deno caches everything offline and only reloads if you use --reload flag. I would recommend going through the manual to learn more about deno workflow. https://deno.land/manual https://deno.land/manual
jansommer 6y ago
"Deno can store and check subresource integrity for modules using a small JSON file." - https://deno.land/manual/linking_to_external_code/integrity_checking https://deno.land/manual/linking_to_external_code/integrity_...
- ivan888 6y ago
  Unfortunately this won't help those who add dependencies based on shared snippets, without the context of a project. Or the innocent mistake (or choice?) of not checking the lock file into version control. But yes good point, existing projects that have checked in the integrity file will be safe against future malicious modifications of the resource
  - searchableguy 6y ago
    > Unfortunately this won't help those who add dependencies based on shared snippets, without the context of a project Could you expand on this? Any examples would be appreciated.
    - ivan888 6y ago
      Code examples abound on Stack Overflow, GitHub Gist, blog posts, etc. These may contain direct URL dependencies. Example guiding users to include a Maven dependency: https://www.baeldung.com/guava-mapmaker#map-maker https://www.baeldung.com/guava-mapmaker#map-maker There is some degree of assurance that this dependency won't last long in the Maven central repo, or any other user configured repository, if it contained malicious code. Obviously it is not foolproof and incidents happen, but without a centralized authority for package management, there is much less assurance that a package is not malicious
      - searchableguy 6y ago
        I find your concern valid. Deno makes it easy to import from temporary places. However, this wouldn't be solved by having a centralized registry or a package manager like npm. Npm can install from git repos and registries other than npmjs. Having a package on npm by its own doesn't make it any less malicious. A solution would be to enforce registries you can import from and fail if it's outside that.
sod 6y ago
Answered in https://deno.land/manual@v1.8.2/linking_to_external_code#but-what-if-the-host-of-the-url-goes-down-the-source-won#39t-be-available https://deno.land/manual@v1.8.2/linking_to_external_code#but... Also: Nobody prevents you from using a package manager anyway. Just because you can use urls in imports doesn't mean you have to. But it is very convenient that deno downloads exactly the code that is imported. A package manager will always just throw everything at you. Some packages in node.js try to fix this by splitting the project into submodules like @babel/core, @babel/env, .... But that made installing dependencies worse. Just let deno figure out what is required is way more elegant IMO.
- nawgz 6y ago
  Not sure I understand, are you implying Deno does automatic tree-shaking on package imports? If not, how does "deno download exactly the code that is imported" and not just a whole package? Also, from your link: "In Node this is done by checking node_modules into source control. In Deno this is done by pointing $DENO_DIR to some project-local directory at runtime, and similarly checking that into source control:" I disagree with this. In my opinion, this is done by using a pull-through cache that caches every package developers request and so inherently has a cache of the packages that will go to production. Is it possible to do this in deno today? I don't really get that sense.
  - WorldMaker 6y ago
    > Not sure I understand, are you implying Deno does automatic tree-shaking on package imports? If not, how does "deno download exactly the code that is imported" and not just a whole package? npm install copies in to your node_modules an entire zip/tarball package. Deno uses ES2015+ module syntax and it's only going to grab the JS files that are imported (or imported by imports). So it "naturally" tree shakes at the file level, and doesn't have a concept of a "package" in the same way. It's not directly going to tree shake inside of single file boundaries in the way that a major bundler/packager might (though the V8 JIT should still sort of indirectly compensate). So yeah, if the package is published as just a single (M)JS file it will still get entirely downloaded by Deno, but if the modules are split across multiple files, Deno will only download the ones that are directly or indirectly imported (and will have no idea of the remainder of the files in the "package"). > I disagree with this. In my opinion, this is done by using a pull-through cache that caches every package developers request and so inherently has a cache of the packages that will go to production. > Is it possible to do this in deno today? I don't really get that sense. Yes, because URLs are just URLs, you could always have a Proxy service running at a URL that knows how to request the packages from upstream. https://jsproxy.mydomain.example.com/lodash/v1.1/module.js https://jsproxy.mydomain.example.com/lodash/v1.1/module.js could be simple caching proxy that knows how to get lodash from upstream if it doesn't have the requested version cached (or sends a 404 error if it isn't allowed to cache a specific version or whatever).
goodoldneon 6y ago
URL-based imports aren't less secure. They just make an existing attack vector more obvious. Is NPM really keeping you safe? What happens if a package maintainer is compromised and the attacker adds malicious code? The fact that URL-based imports make you uncomfortable is good. Let that discomfort guide you to adopt some extra security measures to protect yourself from third-party dependency exploits
- Normal_gaussian 6y ago
  a note for many: yarn v2 provides '0-config' fully cachable dependencies (zips in lfs). This makes it possible to fully vet dependencies and enforce change approval and analysis in CI/CD.
  - mkranjec 6y ago
    Exactly. Not to mention installs being insanely fast.
  - gervwyk 6y ago
    I must chime in here. Yarn 2 is a fantastic experience!
  - xrd 6y ago
    I didn't know about that regarding yarn 2. Is there a good link to read about this? I did a search for yarn 2 and didn't find that immediately.
    - Normal_gaussian 6y ago
      https://yarnpkg.com/ https://yarnpkg.com/ They don't do a great job of advertising the changes; take a look under features/zero-installs. The common practice is to still use yarnv1 as your global yarn, just do "yarn set version berry" inside your project to use v2. 0-config can be a breaking change - though I haven't had problems in a long time.
- ivan888 6y ago
  I would argue that NPM and other centralized package managers have the ability to add security: if npm made 2FA a requirement (or publicized the status of a package maintainer having 2FA enabled like GitHub does, which is perhaps a security concern itself), there would be some assurance that a maintainer is not compromised. If we are using URL-based imports, the scope of security assurances are much broader: an SSL certificate doesn't say anything about whether the current owner of a domain was the owner at the time of a dependency being safe. There is no one authority who we can expect to take swift (or even slow) action to remove malicious packages from being available on the myriad hosting protocols that are accessible through an environment like Deno

Already__Taken 6y ago

I was just looking for git tooling and found a few node base projects with npm-install instructions. I thought deno is going to eat these things up for teams. We don't want C++ devs to need a node tool-chain for one tool.

ericlewis 6y ago

- AFAIK - it still compiles into normal JS nor does the TS team work on deno (hope I am wrong) so it's not really FCC as most would think - this doesn't make sense, its bad API design and shoe horning in a completely different paradigm is not a good idea, it should have moved somewhere less familiar and more oriented to the environment (I know that sounds weird but giving a quick answer, there are better solutions and this aint a browser) - not bad, but seems odd to me as a language feature in some ways, there are plenty of ways to achieve this. (macOS will do this to your node scripts even itself, why do we need more of it) - this is subject to the same problems NPM could have, but I guess it is easier? Now you have to lexically parse all files to determine an import and you also have to remember where you keep your 3rd party packages without a centralized way to know it (edit: this seems to harm the previous point) - bundling isn't that interesting in this context as it just bundles the whole runtime with the package, which is terrible for size of packages and doesn't net a lot of benefit since they are also now tied together - if there is a security flaw you now must fix the entire binary and hopefully it still compiles. (edit: technically swift did this a long time too... but they also were reasonably sure they could include their runtime with the OS itself once ABI was stable, I am not sure if Deno has a path for this or if we just get fat binaries forever) - top level await is a weird one to me, there are valid reasons its not in node currently. but yeah- no one likes having to write janky init code to work around this final edit: I have a lot of opinions on this and would love to learn more about why deno is great. from what I can tell, its just a faster language of js which, imo, is great. But the points drawn from GP are just bizarre to me.

seer 6y ago
While I also think url based imports are a weird idea, it might just stem from the fact that I haven’t used it much, it might be wonderful, who knows. But what I’d like to question is why the idea of parsing everything is considered bad. Semver itself, while miles ahead of what came before, is still just lies we tell the compiler. You can never actually rely on the fact that a miner fix will not be a breaking change and the like. Rich Hicky had a great talk on the subject of imports and breakage, and the conclusion that I agree with was to actually load and check every function in all the libraries you use, so that if there is an incompatible change you will not be none the wiser. I’m glad people are trying to experiment here, as package management is far from a solved problem and issues with it cause sweat, tears and blood to most devs during their careers.

hombre_fatal 6y ago

Those still are all trivial in the "too little too late" sense. URL-based imports are already something you can do in package.json if you really thought that was great. Top-level await really is trivial. The permissions system does very little for you since they are process-level permissions when I'm scared of transitive dep attacks. Typescript in Node is good and Deno has to catch up in tooling. If Deno was where it is today but like 8 years ago, it would have made a splash. Now it just looks like someone made a few creature comforts to Node.

ericlewis 6y ago
top-level await isn't really trivial implementation or action wise. But as a feature it seems obvious until you step into all the edge cases it can create.
- hombre_fatal 6y ago
  It's cute for scripts. Otherwise there's the trivial top-level wrapper runProgram.catch(console.error) entry point. It's just not a detail that does much to sell Deno. Though I admit it's not that fun for me to come in here to poopoo Deno.
  - ericlewis 6y ago
    I am not trying to do that either - I think the work they're doing is great and important, but the reasons listed above ain't it.
- ravenstine 6y ago
  Care to share some examples of said edge cases? I write a lot of short JS files that aren't part of a big cohesive backend, and little things like top-level await make the code somewhat easier to read. Yes, you can just do an async IIFE, but that's just another thing for the eye to parse and feels quite vestigial. EDIT: And since I can't respond to your other comment, I'll ask this here; what do you consider great and important about Deno that doesn't fall under the bullet-points I listed? I'm simply curious.

schnable 6y ago

> An actual `window` global with familiar browser APIs This doesn't seem good?

ericlewis 6y ago
it's not. actually I would argue any sort of global state like this should go away.
- ravenstine 6y ago
  Well, okay, but it's pretty much here to stay and doesn't have that great of a drawback that it's worth breaking any cross-compatible code that currently exists. If there is going to be a global object, then it might as well be the same one used in the browser, which everyone who writes JS is familiar with.
- kinjba11 6y ago
  I agree with the spirit of what you're saying, but there billions of lines of JavaScript code that can't "just go away". Being able to use e.g. 'window.crypto' without worrying about whether I'm in Node, Deno, some other runtime or a browser is great news for reusing huge amounts of code.
  - cpcallen 6y ago
    I'm in favour of compatibility and against a global named 'window' in a non-browser JS implementation, and I don't understand why the former necessitates the latter. Since window is the global object, why not just refer to crypto? Then you don't care what the global object is named.
    - afiori 6y ago
      It is relevant to this that ecmascript specifies `globalThis` as the global object (the one pointed by this outside of functions in non-strict mode), all js environments have it and simiply globalThis === window || globalThis === global

hctaw 6y ago

My personal view is that syntactic debate over imports (including whether it's in an import/require/url/package.json/whatever) are basically meaningless except for surface level debate. How "nice" it is to write imports is pretty worthless to me. The structural and semantic differences between imports are a much more important discussion. Import syntax is the front end to the languages meta programming semantics. It's meta programming in the sense that your code and other code is the data, but what you're really programming is a task runner with specific instructions about how to find and satisfy the requirements to build and/or run the software. Integrating package resolution into the language itself is a really important distinction for contemporary designs - passing that buck to external tools but simultaneously coupling them to the runtime is a mistake that I think we should learn from. Deno is a good step in that direction.

LunaSea 6y ago

Highly disagree on the impact of those points. > - Typescript as a first class citizen This doesn't seem to add much besides having to install `tsc` or `ts-node` and also not having the choice of the TypeScript compiler version you use. - An actual `window` global with familiar browser APIs Node.js has a `global` global object and the only API I would understand having in common with the `window` object is the `fetch()` API. - Sandboxing w/ permissions Sandboxing is so basic that any large project will have to enable all permissions. - URL-based imports (no need for NPM) I would consider this a disadvantage. - Bundling into self-contained binaries Again, I would say that this is rarely useful in a world where a lot of operations use container technology. - Things like top-level-await which Node.js still treats as experimental. This is trivially solved by anonymous self-executing functions - Better-designed APIs than the Node standard lib (esp. when it comes to promises instead of callbacks) I think that this is the strongest advantage, however I would argue that this is not a reason to start a completely new backend platform. Also, I think that it might be a disadvantage in some high performance scenarios because Promises are much, much slower than callbacks currently.

ravenstine 6y ago
> This doesn't seem to add much besides having to install `tsc` or `ts-node` and also not having the choice of the TypeScript compiler version you use. Depends on your point of view. With TypeScript being built in, you don't have to think about using tsc or whatever version of TypeScript you have. It's just what version of Deno you use. If someone doesn't like that, then they still can have the option of using TypeScript by itself. > Node.js has a `global` global object and the only API I would understand having in common with the `window` object is the `fetch()` API. It also supports `addEventListener`, which is commonly used by browser code on the window object. Just the existence of something defined as `window` makes more sense than a `global` which never existed in browsers in the first place. > Sandboxing is so basic that any large project will have to enable all permissions. That's pretty dismissive. Why should an app that doesn't interact with the file system be allowed to write or even read from it? I don't know how this feature can be considered a drawback. Don't like it? Don't use it. I don't see how it detracts objectively from Deno. > I would consider this a disadvantage. Then you can still use NPM. Others of us get the option to just import packages from a URL instead of publishing it to a central repository. > Again, I would say that this is rarely useful in a world where a lot of operations use container technology. Why? Building Docker images requires extra software, Linux images, time spent running apt-get or apk, time spent downloading and installing your runtime of choice, and so forth. Having Deno build a binary can give you a bit of a shortcut in that you have one tool for running and bundling code, and you don't need to deal with as many OS-level nuances to do so. Docker and k8s are there for anyone who needs something beyond that. > This is trivially solved by anonymous self-executing functions That's your opinion. Just promise me you don't go on to say that JS is a bad language, because people keep saying that yet are opposed to reducing complexity they consider "trivial". If using IIFE for the mere purpose of accessing syntax makes more sense to you than making `await` syntax available, then I really don't know what to tell you. What exactly is the argument for not implementing this feature besides "all you have to do is type some extra characters", to loosely paraphrase you. > I think that this is the strongest advantage, however I would argue that this is not a reason to start a completely new backend platform. Also, I think that it might be a disadvantage in some high performance scenarios because Promises are much, much slower than callbacks currently. > I think that this is the strongest advantage, however I would argue that this is not a reason to start a completely new backend platform. Also, I think that it might be a disadvantage in some high performance scenarios because Promises are much, much slower than callbacks currently. I honestly have to wonder if you are joking. This is exactly why people invent new backends, new libraries, and new languages. My only response to your point about Promises is that perhaps one shouldn't be using JavaScript if Promises are that much of a bottleneck. What you're saying is totally valid, though.

dmux 6y ago

First class in all but its REPL.