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

State of the Web: Deno

byteofdev.com

Post reply on HN
Print view View original

51–60 of 116 posts

Re: State of the Web: Deno

#51

Post by goldsteinq »

e12e wrote: post #42
goldsteinq wrote: post #16

Deno’s permission system is broken, you shouldn’t rely on it. Deno developers consistently ignore security issues, high priority bugs take months to fix. https://github.com/denoland/deno/issues/11964 https://github.com/denoland/deno/issues/9750 API-based access control can’t possibly work because it’s nearly impossible to predict the effect of any single permission. For example, “permission to run specific command” m…

I'm not overly concerned that allow-run leads to possible elevation, I'm more interested if: > deno run --allow-read=./assets works as intended - preventing most execution of local code, and prevents writing to disk. I think it's a useful real-world use-case, that is complicated to copy with nodejs. That said, I think one should still be wary of running random code - but at least deno makes it a little easier for hon…

Read permission for a specific (non-system) directory is probably fine.

Re: State of the Web: Deno

#52

Post by wruza »

jcelerier wrote: post #40
wruza wrote: post #38

I'd like to use some modern common ground for js/ts development, but the entire toolchain is not ready for this, somehow turning it into chicken/egg problem. Typescript, webpack, babel contribute to that. For last 10 days I tried to pull my generic project as much to the top as I could^, but modules are still commonjs, because to use imports I have to "type":"module" in package.json, which makes webpack.server.config…

Reading that makes me so happy to just have to open QtCreator, hit "new project" and get rolling

You can do that with nodejs too, e.g. edit package.json and main.js in vscode, hit hotkey to npm install hit hotkey to run node ./main.js. This is what I'm doing at the day job.

What I'm trying to do there is to have a client and server in the same ./src, hot-reloaded module-wise on "save" only when a relevant part changes, and vscode to typecheck both at the same time. The language similarity is also a goal. It's a little more than just a traditional lazy-compile-restart cycle.

Non-monorepo non-ts-only guys do not experience my issues, because they only have one environment per project (or per src-), and don't try to make their build configs incompatible with other parts of a build system. I tried to push it as far as it could go to evaluate the state of things for writing non-standard slightly different web apps. To make a ts-react app, they just use CRA, for a backend they just use node main.js.

But anyway this shows how interdependent this ecosystem is, instead of being full of orthogonal possibilities.

Re: State of the Web: Deno

#53

Post by afiori »

greggman3 wrote: post #22
afiori wrote: post #13

Earlier quoted context omitted.

there is not really a difference between a url to a registry and a npm package name. the different approach would be yarn's saving zipped versions of packages, I don't know if deno supports it

There is one difference. I know npm keeps published versions. I don't know that random URL keeps versions. Caching locally doesn't help. I expect my code to work for others. Of course using any source is nice. node also allows this, just put a git URL as your dependency.

URLs to a registry keep published versions if the registry keeps published versions.

Your argument is that npm is more trustworthy than another random registry, this is likely true but also a matter of opinion.

Re: State of the Web: Deno

#54

Post by skrebbel »

usea wrote: post #46
skinkestek wrote: post #44

Earlier quoted context omitted.

Lots of weasel words here and you don't answer directly. It still seems to me that a Deno script running with necessary permissions will be a huge hurdle compared to running a Node script which by default has al permissions. Edit : Also I'm seriously fed up with tech community cr#pping at everything good because it isn't perfect. Today with Node any random package can download any DLL as long as it is novel enough to…

Painting any criticism of deno as simply the work of haters is much more a tactic of stopping thought. Whether or not ideas and discussion are negative or positive is not relevant at all. When they're presented in some detail and in good faith, we should tackle them in turn. This encourages thought, discussion, and understanding among all.

GP's comment is in a thread that starts with "Deno’s permission system is broken, you shouldn’t rely on it".

Not relying on Deno's permission system will, in practice, mean just allowing everything or using Node instead of Deno. I can't for the love of god understand why that's better than using a permission system that provides some more protection than just about any other currently-commonly-used backend dev platform. Nobody at Deno is suggesting that their permission system solves all your security risk.

I bet "just allow everything" is not what the top poster intended but that's the takeaway. How many Node deployments do you know that use OS-level protections to eg disallow Node from spawning child processes?

Re: State of the Web: Deno

#55

Post by _jplc »

Think of it as Node.js + Typescript, but you don't have to think about configuring the typescript compiler, linter and formatter as everything is bundled in the `deno` binary.

Don't think about syncing that formatting/linting/import aliases configuration with VSCode, all you need is the Deno plugin and you'll get all the benefits of working with TS on VSCode.

Packages are obtained (and heavily cached) from any URL instead of relying on a centralized repository. Obtain your dependencies as you want, whether it's Deno's proxy, directly from raw.githubusercontent.com, your own http server, or any other thing accessible thru an URL.

At the end, the permission system is the least interesting part of the project imho. It's useful, because if you're doing a CLI that just receives stdin, processes it, and prints to stdout, you can block any disk and network access, but apart from that it's really limited because the nature of JS itself. (Maybe for the next trendy language we could think about the Object-capability model before it's too late. https://en.wikipedia.org/wiki/Object-capability_model)

The thing I value the most is consistency and having a fully working development environment out of the box to be productive.

Re: State of the Web: Deno

#56

Post by norman784 »

dmitriid wrote: post #7

Mentions security and then completely glosses over security in the section on "yeah, we load random modules from URLs but it's okay because most Deno registries are immutable and we cache files"

If you care about security you will have setup your own node package registry with a curated/audited list of dependencies, then you need to point to the registry for the dependencies and maintain the registry.

With deno it should be easier to do this, you setup your own cdn, just upload plain js files and point it from your import map[1], the browser will take care of download/cache them all.

[1] https://wicg.github.io/import-maps/

Re: State of the Web: Deno

#57

Post by dmitriid »

lucacasonato wrote: post #41
dmitriid wrote: post #7

Mentions security and then completely glosses over security in the section on "yeah, we load random modules from URLs but it's okay because most Deno registries are immutable and we cache files"

And we have lock files to verify integrity. This is no different to module loading in Node. If you don’t trust your registry, you should not be loading code from it!

> And we have lock files to verify integrity.

Where do you et these lockfiles files from?

> This is no different to module loading in Node.

This is very much different from module loading in Node: https://news.ycombinator.com/item?id=29871936

> If you don’t trust your registry, you should not be loading code from it!

So you immediately pinpointed the difference: with Node I can run my own registry and easily set up npm/yarn to never load packages from anywhere else. Deno loads code from random urls.

Re: State of the Web: Deno

#58

Post by dmitriid »

norman784 wrote: post #56
dmitriid wrote: post #7

Mentions security and then completely glosses over security in the section on "yeah, we load random modules from URLs but it's okay because most Deno registries are immutable and we cache files"

If you care about security you will have setup your own node package registry with a curated/audited list of dependencies, then you need to point to the registry for the dependencies and maintain the registry. With deno it should be easier to do this, you setup your own cdn, just upload plain js files and point it from your import map[1], the browser will take care of download/cache them all. [1] https://wicg.github.…

> If you care about security you will have setup your own node package registry with a curated/audited list of dependencies, then you need to point to the registry for the dependencies and maintain the registry.

Exactly. And it's quite easy to do.

> With deno it should be easier to do this, you setup your own cdn, just upload plain js files and point it from your import map

I was waiting for the inevitable just.

- Just set up your own CDN.

- Just upload a plain js file there (where do I get those files from?)

- Just point to dependencies using a feature that, quote "is not a W3C Standard nor is it on the W3C Standards Track"

- And then the browser... record scratch who said anything about a browser?

Re: State of the Web: Deno

#59

Post by dmitriid »

afiori wrote: post #53
greggman3 wrote: post #22

Earlier quoted context omitted.

There is one difference. I know npm keeps published versions. I don't know that random URL keeps versions. Caching locally doesn't help. I expect my code to work for others. Of course using any source is nice. node also allows this, just put a git URL as your dependency.

URLs to a registry keep published versions if the registry keeps published versions. Your argument is that npm is more trustworthy than another random registry, this is likely true but also a matter of opinion.

> URLs to a registry keep published versions if the registry keeps published versions.

Yes. Have you've ever heard of running your own registry? It' quite easy to do and most companies do it prcisely because they want to a) keep published versions and b) prevent things like colors/fake.js

Literally no one who promotes Deno has yet shown how to do the same with Deno beyond "yeah, you check in all your node_modules dependencies into Git".

Re: State of the Web: Deno

#60

Post by vorticalbox »

dmitriid wrote: post #57
lucacasonato wrote: post #41

Earlier quoted context omitted.

And we have lock files to verify integrity. This is no different to module loading in Node. If you don’t trust your registry, you should not be loading code from it!

> And we have lock files to verify integrity. Where do you et these lockfiles files from? > This is no different to module loading in Node. This is very much different from module loading in Node: https://news.ycombinator.com/item?id=29871936 > If you don’t trust your registry, you should not be loading code from it! So you immediately pinpointed the difference: with Node I can run my own registry and easily set up n…

> Where do you et these lockfiles files from?

I don't know about any lock files but the `version` it locked via the import url E.G import R from 'https://deno.land/x/rambda@v7.0.1'

Post reply on HN