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

Deno 1.0

deno.land

Post reply on HN
Print view View original

551–560 of 598 posts

Re: Deno 1.0

#551

Post by mekster »

tolmasky wrote: post #210

Forget the (reasonable) security and reliability concerns people have already brought up with regard to importing bare URLs. How about just the basic features of dealing with other people's code: how am I supposed to update packages? Do we write some separate tool (but not a package management tool!) that parses out import URLs, increments the semver, and... cURLs to see if a new version exists? Like if I am currentl…

Just come up with a convention like host a file called version.ts that lists all available versions. Brute forcing for available versions sounds dumb.

Re: Deno 1.0

#553

Post by fbn79 »

alain_gilbert wrote: post #427
fbn79 wrote: post #423

The claim "TypeScript is an extension of the JavaScript language that allows users to optionally provide type information" is misleading. Typescript is not an extension of Javascript (not all javascript code is valid TS code). Typescript is a subset of Javascript plus mild type checking. For more details a nice article https://medium.jonasbandi.net/here-is-why-you-might-not-want...

Do you hav any example of valid javascript that is not valid typescript ?

For example accessing static methods differ from vanilla Javascript. See https://stackoverflow.com/questions/33864167/accessing-stati...

Re: Deno 1.0

#554

Post by fbn79 »

hombre_fatal wrote: post #428
fbn79 wrote: post #423

The claim "TypeScript is an extension of the JavaScript language that allows users to optionally provide type information" is misleading. Typescript is not an extension of Javascript (not all javascript code is valid TS code). Typescript is a subset of Javascript plus mild type checking. For more details a nice article https://medium.jonasbandi.net/here-is-why-you-might-not-want...

This is such a weird point to me, maybe pedantry at best. Typescript is, to 99% of people, just Javascript with types. With few exceptions, TS compiles 1:1 to JS. That blog article just looks like an intro for beginners who don't quite know what static typing entails. Yes, static typing is different from runtime checks, that's why it's static.

The devil is in the detail

Re: Deno 1.0

#555

Post by Zooper »

goofballlogic wrote: post #530

Main thing that would prevent me investing in this stack is that the runtime has been designed with typescript in mind. In a few years if the typescript thing blows over, you're left with a runtime and conventions skewed toward statically-typed programming patterns.

I used to dislike typescript, until I was hired to write it. It has warts, but the benefits outweigh them, and you aren't forced to use the parts you may not find beneficial. I think it's a good way to prototype a typed version of javascript, at the least.

Re: Deno 1.0

#556

Post by mekkkkkk »

bgdam wrote: post #118
ryanseys wrote: post #115

Earlier quoted context omitted.

It's just a URL right? So could you not mirror the packages to your own server if you're so concerned, or better yet import from a local file? Nothing here seems to suggest that packages must be loaded from an external URL.

> or better yet import from a local file And this is different from NPM how? Except that I've now lost all the tooling around NPM/Yarn.

It's different because it is much further removed from a centrally controlled dumpster fire. The JS, Node and NPM ecosystem is a pain on so many levels. Blindly trusting developers to follow semver by default. Leftpad. Build toolchains. The whole micro-depedency madness. Having a peek into your node_modules is like looking into the depths of hell.

Not saying Deno won't devolve into this sad state at some point. Maybe it already has. But it seems to try to combat some of the problems by being honest and pragmatic about dependencies, promoting minimal external tooling and removing some of the dangerous abstractions from NPM.

To me Deno seems like a desperately needed and well thought out reset button.

Semi-related rant over.

Re: Deno 1.0

#557

Post by otoburb »

lame88 wrote: post #550

I briefly looked over this project when this link first popped up and didnt think much of it, but then i was surprised to see this huge surge in votes. I dont do much in the javascript and related world - can someone explain what in particular about this project has generated such interest? Even after reading the top comments, I feel like im missing the bigger pitcure.

>>I dont do much in the javascript and related world - can someone explain what in particular about this project has generated such interest?

The majority of the interest lies in the fact that Ryan Dahl[1] was the original creator of Node.JS[2], which is currently a very popular Javascript runtime and web backend.

Dahl released the initial version of Node.JS in 2009[3]. After a decade of experience working on Node.JS and growing the community, Dahl decided to create an alternative Javascript (and Typescript) runtime in mid/late 2018 called Deno which is now v1.0.

[1] https://en.wikipedia.org/wiki/Ryan_Dahl

[2] https://nodejs.org/en/

[3] https://en.wikipedia.org/wiki/Node.js

Re: Deno 1.0

#558

Post by tolmasky »

mekster wrote: post #551
tolmasky wrote: post #210

Forget the (reasonable) security and reliability concerns people have already brought up with regard to importing bare URLs. How about just the basic features of dealing with other people's code: how am I supposed to update packages? Do we write some separate tool (but not a package management tool!) that parses out import URLs, increments the semver, and... cURLs to see if a new version exists? Like if I am currentl…

Just come up with a convention like host a file called version.ts that lists all available versions. Brute forcing for available versions sounds dumb.

Yes, that is of course the point. There’s an infinite number of possible later versions to check for. The suggestion to poll for new versions using cURL was sarcastic. These “conventions” you speak of actually get handled by... package managers! If not everyone who hosts a package needs to “know” about magic files and make sure they make it following a spec that isn’t enforced by anyone and doesn’t break immediately but rather much later when someone tries to update. It’s like everyone managing their own database row with an informally agreed upon database schema.

Re: Deno 1.0

#559

Post by eyelidlessness »

megavolcano wrote: post #103
eyelidlessness wrote: post #92

Earlier quoted context omitted.

> It's basically the same "exposure" as importing a random npm, but it has the benefit if being explicit when you do it. This is definitely false. For all the problems with the NPM registry and the Node dependency situation, an NPM package at a specific version is not just at the whims of whatever happens to be at the other end of a URL at any given moment it's requested. This is a huge vulnerability that the Node/NP…

Deno has lock files and caches files locally on first import.

I'm not sure how a lock file would help in this scenario, unless you're also committing your cache to source control (like a lot of folks did in the bad old days of NPM). The local cache is great, but that doesn't prevent the content of those URLs changing for someone who doesn't have access to your cache.

Re: Deno 1.0

#560

Post by Rapzid »

afiori wrote: post #380
Rapzid wrote: post #326

Earlier quoted context omitted.

> which is not inline with the ideals of the web Subjective. > Centralized currency exchanges and arbitration is not in line with the ideals of the web! - Cryptocurrency Nek minute. Besides, let's get real here; they will just end up centralized on GitHub. How exactly is that situation much different than npm or any other language ecosystems library directory being mirror-able?

The centralization of git on Github is completely different in nature from the centralization of Node packages on npm. git does not require Github to be online to work, nor relies on Github existence for its functionality.

I'm talking about the centralization of software packages(Go, Deno) on GitHub as it applies to dependency resolution.
Post reply on HN