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

31–40 of 116 posts

Re: State of the Web: Deno

#31

Post by redisman »

forty wrote: post #24
tmikaeld wrote: post #10

Earlier quoted context omitted.

I beg to differ, Deno adds some fire to quality modules becoming the better norm for javascript on the server-side, smaller, faster, purpose-made modules and frameworks that don't rely on thousands of dependencies. Of course, it's up to each and every developer that contribute, but looking at some of the most up-stared Deno modules, that's the direction it's heading.

My understanding is that one of the goal of deno is to be more compatible with the Web. As a backend only dev I don't find that great, I rather have clearer separation between quality backend modules and shitty 100-dependencies web modules ;) Also I don't want smaller modules. I want bigger and better maintained modules with few dependencies. Small modules is what makes npm ecosystem not that great.

Thing is - unless you really love JS for some weird reason, then deno is competing with established languages like “go” that have a great web server in the standard library. In addition to competing with node which is fine! Apart from it’s insane package management situation. Which most people just kind of shrug at

Re: State of the Web: Deno

#32

Post by lewisl9029 »

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…

Re: the first linked issue, does it only affect scripts that require the --allow-run permission in some form? Are the other permission types (--allow-read/write/net/etc) also affect by this or similar issues somehow?

The 2nd issue does seem concerning to have taken so long to resolve.

Re: State of the Web: Deno

#33

Post by codeptualize »

pjmlp wrote: post #9

Deno is an interesting experiment, but I don't see it ever replacing nodejs, beyond the nodejs ecosystem eventually adopting it. It is the usual case of worse is better, and nodejs for better or worse, does it job.

You are probably right. It would be nice if node adopted it, I agree that it's unlikely to replace, but I do hope it can at least coexist.

I use Deno mainly for simple scripts with Typescript. In nodejs I always find myself having to configure the environment, while in Deno it mostly just runs.

I also like the Deno standard library.

Re: State of the Web: Deno

#34

Post by jsmith99 »

galaxyLogic wrote: post #3

Why is it that ES6 modules load only asyncly but Node.js CommonJS modules only syncly? I find sync is often simpler to code for.

Node modules are usually on the local filesystem and load quickly, whereas loading an ES6 module in a browser requires a network trip.

Re: State of the Web: Deno

#35

Post by goldsteinq »

lewisl9029 wrote: post #32
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…

Re: the first linked issue, does it only affect scripts that require the --allow-run permission in some form? Are the other permission types (--allow-read/write/net/etc) also affect by this or similar issues somehow? The 2nd issue does seem concerning to have taken so long to resolve.

Yes, it exploits `--allow-run=whatever` + `--allow-write=whatever` to execute arbitrary code outside of the sandbox.

The problem with the Deno security model is that it’s hard to predict how granting any specific permission would affect overall security. For example, it may seem to be kinda reasonable for an application to ask for `--allow-write=~/.config` to create config directories & files, but it’s probably exploitable to escape the sandbox. Is `--allow-env` + `--allow-write=whatever` dangerous? I don’t know. If Deno runtime spawns a subprocess at some point, it could be used to execute arbitrary code via `LD_PRELOAD`. Is there a guarantee that Deno runtime will never spawn subprocesses? There is no way to know.

Re: State of the Web: Deno

#37

Post by nexuist »

eyelidlessness wrote: post #5

> V8 is a sandboxed language False, V8 is a JS runtime with sandboxing built into its core design. It’s not a language and it doesn’t guarantee sandboxing the JS runtime. > that makes it impossible False, breaking out of the sandbox is trivial in environments which allow native addons.

I am very interested in this. Are there existing exploits for deno? Using a stock out of the box configuration, can you execute some code that breaks its permission model?

Has deno undergone some kind of security audit to verify its claims irt security?

EDIT: I see some referenced issues in comments down below involving the --allow-read/write flag. I'm not interested in that. I'm interested in if anyone can prove that with no permissions granted at all, they can break out of the sandbox and achieve ACE.

Re: State of the Web: Deno

#38

Post by wruza »

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.ts fail because typescript is not ready for type:module until 4.6. I can't even recall now what's with Babel, I guess the same issue, since I'm using it to strip types in development builds. And then there are modules from ESM movement which are incompatible with this state of things. I understand their idea that nothing will move if not kicked further, but I hate it in real production where I can't upgrade because the author said so. Once ESM transition will be done, Deno will get much more modules, I believe. But right now the friction is unbelievable. Idk why they can't just allow all of the things like imports, requires, sync/async, side effects thing at least for a while, to cooperate. It's a matter of a form, not of a content. And there is no reason seemingly why nodejs couldn't make main.js async by default — sync modules would return a resolved promise. There is so much circus in all of that, which makes you pull hairs for weeks of a setup process.

^ I'm bundling server-side for hmr/watch functionality in a monorepo with many cross-side shared code/modules.

Re: State of the Web: Deno

#40

Post by jcelerier »

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
Post reply on HN