[tmikaeld]

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.

[Griffinsauce]

> smaller, faster, purpose-made modules and frameworks that don't rely on thousands of dependencies.

This isn't necessarily enforced by Deno itself right? That seems like more of a side-effect from the self-selection of its users. Once the ecosystem grows and the all the "normies" come in, this doesn't seem guaranteed at all.

[tmikaeld]

Right, like I wrote, it's up to each developer, but i really do hope the trend continues.

[forty]

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.

[tehbeard]

> 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 snowflakes ( eg the web crypto api as browsers use vs nodes crypto module) and being permission focused rather than access by default. Feel free to debate the merits of that instead.

[forty]

Sorry again, I see that I forgot to answer your good points about crypto api and permission.

- I think the permission thing is bullshit (and probably a reason enough not to take deno seriously). I'd be interested to be proved wrong (I work on backend security so this is sincere), but it feels like traditional server side isolation mechanims (cgroup, namespace, outgoing http proxy, ...) are well known, work well, seem safer and more flexible and are not nodejs specific, so are better in any system that are not running JS only backend (probably any reasonably large system)

- nodejs now supports the webcrypto API - experimentally (and for what it's worth, I liked the nodejs one better ^^)

[forty]

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.

[wruza]

What's the real problem with 100 dependencies and size of a folder? I can name only non-cached install time, which is irrelevant for a regular developer.

What is "shitty"? Do we have something better than that? Like one big web framework which is both maintainable, DCE-able and solved everything frontend ever needs? Why further modularization of this theoretical module would be shitty?

Edit: Also, what are we comparing to? VS202x takes several gigabytes for a base set of libraries. Xcode is tens of gigabytes now, afaik. Qt is few gigabytes. Enterprise systems also take few gigabytes at least. But when node_modules takes more than 80mb to produce a 0.5mb bundle for a webscale product, we start to complain. I don't understand.

[forty]

I don't mind 100 dependencies maintained by a single large community/project. I hate 100 dependencies each maintained (or not maintained) by single amateur devs (not negative to be clear, I just mean they are not paid for this).

[redisman]

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

[forty]

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

[andrew_]

There are people who exist that just like the language.

[evv555]

JS is already a popular language for "DevOps" cloud scripting. Deno would be a better fit for these kinds of use cases for the same reason Go is a good fit and there's already market share.

[andris9]

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 install. It turned out to have other benefits as well. For example, it is far easier to support older platforms (Nodemailer supports all Node.js versions since Node v6) if your dependencies do not start using the latest ES syntax overnight.

[andrew_]

nuance required:

- vet pnpm and the multiple dependency install

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

[dmitriid]

"smaller, faster, purpose-made modules" directly leads to "thousands of dependencies".

[pjmlp]

My relevant stars are what IT decides to install on devenvs or is part of RFPs technical requirements.