Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Deno 1.0

deno.land

Post reply on HN
Print view View original

361–370 of 598 posts

Re: Deno 1.0

#361

Post by janpot »

littlestymaar wrote: post #190
fiddlerwoaroof wrote: post #159

Earlier quoted context omitted.

Using a universally unique identifier like a URL is a good idea: this way, https://foo.com/foo and https://bar.com/foo are distinct and anyone who can register their own name gets a namespace, without relying on yet another centralized map of names->resources. After all, the whole point of a URL is that it unambiguously identifies resources in a system-independent way.

Good luck finding which of foo.com/foo or bar.com/foo is the foo module you want though…

Good luck finding which of google.com/search or bing.com/search is the search engine you want though

Re: Deno 1.0

#363

Post by damagednoob »

seleniumBubbles wrote: post #5

Congratulations on the 1.0 release! I've been using Deno as my primary "hacking" runtime for several months now, I appreciate how quickly I can throw together a simple script and get something working. (It's even easier than ts-node, which I primarily used previously.) I would love to see more focus in the future on the REPL in Deno. I still find myself trying things in the Node.js REPL for the autocomplete support.…

I evaluated replacing ts-node with deno but if I use -T and install ts-node globally that seems equivalent to deno to me.

I think stepping outside the npm ecosystem is going to be a bigger issue then people think.

Re: Deno 1.0

#364

Post by feihcsim »

seleniumBubbles wrote: post #5

Congratulations on the 1.0 release! I've been using Deno as my primary "hacking" runtime for several months now, I appreciate how quickly I can throw together a simple script and get something working. (It's even easier than ts-node, which I primarily used previously.) I would love to see more focus in the future on the REPL in Deno. I still find myself trying things in the Node.js REPL for the autocomplete support.…

i wonder if it's conceivable to ever write typescript in a REPL

Re: Deno 1.0

#365

Post by KitDuncan »

stackzero wrote: post #216

As someone not from a js background, when would I use this? is it a drop in replacement for node with TS support? or something else

I think I'll use it for personal system scripts, as JS is the language I am most comfortable in.

Re: Deno 1.0

#366

Post by ranguna »

I'm probably just one more person among the hundreds who are missing something here but: if the big thing about deno is that you can directly fetch dependencies from source with, for example, a GitHub repo URL, instead of going to a package registry like npm, where the package is decoupled from the source, why don't you simply do this already by changing the package.json and swapping the npm identifier with a URL to the repo?

You can already do decentralisation with npm by simply not using`npm i some-package --save` and instead, modify the package.json yourself.

Now the problem with deno is that if I import 5 packages (locked to a specific version) across 50 files and I want to update them to a new version, am I really gonna need to go into every single file and change the URLs??

That's just insane, I get the whole idea of decentralisation but why can't we concentrate all packages into a single file??

Sire this is all good for distribution because you won't have to run `npm i` every time you want to run your program, but more often than not, I'm the one that's going to use my program and I don't mind running `npm i` beforehand and feel safe that I have all my packages downloaded and ready to go, instead of worrying that my program will fail at run-time because the URL for one of my packages is down..

Re: Deno 1.0

#367

Post by dgellow »

qudat wrote: post #290
littlestymaar wrote: post #186

Earlier quoted context omitted.

True, but that's what people using Go have been doing for years without complaining much, so I guess it works fine for most workload. And before npm fixed things after the left-pad incident, the npm builds where not reproducible either (as demonstrated by the said left-pad incident).

> True, but that's what people using Go have been doing for years without complaining much, so I guess it works fine for most workload. I hate to break it to you but dependency management has been a massive issue in golang until the devs formally adopted go mod. Only Google seemed okay with checking in their dependencies to version control. Everyone else was doing crazy hacks like https://labix.org/gopkg.in

The vendoring has never been the issue though.

Re: Deno 1.0

#368

Post by WatchDog »

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 central, and run a central repo that actually provides some validation on the quality of and consistency of published artifacts.

Re: Deno 1.0

#370

Post by _630w »

sakarisson wrote: post #350
searchableguy wrote: post #209

Earlier quoted context omitted.

What happens?

My least favorite thing about importing from NPM is that I don't actually know what I'm importing. Sure, there might be a GitHub repository, but code is uploaded to NPM separately, and it is often minified. A malicious library owner could relatively easily inject some code before minifying, while still maintaining a clean-looking repo alongside the package. Imports from URL would allow me to know exactly what I'm get…

install from the repo then?

You can install a specific version from git via yarn/npm.

How do you trust a url more without reading the code?

What's going to stop deno ecosystem from putting minified js files on cdns and import them?

Post reply on HN