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

81–90 of 157 posts

Re: Deno 1.10 Release Notes

#81

Post by WA »

1_player wrote: post #69
ranguna wrote: post #34

Earlier quoted context omitted.

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

I'm like you. I want as few dependencies as possible. I liked this about PHP: You could get very far without any dependencies at all.

For a toy project, pull in some dependencies. For a more serious project that requires to do due diligence on every dependency you pull in, it gets annoying very quickly.

Also, I kinda dread all the fast-changing version numbers in the JS ecosystem.

Re: Deno 1.10 Release Notes

#82

Post by oblio »

littlestymaar wrote: post #64
oblio wrote: post #23

Earlier quoted context omitted.

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”

Python packages, in general, are much bigger though.

And you'd probably be surprised how much the stdlib is used. In many environments third party libraries have to be vetted by security, or the developers are junior and can't probably check/understand a third party library so they just take the safe option and use the stdlib and hand-code a bit to make it do what they want, etc.

Plus, the third party packages that are used generally have to offer much higher convenience or quality or scope (or all three) to be adopted over the stdlib alternative.

So the bar is much higher than leftpad or is-odd.

Re: Deno 1.10 Release Notes

#83

Post by gadrev »

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…

re-[0]: 15:43

Re: Deno 1.10 Release Notes

#84

Post by littlestymaar »

mirekrusin wrote: post #45
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…

Comparing node, deno and zig is like comparing red apple, green apple and sushi.

But deno is written in Rust, so obviously the Zig squad had to chime in. /s

Re: Deno 1.10 Release Notes

#85

Post by enumjorge »

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…

Simple, and lightweight sound great in theory but some problems are complex enough they they require a lot logic, and that complexity needs to live somewhere, whether it’s your code base or a dependency. Node.JS could provide its libraries in a modular way so that you only install what you need. Essentially, that’s how npm works now except that the packages are provided by random people, and often times the work of getting them to work together to form a complete solution to a problem is left as an exercise to the reader.

When everything is broken down to very simple packages, you often end up in a situation where your dependency tree is very deep and now keeping track of which packages you use and vetting them becomes a complex task. Many devs are too trusting of the packages they take a dependency on. Remember that npm package that everyone used but was buried like 3 levels deep in people’s dependency trees, and then maintainer got tired of working on it so he handed it over to someone else who then purposefully injected a vulnerability into it which affected a lot of projects?

> If you don’t like it, don’t use it

Again, simpler said than done. My guess is most of us are working on projects where we don’t/didn’t get to choose the tech stack.

Re: Deno 1.10 Release Notes

#86

Post by styfle »

runarberg wrote: post #72
hackerbrother wrote: post #55

Earlier quoted context omitted.

It might catch on, it might not. Not everyone has to like it. I personally do like it a lot. I think of it as Node.JS with a better organized core (with the benefit of hindsight), use of browser APIs whenever possible, and built in Typescript. I think it might catch on once we have some mature MySQL, Express.js, etc libraries. I know seeing popular tools be rewritten from scratch is tiresome, but I don't think it's u…

> use of browser APIs whenever possible Correct me if I’m wrong, but isn’t Node.js aligning more and more with the browser APIs. For example if you `import { URL } from 'url'` you get the WHATWG standard URL object (it is also available as a global object). Node.js now has EventTarget and event listeners aligned with the DOM Event API. `crypto` is now a global object with the same API as the Web Crypto API. You have…

fetch() is a notable web feature missing from Node.js core

Re: Deno 1.10 Release Notes

#87

Post by andrew_ »

whalesalad wrote: post #70
caspervonb wrote: post #54

Uhm, so this submission was edited and renamed to Deno 1.1, but this is release version 1.10 as in version one dot ten.

Isn’t that the normal behavior of JavaScript numbers? Just do your own thing sometimes? Heh.

It's become somewhat the norm that JavaScript projects have adopted semver (https://semver.org/) for releases.

Re: Deno 1.10 Release Notes

#88

Post by andrew_ »

styfle wrote: post #86
runarberg wrote: post #72

Earlier quoted context omitted.

> use of browser APIs whenever possible Correct me if I’m wrong, but isn’t Node.js aligning more and more with the browser APIs. For example if you `import { URL } from 'url'` you get the WHATWG standard URL object (it is also available as a global object). Node.js now has EventTarget and event listeners aligned with the DOM Event API. `crypto` is now a global object with the same API as the Web Crypto API. You have…

fetch() is a notable web feature missing from Node.js core

add WebSockets to that list.

Re: Deno 1.10 Release Notes

#89

Post by grumple »

1_player wrote: post #25
hnbad wrote: post #24

Earlier quoted context omitted.

Deno has passed 1.0. Having the standard library still be "not stable yet" doesn't spark much confidence in me for something meant to replace node.

Yes, I would have wanted to see a decent stdlib to be a goal for 1.0. I recently wrote a 10 line script that had to work with date arithmetic *, and while importing URLs is pretty cool, it still was the same shit of spending 80% of the time it took to write the code browsing and evaluating multiple third party date libraries to find one good enough for my use case. So in practice the only improvement Deno had over No…

I have yet to find a datetime library in any language that was adequate for all purposes I've needed. That's not a particularly damning example in my opinion. I've had to write very weird datetime code in JS, Python, and Ruby. I don't even want to imagine the horrible things you could find in some other languages.

Re: Deno 1.10 Release Notes

#90

Post by bliteben »

littlestymaar wrote: post #64
oblio wrote: post #23

Earlier quoted context omitted.

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”

Not really, I mean what do you think is missing from the standard library json package? It obviously solves most use cases since just yesterday flask dropped simplejson. Standard library is just not great for libraries that are not yet stable.
Post reply on HN