371–380 of 598 posts
It's not the first time I see js iterators used and abused this way, and every time I feel that js and it's users are ready for full-blown monads and do notation instead.
Earlier quoted context omitted.
You'll like https://www.npmjs.com/package/ts-node - it allows zero processing use of typescript
Word of warning though - ts-node can be excruciatingly slow. We recently switched a project from using ts-node in our dev environment to compiling with tsc and running with node, and shaved around 5 minutes from our startup time.
Of all the problems with NPM, it being centralized is the last of them imo. Having experienced the mess that is go's decentralized dependency management, I'm not sure why anyone would want to replicate it. Putting aside security, availability and mutability is a massive problem, anyone can stop hosting their module, or worse, change an existing published module at any time. Why not take some inspiration from maven ce…
Because then it would be hard to have a new hot framework every day.
I think it falls into the same category as Koa (TJs successor to Express) and the upcoming "Rome" project. Someone creates a successful open-source project and then at some point in the future decides to make a better one with questionable tangible benefit and various downsides of its own.
The downsides I can see of Deno so far are that it is slower than node, it is not compatible with any server-side node code because it has rewritten the standard library, and it is inspired and based on the Go standard library, seemingly using Go idioms and so on.
Its benefits are questionable, vague, and not really proven.
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.
I thought a lot about it, and it seems as secure as node_modules, because anybody can publish to npm anyway. You can even depend to your non-npm repo (github, urls...) from a npm-based package. 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 simp…
npm installs aren't the same as installing from a random URL, because:
* NPM (the org) guarantees that published versions of packages are immutable, and will never change in future. This is definitely not true for a random URL.
* NPM (the tool) stores a hash of the package in your package-lock.json, and installing via `npm ci` (which enforces the lockfile and never updates it in any case) guarantees that the package you get matches that hash.
Downloading from a random URL can return anything, at the whims of the owner, or anybody else who can successfully mitm your traffic. Installing a package via npm is the same only the very first time you ever install it. Once you've done that, and you're happy that the version you're using is safe, you have clear guarantees on future behaviour.
The dependency management is highly questionable for me. Apart from the security concerns raised by others, I have huge concerns about availability. In it's current form, I'd never run Deno on production, because dependencies have to be loaded remotely. I understand they are fetched once and cached, but that will not help me if I'm spinning up additional servers on demand. What if the website of one of the packages I…
I'm a desktop developer so I understand I'm the dinosaur in the room but I've never understood why you would not cache all the component packages next to your own source code.
Since this is straighforward to do I presume there is some tradeoff I've not thought about. Is it security? Do you want to get the latest packages automatically? But isn't that a security risk as well, as not all changes are improvements?
I like what Deno is selling. URL like import path is great, I don't know why people are dismissing it. It is easy to get up-and-running quickly. Looks like my personal law/rule is in effect again: The harsher HN critics are, the more successful the product will be. I have no doubt Deno will be successful.
Earlier quoted context omitted.
From the post: > [With NPM] the mechanism for linking to external libraries is fundamentally centralized through the NPM repository, which is not inline with the ideals of the web.
> which is not inline with the ideals of the web Subjective. > Centralized currency exchanges and arbitration is not in line with the ideals of the web! - Cryptocurrency Nek minute. Besides, let's get real here; they will just end up centralized on GitHub. How exactly is that situation much different than npm or any other language ecosystems library directory being mirror-able?
git does not require Github to be online to work, nor relies on Github existence for its functionality.