8 ms·

I've found these differences make it tough to use Deno on large or important projects. Deno does a lot of novel things. On the surface they're all things I agre

I've found these differences make it tough to use Deno on large or important projects. Deno does a lot of novel things. On the surface they're all things I agree with, but in practice they're too novel to understand the implications of. For instance, bundling typescript. I like typescript and hate setting up the build toolchain so this sounds like a good idea. But not every typescript upgrade is backwards compatible (even if unintentional when not), and I'd hate to be stuck not upgrading V8 because it's bundled with typescript. Or the import system. Importing from HTTP is useful, it ensures things "just work". I like it, on first sight. But is it manageable? Let's say I isolate all my external dependencies into files that just re-export them, or whatever the standard is nowadays. Is the tooling there for when I need to upgrade? How do I deal with sub-dependencies using different versions of things? How do I keep versions compatible? Will something break if I depend on Xv1.1 and Yv1.2 and X uses Yv1.3? Can I force X to use Yv1.2? I can see a world where these things are solved, but it's a vague image. Or the permissions. Why does my text processing app need to access the web? Again, seems like a good idea. But now the behavior of your standard library is tied to cli options. Phone apps make this work, but they request permissions, you don't explicitly say, "Open Maps with internet access". Ideally I'd like my code not to behave too differently just because it's in a different environment. I want to believe, I see a world where this all comes together smoothly, but it's tough to trust right now.

searchableguy 5y ago
> Or the permissions. Why does my text processing app need to access the web? Again, seems like a good idea. But now the behavior of your standard library is tied to cli options. Phone apps make this work, but they request permissions, you don't explicitly say, "Open Maps with internet access". Ideally I'd like my code not to behave too differently just because it's in a different environment. I want to believe, I see a world where this all comes together smoothly, but it's tough to trust right now. If I'm understanding you correctly, you don't want to run the code with correct flags and instead, have deno figure it out like a browser where it prompts the user to ask if they would like to give a certain permission. If yes, that is already the case with deno. You can pass --prompt flag.
- tinalumfoil 5y ago
  Not quite. Prompting works in a user applications but let's say I launch my app from a systemd service so there's nobody to respond to those prompts. It's not that I don't want to run it with the correct flags. I do want that. Things is, if I run it with too few flags the program breaks. Hopefully in a way where it's obvious what happened! If I run it with too many, I lose the security benefit Deno gives. But the last thing I want is my whole service to fail because I forgot to add that one darned cli flag to my service file! And, I admit, maybe this is a non-issue. Maybe I can just check I'm in the right environment at program start. But it's one of those things where I don't feel like I fully grasp the implications.
  - jonny_eh 5y ago
    It’s definitely a new failure scenario we need to worry about.
  - brundolf 5y ago
    I wonder if they could check API usage statically and fast-fail if you don’t provide the right flags, instead of waiting to find out later
hitekker 5y ago
It sounds like you haven't used Deno in a large project before. Which is weird because you're started by saying "in practice" or "I've found", but later switched to abstract "what if's".
develatio 5y ago
Importing from HTTP is a bad idea on so many different levels and for so many different reasons (security, immutability, sec compliance, project integrity… the list just goes on and on). We’ve been there (PHP remote includes) and it’s as bad as it can get. Please don’t say HTTP imports are a good idea. Please.
- nkozyra 5y ago
  I think you're maybe confusing what's effectively a namespace and point in time install with a dynamic import. Otherwise there's no difference between http "imports" and any dependency management system (which ultimately import from some http endpoint)
  - develatio 5y ago
    If we're talking about https://deno.land/manual/linking_to_external_code https://deno.land/manual/linking_to_external_code , then I stand to what I said.
    - nkozyra 5y ago
      But again - and this is mentioned in the page, nothing here is unique to Deno. It semantically feels different, but is in practice no different than most dependency management systems.
      - develatio 5y ago
        It feels broken, because it's a bad idea, per the design itself. Basically, you're ("you" as in figuratively speaking) smashing the functionality of a package manager into the interpreter. I'm not convinced at all that making a single tool do more and more stuff is a good idea, but let's keep on. Then, you're writing URLs (for the libraries you're importing) all over the code (which is just bad). Deno's solution (from the link in my prev reply) is to just put all the URLs in a single file (so, basically a "packages.json", but now inside your code, ¿because that's somehow a good idea?). Then there's the entire thing about replacing NPMJS, which has full-time engineers working on security, maintenance, etc... with a bunch of different servers, maybe maintained, maybe not, by random people. Then there's the entire "but how can I be sure that the code didn't change?" thing, to which Deno suggests to use a "--lock command flag". This sounds like "npm.lock / yarn.lock". And finally, there's the availability concern ("what happens if any of these servers goes down?"), which Deno just dismisses by saying that this can happen to any server. And while that is technically true, pulling all your dependencies from a single place, instead of N different places, reduces the points of failure to 1 (instead of N). So, this entire "import directly from URLs" sounds just like a package manager with different steps, without providing anything new, without fixing any specific problems with package managers, and introducing new problems (which are in fact old problem, because as I said, we've been there already when PHP thought remote includes were a good idea).
nicoburns 5y ago
Regarding TypeScript toolchains: esbuild and node make a dream combination. The configuration comes down to 3-4 command line parameters, and it's fast enough that you don't need to use any kind of incremental compilation mode. You can just recompile the world before restarting node each time. It's under 0.1 of a second for our projects at work! (and that's on a fairly slow machine where the node process startup time itself can be a few seconds when under load)
- mekster 5y ago
  Incremental compilation with "tsc -w" is instant as well, triggers automatically on file changes and does type checking too. What am I missing?
  - nicoburns 5y ago
    1. It's only instant on small projects in my experience. I've worked on projects where it would take closer to 10 seconds without type checking or 30 seconds with. 2. It's a bit of a pain to have to run 2 separate processes. With esbuild you have a single watch process that does compile+run rather than a compile watch and a separate run watch.
brundolf 5y ago
For the versioning thing: each of those would presumably pull from a different url, so they’d be fully independent. That might result in redundant downloads, but that should be fine, because we’re not talking about the front-end. Deno has no knowledge of versions, just urls. The permissions model may have been a mistake. In my own projects I find myself just doing —-allow-all constantly. I could see it being useful for a hardened production server that eg. should only have access to the network, but I think permission-denial may have been better than permission-granting. Maybe they’ll change the CLI around this at some point.
- kybernetikos 5y ago
  What I don't like is that in deno you permission processes when really you want to permission dependencies or APIs. If I'm writing a web app, I will definitely trust some of my code to access storage, but there's no reason why I should have to trust flatmap-stream to do so, even if I do trust it to flat map my streams. https://www.theregister.com/2018/11/26/npm_repo_bitcoin_stealer/ https://www.theregister.com/2018/11/26/npm_repo_bitcoin_stea...

searchableguy 5y ago

> Or the permissions. Why does my text processing app need to access the web? Again, seems like a good idea. But now the behavior of your standard library is tied to cli options. Phone apps make this work, but they request permissions, you don't explicitly say, "Open Maps with internet access". Ideally I'd like my code not to behave too differently just because it's in a different environment. I want to believe, I see a world where this all comes together smoothly, but it's tough to trust right now. If I'm understanding you correctly, you don't want to run the code with correct flags and instead, have deno figure it out like a browser where it prompts the user to ask if they would like to give a certain permission. If yes, that is already the case with deno. You can pass --prompt flag.

tinalumfoil 5y ago
Not quite. Prompting works in a user applications but let's say I launch my app from a systemd service so there's nobody to respond to those prompts. It's not that I don't want to run it with the correct flags. I do want that. Things is, if I run it with too few flags the program breaks. Hopefully in a way where it's obvious what happened! If I run it with too many, I lose the security benefit Deno gives. But the last thing I want is my whole service to fail because I forgot to add that one darned cli flag to my service file! And, I admit, maybe this is a non-issue. Maybe I can just check I'm in the right environment at program start. But it's one of those things where I don't feel like I fully grasp the implications.
- jonny_eh 5y ago
  It’s definitely a new failure scenario we need to worry about.
- brundolf 5y ago
  I wonder if they could check API usage statically and fast-fail if you don’t provide the right flags, instead of waiting to find out later

hitekker 5y ago

It sounds like you haven't used Deno in a large project before. Which is weird because you're started by saying "in practice" or "I've found", but later switched to abstract "what if's".

develatio 5y ago

Importing from HTTP is a bad idea on so many different levels and for so many different reasons (security, immutability, sec compliance, project integrity… the list just goes on and on). We’ve been there (PHP remote includes) and it’s as bad as it can get. Please don’t say HTTP imports are a good idea. Please.

nkozyra 5y ago
I think you're maybe confusing what's effectively a namespace and point in time install with a dynamic import. Otherwise there's no difference between http "imports" and any dependency management system (which ultimately import from some http endpoint)
- develatio 5y ago
  If we're talking about https://deno.land/manual/linking_to_external_code https://deno.land/manual/linking_to_external_code , then I stand to what I said.
  - nkozyra 5y ago
    But again - and this is mentioned in the page, nothing here is unique to Deno. It semantically feels different, but is in practice no different than most dependency management systems.
    - develatio 5y ago
      It feels broken, because it's a bad idea, per the design itself. Basically, you're ("you" as in figuratively speaking) smashing the functionality of a package manager into the interpreter. I'm not convinced at all that making a single tool do more and more stuff is a good idea, but let's keep on. Then, you're writing URLs (for the libraries you're importing) all over the code (which is just bad). Deno's solution (from the link in my prev reply) is to just put all the URLs in a single file (so, basically a "packages.json", but now inside your code, ¿because that's somehow a good idea?). Then there's the entire thing about replacing NPMJS, which has full-time engineers working on security, maintenance, etc... with a bunch of different servers, maybe maintained, maybe not, by random people. Then there's the entire "but how can I be sure that the code didn't change?" thing, to which Deno suggests to use a "--lock command flag". This sounds like "npm.lock / yarn.lock". And finally, there's the availability concern ("what happens if any of these servers goes down?"), which Deno just dismisses by saying that this can happen to any server. And while that is technically true, pulling all your dependencies from a single place, instead of N different places, reduces the points of failure to 1 (instead of N). So, this entire "import directly from URLs" sounds just like a package manager with different steps, without providing anything new, without fixing any specific problems with package managers, and introducing new problems (which are in fact old problem, because as I said, we've been there already when PHP thought remote includes were a good idea).

nicoburns 5y ago

Regarding TypeScript toolchains: esbuild and node make a dream combination. The configuration comes down to 3-4 command line parameters, and it's fast enough that you don't need to use any kind of incremental compilation mode. You can just recompile the world before restarting node each time. It's under 0.1 of a second for our projects at work! (and that's on a fairly slow machine where the node process startup time itself can be a few seconds when under load)

mekster 5y ago
Incremental compilation with "tsc -w" is instant as well, triggers automatically on file changes and does type checking too. What am I missing?
- nicoburns 5y ago
  1. It's only instant on small projects in my experience. I've worked on projects where it would take closer to 10 seconds without type checking or 30 seconds with. 2. It's a bit of a pain to have to run 2 separate processes. With esbuild you have a single watch process that does compile+run rather than a compile watch and a separate run watch.

brundolf 5y ago

For the versioning thing: each of those would presumably pull from a different url, so they’d be fully independent. That might result in redundant downloads, but that should be fine, because we’re not talking about the front-end. Deno has no knowledge of versions, just urls. The permissions model may have been a mistake. In my own projects I find myself just doing —-allow-all constantly. I could see it being useful for a hardened production server that eg. should only have access to the network, but I think permission-denial may have been better than permission-granting. Maybe they’ll change the CLI around this at some point.

kybernetikos 5y ago
What I don't like is that in deno you permission processes when really you want to permission dependencies or APIs. If I'm writing a web app, I will definitely trust some of my code to access storage, but there's no reason why I should have to trust flatmap-stream to do so, even if I do trust it to flat map my streams. https://www.theregister.com/2018/11/26/npm_repo_bitcoin_stealer/ https://www.theregister.com/2018/11/26/npm_repo_bitcoin_stea...