Live data from Hacker News

What the Hell Is a Deno?

breadth.substack.com

11–20 of 151 posts

Re: What the Hell Is a Deno?

#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 two takes about 20 lines of code[2]. I'd bet my bottom dollar that everyone's going to use them, which is going to lead to exactly the same types of problems as Node.

[1] https://blog.asana.com/2020/01/typescript-quirks/

[2] https://github.com/WICG/import-maps/issues/60

Re: What the Hell Is a Deno?

#14
post #2

Node => Deno => Done. One can simply say, 'Deno is like Node but done right'.

I think its only the natural progression. there are definitely some flaws with it, it isn't perfect. However, the tradeoffs really do seem to swing in favor of deno.

It's too little, too late. Deno today might have been more interesting years ago when you had to write your own Typescript definitions for every library because TS had no traction.

In 2020, Deno is just a stone's throw from `ts-node server.ts`.

And the permissions system lacks the granularity to be useful.

Re: What the Hell Is a Deno?

#15

The author already inflicted one of the worst "worse is better" victories I can think of in the history of computing. Now he's fighting his own monstrosity.

Author of the artcile (me) or Author of Deno?

I think he means Ryan Dahl

Anecdotally, there are several languages (French, "Argentinian" Spanish to name a couple) where it's common to re arrange the syllables of the words backward-ish (More often than not for slang - argot for France, lunfardo in Argentina - uses).

Re: What the Hell Is a Deno?

#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 be watching Deno very closely these next few months!

Re: What the Hell Is a Deno?

#17
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…

100% agree that typescript has it quirks and definitely agree about import maps most likely going to be the way you use deno.

However there are tradeoffs with everything you use.

It really comes down to which tradeoffs are the right ones for you, which may not be the same for someone else.

Re: What the Hell Is a Deno?

#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 the wheel but just use some form of MAC if you really care about security.

Re: What the Hell Is a Deno?

#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 is trying to create a 'map' file to consolidate the 'distributed version' issue.

Sadly, Ruby's Bundler has solved this for years and while I love TypeScript, I'm always saddened by the state of package management in the Node space.

I'm not saying Bundler perfect, but its basis with canonical lock and ability to have side-by-side versions allows me not to think about that issue.

Post reply on HN