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

231–240 of 598 posts

Re: Deno 1.0

#231

Post by mrkurt »

tolmasky wrote: post #227
mrkurt wrote: post #224

Earlier quoted context omitted.

The Deno solution is either: * A deps.ts that handles all external dependencies and re-exports them * Import maps Neither of these really give you a way to do the equivalent of "npm update". But I almost never want to update all my packages at once.

You don’t like checking for security updates?

Lately I just merge GitHub's pull requests for that. ;)

I don't like running "npm update" to try and get security updates, though. npm packages aren't very rigorous about PATCH level changes.

Re: Deno 1.0

#232

Post by sirius87 »

bgdam wrote: post #180
mrkurt wrote: post #174

Earlier quoted context omitted.

Sometimes it's ok to think "this project isn't for me" and just leave it be. The cynical-security-concern act is boring.

Contrary to the impression I seem to have given you, I'm actually super excited about Deno and am planning to write my next MVP app in it. That means that I am actually a lot more vested into it, and if I want to put it in production, then I have to be concerned about things like this. When somebody says they think X is broken, and they present a solution Y which they say is better, I am definitely entitled to ask wh…

But you don't seem to be genuinely seeking answers, at least not in this thread. Does seem you're already convinced of the projects faults.

You're entitled to your opinion, of course. I had to read through the docs to understand their module system and intent. And I find it very exciting.

Re: Deno 1.0

#233

Post by svieira »

ricardobeat wrote: post #156
bgdam wrote: post #151

Earlier quoted context omitted.

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…

Maybe this will develop into a standard of multi-process servers (real micro services you could say), where the permissions are only given to a slice of the application.

That sounds like the Postfix architecture [1]

[1]: https://www.akadia.com/services/postfix_mta.html

Re: Deno 1.0

#234

Post by austincheney »

bgdam wrote: post #222
austincheney wrote: post #183

Earlier quoted context omitted.

NPM is a dependency management failure which is why you are ending up with hundreds of dependencies in the first place. It sounds like you want to reproduce that insanity in Deno. Deno is set up in such a way to dissuade you from the stupidity by default but allow it in very few steps if you cannot imagine a world without it. In my opinion this is Deno’s biggest selling point.

> Deno is set up in such a way to dissuade you from the stupidity by default but allow it in very few steps if you cannot imagine a world without it. Could you elaborate on this? Is it that Deno is against the whole 'small packages that do one thing well' principle and instead in favor of complete libaries? How exactly would it dissuade me from installing hundreds of dependencies?

The default design style for a Deno application is that the application becomes a single file. Just like packages coming off Steam. This requires that dependencies are packaged into the application before it is distributed to others. The idea there is to include only what you need deliberately and it manage it as a remotely written extension of your application.

Re: Deno 1.0

#235

Post by afiori »

bgdam wrote: post #161
afiori wrote: post #140

Earlier quoted context omitted.

I do not speak for the project, but based on my understanding part of the point was to avoid the magic of npm. You can use lock-files, bundles, and many other features that makes dependencies management easier.

Ah from that perspective I can see how this might appear to be better. Personally, I like the 'magic' of NPM (which to be honest I don't really think is all that magical, it's quite transparent what's happening behind the scenes). This 'magic' means I no longer have to write 200 line makefiles, so it definitely makes my life easier.

Some of that convenience will still be included, a couple of things that deno will do differently from node will be that there is no standard index.* file to load and import path include the extension.

Re: Deno 1.0

#236

Post by tolmasky »

austincheney wrote: post #221
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…

You have to stop thinking in terms of NPM where it takes 1000000000 packages to do anything. A Deno application is designed to be distributed as a single file. You can override the default behavior to have NPM like stupidity, but if that is really your goal why bother moving to Deno in the first place?

Forget 10000000 packages. Many languages often make use of 10s of packages. If I have several projects, each with around 10 packages, and no automated way to just check if all my projects’ respective dependencies have security updates that could be applied, it seems to go against the stated security goal.

Separately I’m not sure what is enforcing this “small dependency graph” aside from making it hard to import things I guess. I wouldn’t be surprised if you end up with the normal behavior of people coming up with cool things and other people importing them.

Re: Deno 1.0

#237

Post by sintaxi »

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

Deno will likely be well suited for network oriented server-side programs. Deno is not a drop-in replacement for node. It is an alternative JS runtime.

Re: Deno 1.0

#238

Post by Bahamut »

littlestymaar wrote: post #186
bgdam wrote: post #127

Earlier quoted context omitted.

Ah, in this case, I would then have to commit my dependencies into my VCS to maintain reproducible builds. I'm not sure I like that solution very much either. I've seen node_modules in multiple GBs, and I'm sure Deno's dependency sizes are going to be similar.

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

Dependency management is one of the biggest complaints I have seen around Go - I don't think this is accurate.

Re: Deno 1.0

#239

Post by drcode »

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 view it as a replacement for node that requires less overall handholding and ceremony.

Re: Deno 1.0

#240

Post by Cldfire »

VWWHFSfQ wrote: post #223
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…

I guess I'm wondering why Deno is targeting V8 instead of Servo? Maybe I'm mistaken, but Servo [0] and Stylo [1] are both production-ready browser scripting and styling engines implemented in Rust. [0] https://servo.org/ [1] https://wiki.mozilla.org/Quantum/Stylo

Servo is an experimental project designed to build and test components that can be integrated into Firefox. It relies on Gecko for JS.
Post reply on HN