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…
deno is definitely better in the sense that it's way more compatible with browser and I think that's really big thing in the long run (but nodejs could do that too, eventually) regarding 1000+ deps, yes that's a bad thing but it's not really about language, it's rather about people. when node started, usual number of dependencies was low. I know because I was there and I was making fun of maven and how it pulls half…
If the standard library would be richer you'd just ignore half a million of those packages. They'd just die a quiet death.
I think you're underestimating just how passionate the Node crowd is on customization and reusability. There are feature-rich, extremely popular packages which act as a stdlib in many ways for particular functions - yet there are constantly alternatives to ecosystem-dominating packages that spring up. Some gain traction, some do not. I don't see this changing, even with a robust stdlib. It's the culture around the toolset that drives this.
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.
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…
If you have a problem with library written and maintained by a random guy in Albania you have the option of not using it. If a functionality is so niche that you can only find one fit in the entire npm ecosystem, I doubt this functionality will ever make it to the standard lib of a non-node runtimes. Personally I like dependencies written and maintained by a random guy in Albania on their spare times. And I would use…
How many people audit their dependency authors more than 1 level deep? That's the problem: I know who wrote all of my first level dependencies (react, react-router, redux, reacstrap, etc). I don't know who wrote _their_ dependencies, and the 3rd level, 4th level. And I don't think anyone has the time to adequately evaluate that every time a dependency's version gets bumped given how deep the graph goes.
That looks like a pretty simple problem. Deno probably doesn’t work on FreeBSD simply because nobody has done the work of making it compatible yet. Rust, V8 and nodejs all run great on FreeBSD. If you care about FreeBSD support, I bet the community would be delighted to receive some pull requests patching the problem.
I gave it a whirl: > git clone https://github.com/denoland/deno.git denoland/deno > git clone https://github.com/denoland/rusty_v8.git denoland/rusty_v8 > cd denoland/deno > vi Cargo.toml ... [patch.crates-io] rusty_v8 = { path = "../rusty_v8" } ... > cargo build --release ... as expected same failure - good ... Make rusty_v8 build.rs aware of freebsd > vi ../rusty_v8/build.rs ... #[cfg(target_os = "freebsd")] { "fre…
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 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.
> Here I don't see how Deno is solving this , all the APIS seems again so barebone.. instead of having 1000+ dependency from NPM you'll have 1000+ dependency from remote URL With Deno you can already do a lot with only what is provided by the main executable. Here's a subset of the available subcommands: bundle: Bundles JS. While it doesn't do everything that webpack does, it already provides enough to deploy SPAs. c…
> 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?
deno is definitely better in the sense that it's way more compatible with browser and I think that's really big thing in the long run (but nodejs could do that too, eventually) regarding 1000+ deps, yes that's a bad thing but it's not really about language, it's rather about people. when node started, usual number of dependencies was low. I know because I was there and I was making fun of maven and how it pulls half…
If the standard library would be richer you'd just ignore half a million of those packages. They'd just die a quiet death.
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 think it might catch on once we have some mature MySQL, Express.js, etc libraries.
This resonates a lot with me. I first wrote nodejs apps not because of nodejs but rather because of Express. I could build a simple app very quickly, wire it up to a database, use Passport to secure it and call it a day. It was the libraries that drew me in.
What's the status of grpc both as client and server? I seem to recall reading somewhere that some features(trailing headers?) needed to call grpc as client were out of the fetch spec and thus would to be implemented. It's also not clear from this issue either. https://github.com/denoland/deno/issues/3326