Live data from Hacker News

A Secure Runtime for JavaScript and TypeScript Built with V8, Rust, and Tokio

deno.land

31–40 of 68 posts

Re: A Secure Runtime for JavaScript and TypeScript Built with V8, Rust, and Tokio

#32
post #12

As a long time Node.js developer I took a look at the project but it's still a really half-baked implementation of the security flags. You almost always end up flipping all security switches off because your application needs every feature (network, filesystem, etc). No package signing, no flags per module, no syscall whitelisting, etc.

You turn all permissions on if you are actually using it as if it is Node for writing servers. But in the case when you are using a (potentially untrusted) code snippet to perform certain operations (like encode/decode base64 values), you do might want a sandbox. (For the case of Node-like usage, we actually also have a basic implementation of whitelisted directories/files for certain permissions, though not perfect…

In world of hypervisors, containers, apparmors ..., is sandbox really a significant advantage over nodejs?

Actually I saw yt presentation and it didn't convinced me to switch from nodejs. The differences to nodejs are so little, specially when you're using typescript already. The only significant change is "es modules" with ability to resolve modules from url (plus the sandbox).

Still big kudos to Ryan for nodejs.

Re: A Secure Runtime for JavaScript and TypeScript Built with V8, Rust, and Tokio

#34
post #31

Careful with Deno, performance is still low: https://user-images.githubusercontent.com/3397140/48649635-8...

That's just FUD through a synthetic benchmark by the person who wrote uWS after he approached Ryan and Ryan wouldn't do everything he asked for...

Re: A Secure Runtime for JavaScript and TypeScript Built with V8, Rust, and Tokio

#35
post #34
post #31

Careful with Deno, performance is still low: https://user-images.githubusercontent.com/3397140/48649635-8...

That's just FUD through a synthetic benchmark by the person who wrote uWS after he approached Ryan and Ryan wouldn't do everything he asked for...

Running a local benchmark to compare Node.js and Deno gave me the same magnitude of performance difference. I like the concepts behind Deno but the performance should stay a top priority. Even more for a new technology that is looking for future adoption. If Deno gets faster than Node.js, I adopt it. If it stays 5x less performant than Node.js, I skip it.

Re: A Secure Runtime for JavaScript and TypeScript Built with V8, Rust, and Tokio

#36

For the inevitably "what differentiates this from node?" Single executable Allows imports from url File system & network Sandboxing is controlled with flags Dies on uncaught errors https://deno.land/manual.html#introduction

>Dies on uncaught errors

how can JS programmers deal with this?

Re: A Secure Runtime for JavaScript and TypeScript Built with V8, Rust, and Tokio

#37
post #36

For the inevitably "what differentiates this from node?" Single executable Allows imports from url File system & network Sandboxing is controlled with flags Dies on uncaught errors https://deno.land/manual.html#introduction

>Dies on uncaught errors how can JS programmers deal with this?

... catch the errors?

Re: A Secure Runtime for JavaScript and TypeScript Built with V8, Rust, and Tokio

#39
post #31

Careful with Deno, performance is still low: https://user-images.githubusercontent.com/3397140/48649635-8...

That bench has deno at 0.2, it's now at 0.10, though I have no idea how much performance work has been done.

Performance should improve over time, there's no fundamental reason from what I understand that it shouldn't be as fast or faster than node.

node has had 10 years of work and performance effort from so many people and organisations.

Re: A Secure Runtime for JavaScript and TypeScript Built with V8, Rust, and Tokio

#40
post #22
post #16

Earlier quoted context omitted.

It's not even 1.0 yet.

I'm not talking about the maturity of the project but more about the concept of the feature flag for security.

I like the idea from a ux perspective. It puts the control in a place where the user runs the code.
Post reply on HN