111–116 of 116 posts
Earlier quoted context omitted.
Node did make modules async (just ESM modules). They can’t/won’t make CJS async because their synchronous semantics are a guarantee they determined not to break well before ESM. If you want async modules, ESM is the solution for that.
ESM will be the solution to that, when all the major toolchains catch up. I wouldn't sell this future short, but we aren't there yet either.
Why is it that ES6 modules load only asyncly but Node.js CommonJS modules only syncly? I find sync is often simpler to code for.
Node modules are usually on the local filesystem and load quickly, whereas loading an ES6 module in a browser requires a network trip.
But sometimes I'd like the same code to work also in the browser. Then I should be using ES6, but it doesn't work very smoothly with Node.js and I fear there may be complications if I have to wait (or "await") for the modules to have loaded.
The ES6 "dynamic imports" add more considerations to the mix. Surely their exports can not be used until "await" is over?
I think it would simplify things if I didn't have to choose between module-systems when I really just want to choose between sync and async.
Think of it as Node.js + Typescript, but you don't have to think about configuring the typescript compiler, linter and formatter as everything is bundled in the `deno` binary. Don't think about syncing that formatting/linting/import aliases configuration with VSCode, all you need is the Deno plugin and you'll get all the benefits of working with TS on VSCode. Packages are obtained (and heavily cached) from any URL in…
nice to have ts+linter+formatter together, it took me one or two hours to set up with my own vim(using vite/volar), so it saves me some time. what I really like a new Node.js(e.g. deno) is actually its module system, I don't like the `npm i` in node.js pulls hundreds of modules, a standard library that contains most commonly needed modules is the key. If deno does not do that, I probably will never try that(as I can…
Because modules/packages routinely have dependencies. And their dependencies have dependencies. And...
Deno changes nothing in that regard with one single exception:
> a standard library that contains most commonly needed modules is the key
^ This is the bane of Javascript, yes. But this doesn't mean that having a standard library somehow prevents modules having multiple dependencies and subdependencies.
> "you pull whatever you want freely now even over http URL", for security and stability reasons.
- If you pull your deps from a random URL and that URL goes away, how do you solve that?
- If your deps pull other subdeps from a random URL and that URL goes away, how do you solve that?
- For security, how do you vet what your dependencies keep on pulling from random URLs?
For node, the answer is: run your own registry, and don't load anything from outside. That's how many companies operate. How can this be solved with Deno?
Earlier quoted context omitted.
Isn't the scope of the standard library of C and C++ close to the scope of the Rust standard library (an thus much smaller than python's)?
nope, I was told rust prefers to a light stdlib approach.
Rust has collections, strings and algorithms manipulating these. It supports synchronous IO (files and network) and can work with threads/processes. It lacks async IO, higher level network protocols (e.g. HTTP and TLS), regex, advanced unicode support, serialization, UUIDs, GUI, linear algebra/vectors, logging, encoding, time, randomness, command line parsing, cryptography, compression.
C++ has reasonable randomness and time support, but apart from that Rust isn't far behind.
Earlier quoted context omitted.
And we have lock files to verify integrity. This is no different to module loading in Node. If you don’t trust your registry, you should not be loading code from it!
> And we have lock files to verify integrity. Where do you et these lockfiles files from? > This is no different to module loading in Node. This is very much different from module loading in Node: https://news.ycombinator.com/item?id=29871936 > If you don’t trust your registry, you should not be loading code from it! So you immediately pinpointed the difference: with Node I can run my own registry and easily set up n…
Which is why we support a) import maps which allow you to rewrite all URLs however you want, and b) HTTP_PROXY, which allows you to intercept all HTTP traffic (also letting you rewrite all specifiers).
I don't know if you have ever worked on a Go project, but it has a very similar registry proxy situation as Deno. It works well.
Earlier quoted context omitted.
> Where do you et these lockfiles files from? I don't know about any lock files but the `version` it locked via the import url E.G import R from ' https://deno.land/x/rambda@v7.0.1 '
This brings us back to the fact that Deno loads random files from random URLs with no way to change it. https://news.ycombinator.com/item?id=29871936
You are so wrong. If you would have done maybe 3 minutes of Googling you would know we support import maps, which allow you to arbitrary rewrite specifiers, even deep inside of the module graph.