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
Deno 1.10 Release Notes
141–150 of 157 posts
Re: Deno 1.10 Release Notes
#142Earlier 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…
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
#143Still 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…
Re: Deno 1.10 Release Notes
#144How 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.
Re: Deno 1.10 Release Notes
#145Node 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
Re: Deno 1.10 Release Notes
#146Re: Deno 1.10 Release Notes
#147Re: Deno 1.10 Release Notes
#148Earlier 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.
Re: Deno 1.10 Release Notes
#149Earlier 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…
Re: Deno 1.10 Release Notes
#150Earlier 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.