141–150 of 598 posts
Earlier quoted context omitted.
It's just a URL right? So could you not mirror the packages to your own server if you're so concerned, or better yet import from a local file? Nothing here seems to suggest that packages must be loaded from an external URL.
> or better yet import from a local file And this is different from NPM how? Except that I've now lost all the tooling around NPM/Yarn.
As a functional developer who doesn't care for TypeScript in any way, it's frustrating to see Deno has it "built-in". As a node developer writing pure none-compiled JavaScript, my run time is extremely fast from changing code to seeing its results. It takes milliseconds for me to run brand new code in my terminal. If I make an index.ts file simply adding two numbers together (with no TypeScript), there is a 1 to 2 se…
Deno runs JavaScript faster than node:
echo "console.log(1 + 2)" > not-ts.js
time deno run not-ts.js
3
0.01s user 0.01s system 89% cpu 0.025 total
time node not-ts.js
3
0.03s user 0.08s system 53% cpu 0.203 total
You can!
Earlier quoted context omitted.
> or better yet import from a local file And this is different from NPM how? Except that I've now lost all the tooling around NPM/Yarn.
It's different because it doesn't rely on require() which is non-standard JavaScript.
Does anyone else see the import directly from URL as a larger security/reliability issue than the currently imperfect modules? I'm sure I'm missing something obvious in that example, but that capability terrifies me.
If you want to "feel" as safe, you have import maps in deno, which works like package.json.
Overall, I think Deno is more secure because it cuts the man in the middle (npm) and you can make a npm mirror with low effort, a simple fork will do. Which means you can not only precisely pin which code you want, but also make sure nobody knows you use those packages either.
Take it with an open mind, a new "JSX" or async programming moment. People will hate it, then will start to see the value of this design down the road.
Earlier quoted context omitted.
Ah, in this case, I would then have to commit my dependencies into my VCS to maintain reproducible builds. I'm not sure I like that solution very much either. I've seen node_modules in multiple GBs, and I'm sure Deno's dependency sizes are going to be similar.
In practice modules will be available from sources that will have similar reliability to npm: github.com, unpkg.com, cdn.pika.dev, jspm.io, etc.
As a functional developer who doesn't care for TypeScript in any way, it's frustrating to see Deno has it "built-in". As a node developer writing pure none-compiled JavaScript, my run time is extremely fast from changing code to seeing its results. It takes milliseconds for me to run brand new code in my terminal. If I make an index.ts file simply adding two numbers together (with no TypeScript), there is a 1 to 2 se…
> As a node developer writing pure none-compiled JavaScript, my run time is extremely fast from changing code to seeing its results. It takes milliseconds for me to run brand new code in my terminal. Deno runs JavaScript faster than node: echo "console.log(1 + 2)" > not-ts.js time deno run not-ts.js 3 0.01s user 0.01s system 89% cpu 0.025 total time node not-ts.js 3 0.03s user 0.08s system 53% cpu 0.203 total > Since…
Yup, and that's really cool and exciting. My issue isn't with runtime timing. That's not what costs me money. Developer time is what costs money, and every change having to "recompile" my already raw JavaScript costs way more than saving 0.02s at runtime.
Earlier quoted context omitted.
Hi! The response to your fears are in the announcement. "If you want to download dependencies alongside project code instead of using a global cache, use the $DENO_DIR env variable." Then, it will work like node_modules.
Ah, in this case, I would then have to commit my dependencies into my VCS to maintain reproducible builds. I'm not sure I like that solution very much either. I've seen node_modules in multiple GBs, and I'm sure Deno's dependency sizes are going to be similar.
Earlier quoted context omitted.
I'm wondering about the practicality of importing from URLs. I didn't see it addressed, but an import like this will be awfully hard to remember. import { serve } from "https://deno.land/std@0.50.0/http/server.ts"; Anyone know if there are alternatives or a plan for this aside from "use an IDE to remember it for you"?
The convention is to make a `deps.ts` and re-export what you need. Like this: https://deno.land/x/collections/deps.ts I don't find versioned URLs much more difficult to work with than package@ though.
jokes aside, i wonder how import-via-url will impact tooling. having to parse arbitrary JS (or even run it, for dynamic imports?) seems like it'd make writing a "list all dependencies" tool much harder than a "dumb" JSON/TOML/whatever file would. though i guess Go does a similar thing, and afaik they're fine
Interesting. If I understand correctly, they're essentially using pull streams[0]/reactive streams[1]. I compiled a few resources on this topic when I was digging into it a while back[2]. I've found the mental model to be very elegant to work with when needing backpressure in asynchronous systems.
As for the dependencies-as-URLs, I don't mind it, and may prefer it. I've been experimenting with minimizing my dependencies lately, and vendoring them in git submodules. It's worked fairly well.
[0]: https://github.com/pull-stream/pull-stream
[1]: https://github.com/reactive-streams/reactive-streams-jvm
Earlier quoted context omitted.
The convention is to make a `deps.ts` and re-export what you need. Like this: https://deno.land/x/collections/deps.ts I don't find versioned URLs much more difficult to work with than package@ though.
i'm wondering if they'll end up adding a 'dependencies.json' to eliminate the boilerplate from 'deps.ts' and to simplify tooling. that'd be revolutionary! ;) jokes aside, i wonder how import-via-url will impact tooling. having to parse arbitrary JS (or even run it, for dynamic imports?) seems like it'd make writing a "list all dependencies" tool much harder than a "dumb" JSON/TOML/whatever file would. though i guess…