261–270 of 598 posts
It would be great if this line were at the top: >> Deno is a new runtime for executing JavaScript and TypeScript outside of the web browser.
Earlier quoted context omitted.
I think the primary way to manage dependencies should be in a local DIR and optionally, a URL can be specified. The default in Deno is questionable choice. Just don't fuck with what works. Default should be safest followed by developers optionally enabling less safe behaviors.
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.
I like that Deno is resetting some of the underlying assumptions that Dahl made in Node. But I think he's throwing the baby out with the bath water. I actually like and prefer an explicit node_modules directory. Grabbing everything I need, and then being able to zip it up as needed to save or share is convenient and easy. Not sure why so much effort was made to avoid this module pattern. I really think using URLs is going to be a maintenance nightmare. Instead of changing one entry in package.json (great for testing new code or tweaking something locally), I have find/replace all the imports? Seems very odd unless I'm missing something big. Also, not a fan of the hidden .deno cache directory, but whatever.
Having to send along a shell script in order to even start an app is another problem. "Here's a JavaScript file which will do some task. In order to run it, you need to make sure you include these 10 command-line flags for security purposes. To make sure you don't forget them, I've included various shell scripts you can run depending on your platform." That's not improving anything.
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.
Earlier quoted context omitted.
You’ve made a category error; Servo is not a JavaScript engine.
> Servo is a modern, high-performance browser engine designed for both application and embedded use. What does that mean? "browser engine" Does it execute JavaScript code? Edit: I bought your Rust book on Amazon, supposed to be delivered this Friday. I can't wait!
Ah cool! I hope you like it! :)
Earlier quoted context omitted.
You answered your own question. Nothing stops you from using a mirror with deno too.
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.
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 removed.
It's better because it's simpler for everyone involved.
In Go, I don't need to "publish" my library. People can just import the latest version or, if they want reproducibility, an explicit git revision. Compared to Go, publishing to npm is just unnecessary busy work.
I've seen JavaScript libraries where every other commit is related to publishing a new version to npm, littering the commit history.
In Go there's no need for package.json, which mostly replicates the information that was lost when publishing to npm (who's the author? what's the license? where's the actual source repository?).
As to this being insecure: we have over 10 years of experience in Go ecosystem that shows that in practice it works just fine.
Earlier quoted context omitted.
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 thin…
Dependency management is a major cornerstone of any infosec program. There is more to that than just auto-installing a new dependency version.
> I’m not sure what is enforcing this “small dependency graph”
Because a large dependency graph is slow, insecure, and fragile.
> ... 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…
Click this link to participate in the contest for free https://bit.ly/2yEjwxD