Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

From Node to Deno

dev.to

Post reply on HN
Print view View original

71–80 of 100 posts

Re: From Node to Deno

#71

Post by LunaSea »

sramam wrote: post #44
ljackman wrote: post #33

It looks like a good evolutionary improvement over Node.js. However, I have a concern about its security claims. Perhaps someone on the project can allay these concerns. My brief skimming of its site indicates that its security model is based around the ability to disable, say, network access for whole Deno programs. However, does it allow starting up with network access, allowing a subset of the program to handle it…

Permissions are a whitelist. While the grant is a blanket grant to a program and all dependencies, typically, a well behaved program will seek a limited scope of permissions. Like " https://my-program.com" , " https://preferred-analytics.com" etc. This prevents dependencies from using call back locations that are outside the permitted list, preventing much of the nefarious activity they can dream up. If a dependency…

The file system module's permissions are however still vulnerable to symlinks for example:

https://github.com/denoland/deno/issues/2318

Re: From Node to Deno

#72

Post by jariel »

cozuya wrote: post #53
hn_throwaway_99 wrote: post #12

I'm really curious about whether people think Deno will succeed. Node certainly has its warts, but I feel like with recent improvements in the JS language and Typescript that Deno doesn't really solve problems people have nowadays. I don't think the decoupling from NPM and the dependency management approach (or lack thereof) is really a thing that most developers want. NPM certainly had a bunch of "dumpster fires" fo…

It will succeed if it handily wins side by side benchmarks, its that simple.

No, performance is not the issue most of the time.

For most systems, the raw performance of the JS just is not a bottleneck.

Re: From Node to Deno

#73

Post by [deleted] »

hn_throwaway_99 wrote: post #58
sramam wrote: post #44

Earlier quoted context omitted.

Permissions are a whitelist. While the grant is a blanket grant to a program and all dependencies, typically, a well behaved program will seek a limited scope of permissions. Like " https://my-program.com" , " https://preferred-analytics.com" etc. This prevents dependencies from using call back locations that are outside the permitted list, preventing much of the nefarious activity they can dream up. If a dependency…

> Importantly, the user is explicitly aware of these & controls it in an absolute sense, at run time. I mean, I guess I see value there for the use case of "I want to download a script to run locally on my machine" type of thing, but for the most common use of Node, i.e. I'm running a server process, does this really even matter?

[deleted]

Re: From Node to Deno

#75

Post by jariel »

dingdingdang wrote: post #29
hn_throwaway_99 wrote: post #12

I'm really curious about whether people think Deno will succeed. Node certainly has its warts, but I feel like with recent improvements in the JS language and Typescript that Deno doesn't really solve problems people have nowadays. I don't think the decoupling from NPM and the dependency management approach (or lack thereof) is really a thing that most developers want. NPM certainly had a bunch of "dumpster fires" fo…

The big deal here is security by default as enforced by the runtime (deno) itself - there is afaik none other doing anything remotely as cool anywhere. It in effect makes it super safe to run code since you have to explicitly allow the various levels of system access. Also makes the system fundamentally unattractive to malware authors whereas installing modules via node.js is like leaving your front door open and tak…

Most folks running Node.js instances have control over all of the software they are running and 'security' in this sense just isn't a huge concern. Obviously, more security is alwasy better all things being equal, but it's not the big issue with Node.js.

It seems that Deno is probably a nicer, overall version of Node, and if we were 10 years ago, undoubtedly, we would chose Deno. But we're not, we have massive installed bases and operating capabilities, so the choice is less obvious.

Re: From Node to Deno

#76

Post by derision »

hn_throwaway_99 wrote: post #15
derision wrote: post #13

Earlier quoted context omitted.

I've used a number of ORMs in the past and have not had a great experience, but recently have been using Eloquent with laravel and it's really great

I just think that at the end of the day, for any moderately complex system under non-trivial load, the idea that you want to "hide the complexity of SQL" from the service developer is an absolutely flawed premise.

It's not just about hiding the complexity of SQL. You also get flexibility you don't have when writing SQL directly. For example, our laravel app uses pgsql in production environments but uses sqlite in our CI environment. We also migrated off of mysql which consisted only of changing a configuration value and verifying no issues by running tests

Re: From Node to Deno

#77

Post by tosserup478 »

thosakwe wrote: post #47
truth_seeker wrote: post #27

Few things comes to my mind if you are moving from NodeJS to Deno: 1. Deno lacks the library eco system which is required to build a production level app today. I am not saying it cant be done. Just think of the different third party service integration modern application has to do, their maintainance and testing by individual vendors or open source contributors ! Blogs mentions few DB driver libraries, i highly doub…

Solely addressing #1 here, and this may come off harsh, but I think it's ridiculous to expect Deno to match the library ecosystem of Node on day 1. That's just literally impossible, but whenever a new language or runtime is released, it manages to become the most prominent question/concern. It also is something of a moot point anyways, because people pushing something into production already are probably not using so…

Well, you should scratch language there. kotlin did manage to start with the huge ecosystem of Java without hassle

Re: From Node to Deno

#78

Post by thegagne »

hn_throwaway_99 wrote: post #59
ljackman wrote: post #45

Earlier quoted context omitted.

The whitelisting looks great. Even with the remaining concerns I raised in the other comment, the ability to whitelist only allowed domains for network connections is a massive step up security-wise, even if they are allowed for the entire program (until revoked globally).

I'm not an expert on this in any sense, but would it be possible to add this into Node at the OS level, e.g. make use of network namespaces to restrict outbound network access?

Yeah, the OS or network firewall can do this, but security happens in layers, and to me it makes sense that an app config is the place to put a whitelist for the apps network needs.

If I was just spitballing an ideal scenario, I’d suggest that each module would define what it needs, and then some sort of central file would be built to hold the aggregate of them (urls / modules), for easy scanning.

The reason I’d rather have it in the app is if you are switching platforms, you don’t need to worry about firewall configs being exactly the same, or being fine grained. Also you might be whitelisting up ranges on the network level, then locking it down further on the app level.

Re: From Node to Deno

#79

Post by recursive »

kingdomcome50 wrote: post #38
seanwilson wrote: post #23

Earlier quoted context omitted.

I guess I mean it's never going to be answered because there is no short answer. It's like asking: what's the best programming language?

I disagree with this sentiment. The use-cases for an ORM are straight-forward. It's more like asking, "which tool is best for getting this nail into this piece of wood?" What most people discover to be the greatest benefit of using an ORM is the "mapper" bit (converting tabulated data into an object graph and visa versa) and, to a lesser degree, change-tracking. Somewhat ironically, the overwhelming majority of the t…

Static type safety is one difference.

Re: From Node to Deno

#80

Post by draw_down »

xkapastel wrote: post #16
hn_throwaway_99 wrote: post #12

I'm really curious about whether people think Deno will succeed. Node certainly has its warts, but I feel like with recent improvements in the JS language and Typescript that Deno doesn't really solve problems people have nowadays. I don't think the decoupling from NPM and the dependency management approach (or lack thereof) is really a thing that most developers want. NPM certainly had a bunch of "dumpster fires" fo…

This is puzzling to me because I had the opposite reaction: among other things, Deno solves an incredibly important problem with Node, which is the complicated configuration used with most projects. Deno can perform, out of the box, many of the things you'd need to configure Webpack + Typescript to do: SUBCOMMANDS: bundle Bundle module and dependencies into single file cache Cache the dependencies completions Generat…

Perhaps this is a start of a way out of the tiny-package madness in the Node ecosystem.
Post reply on HN