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

61–70 of 151 posts

Re: What the Hell Is a Deno?

#61

Post by irjustin »

frankpf wrote: post #50
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 i…

> Different projects can use different versions since the modules are installed locally (inside the `node_modules` directory)

I'm speaking about within the same project. It's not hard to have problems over time when node upgrades (for example[0]) or to get a different version than expected.

Any project that's lived long enough runs into some sort of version mis-match where the solution is `rm -rf node_modules`.

Deleting and reinstalling the package folder as a regular fix is symptomatic of a deeper package issue.

Deno solves parts of this by giving module versions their own explicit folder. I'm concerned if it still stores the package locally that you can still run into a deno version mismatch.

.rbenv + Bundler's folder structure has been `.rbenv/versions/2.6.5/lib/ruby/gems/2.6.0/gems/mime-types-3.3`

The version of ruby and the version of the gem are explicit allowing separation.

Again, far from perfect, but this keeps out so many problems.

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

This thread is about package management. While fair criticism, it's too sideways.

[0] https://stackoverflow.com/questions/46384591/node-was-compil...

Re: What the Hell Is a Deno?

#62

Post by tannhaeuser »

thelazydogsback wrote: post #28
hombre_fatal wrote: post #24

Earlier quoted context omitted.

This doesn't make sense to me. Javascript is a breath of fresh air after writing async code in almost every other ecosystem from Go to Java to Python to Swift. Pretty much any async code snippet in those languages can be improved by porting it to Javascript. Async/await + the ubiquitous Promise make it my go-to choice for writing anything networked. Especially over the other popular dynamically typed languages.

Well, if so I don't think it was true until recent JS versions. And I'm not sure you're picking very good languages for your async comparison. (Python? yikes.) Long-standing async support in C# or newer support in Kotlin, or almost any language with real co-routines will fair better than JS. As for as promises go, using CPS with or without Promise wrappers seems pretty old hat. More to the point I think, is that Node…

Well the async/evented execution model, and omitting synchronize, complex "happens-before" semantics, and shared memory a la Java (which JavaScript and V8 lacks) is the entire point of node.js and libuv. I agree that it doesn't fit typical complex business logic with expectations of some level of isolation, but then node.js isn't a good fit for these kind of problems. Node.js is based on CommonJS, and there are/were alternative implementations of a CommonJS runtime, including process-per-request implementations like v8cgi/TeaJs, or implementations based on Rhino (Mozilla's venerable JavaScript engine written in Java) such as Ringo which can call into the JVM, and do multithreading. Complaining about this on node.js is complaining about your own decision to use node.js really. And multithreading isn't great either for these workloads; it was originally invented for coroutines in desktop apps.

Re: What the Hell Is a Deno?

#63

Post by torb-xyz »

dvt wrote: post #13

> Javascript is great. But... in saying that it has a few quirks and can work in some unexpected ways. Typescript has just as many[1] (in fact more, as it's a superset) quirks than Javascript. I like using it (and it makes JS type-safe-ish), but it's not really some kind of paradigm shift. Not sure how I feel about import maps. They are quite literally the same thing as package.json. In fact, converting between the t…

Frankly I find TypeScript with strict mode turned on to be a safer and saner than C# and Java because of explicitly nullable types alone. I _never_ get null pointer exceptions in my own TypeScript code. Combined with fairly strict ESLint you get something that catches a lot of problems at compile time.

Of course it's still far cry from being as safe as for example Rust.

And yeah the inconsistency of JavaScript/TypeScript can be frustrating for sure. I think my dream language is one that is simply TypeScript cleaned up to be made consistent and sheds a lot the features and retains a simple core.

Re: What the Hell Is a Deno?

#64

Post by frankpf »

irjustin wrote: post #61
frankpf wrote: post #50

Earlier quoted context omitted.

> - 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 i…

> Different projects can use different versions since the modules are installed locally (inside the `node_modules` directory) I'm speaking about within the same project. It's not hard to have problems over time when node upgrades (for example[0]) or to get a different version than expected. Any project that's lived long enough runs into some sort of version mis-match where the solution is `rm -rf node_modules`. Delet…

Your original point was:

> you could not have different versions sitting side-by-side.

bundler can't do that either. You can't depend on both rails 5 and rails 6 in a single package. Most languages can't do that.

> Any project that's lived long enough runs into some sort of version mis-match where the solution is `rm -rf node_modules`.

I agree, but that's not the only solution, as I've said you could write something similar to require "bundler/setup" in JS that does version checking.

> The version of ruby and the version of the gem are explicit allowing separation.

You can specify the node version in your package.json.

EDIT: on the version checking point, I agree that this is a deficiency of npm. It probably should ship something similar to bundler/setup by default and encourage users to do

   require('npm/validatePackageVersions') # or import 'npm/...' in es6
in their top level code.

I was just pointing out that this is not a fundamental limitation of npm, and it should be fairly easy to implement in user-level code

Re: What the Hell Is a Deno?

#65

Post by wwweston »

jessaustin wrote: post #55
CalmStorm wrote: post #18

Deno's sandbox security is somewhat similar to Mandatory Access Control (MAC) implemented by SELinux and AppArmor. But it looks like not as fine-grained as MAC. In the example: deno run --allow-net myWebserver.ts With SELinux, one can specify the port range and network interface that the application is allowed to access. It also provides audit log that can be examined by the admin. Maybe there is no need to reinvent…

Am I wrong in thinking that this example specifically does not protect against the threat posed immediately preceding it? As in, one is running a script that foolishly imports a nefarious package that uploads tasty environmental variables to an evil server, which it can do when network access is not controlled. Well, what if myWebserver.ts imports that package? A more fine-grained approach that limited network access…

> A more fine-grained approach that limited network access by source file might be valuable.

This is what I think I'd like to see as well. The most common case isn't that I don't trust the program I'm running, it's that the level of trust for my dependencies plus their dependencies is essentially opaque.

Re: What the Hell Is a Deno?

#66

Post by sholladay »

I am the author of Pogo, a web server framework for Deno that has friendly APIs and is secure by default. It supports React out of the box and has the best documentation of all the frameworks.

GitHub: https://github.com/sholladay/pogo

Video tutorial: https://www.youtube.com/watch?v=Fe4XdAiqaxI

Re: What the Hell Is a Deno?

#67

Post by tannhaeuser »

osrec wrote: post #16

I like the concept of Deno, and especially love the shift away from NPM. NPM was probably the main reason I never fully embraced node.js. I truly hated the bloat of the modules folder, and the impending fragility the dependencies would bring. I like the idea of a standard library. This will hopefully only improve with time. It sort of brings the ease of use factor of PHP to a server side JavaScript environment. I'll…

The set of core libraries like express (fka connect) + dependencies is the stdlib. It was developed in early node.js days as part of CommonJS, which was an initiative for a portable/modular server-side JavaScript runtime with many implementations besides node.js (RingoJS, Narwhal, Helma, TeaJs/v8cgi). The existence of a community-driven lib effort, the portable nature of JavaScript, and the existence of choice was the entire reason I even looked into node.js.

Re: What the Hell Is a Deno?

#69

Post by jjjensen90 »

torb-xyz wrote: post #63
dvt wrote: post #13

> Javascript is great. But... in saying that it has a few quirks and can work in some unexpected ways. Typescript has just as many[1] (in fact more, as it's a superset) quirks than Javascript. I like using it (and it makes JS type-safe-ish), but it's not really some kind of paradigm shift. Not sure how I feel about import maps. They are quite literally the same thing as package.json. In fact, converting between the t…

Frankly I find TypeScript with strict mode turned on to be a safer and saner than C# and Java because of explicitly nullable types alone. I _never_ get null pointer exceptions in my own TypeScript code. Combined with fairly strict ESLint you get something that catches a lot of problems at compile time. Of course it's still far cry from being as safe as for example Rust. And yeah the inconsistency of JavaScript/TypeSc…

Have you tried Kotlin?

Re: What the Hell Is a Deno?

#70

Post by irjustin »

frankpf wrote: post #64
irjustin wrote: post #61

Earlier quoted context omitted.

> Different projects can use different versions since the modules are installed locally (inside the `node_modules` directory) I'm speaking about within the same project. It's not hard to have problems over time when node upgrades (for example[0]) or to get a different version than expected. Any project that's lived long enough runs into some sort of version mis-match where the solution is `rm -rf node_modules`. Delet…

Your original point was: > you could not have different versions sitting side-by-side. bundler can't do that either. You can't depend on both rails 5 and rails 6 in a single package. Most languages can't do that. > Any project that's lived long enough runs into some sort of version mis-match where the solution is `rm -rf node_modules`. I agree, but that's not the only solution, as I've said you could write something…

> bundler can't do that either. You can't depend on both rails 5 and rails 6 in a single package. Most languages can't do that.

You're right. Originally I was speaking about package versions which deno does solve, but then I brought in node versions w/o explicitly stating so.

That's managed/wrapped at rbenv's level which I hope deno can come up with a way to solve it. But looking at deno briefly, it appears the packages are still stored locally which leaves the deno version mismatch a possibility still.

Post reply on HN