The Deno Company • Hacker News Board

Re: The Deno Company

#301

Post by ericlewis » Mon, Mar 29, 2021, 6:06 PM UTC

ivan888 wrote: post #269

goodoldneon wrote: post #255

Earlier quoted context omitted.

URL-based imports aren't less secure. They just make an existing attack vector more obvious. Is NPM really keeping you safe? What happens if a package maintainer is compromised and the attacker adds malicious code? The fact that URL-based imports make you uncomfortable is good. Let that discomfort guide you to adopt some extra security measures to protect yourself from third-party dependency exploits

I would argue that NPM and other centralized package managers have the ability to add security: if npm made 2FA a requirement (or publicized the status of a package maintainer having 2FA enabled like GitHub does, which is perhaps a security concern itself), there would be some assurance that a maintainer is not compromised. If we are using URL-based imports, the scope of security assurances are much broader: an SSL c…

don't get tricked into a slightly wrong URL

Re: The Deno Company

#302

Post by ericlewis » Mon, Mar 29, 2021, 6:07 PM UTC

searchableguy wrote: post #259

ivan888 wrote: post #252

Earlier quoted context omitted.

Unfortunately this won't help those who add dependencies based on shared snippets, without the context of a project. Or the innocent mistake (or choice?) of not checking the lock file into version control. But yes good point, existing projects that have checked in the integrity file will be safe against future malicious modifications of the resource

> Unfortunately this won't help those who add dependencies based on shared snippets, without the context of a project Could you expand on this? Any examples would be appreciated.

if you can magically copy and paste in code that also includes a dependency then you might have just screwed yourself if you didn't read the code of said dep (or even if you did, maybe you missed something) if it just looks like a comment then maybe your team missed it in review. its harder to reason about deps that live in deep modules.

Re: The Deno Company

#303

Post by woah » Mon, Mar 29, 2021, 6:08 PM UTC

ericlewis wrote: post #278

ravenstine wrote: post #240

A lot of people seem to think the difference between Deno and Node is trivial, but having actually used Deno, I think they're wrong. Here's why: - Typescript as a first class citizen - An actual `window` global with familiar browser APIs - Sandboxing w/ permissions - URL-based imports (no need for NPM) - Bundling into self-contained binaries - Things like top-level-await which Node.js still treats as experimental. -…

- AFAIK - it still compiles into normal JS nor does the TS team work on deno (hope I am wrong) so it's not really FCC as most would think - this doesn't make sense, its bad API design and shoe horning in a completely different paradigm is not a good idea, it should have moved somewhere less familiar and more oriented to the environment (I know that sounds weird but giving a quick answer, there are better solutions an…

Have you used it?

Re: The Deno Company

#304

Post by ericlewis » Mon, Mar 29, 2021, 6:09 PM UTC

woah wrote: post #303

ericlewis wrote: post #278

Earlier quoted context omitted.

- AFAIK - it still compiles into normal JS nor does the TS team work on deno (hope I am wrong) so it's not really FCC as most would think - this doesn't make sense, its bad API design and shoe horning in a completely different paradigm is not a good idea, it should have moved somewhere less familiar and more oriented to the environment (I know that sounds weird but giving a quick answer, there are better solutions an…

Have you used it?

I have. And I am not saying it doesn't make sense, but the GP reasoning are probably some of the worst aspects of what it can do.

edit: but at the same time now I realize why people are attracted to it, they are desirable features wether or not they actually make sense.

Re: The Deno Company

#305

Post by ericlewis » Mon, Mar 29, 2021, 6:11 PM UTC

schnable wrote: post #291

ravenstine wrote: post #240

A lot of people seem to think the difference between Deno and Node is trivial, but having actually used Deno, I think they're wrong. Here's why: - Typescript as a first class citizen - An actual `window` global with familiar browser APIs - Sandboxing w/ permissions - URL-based imports (no need for NPM) - Bundling into self-contained binaries - Things like top-level-await which Node.js still treats as experimental. -…

> An actual `window` global with familiar browser APIs This doesn't seem good?

it's not. actually I would argue any sort of global state like this should go away.

Re: The Deno Company

#306

Post by hctaw » Mon, Mar 29, 2021, 6:15 PM UTC

ravenstine wrote: post #240

A lot of people seem to think the difference between Deno and Node is trivial, but having actually used Deno, I think they're wrong. Here's why: - Typescript as a first class citizen - An actual `window` global with familiar browser APIs - Sandboxing w/ permissions - URL-based imports (no need for NPM) - Bundling into self-contained binaries - Things like top-level-await which Node.js still treats as experimental. -…

My personal view is that syntactic debate over imports (including whether it's in an import/require/url/package.json/whatever) are basically meaningless except for surface level debate. How "nice" it is to write imports is pretty worthless to me.

The structural and semantic differences between imports are a much more important discussion. Import syntax is the front end to the languages meta programming semantics. It's meta programming in the sense that your code and other code is the data, but what you're really programming is a task runner with specific instructions about how to find and satisfy the requirements to build and/or run the software.

Integrating package resolution into the language itself is a really important distinction for contemporary designs - passing that buck to external tools but simultaneously coupling them to the runtime is a mistake that I think we should learn from. Deno is a good step in that direction.

Re: The Deno Company

#307

Post by hu3 » Mon, Mar 29, 2021, 6:18 PM UTC

camdenlock wrote: post #281

Prediction: Microsoft will be buying Deno. Screencap this.

It's cheaper and gentler to the ecosystem to just add Typescript support to node and call it a day.

Re: The Deno Company

#308

Post by forty » Mon, Mar 29, 2021, 6:19 PM UTC

wperron wrote: post #286

threatofrain wrote: post #204

Earlier quoted context omitted.

Is Deno still going for TS runtime? > Deno is a runtime for JavaScript and TypeScript that is based on the V8 JavaScript engine and the Rust programming language.

Insofar as we take `.ts` files seamlessly yes -- though to be clear, one does not simply "run" TypeScript. There are no runtimes for TypeScript directly (there's AssemblyScript that _looks_ like TypeScript, but isn't exactly TypeScript) We've simply incorporated the type-checking and transpiling steps into the deno cli, making it super simple to get going, no config needed.

Exactly. And I guess the package still needs to be compiled to JS before deploying to production? To avoid shipping a full TS compiler on a production server which would be a crazy thing to do.

Re: The Deno Company

#309

Post by forty » Mon, Mar 29, 2021, 6:23 PM UTC

lucacasonato wrote: post #223

threatofrain wrote: post #211

Earlier quoted context omitted.

So Deno is still committing to TS runtime?

Heck yeah

Was does a TS runtime means anyway? Doesn't checking types at run time rather than at compile time a pure loss?

Re: The Deno Company

#310

Post by LunaSea » Mon, Mar 29, 2021, 6:40 PM UTC

ravenstine wrote: post #240

A lot of people seem to think the difference between Deno and Node is trivial, but having actually used Deno, I think they're wrong. Here's why: - Typescript as a first class citizen - An actual `window` global with familiar browser APIs - Sandboxing w/ permissions - URL-based imports (no need for NPM) - Bundling into self-contained binaries - Things like top-level-await which Node.js still treats as experimental. -…

Highly disagree on the impact of those points.

> - Typescript as a first class citizen

This doesn't seem to add much besides having to install `tsc` or `ts-node` and also not having the choice of the TypeScript compiler version you use.

- An actual `window` global with familiar browser APIs

Node.js has a `global` global object and the only API I would understand having in common with the `window` object is the `fetch()` API.

- Sandboxing w/ permissions

Sandboxing is so basic that any large project will have to enable all permissions.

- URL-based imports (no need for NPM)

I would consider this a disadvantage.

- Bundling into self-contained binaries

Again, I would say that this is rarely useful in a world where a lot of operations use container technology.

- Things like top-level-await which Node.js still treats as experimental.

This is trivially solved by anonymous self-executing functions

- Better-designed APIs than the Node standard lib (esp. when it comes to promises instead of callbacks)

I think that this is the strongest advantage, however I would argue that this is not a reason to start a completely new backend platform. Also, I think that it might be a disadvantage in some high performance scenarios because Promises are much, much slower than callbacks currently.