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

591–598 of 598 posts

Re: Deno 1.0

#591

Post by peartips »

aazaa wrote: post #138

> ... Deno is (and always will be) a single executable file. Like a web browser, it knows how to fetch external code. In Deno, a single file can define arbitrarily complex behavior without any other tooling. > ... > Also like browsers, code is executed in a secure sandbox by default. Scripts cannot access the hard drive, open network connections, or make any other potentially malicious actions without permission. The…

> This seems like an experiment worth trying at least.

Yup! I am really excited about Deno and curious about how popular it will be in a few years.

Re: Deno 1.0

#592

Post by anyhooo »

z3t4 wrote: post #581
lame88 wrote: post #550

I briefly looked over this project when this link first popped up and didnt think much of it, but then i was surprised to see this huge surge in votes. I dont do much in the javascript and related world - can someone explain what in particular about this project has generated such interest? Even after reading the top comments, I feel like im missing the bigger pitcure.

I think the goal was to eradicate JavaScript (Deno was originally TypeScript only. But in order to run fast, TS first need to compile to JavaScript). After buying Github and NPM, moving people over from Node.JS to Deno would be the final blow to the JavaScript community.

I don't think that's correct. From what I remember of watching his talk[0], Ryan is a fan of JavaScript. TypeScript gives optional typing, so you can still write normal JavaScript anyway. I don't think there was ever a plan to enforce types in Deno.

[0] https://www.youtube.com/watch?v=M3BM9TB-8yA

Re: Deno 1.0

#593

Post by moogly »

kjksf wrote: post #266
bgdam wrote: post #172

Earlier quoted context omitted.

Which again brings me back to something I'm still not understanding - How is Deno's package management better than NPM if it is extremely similar to NPM, but slightly less secure? I'm only asking because lots of people seem to be loving this new dependency management, so I'm pretty sure I'm missing something here.

We need to distinguish between npm, the service ( https://www.npmjs.com/ ) and npm, the tool. Deno has the functionality of npm, the tool, built-in. The difference is that like Go, Deno imports the code directly from the source repository. In practice it's going to be github.com (but can be gitlab or any code hosting that you, the author of Deno module, use). NPM is a un-necessary layer that both Go and Deno has remo…

NPM, the tool, has had the feature to be able to install directly from GitHub instead of npmjs.org for many many years as well. No one really used it unless as a workaround for unpublished fixes because it has no other tangible benefits.

Re: Deno 1.0

#594

Post by BillinghamJ »

fermienrico wrote: post #262
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.

No one is questioning the utility of URLs. Using URLs to specify dependencies right in the import statement is a horrible idea.

That's exactly what Go does - it works fine

Re: Deno 1.0

#595

Post by MuffinFlavored »

Pyrodogg wrote: post #475
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.…

Repl.it recently announced a Deno REPL https://repl.it/languages/deno

I really wish they had docker-compose / Terraform support. Just not sure at what point that becomes "free" hosting.

Re: Deno 1.0

#596

Post by ric2b »

akamaozu wrote: post #544
ric2b wrote: post #503

Earlier quoted context omitted.

Is it? It's on every browser I know.

See: https://stackoverflow.com/questions/8852198/settimeout-if-no...

Ah, makes sense, it's not part of the spec so it might be missing on other environments. Thank you.

Re: Deno 1.0

#597

Post by dbrgn »

Aldo_MX wrote: post #525
didip wrote: post #332

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.

My concern is what happens when popular-library.io goes down or gets hacked? Or how about attack vectors like DNS poisoning? or government-based firewalls? I know there's this[1], but somehow I still feel uneasy because the web is so fragile and ephemeral... At the very least I would like to have the standard library offline... [1] https://github.com/denoland/deno/blob/master/docs/linking_to...

You can always download the scripts and host them yourself, right?

Re: Deno 1.0

#598

Post by mileycyrusXOXO »

tolmasky wrote: post #210

Forget the (reasonable) security and reliability concerns people have already brought up with regard to importing bare URLs. How about just the basic features of dealing with other people's code: how am I supposed to update packages? Do we write some separate tool (but not a package management tool!) that parses out import URLs, increments the semver, and... cURLs to see if a new version exists? Like if I am currentl…

I prefer a unix approach where each tool does a single thing.

The runtime does runtime things and someone can build a package manager to do package manager things.

The benefit of having runtime + package management bundled into one is you have an opinionated and standard way of doing things - the downside is if the package manager stinks then the whole ecosystem stinks.

Post reply on HN