Deno vs Node.js about deno HOT 26 CLOSED

The main difference is that Node works and Deno does not work : )

The README does give some technical specifics, but at a high level, Deno is about simplifying as much as possible in binding V8 to system APIs - which results in

• a simpler, less britle, module system and
• secure sandbox

Finally by using Golang instead of C++ as the binding language - it is much easier to add high-level functionality than it was in Node. EG http2.0 support shouldn't be more than adding some routing APIs and a few messages to the protobuf file.

from deno.

You will make it work, I believe in you! Someone creative and the master of all masters you are.. Two people I think they're Gods at small scale of this industry:

• Linus Torvalds
• Ryan Dahl

Thanks a lot and wish ya good luck!

from deno.

It’s a good question - this is a prototype to see if the TS+ url import + message passing is viable. I’m currently evaluating rust and other tech for the next sprint. Update soon.

from deno.

@ry Why golang and not rustlang？

from deno.

Rust!!!

from deno.

Yea instead of go i think Rust is future 👍 Go is good language but for such purpose I think rust suits more.

Update:

Rust is used :)

from deno.

If you do try rust. This may be a replacement for parcel. https://github.com/nathan/pax.

from deno.

@ry What is the difference between ts-node and deno?

from deno.

yeah, my question is same as @285858315 , why go not rust?

from deno.

@shobhitg where to start...

If you want to run TypeScript under Node.js without having to worry about transpiling, then ts-node is the solution for you.

Deno is a full binary runtime which uses V8 (the same as Node.js) but shares little else. By default it only allows read access to the file system and requires explicit permissions for any other access. It can load modules just based on URLs, etc... etc... It isn't Node.js + TypeScript, it is quite a bit different.

from deno.

In case anyone comes across this, running TS in node should be done with babel-node instead of ts-node since the Babel 7 TS transform is faster.

from deno.

@wenq1 Will NPM get hacked (again) everything will get infected? It did

Difference is Deno won't let that malware get far because it will block it's access to the filesystem, network, etc, a thing Node doesn't do

However simple solution for both cases: import only what you need and know what it does

from deno.

I felt like the readme gave me a pretty good idea of the differences between deno and node - is there something specific you were wondering about?

from deno.

@slikts but that requires webpack etc right? And ts node gives u error, warnings etc which is ignored by babel right?

from deno.

It just requires Babel, not webpack, and yes, typechecking would be done separately (by the editor and CI pipeline in a typical workflow).

from deno.

@slikts you can try my module https://github.com/kodhework/kawix/tree/master/core if you want something more like deno (including typescript,url imports and more) with nodejs

from deno.

import { serve } from "https://deno.land/[email protected]/http/server.ts";

Really?

Will deno.land being hacked mean all of the server using it becomes ....infected?

from deno.

@wenq1 it should be cached and probably they uses hash of original file on lock file and should probably warn you before updating the version?

from deno.

import { serve } from "https://deno.land/[email protected]/http/server.ts";

Really?

Will deno.land being hacked mean all of the server using it becomes ....infected?

Yes, unless you use lock files (look in the manual). In node's case this is even worse: if npmjs.com gets hacked, all npm packages can be infected.

from deno.

@lucacasonato Oh yeah, forgot about having all the packages in the world in the same place problem

from deno.

@wenq1 Will NPM get hacked (again) everything will get infected? It did

Difference is Deno won't let that malware get far because it will block it's access to the filesystem, network, etc, a thing Node doesn't do

However simple solution for both cases: import only what you need and know what it does

I like your reply, but I don’t agree with “setting up permission prevents malware from spreading” thingy.

Most developers will probably rely on system permissions to control access. I might be missing something but I don’t see the point of this security feature, not to mention it is slightly off the topic to my concern.

Importing an arbitrary url inadvertently has actually got a name: injection attack. That’s why things such as CORS are invented. Voluntarily importing from arbitrary source makes a worse case imho, especially “decentralized” packages (urls) are the “recommended”

from deno.

Most developers will probably rely on system permissions to control access.

Most developers don't have the knowledge or skills to properly control access of a runtime. When something like Node.js has full access to the file system, full access to the network, etc. without restriction, it becomes really hard to do.

Voluntarily importing from arbitrary source makes a worse case imho, especially “decentralized” packages (urls) are the “recommended”

You have been doing this with your browser for ever, though. You haven't gotten every website from the official Google server, where people publish register their websites.

from deno.

@wenq1 @kitsonk Is right.

Everyday, hundreds of times a day you are importing JS modules and scripts from resources all over internet. How many times do you run in trouble with a webpage because it was serving an incorrect file or package? Most likely zero, and if it did happen, you probably didn't even notice.

The reality is, Deno is removing an unnecessary "feature" (importing only from NPM) and then adding a layer of security Node didn't have. They might as well be unrelated, since Node doesn't make checks on what you download, it just blindly runs everything.

Finally, yes you could serve Deno with a fake module that is intended to do damage to your system. That would have required you to:

1. Rely on system access and file permissions(not a thing in Windows BTW).
2. Disable all of the security in Deno.

And at that point It would be really clear who to blame when something goes wrong.

from deno.

@wenq1 @kitsonk Is right.

It is not a right or wrong debate. Dev experiences are different. At least here in my office importing from random source (in virtually any language we use) will immediately trigger a red alarm, and insisting on doing so will likely result in a love letter.

Everyday, hundreds of times a day you are importing JS modules and scripts from resources all over internet. How many times do you run in trouble with a webpage because it was serving an incorrect file or package? Most likely zero, and if it did happen, you probably didn't even notice.

In fact, nil time over the past 5 years of my experience using nodejs (from its 0.12 dynasty)

The reality is, Deno is removing an unnecessary "feature" (importing only from NPM) and then adding a layer of security Node didn't have. They might as well be unrelated, since Node doesn't make checks on what you download, it just blindly runs everything.

Finally, yes you could serve Deno with a fake module that is intended to do damage to your system. That would have required you to:

1. Rely on system access and file permissions(not a thing in Windows BTW).
2. Disable all of the security in Deno.

And at that point It would be really clear who to blame when something goes wrong.

If you think simple ”-allow“ switches are you best friends rather the system permission that has been devised and implemented and improved and fine grained over the past decades, what can I say otherwise.

from deno.

@wenq1

It is not a right or wrong debate. Dev experiences are different.

I never said it was, I just wanted to elaborate on his idea.

If you think simple ”-allow“ switches are you best friends rather the system permission that has been devised and implemented and improved and fine grained over the past decades, what can I say otherwise.

As I pointed out, this is not an option in many systems.
And anyway, these are two separate matters. Unix permissions are meant to fragment the access level to your filesystem into users, and somewhat prevent side effects. But it won't prevent your code from downloading from a foreign source and then executing. It won't prevent your code from running a second server and opening a backdoor into your system.

It won't either allow you to debug your code. Since those permissions are only check on execution time, while flags are check on the compilation step.

This are not interchangeable functionalities, butrather some that can complement on each other.

from deno.

@wenq1

In fact, nil time over the past 5 years of my experience using nodejs (from its 0.12 dynasty)

Do you use NPM? If so then you are indeed downloading from “resources all over internet`. Your package has thousands of dependencies made by random people.

the system permission that has been devised and implemented and improved and fine grained over the past decades

How system permission can help with this incident in any way?
https://blog.npmjs.org/post/180565383195/details-about-the-event-stream-incident

from deno.