Live data from Hacker News

Deno 1.10 Release Notes

deno.com

141–150 of 157 posts

Re: Deno 1.10 Release Notes

#141

Earlier quoted context omitted.

...it’s only been around ~3 years.

Wrong, 1.0 released exactly one year ago, before there was mostly destabilization of the runtime and not really development features

Okay great. It was announced 3 years ago. Regardless of which version (pre/post 1.0), there really hasn’t been enough time for Deno to take hold. My point stands.

Re: Deno 1.10 Release Notes

#142

Earlier quoted context omitted.

I can see why npm is annoying, but I wonder what would be a good role model for a better ecosystem. I can personally only compare npm to PHP, Python and Java, and I think npm is far superior. Do you have an example of a better ecosystem/package manager? I'm genuinely curious.

I think some people like to compare Deno’s package management to go’s. I think that is a good comparison since dependencies live (sort of) on a URL in both cases. However I think Deno has improved significantly on the go approach. When I look for a better ecosystem though, I like to look towards Rust’s Cargo. However that is bit of an unfair comparison since Cargo was heavily inspired by npm, had learned from npm’s p…

Cargo is one of the nicest build systems I've used. Coming from maven, I have nothing but love for what cargo brings and how easy it makes it.

The key thing for me with Cargo (and Rust) is the documentation. I'm able to quickly glean what I need to do from the docs, and often with useful examples that are close to my use case.

I do wish the package ecosystem was set up with namespaces. Abandoned crates, name squatting, etc. should really be a thing of the past. But I guess this fosters creativity in names.

Re: Deno 1.10 Release Notes

#143
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…

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…

I don't get the "built in Typescript" argument. Everything is running on V8 at the end of the day. With Node you run a one-line compilation step, Deno does the same thing just under the covers.

Re: Deno 1.10 Release Notes

#144
post #93

How is the built in testing? I'm a bit wary because Jest is so good and wonder if it can compete on every front it's baking in. It reminds me of Angular coming with it's own Router, Forms, Animations and then since they're provided officially, alternatives don't get created and then the half of the team leaves and the packages are abandoned.

I know a fella working on a Deno port of Ava ( https://github.com/avajs/ava ). When that and Koa are ported or compatible, I'll be giving Deno a legitimate go.

FYI https://github.com/oakserver/oak is a port of Koa for Deno.

Re: Deno 1.10 Release Notes

#145

Node is amazing, but it was Electron that really made Node something that every school kid had to learn. As long as Electron has no plans to support Deno, it will be WAY behind in traction. /useless prediction

We may have WebGPU powered desktop applications in the near future though. Let's see how things play out, as you daid

Canvas is already a thing, but ultimately the biggest advantage of HTML-based UI is the layout engine. People want to throw together some s and a stylesheet and call it a day.

Re: Deno 1.10 Release Notes

#146
Great to see Deno going from good to better and better steadily over the past year. It is such a pleasure when compared with Nodejs projects. Always appreciate products that make life easier.

Re: Deno 1.10 Release Notes

#147
I have been following the progress of Deno for a little bit, and slowly but surely the project is evolving from a full-scale Node.js replacement to a serverless/edge compute platform. I get that it's the hot thing in tech these days, but to me that just isn't very appealing.

Re: Deno 1.10 Release Notes

#148
post #89

Earlier quoted context omitted.

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.

There is a difference however between "Does all the things my snowflake app needs" and "does the top 20 most common things". The latter is easy, and even quantifiable if you have the time (to scour open source repos for use cases). When you write dozens of utilities, a few libs, and several apps, its likely the common date time use cases will be suitable for 80% of them. Rinse and repeat across numerous other dependencies, and the result is a std library you learn once, that serves 80% of your use cases just fine. Its not about no dependencies, its about dependencies focused on novel or niche problems, not common and already solved ones.

Re: Deno 1.10 Release Notes

#149

Earlier quoted context omitted.

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”

Isn't that one of the big justifications for not bundling the standard library? It seems to me like not shipping the std library with the runtime is potentially one of the biggest language innovations we've seen in awhile because it should allow the std library to evolve over time in a much more graceful way ... -- you'll actually be able to make breaking changes to the std library as folks who are unwilling to updat…

How does it work when you want to use third-party libraries though? (because even if you have the biggest stdlib in existence, you'll still gonna end up using some external libraries no matter what)

Re: Deno 1.10 Release Notes

#150
post #56

Earlier quoted context omitted.

> Starting a few of years ago, I don't even consider the possibility of creating a Javascript project without using Typescript as the main ... The truth value of this statement is suspect but.. In any case, why should typescript be the default when it compiles to JS? Why shouldn't js be the default in a js framework?

I don't understand what you mean by "default". Deno simply provides a builtin compiler which allows it to run Typescript transparently. Clearly Deno also supports JS out of box.

Isn’t typescript a superset of javascript so any ts compiler must also run js?
Post reply on HN