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

301–310 of 598 posts

Re: Deno 1.0

#301

Post by fiddlerwoaroof »

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.

How is it any worse than using names from a namespace controlled by “npmjs.com”: if you’re concerned about build stability, you should be caching your deps on your build servers anyways.

Re: Deno 1.0

#302

Post by mkolodny »

bgdam wrote: post #241
batmansmk wrote: post #179

Earlier quoted context omitted.

To be the rubber duck, if wiping the cache at each build is a risk to your CI, what could you do to keep your CI up? 1 - not wipe the cache folder at each build? It's easy and secure. Oh and your build will be faster. 2 - use a cached mirror of the deps you use? It's like 10min to put in place and is already used in companies that care about security and availability anyway. 3 - you have https://deno.land/x if you wa…

Yes, I think I'd probably settle for solution number 2. I still don't understand how this is better than NPM, and how Deno solves the horrible dependency management of Node, but maybe if I actually build something with Deno I'll get some answers.

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.

Re: Deno 1.0

#303

Post by simonw »

Question:

    deno run https://deno.land/std/examples/welcome.ts
This works - it downloads the code from that URL, then compiles and runs it.

But if you visit https://deno.land/std/examples/welcome.ts in your browser you get back HTML, not raw code.

Anyone know how this works? Is deno.land a special case or is there some Accept header cleverness or something going on?

Re: Deno 1.0

#304

Post by greggman3 »

xg15 wrote: post #81
mrkurt wrote: post #54

Earlier quoted context omitted.

It's basically the same "exposure" as importing a random npm, but it has the benefit if being explicit when you do it. It's also exactly what the websites you visit do. ;)

> It's basically the same "exposure" as importing a random npm, but it has the benefit if being explicit when you do it. I'm not sure how this works in detail here, but at least in NPM you got a chance to download packages, inspect them and fix the versions if so desired. Importantly, this gave you control over your transitive dependencies as well. This seems more like the curl | bash school of package management. Ed…

AFAIK there is no option to allow a website to read and write random files anywhere to my hard drive period. At most a website can ask the user select a file or offer one for downloading. In the future maybe it can be given a domain specific folder.

That's not true here. If I'm running a web server I'm going to need to give the app permission to read the files being served and access to the database. That something that never happens in the browser.

Re: Deno 1.0

#305

Post by CGamesPlay »

bgdam wrote: post #111

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…

Several responses to your concern but all of them seem to say "you can cache dependencies". How does Deno find dependencies ahead of runtime? Does Deno not offer dynamic imports at all?

If I have an application that uses, say, moment.js and want to import a specific locale, typically this is done using a dynamic import.

Re: Deno 1.0

#306

Post by simonw »

simonw wrote: post #303

Question: deno run https://deno.land/std/examples/welcome.ts This works - it downloads the code from that URL, then compiles and runs it. But if you visit https://deno.land/std/examples/welcome.ts in your browser you get back HTML, not raw code. Anyone know how this works? Is deno.land a special case or is there some Accept header cleverness or something going on?

Figured this out myself:

    $ curl 'https://deno.land/std/examples/welcome.ts'
    console.log("Welcome to Deno ");
So this is an Accept header trick. If I do this instead:

    $ curl 'https://deno.land/std/examples/welcome.ts' -H 'Accept: text/html'
I get back the full HTML version of the page.

Re: Deno 1.0

#307

Post by NoInkling »

TypeCaste wrote: post #102
cryptica wrote: post #59

>> Internally Deno uses Microsoft's TypeScript compiler to check types and produce JavaScript. Compared to the time it takes V8 to parse JavaScript, it is very slow. >> We certainly think there are improvements that can be done here on top of the existing TypeScript compiler, but it's clear to us that ultimately the type checking needs to be implemented in Rust. Funny, I was just talking about something like this in…

>I just hate having to debug mangled transpiled code and dealing with sourcemaps. I want to be able to run and debug my own code, not some alternative mangled version of it. Look into ts-node. It lets me run and debug the TypeScript itself before transpiling it.

ts-node still transpiles under the hood, just as this does.

Re: Deno 1.0

#308

Post by CGamesPlay »

c-cube wrote: post #226
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…

Maybe a convention will arise, that you do all the imports in one file (basically like a `package.json` file) and import that from the rest of your code? It seems hackish to me but could work.

This is explicitly listed as best practice by Deno [1], but it doesn't handle the updating problem at all.

[1] https://deno.land/manual/linking_to_external_code#it-seems-u...

Re: Deno 1.0

#309

Post by jeswin »

bgdam wrote: post #151
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…

See the thing about the sandbox is that it's only going to be effective for very simple programs. If you're building a real world application, especially a server application like in the example, you're probably going to want to listen on the network, do some db access and write logs. For that you'd have to open up network and file access pretty much right off the bat. That combined with the 'download random code fro…

> That combined with the 'download random code from any url and run it immediately', means it's going to be much less secure than the already not-that-secure NPM ecosystem.

What deno does is move package management away from the framework distribution. This is great - one thing I hate about node is that npm is default and you get only as much security as npm gives you. (You can switch the npm repo, but it's still the overwhelming favourite because it's officially bundled.)

Deno can eventually give you:

  import lib from 'verified-secure-packages.com'
  import lib from 'packages.cloudflare.com'
So you'll be able to pick a snippet repository based on your risk appetite.

Re: Deno 1.0

#310

Post by chrismorgan »

Pet peeve: programming sites behind Cloudflare protection with email address protection enabled, because we regularly have things with at signs in them that aren’t email addresses, which it mangles, ruining my standard no-JS experience:

  import { serve } from "https://deno.land/[email protected]/http/server.ts";
I mean, std@0.50.0 is a syntactically valid email address, but… protecting email addresses on IP addresses? Why, Cloudflare, why?
Post reply on HN