5 ms·

I was thinking, watching the video "Ryan should fork it, or start over"... until he revealed it: https://github.com/ry/deno https://github.com/ry/deno :)

sametmax 8y ago
My head can't wrap itself around: import { test } from "https://unpkg.com/deno_testing@0.0.5/testing.ts" https://unpkg.com/deno_testing@0.0.5/testing.ts" There is so many issues with that I don't even no where to begin.
- dylrich 8y ago
  His arguments for it seemed reasonable - would love to hear your criticisms
  - freditup 8y ago
    Not OP, but a couple guesses off the top of my head: * It becomes a more painful process to upgrade dependencies (have to find/replace across your codebase). * Many versions of the same library get pulled in. If you depend on package@1.5.3 and a dependency of yours depends on package@1.5.4, that's twice the dependency size as compared to both just using 1.5.4. This matters more in the case of web app bundle size though than running local programs.
    - t-sauer 8y ago
      You could have an entry file for your dependencies (let's say dependencies.ts) and reexport everything from there. When you have to update, you only have to upgrade it in the entry file and you can avoid multiple versions.
      - wereHamster 8y ago
        Hm, how about we call that file package.json?
        myth_buster 8y ago
        How about we link them to modules downloaded onto local file system instead, just in case of network issues.
        WA9ACE 8y ago
        How about a cli tool to cache and build those modules/native extensions all at once? We could call that Deno Package Manager.
  - sametmax 8y ago
    What the others say. And also, golang tried no centralized package management by using git repo. It didn't end with people go getting from moving masters. Of course they did. And in an area of finally accepting lock files, do you really want to go back in middle age ? Lock files are not a constraint. They are a god saver. You want lock files. You don't want to have either vague dependencies or pin pointed ones. You need both to stay sane. And of course somebody will do something dynamic that will open a security issue. And of course typo squatting is going to be so much easier. And removing a bad lib ? From npm you signal the admin. When it's on it's own domain ? Good luck. And then searching for libs is going to be fun. And naming, naming will be amazing. And having a quick glance at the dependency of a lib ? So much fun. And wait for the search/replace in the code that will change your entire run time by mistake. And no possible alternative package manager. Hope their dependency resolver never sucks cause you will be stuck till you can install the next node... if they ever fix it. Ah, and the git blames to see what dependencies have changed are going to be just peachy. Oh, and your juniors copy/pasting code from the net is going to get extra crispy. But wait, running the code on conditional imports means your project may install something at ANY moment in its life cycle. And could be changed by somebody editing the code by mistake without really asking to change a depandancy. You know, like a ctrl + D on "0.1" to replace all those floats quickly. Also cool URLs don't change. Until they do. Tiny URLS dependencies are going to be hilarious. I could go on and on and on and on... I can't understand how you can be intelligent enough to code freaking node JS and not see THAT elephant in the doll room.
    - sagichmal 8y ago
      > golang tried no centralized package management by using git repo. It didn't end well. What? There's no fundamental problem with it. It will continue. What do you mean?
      - jcranendonk 8y ago
        I like go as a language, but its lack of package management is the single reason I no longer use it.
- MatekCopatek 8y ago
  Care to elaborate?
  - sametmax 8y ago
    I did. But I was not expected to have to. It's quite unsettling.
- Joeri 8y ago
  Actually, I can’t think of a single issue that npm doesn’t also have. Possible issues: - trust Not an issue since if you trust an author’s packages on npmjs you should also trust them from unpkg, github, etc... (Aka there is no trust in npm land except trust in the author) - Versioning Put the version in the url instead of some json, same difference. - Lack of ^ for automatic upgrades That’s a feature. Avoids the need for lock files. - Repetitive Have a dependencies.ts to group external imports, same thing as package.json Any other issues?
  - jonny_eh 8y ago
    Dependencies, especially for dynamic imports?
    - ricardobeat 8y ago
      Going from what he said about packaging, every program/module is compiled into a single file, including dependencies.
      - jonny_eh 8y ago
        Wouldn't that lead to even more bloat than what he regretted in the talk?
        pknopf 8y ago
        Runtime dependencies is what he is trying to get ready of. You will always have built time dependencies with npm/yarn.
- ChicagoDave 8y ago
  I'm not a huge NodeJS developer, but have done enough (and other development) to think this is not a good solution to the packaging/dependency problem. My experience with npm issues were usually that some dependency had its own build process. There are so many inconsistencies in how JS libraries are packaged and downloaded. I think scripting in general leaves the whole dependency thing out in the wind. Now. If we could turn packages into testable objects, that would be cool.
  - thecrazyone 8y ago
    Well, packages are testable. You can test the api of a package today. Having people write said tests is the tough part. Did you mean to say something else?
    - ChicagoDave 8y ago
      I meant more like a binary compiled object. So many libraries have a highly varied set of folders and files. It’s just messy.
- __s 8y ago
  What if it said import { test } from "https://npmjs.com/deno_testing@0.0.5/testing.ts" https://npmjs.com/deno_testing@0.0.5/testing.ts" ?
- inimino 8y ago
  But this is exactly the way the Web works. Right? And that platform seems to have done alright for itself. For libraries or professional projects, ship your dependencies or use a build system. But for one-off projects, being able to pull in a utility library without needing any tool but the interpreter you're using or some extra build step seems like a big win.
  - sametmax 8y ago
    The entire world moved out of inline dependencies in the HTML page to a package managers. We invented bower or npm __because__ of it.
    - inimino 8y ago
      We invented bower or NPM because people thought it was a good idea to have 20MB of JavaScript on a page and 19MB of it written by third parties. Generally speaking, this turns out to have been a mistake.

sametmax 8y ago

My head can't wrap itself around: import { test } from "https://unpkg.com/deno_testing@0.0.5/testing.ts" https://unpkg.com/deno_testing@0.0.5/testing.ts" There is so many issues with that I don't even no where to begin.

dylrich 8y ago
His arguments for it seemed reasonable - would love to hear your criticisms
- freditup 8y ago
  Not OP, but a couple guesses off the top of my head: * It becomes a more painful process to upgrade dependencies (have to find/replace across your codebase). * Many versions of the same library get pulled in. If you depend on package@1.5.3 and a dependency of yours depends on package@1.5.4, that's twice the dependency size as compared to both just using 1.5.4. This matters more in the case of web app bundle size though than running local programs.
  - t-sauer 8y ago
    You could have an entry file for your dependencies (let's say dependencies.ts) and reexport everything from there. When you have to update, you only have to upgrade it in the entry file and you can avoid multiple versions.
    - wereHamster 8y ago
      Hm, how about we call that file package.json?
      - myth_buster 8y ago
        How about we link them to modules downloaded onto local file system instead, just in case of network issues.
        WA9ACE 8y ago
        How about a cli tool to cache and build those modules/native extensions all at once? We could call that Deno Package Manager.
- sametmax 8y ago
  What the others say. And also, golang tried no centralized package management by using git repo. It didn't end with people go getting from moving masters. Of course they did. And in an area of finally accepting lock files, do you really want to go back in middle age ? Lock files are not a constraint. They are a god saver. You want lock files. You don't want to have either vague dependencies or pin pointed ones. You need both to stay sane. And of course somebody will do something dynamic that will open a security issue. And of course typo squatting is going to be so much easier. And removing a bad lib ? From npm you signal the admin. When it's on it's own domain ? Good luck. And then searching for libs is going to be fun. And naming, naming will be amazing. And having a quick glance at the dependency of a lib ? So much fun. And wait for the search/replace in the code that will change your entire run time by mistake. And no possible alternative package manager. Hope their dependency resolver never sucks cause you will be stuck till you can install the next node... if they ever fix it. Ah, and the git blames to see what dependencies have changed are going to be just peachy. Oh, and your juniors copy/pasting code from the net is going to get extra crispy. But wait, running the code on conditional imports means your project may install something at ANY moment in its life cycle. And could be changed by somebody editing the code by mistake without really asking to change a depandancy. You know, like a ctrl + D on "0.1" to replace all those floats quickly. Also cool URLs don't change. Until they do. Tiny URLS dependencies are going to be hilarious. I could go on and on and on and on... I can't understand how you can be intelligent enough to code freaking node JS and not see THAT elephant in the doll room.
  - sagichmal 8y ago
    > golang tried no centralized package management by using git repo. It didn't end well. What? There's no fundamental problem with it. It will continue. What do you mean?
    - jcranendonk 8y ago
      I like go as a language, but its lack of package management is the single reason I no longer use it.
MatekCopatek 8y ago
Care to elaborate?
- sametmax 8y ago
  I did. But I was not expected to have to. It's quite unsettling.
Joeri 8y ago
Actually, I can’t think of a single issue that npm doesn’t also have. Possible issues: - trust Not an issue since if you trust an author’s packages on npmjs you should also trust them from unpkg, github, etc... (Aka there is no trust in npm land except trust in the author) - Versioning Put the version in the url instead of some json, same difference. - Lack of ^ for automatic upgrades That’s a feature. Avoids the need for lock files. - Repetitive Have a dependencies.ts to group external imports, same thing as package.json Any other issues?
- jonny_eh 8y ago
  Dependencies, especially for dynamic imports?
  - ricardobeat 8y ago
    Going from what he said about packaging, every program/module is compiled into a single file, including dependencies.
    - jonny_eh 8y ago
      Wouldn't that lead to even more bloat than what he regretted in the talk?
      - pknopf 8y ago
        Runtime dependencies is what he is trying to get ready of. You will always have built time dependencies with npm/yarn.
ChicagoDave 8y ago
I'm not a huge NodeJS developer, but have done enough (and other development) to think this is not a good solution to the packaging/dependency problem. My experience with npm issues were usually that some dependency had its own build process. There are so many inconsistencies in how JS libraries are packaged and downloaded. I think scripting in general leaves the whole dependency thing out in the wind. Now. If we could turn packages into testable objects, that would be cool.
- thecrazyone 8y ago
  Well, packages are testable. You can test the api of a package today. Having people write said tests is the tough part. Did you mean to say something else?
  - ChicagoDave 8y ago
    I meant more like a binary compiled object. So many libraries have a highly varied set of folders and files. It’s just messy.
__s 8y ago
What if it said import { test } from "https://npmjs.com/deno_testing@0.0.5/testing.ts" https://npmjs.com/deno_testing@0.0.5/testing.ts" ?
inimino 8y ago
But this is exactly the way the Web works. Right? And that platform seems to have done alright for itself. For libraries or professional projects, ship your dependencies or use a build system. But for one-off projects, being able to pull in a utility library without needing any tool but the interpreter you're using or some extra build step seems like a big win.
- sametmax 8y ago
  The entire world moved out of inline dependencies in the HTML page to a package managers. We invented bower or npm __because__ of it.
  - inimino 8y ago
    We invented bower or NPM because people thought it was a good idea to have 20MB of JavaScript on a page and 19MB of it written by third parties. Generally speaking, this turns out to have been a mistake.