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

511–520 of 598 posts

Re: Deno 1.0

#511

Post by timw4mail »

devit wrote: post #500

What is the reason for making a JavaScript runtime based on browser APIs that cannot also be a browser? Or in other words, wouldn't it have been easier and better to make an optionally headless version of the Servo browser with additional native APIs and some enhancements like being able to run JavaScript directly in addition to HTML? The choice made means that Deno can't be used, at least directly, to make desktop a…

The Javascript engine is a lot smaller code surface area than an entire browser rendering engine.

Re: Deno 1.0

#512

Post by tleb_ »

Cthulhu_ wrote: post #479
iillexial wrote: post #478

Earlier quoted context omitted.

Deno does not provide API to Video & Audio. It was just an analogy.

I think they could've used an analogy using a feature they do actually support, then.

Would it still be an analogy though?

Re: Deno 1.0

#513

Post by petecoop »

petercooper wrote: post #33

If you're getting into Deno and want to keep up with new stuff from the ecosystem on a regular basis, we're now publishing https://denoweekly.com/ .. issue 2 just went out minutes after the 1.0 release. I've been doing JavaScript Weekly for 487 issues now, so this is not a flash in the pan or anything :-D Of course, Deno has an official Twitter account as well at https://twitter.com/deno_land :-)

Great :)

Re: Deno 1.0

#514

Post by epr »

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…

Simple solution to the dependency management (spitballing): a directory of files where the filename is the module name. Each file is simply:
And then in an application:

  import { serve } from deno.http.server;
If you want nested levels so deno.X.X wouldn't be a ton of files you could possibly just do nested directories so deno/http/server would equate to deno.http.server.

Most people would want the option to do dependency management on a per-project basis as well. Simply allow a command-line parameter to provide one or more other directories to source from first (besides presumably the global one for your installation).

If we wanted the file to be generated automatically, maybe something like this:

  import { serve } from deno.http.server at "https://deno.land/std@0.50.0/http/server.ts";

Re: Deno 1.0

#515

Post by pknopf »

emerongi wrote: post #480
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…

Another thing is that with package.json every dependency can say which versions of its dependencies it works with. This lets you update a dependency that is used by other dependencies and only have a single version (most up to date) of it. Some package managers also let you completely override a version that one of your dependencies uses, allowing you to force the use of a newer version. With Deno, both of these use…

> None of your dependencies can say "hey, I work with versions 1.1 to 1.3 of this dependency"

That's a real problem that needs to be solved.

Also, what happens when two lib A and lib B depend on different versions of lib C? Each have their own scoped instance of C?

Re: Deno 1.0

#516

Post by petercooper »

lenkite wrote: post #486
petercooper wrote: post #33

If you're getting into Deno and want to keep up with new stuff from the ecosystem on a regular basis, we're now publishing https://denoweekly.com/ .. issue 2 just went out minutes after the 1.0 release. I've been doing JavaScript Weekly for 487 issues now, so this is not a flash in the pan or anything :-D Of course, Deno has an official Twitter account as well at https://twitter.com/deno_land :-)

Root certificate not trusted for https://denoweekly.com/ on both chrome and firefox.

Hmm, interesting! Thanks for the report. I just ran it through Qualys SSL Labs and everything passed. (We got a B though because we still support TLS 1.1.)

It's a multi-domain Let's Encrypt X3 certificate and I believe most LE users will be in a similar boat now.

Re: Deno 1.0

#517

Post by megavolcano »

chrischen wrote: post #343
megavolcano wrote: post #245

Earlier quoted context omitted.

Why are you _regularly_ clearing lock files? If you're bypassing lock files you're going to have the exact same issue with npm or yarn or any other package manager that downloads from the internet.

Dunno about OP but I pin versions in package.json because it allows me to control the versions and upgrade major versions only when explicit and necessary, and rely only on the lock file to keep it the same between commit time and the production build.

What about the dependencies of your dependencies? You're gonna get burned when a breaking change gets introduced a few levels deeper than your package.json. Not everyone follows semver perfectly, and sometimes malicious code gets distributed as one of these transitive dependencies.

Re: Deno 1.0

#518

Post by ignoramous »

philholden wrote: post #466
yoz-y wrote: post #443

Earlier quoted context omitted.

Well, I suppose they do (or will) provide a self hosted version of the registry. Like npm does.

If you publish your module versions on IPFS that would provide a guarantee to your users the module versions do not change once published. But hashes are not very memorable as module names.

> If you publish your module versions on IPFS...

Well, using message digests, NPM or Yarn can pretty much guarantee content addressable versions, too. Do not have to use IPFS or blockchains, just because...

Re: Deno 1.0

#519

Post by gpm »

lenkite wrote: post #486
petercooper wrote: post #33

If you're getting into Deno and want to keep up with new stuff from the ecosystem on a regular basis, we're now publishing https://denoweekly.com/ .. issue 2 just went out minutes after the 1.0 release. I've been doing JavaScript Weekly for 487 issues now, so this is not a flash in the pan or anything :-D Of course, Deno has an official Twitter account as well at https://twitter.com/deno_land :-)

Root certificate not trusted for https://denoweekly.com/ on both chrome and firefox.

Maybe they fixed this in the last 2 hours, but it works for me (firefox, linux).

Re: Deno 1.0

#520

Post by swrobel »

appleflaxen wrote: post #463

This project looks really cool to me. I'm glad the link to the video is there, because my intuition about pronouncing the name was incorrect. It looks like it could be "deeno" OR "denno", and I was pushed to the former by the presence of the dinosaur graphic. Isn't that old fashioned dinosaur on the Flinstones pronounced deeno? Anywho... good name overall: short, no collisions (i think?), and no strong baseline assoc…

What video? Mind linking directly?
Post reply on HN