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

341–350 of 598 posts

Re: Deno 1.0

#341

Post by triyambakam »

turblety wrote: post #136

As a functional developer who doesn't care for TypeScript in any way, it's frustrating to see Deno has it "built-in". As a node developer writing pure none-compiled JavaScript, my run time is extremely fast from changing code to seeing its results. It takes milliseconds for me to run brand new code in my terminal. If I make an index.ts file simply adding two numbers together (with no TypeScript), there is a 1 to 2 se…

I'm a functional enthusiast and I find it much more enjoyable in TS. There is a lot of cool and interesting functional theory that only relates to types. Having a good type system tht TS provides has also saved me so much time debugging. It's invaluable

Re: Deno 1.0

#342

Post by gavinray »

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…

How do you list the dependency libraries if you don't have a package.json?

Do you manually install a list of libraries provided by the author's readme?

Re: Deno 1.0

#343

Post by chrischen »

megavolcano wrote: post #245
pedalpete wrote: post #187

Earlier quoted context omitted.

yeah, but we regularly clear out our cache and lock files, so this doesn't really solve the issue, unless you're commiting all of your packages

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.

Re: Deno 1.0

#344

Post by lucasyvas »

stevehiehn wrote: post #324

This is interesting. Can you ship the Deno runtime with your runtime code? That's the thing that kills me about Javascript; having to assume the consumer has a runtime setup.

Compiling to a single binary is on the roadmap, but was dropped from 1.0

Re: Deno 1.0

#345

Post by fermienrico »

fiddlerwoaroof wrote: post #340
fermienrico wrote: post #322

Earlier quoted context omitted.

I've never used npm or developed any javascript before but it sounds equally horrible. Not decoupling the source of the package (i.e., the location of the repository whether it is on remote or local) and its usage in the language is a terrible idea. from foo import bar # foo should not be a URL. It should just be an identifier. # The location of the library should not be mangled up in the code base. Are we gonna sear…

The whole idea of a URL is that it’s a standardized way of identifying resources in a universally unique fashion: if I call my utility library “utils”, I’m vulnerable to name collisions when my code is run in a context that puts someone else’s “utils” module ahead of mine on the search path. If my utility module is https://fwoar.co/utils then, as long as I control that domain, the import is unambiguous (especially if…

Allow me to provide an extremely relevant example (medium sized code base).

About 100 python files, each one approximately 500-1000 lines long.

Imagine in each one of these files, there are 10 unique imports. If they are URLs (with version encoded in the URL):

- How are you going to pin the dependencies? - How do you know 100 files are using the same exact version of the library? - How are you going to refactor dependency resolution or upgrades, maintenance, deprecation?

How will these problems be solved? Yes, I understand the benefits of the URL - its a unique identifier. You need an intermediate "look up" table to decouple the source from the codebase. That's usually requirements.txt, poetry.lock, pipenv.lock, etc.

Re: Deno 1.0

#346

Post by chrischen »

NoInkling wrote: post #297
jon889 wrote: post #154

Earlier quoted context omitted.

Can't you just pass it a .js file and it will skip the TypeScript compiling completely?

That's not gonna help if you're using any part of the standard library though (or presumably most 3rd-party modules), since it's written in TS, right?

I'd assume you can just use regular node modules in that case?

Re: Deno 1.0

#347

Post by danShumway »

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

What protection does NPM actually give you?

Sure, they'll remove malware as they find it, but it is so trivially easy to publish packages and updates to NPM, there effectively is no security difference between an NPM module and a random URL. If you wouldn't feel comfortable cloning and executing random Github projects, then you shouldn't feel comfortable installing random NPM modules.

> and run it immediately

NPM packages also do this -- they can have install scripts that run as the current user, and have network access that can allows them to fetch, compile, and execute random binaries off the Internet.

From a security point of view, Deno is just making it clear up-front that you are downloading random code snippets, so that programmers are less likely to make the mistake of trusting a largely unmoderated package repository to protect themselves from malware.

I lean towards calling that a reasonably big security win on its own, even without the other sandboxing features.

Re: Deno 1.0

#349

Post by nine_k »

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…

It's always a good idea to run in a container, which limits the ports you can listen on, directories allowed for writing and reading, and can have its own firewall to limit outgoing connections.

If you don't need the firewall, you can just run in a chroot under a low-privilege user.

I mean, if you do otherwise, you are not following best practices and the voice of reason.

Re: Deno 1.0

#350

Post by sakarisson »

searchableguy wrote: post #209
mrkurt wrote: post #176

Earlier quoted context omitted.

I like it because it's simpler. I know what happens when I import from a URL. I'd have a hard time whiteboarding exactly what happens when I `npm install`.

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 getting.

Post reply on HN