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

Deno 1.10 Release Notes

deno.com

Post reply on HN
Print view View original

61–70 of 157 posts

Re: Deno 1.10 Release Notes

#61

Post by seumars »

oblio wrote: post #23
cztomsik wrote: post #20

Earlier quoted context omitted.

deno is definitely better in the sense that it's way more compatible with browser and I think that's really big thing in the long run (but nodejs could do that too, eventually) regarding 1000+ deps, yes that's a bad thing but it's not really about language, it's rather about people. when node started, usual number of dependencies was low. I know because I was there and I was making fun of maven and how it pulls half…

If the standard library would be richer you'd just ignore half a million of those packages. They'd just die a quiet death.

Exactly this. If anything, Deno can help introduce the use of standard libraries as a source of truth to webdevs who may not be familiar with the concept to begin with.

Re: Deno 1.10 Release Notes

#62

Post by Octoth0rpe »

tannhaeuser wrote: post #36
kigiri wrote: post #15

Earlier quoted context omitted.

But the bad ecosystem in npm is one of the main reason he made deno, that's what deno/std is for. While not stable yet, they are working to address this very issue Zig is looking great but also, solving a different problem

Excuse me, but what's this "bad ecosystem in npm" you're talking about? Every single JS lib, pipeline tool, framework is on npmjs.com (react, webpack, bootstrap, expressjs, and 100'000s others). It's the ecosystem that every contender would love to be. And the lack of a "stdlib" is exactly how and why npm started over ten years ago, via the community-driven CommonJs initiative (JSCI, connect/express.js, the package.j…

> Every single JS lib, pipeline tool, framework is on npmjs.com (react, webpack, bootstrap, expressjs, and 100'000s others). It's the ecosystem that every contender would love to be.

This is only a strength if you accept that those libs (and their dependencies, and their dependencies' dependencies, and so on...) are adequately scanned for malicious behavior. If you don't accept that, then the incredibly deep dependency graph that is typical of frontend projects these days is a liability.

Re: Deno 1.10 Release Notes

#63

Post by tarruda »

echopom wrote: post #33
rapsey wrote: post #19

Earlier quoted context omitted.

Just because they are attempting to address it does not mean they will succeed.

> Just because they are attempting to address it does not mean they will succeed. Strongly agree this statement , hence I don't see how switching from "npm" to "raw urls" will solve anything... The problem with Node dependency is bigger than just "npm is not a good package manager"... Honestly in this case just fork node and replace npm with something else... Here the problem relies on a mixture between poor built-in…

> I just know very well that Ryan is redoing exactly the same mistakes as Node with the same obsession he had on "EPOLL"[0] back then that will end up in a new fiasco.

"epoll" is a Linux API for listening on multiple file descriptors. Different platforms have equivalent APIs, and these are normally core of any scalable non-blocking I/O network program.

Can you elaborate why do you think he had an obsession with "epoll"? More importantly, can you elaborate what was the fiasco? Epoll is still used under the hoods by Node.js (through libuv) and many other network servers such as Nginx

Re: Deno 1.10 Release Notes

#64

Post by littlestymaar »

oblio wrote: post #23
cztomsik wrote: post #20

Earlier quoted context omitted.

deno is definitely better in the sense that it's way more compatible with browser and I think that's really big thing in the long run (but nodejs could do that too, eventually) regarding 1000+ deps, yes that's a bad thing but it's not really about language, it's rather about people. when node started, usual number of dependencies was low. I know because I was there and I was making fun of maven and how it pulls half…

If the standard library would be richer you'd just ignore half a million of those packages. They'd just die a quiet death.

Look at the python ecosystem and you'll see that it's not the case. Because of its compatibility commitment, a standard library cannot evolve much and its features end up being replaced with external libs.

“The standard library is where modules go to die”

Re: Deno 1.10 Release Notes

#66

Post by m00dy »

echopom wrote: post #8

Still not tempted by Deno to be honest. All the problem that currently exist in Node are being ported to Deno straight up. The built-in apis provided by Node.JS are almost non-existent... hence most of them are buggy and quiet tedious to use , it's why the community has created thousands of packages to resolve those issues. Here I don't see how Deno is solving this , all the APIS seems again so barebone.. instead of…

I setup my business entirely around those remote urls.

https://deno.services

Re: Deno 1.10 Release Notes

#67

Post by Octoth0rpe »

cztomsik wrote: post #20
echopom wrote: post #8

Still not tempted by Deno to be honest. All the problem that currently exist in Node are being ported to Deno straight up. The built-in apis provided by Node.JS are almost non-existent... hence most of them are buggy and quiet tedious to use , it's why the community has created thousands of packages to resolve those issues. Here I don't see how Deno is solving this , all the APIS seems again so barebone.. instead of…

deno is definitely better in the sense that it's way more compatible with browser and I think that's really big thing in the long run (but nodejs could do that too, eventually) regarding 1000+ deps, yes that's a bad thing but it's not really about language, it's rather about people. when node started, usual number of dependencies was low. I know because I was there and I was making fun of maven and how it pulls half…

> regarding 1000+ deps, yes that's a bad thing but it's not really about language, it's rather about people.

Not sure that I agree that it's about 'people', except in the sense that every problem with languages/their ecosystems are a people problem because people created them; but I 100% agree that it's not about the language.

My take on the situation is that we have 2 separate issues:

1) Auditing, which is basically an economics issue. It'd help a lot if someone with pockets full o' money were willing to fund a couple mil of auditing infrastructure for npmjs. 2) Devs pulling in lots of packages (which pull in packages, all the way down), which _may_ be partially mitigated by a better base language (no more leftpad, etc). Personally I'm skeptical of the better runtime/language solution.

I think one thing that might help is if there was some automatic way of marking packages as 'safe' in the sense of no side effects, no writing to files, no network activity guaranteed. Such packages could be installed with confidence, and have a lower priority for auditing.

Another possible solution would be a cultural shift among developers to prioritize reducing dependencies with every release. I'd love to see that in a release notes, how many packages were added/removed!

Re: Deno 1.10 Release Notes

#69

Post by 1_player »

ranguna wrote: post #34
echopom wrote: post #8

Still not tempted by Deno to be honest. All the problem that currently exist in Node are being ported to Deno straight up. The built-in apis provided by Node.JS are almost non-existent... hence most of them are buggy and quiet tedious to use , it's why the community has created thousands of packages to resolve those issues. Here I don't see how Deno is solving this , all the APIS seems again so barebone.. instead of…

I personally like to have a few dependencies in my projects and a simple runtime vs having a monster of a language with a huge amount a unrelated and specialised APIs (java) and still need to install some additional dependencies. I think the barebone nature of nodejs and javascript is what makes it great. If you don't like it, don't use it, there are other languages and runtimes out there and node is a really good fi…

I don't. I'd rather trust the tens of thousands of developers working on the core language and core stdlib, than on a dependency some random guy in Albania maintains on his spare time.

Or in the case of the JS ecosystem, you might only use established dependencies, which in turn use dozens more which in turn use dozens more, and the probability that there's a dependency some random guy in Albania maintains very quickly approaches 100%.

Have we already forgotten left-pad?

Post reply on HN