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

71–80 of 116 posts

Re: State of the Web: Deno

#71

Post by forty »

tehbeard wrote: post #29
forty wrote: post #24

Earlier quoted context omitted.

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.

> quality backend modules and shitty 100-dependencies web modules As someone who works in both stacks, I have seen incredibly shitty backend modules that dump 400mb of node_module deps. I'd even argue node ecosystem is at fault because frontend adopted their package manager and "best practices". So off of your high horse. And Deno's goal of web compatible is in using web APIs where applicable instead of special snowf…

Okay, well my experience is different, sorry :) maybe it had more to do with the people working on the FE teams vs the BE teams than with ecosystem, but FE always ended up downloading half of npm, while BE was much more reasonable.

I'm sure not everyone use React&co, so you are probably right, I should not have generalized too quickly.

Re: State of the Web: Deno

#72

Post by forty »

redisman wrote: post #31
forty wrote: post #24

Earlier quoted context omitted.

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

Exactly. If you are going to part with the very large node ecosystem, I'm not sure why you would keep JS :)

Re: State of the Web: Deno

#73

Post by Longwelwind »

dmitriid wrote: post #65
Longwelwind wrote: post #63

Earlier quoted context omitted.

> Where do you et these lockfiles files from? At dev time, you generate a lock file of the hashes of your dependencies. You commit this file to your code repository. When getting dependencies, the hash of the downloaded dependency is compared to the one in the lockfile.

> At dev time, you generate a lock file of the hashes of your dependencies. So. At dev time. You download random files from random urls via Deno. Compared to: At dev time you download files from a trusted repository. https://news.ycombinator.com/item?id=29871936

NPM is not a trusted repository, I think. There are no checks done to the content of the packages uploaded by users. It's up to you to make sure that what you add to your project doesn't contain malware/vulnerabilities.

If you use a lockfile, downloading a package from NPM or directly using a random URL is conceptually the same, since they are both untrusted sources. Having a lockfile will ensure that if you download a dependency to review it for vulnerabilities, later re-downloads of the dependency will not have changed files.

Re: State of the Web: Deno

#74

Post by vorticalbox »

dmitriid wrote: post #66
vorticalbox wrote: post #60

Earlier quoted context omitted.

> 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 '

This brings us back to the fact that Deno loads random files from random URLs with no way to change it. https://news.ycombinator.com/item?id=29871936

sure but is that not how a browser works?

for example to add bootstrap to a site you import like this

https://cdn.jsdelivr.net/npm/bootstrap@5.1.3/dist/js/bootstr..." integrity="sha384-ka7Sk0Gln4gmtz2MlQnikT1wXgYsOg+OMhuP+IlRH9sENBO0LRn5q+8nbTov4+1p" crossorigin="anonymous">

which is exactly the same as deno's "loads random files from random URLs"

Re: State of the Web: Deno

#75

Post by andrew_ »

_jplc wrote: post #55

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 in…

That built in linter leaves a lot to be desired. If you're a big big fan of being told how your code should be formatted, then it's a good fit. however, if you're the slightest bit opinionated, you still have to implement ESLint and jump through those hoops.

Re: State of the Web: Deno

#76

Post by andrew_ »

andris9 wrote: post #49
forty wrote: post #24

Earlier quoted context omitted.

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.

I maintain Nodemailer and moved to the zero dependency model years ago (Nodemailer only has some development dependencies needed to run the test suite but no production dependencies). Mostly though, because npm versions of that time were super slow – aggregating all modules into a single package took install time to around a single second while the same code separated into modules took like 15 seconds or more to inst…

nuance required:

- vet pnpm and the multiple dependency install

- consider bundling with roll-up for a dependency free userland experience and compare

Re: State of the Web: Deno

#77

Post by andrew_ »

forty wrote: post #72
redisman wrote: post #31

Earlier quoted context omitted.

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

Exactly. If you are going to part with the very large node ecosystem, I'm not sure why you would keep JS :)

There are people who exist that just like the language.

Re: State of the Web: Deno

#78

Post by skinkestek »

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…

So, I have a highly upvoted answer below but I'm going to humble myself a bit (smart anyways when I'm wrong and definitely better than having others do it).

I read through your bug reports now.

These are sound and very very useful.

I must admit I pattern matched on your language and answered based on that below and therefore my answer even if it is maybe somewhat(?) correct is extremely wrong in tone and what it implies.

Sorry.

I still think that it would be better if you were somewhat more specific. All in this thread seems to be related to subprocesses, which is a scary thing anyways for anything internet facing, isn't it.

Re: State of the Web: Deno

#79

Post by tomxor »

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.

NodeJS's ecosystem looks like more of a liability and less of an asset to me each passing day.

This perspective is making Deno feel easy for me to jump to for my next backend project, now that I'm actively fighting against dependencies.

Re: State of the Web: Deno

#80

Post by Zababa »

_jplc wrote: post #55

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 in…

> 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

There is an object-capability model in the upcoming OCaml 5.0, however it's only in the Eio library, that deals with IO https://github.com/ocaml-multicore/eio#design-note-object-ca.... There's also Emily, a subset of OCaml based on POLA (Principle of Least Authority) https://www.hpl.hp.com/techreports/2006/HPL-2006-116.pdf. I'm unaware of any plain to extend OCaml in that direction though.

Post reply on HN