Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What the Hell Is a Deno?

breadth.substack.com

Post reply on HN
Print view View original

41–50 of 151 posts

Re: What the Hell Is a Deno?

#41

Post by muratsu »

jfkebwjsbx wrote: post #37
thawaway1837 wrote: post #27

The security stuff for NodeJS is really frustrating. If anything, NodeJS is more secure than something like the JVM or C++. If I include a 3rd party package in the JVM, I have absolutely no guarantee that it will work well, much like in Node. In fact, in Node, I can actually read the source code and see what the package is, running is doing. In nearly every other environment, you may simply have access to a binary, w…

Because in those languages: . dependencies are carefully considered by users . dependencies are not added recursively . dependencies try to be dependency-free themselves to assist with the previous point . dependencies are not blindly nor automatically updated . dependencies solve important domain problems, they are not trivial one-line-functions . dependencies are typically developed and tested by a known team or co…

What you’ve said has nothing to do with languages. Claiming X devs are better than Y devs is just your bias. Other languages can be more domain specific, have more frictions around using package management, and have less nr of developers.

Re: What the Hell Is a Deno?

#42

Post by mkj »

leeoniya wrote: post #38

do permissions in deno propagate to all dependencies recursively? like, if i grant filesystem access to a top-level script, did all its imports just inherit that permission, too? if so, i can see this type of system being mostly worthless.

Doesn't seem to limit them?

Using something like Caja https://developers.google.com/caja/docs/about might work, using object capabilities rather than ambient privileges. Not sure if Deno helps at all there though.

Re: What the Hell Is a Deno?

#43

Post by etaioinshrdlu »

leeoniya wrote: post #38

do permissions in deno propagate to all dependencies recursively? like, if i grant filesystem access to a top-level script, did all its imports just inherit that permission, too? if so, i can see this type of system being mostly worthless.

Yes... it would actually be quiet amazing to have different libraries in different sandboxes with defined communication channels.

The browser actually does something quite a bit like this with iframes. Iframes are sandboxed and can only communicate through postMessage. There's more to it but at a simple level it looks like this.

Chrome nowadays even runs iframes in a separate process! Finally... https://www.chromium.org/developers/design-documents/oop-ifr...

This is actually quite impressive because it presents a decent illusion to JS that all frames are running under the same thread.

Re: What the Hell Is a Deno?

#44

Post by [deleted] »

jfkebwjsbx wrote: post #37
thawaway1837 wrote: post #27

The security stuff for NodeJS is really frustrating. If anything, NodeJS is more secure than something like the JVM or C++. If I include a 3rd party package in the JVM, I have absolutely no guarantee that it will work well, much like in Node. In fact, in Node, I can actually read the source code and see what the package is, running is doing. In nearly every other environment, you may simply have access to a binary, w…

Because in those languages: . dependencies are carefully considered by users . dependencies are not added recursively . dependencies try to be dependency-free themselves to assist with the previous point . dependencies are not blindly nor automatically updated . dependencies solve important domain problems, they are not trivial one-line-functions . dependencies are typically developed and tested by a known team or co…

[deleted]

Re: What the Hell Is a Deno?

#45

Post by toohotatopic »

thawaway1837 wrote: post #27

The security stuff for NodeJS is really frustrating. If anything, NodeJS is more secure than something like the JVM or C++. If I include a 3rd party package in the JVM, I have absolutely no guarantee that it will work well, much like in Node. In fact, in Node, I can actually read the source code and see what the package is, running is doing. In nearly every other environment, you may simply have access to a binary, w…

> If I include a 3rd party package in the JVM, I have absolutely no guarantee that it will work well, much like in Node.

In the JVM you can use the security Manager [1] and limit file access and access to similarly sensitive areas. If you want you can fully guarantee that nothing is accessed randomly.

Of course that builds on the JVM not having a zero-day bug.

[1] https://en.wikipedia.org/wiki/Java_security

Re: What the Hell Is a Deno?

#46

Post by lol636363 »

jfkebwjsbx wrote: post #37
thawaway1837 wrote: post #27

The security stuff for NodeJS is really frustrating. If anything, NodeJS is more secure than something like the JVM or C++. If I include a 3rd party package in the JVM, I have absolutely no guarantee that it will work well, much like in Node. In fact, in Node, I can actually read the source code and see what the package is, running is doing. In nearly every other environment, you may simply have access to a binary, w…

Because in those languages: . dependencies are carefully considered by users . dependencies are not added recursively . dependencies try to be dependency-free themselves to assist with the previous point . dependencies are not blindly nor automatically updated . dependencies solve important domain problems, they are not trivial one-line-functions . dependencies are typically developed and tested by a known team or co…

This is 100% true especially stupid libraries that are someone's class project. And JavaScript developers are so used to dependency hell that one of my developer imported 3rd party package for date formatting.

Re: What the Hell Is a Deno?

#47

Post by com2kid »

lol636363 wrote: post #46
jfkebwjsbx wrote: post #37

Earlier quoted context omitted.

Because in those languages: . dependencies are carefully considered by users . dependencies are not added recursively . dependencies try to be dependency-free themselves to assist with the previous point . dependencies are not blindly nor automatically updated . dependencies solve important domain problems, they are not trivial one-line-functions . dependencies are typically developed and tested by a known team or co…

This is 100% true especially stupid libraries that are someone's class project. And JavaScript developers are so used to dependency hell that one of my developer imported 3rd party package for date formatting.

JS's built in date formatting/handling is terrible and often do what needs to be one.

MomentJS may be a giant import, but it works an it works really well.

Re: What the Hell Is a Deno?

#48

Post by bryanrasmussen »

jfkebwjsbx wrote: post #37
thawaway1837 wrote: post #27

The security stuff for NodeJS is really frustrating. If anything, NodeJS is more secure than something like the JVM or C++. If I include a 3rd party package in the JVM, I have absolutely no guarantee that it will work well, much like in Node. In fact, in Node, I can actually read the source code and see what the package is, running is doing. In nearly every other environment, you may simply have access to a binary, w…

Because in those languages: . dependencies are carefully considered by users . dependencies are not added recursively . dependencies try to be dependency-free themselves to assist with the previous point . dependencies are not blindly nor automatically updated . dependencies solve important domain problems, they are not trivial one-line-functions . dependencies are typically developed and tested by a known team or co…

the parent said something about problems being solved if there was a standard library, and if perhaps there were a standard library people would be willing to write more code instead of just adding another dependency.

I believe these points

dependencies are carefully considered by users dependencies try to be dependency-free themselves to assist with the previous point dependencies solve important domain problems, they are not trivial one-line-functions dependencies are typically developed and tested by a known team or company, which you trust, not just someone random

would be solved by the parent comment's proposed standard library.

Re: What the Hell Is a Deno?

#49

Post by judge2020 »

lol636363 wrote: post #46
jfkebwjsbx wrote: post #37

Earlier quoted context omitted.

Because in those languages: . dependencies are carefully considered by users . dependencies are not added recursively . dependencies try to be dependency-free themselves to assist with the previous point . dependencies are not blindly nor automatically updated . dependencies solve important domain problems, they are not trivial one-line-functions . dependencies are typically developed and tested by a known team or co…

This is 100% true especially stupid libraries that are someone's class project. And JavaScript developers are so used to dependency hell that one of my developer imported 3rd party package for date formatting.

This seems to be a similar situation to the Bootstrap fallacy where you use the same frameworks every time you make something in a language to make it quick and easy for developers to work on all of your company's projects by just learning one. Using the same familiar libraries is great for reducing the amount of time it'll take to train someone to work on and maintain a large portion of your company's tech.

Re: What the Hell Is a Deno?

#50

Post by frankpf »

irjustin wrote: post #20

My gripe with npm was the lack of a lock file. - Yarn helped solve that, but because of its backwards compatibility to node_modules, you could not have different versions sitting side-by-side. - Node_modules could have a different version installed vs lock file and no one would know without looking. It seems Deno is able to solve the side-by-side versions and distributing the 'lock' to the file itself. The Deno team…

> - Yarn helped solve that, but because of its backwards compatibility to node_modules, you could not have different versions sitting side-by-side.

> - Node_modules could have a different version installed vs lock file and no one would know without looking.

> Sadly, Ruby's Bundler has solved this for years [...]

I don't understand your first point. Different projects can use different versions since the modules are installed locally (inside the `node_modules` directory). And nested modules can also have different dependency versions, e.g.:

    A
    => depends on B @ 1.0
    => depends on C, and C can depend on B @ 2.0
Regarding your second point, I haven't ever seen that happen in practice and IIUC it's mostly a property of the the fact that `require 'bundler/setup'` checks your dependency versions, and you could implement something similar for JS (e.g. traverse node_modules directories recursively checking if the versions declared in the package.json of dependencies match the ones in your root lockfile).

Since we're on the topic of Ruby and JS, Ruby's module system is probably one of the worst I've ever seen and JS one of the best.

In Ruby, just like in Python, everything in a file is public by default and the only way to make things private, AFAIK, is using Module#private_constant, and that only works for methods/inner classes/things in a class scope.

And, unlike Python's import, require is side-effectful! If you have file a.rb that requires b.rb, and b.rb requires c.rb, everything in c.rb will be visible in a.rb. This is terrible.

JS's module system is one of the best IMO (better than haskell, python, java, etc):

- simple mental model: a file is a module

- everything in a module is private by default, you have to explicitly mark things with `export` to make them public

- You can either qualify imports or explicitly import individual functions, so it's always possible to find out where something is defined by simply looking at a file. Most languages fail here. This is useful for beginners and in places where you don't have an IDE available, like GitHub

Post reply on HN