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

161–170 of 598 posts

Re: Deno 1.0

#161

Post by bgdam »

afiori wrote: post #140
bgdam wrote: post #99

Earlier quoted context omitted.

> in term of vendoring you can simply download everything yourself and use local paths for imports. So I basically have to do manually, what NPM/yarn do for me already?

I do not speak for the project, but based on my understanding part of the point was to avoid the magic of npm. You can use lock-files, bundles, and many other features that makes dependencies management easier.

Ah from that perspective I can see how this might appear to be better. Personally, I like the 'magic' of NPM (which to be honest I don't really think is all that magical, it's quite transparent what's happening behind the scenes). This 'magic' means I no longer have to write 200 line makefiles, so it definitely makes my life easier.

Re: Deno 1.0

#162

Post by ricardobeat »

bgdam wrote: post #153
batmansmk wrote: post #147

Earlier quoted context omitted.

To solve your issue, you would do exactly how you do your node deployments: download the deps in a folder in CI, then deploy the whole build.

Except that now, the download deps in CI step can fail if one of hundreds of websites for my hundreds of dependencies goes down. If the main NPM repository goes down, I can switch to a mirror and all of my dependencies will be available again.

You answered your own question. Nothing stops you from using a mirror with deno too.

Re: Deno 1.0

#163

Post by polishdude20 »

nkozyra wrote: post #69
gen220 wrote: post #39

Earlier quoted context omitted.

such is the curse of having the audacity to develop software :)

Sure, but there's a tendency to start over when the development gets hard to maintain or support instead of just fixing the mistakes. This really feels like the fundamental response in the js world and why we see much churn.

But isn't this an inherent problem in software development that is really super hard to not do?

Let's say you are deciding how to make node when it was first conceived and how it would work. You've made decisions about how the thing fundamentally works. Then after using it and developing for it many years and after having millions of critical software projects dependant on it, you slowly start to see the shortcomings of the software that you could only see at this stage. The problem is that these shortcomings come from a false assumption or solution to the fundamental problems you had to solve when making node. Now, the only way to fix node is to change how it fundamentally works. But if you do that, millions of users' code will break. So, do you require everyone now to fix their broken code and potentially piss everyone off? Or do you give people a choice? Stick with node if you aren't noticing any of those fundamental problems you found, or switch to the new thing on your own time? It's a question of how to affect the least number of people in the least negative way.

Re: Deno 1.0

#164

Post by turblety »

jon889 wrote: post #154
turblety wrote: post #146

Earlier quoted context omitted.

> Deno runs JavaScript faster than node Yup, and that's really cool and exciting. My issue isn't with runtime timing. That's not what costs me money. Developer time is what costs money, and every change having to "recompile" my already raw JavaScript costs way more than saving 0.02s at runtime.

Can't you just pass it a .js file and it will skip the TypeScript compiling completely?

Haha, yup. Thats much better. Thanks!

Re: Deno 1.0

#165

Post by ricardobeat »

turblety wrote: post #136

As a functional developer who doesn't care for TypeScript in any way, it's frustrating to see Deno has it "built-in". As a node developer writing pure none-compiled JavaScript, my run time is extremely fast from changing code to seeing its results. It takes milliseconds for me to run brand new code in my terminal. If I make an index.ts file simply adding two numbers together (with no TypeScript), there is a 1 to 2 se…

Since typescript has no runtime, it doesn't really need to be compiled, you just strip away all the type annotations. There are tools like SWC[1] that can process TS in milliseconds if you want to skip the type checking.

[1] https://swc-project.github.io/

Re: Deno 1.0

#166

Post by cakoose »

anderspitman wrote: post #149

> In Deno, sockets are still asynchronous, but receiving new data requires users to explicitly read() Interesting. If I understand correctly, they're essentially using pull streams[0]/reactive streams[1]. I compiled a few resources on this topic when I was digging into it a while back[2]. I've found the mental model to be very elegant to work with when needing backpressure in asynchronous systems. As for the dependen…

When describing the input stream back-pressure problem:

> To mitigate this problem, a pause() method was added. This could solve the problem, but it required extra code; and since the flooding issue only presents itself when the process is very busy, many Node programs can be flooded with data. The result is a system with bad tail latency.

Are they saying that even with correct use of pause() there are still issues?

Re: Deno 1.0

#167

Post by malkia »

No. Without some kind of signature check (SHA256 or SHA512 or something more modern - just say No). it's tempting though :)

Re: Deno 1.0

#169

Post by nkozyra »

polishdude20 wrote: post #163
nkozyra wrote: post #69

Earlier quoted context omitted.

Sure, but there's a tendency to start over when the development gets hard to maintain or support instead of just fixing the mistakes. This really feels like the fundamental response in the js world and why we see much churn.

But isn't this an inherent problem in software development that is really super hard to not do? Let's say you are deciding how to make node when it was first conceived and how it would work. You've made decisions about how the thing fundamentally works. Then after using it and developing for it many years and after having millions of critical software projects dependant on it, you slowly start to see the shortcomings…

I think the answer is a break in backwards compatibility on a major version release.

People in JS/frontend world are willing to drop the world for the latest new thing, I see this as less jarring than, say, Python 2 -> Python 3.

Re: Deno 1.0

#170

Post by jfkebwjsbx »

turblety wrote: post #136

As a functional developer who doesn't care for TypeScript in any way, it's frustrating to see Deno has it "built-in". As a node developer writing pure none-compiled JavaScript, my run time is extremely fast from changing code to seeing its results. It takes milliseconds for me to run brand new code in my terminal. If I make an index.ts file simply adding two numbers together (with no TypeScript), there is a 1 to 2 se…

Don't ever think of trying a compiled language like C++ or Rust, then :)
Post reply on HN