[fearingreprisal]

At what point are people going to just admit that implementing applications in Javascript outside the browser is a poor idea? The ecosystem has been in this poor state for years. It's not like the ecosystem is getting worse. This is the best it's ever been, and it's still horrible. There's so many better, more mature alternatives with much better ecosystems: Python, Java, C#, Ruby, Go, Haskell, Perl... The list goes on.

[zelly]

The fact that 90% of your code (i.e., business logic sans OS) can run in a Chrome Dev Tools window is pretty powerful. There really isn't anything that competes except PHP on a LAMP server in 2007. The ease of "getting started" is a big part of the network effect and the number of npm packages out there. Yes, the quality of those packages is terrible, but you don't find that out right away.

[hn_throwaway_99]

Your comment is somewhat incomprehensible, because this article is not about building end user applications in Typescript. It's about building the container itself in Typescript. I switched to Node from Java a couple years ago, and to Typescript within the past year, and I have never been on a team that has had this level of productivity.

[fearingreprisal]

What part of it couldn't you comprehend? I understand what the article is saying. I'm talking about the dysfunctional Node.js ecosystem, which includes Typescript.

In response to your personal experience, I'll share my own: I switched from C++ to Java, to .net, to Node.js, to Typescript. Working on Node/TS I have never been on a team that wastes so much time fixing silly problems that a better language would simply not allow to happen in the first place. I have also never worked on a team that spends so much time dealing with issues in poorly written community packages, or arguing with package maintainers who could never in a million years pass a technical skills test at the company I work for.

[zdragnar]

> arguing with package maintainers who could never in a million years pass a technical skills test at the company I work for.

So why on earth are you using their packages?

[reificator]

> I have also never worked on a team that spends so much time dealing with issues in poorly written community packages, or arguing with package maintainers who could never in a million years pass a technical skills test at the company I work for.

Excuse me for asking the obvious, but if they would never pass a technical skills test at the company you work for, why are the people who did pass using code that these maintainers wrote?

It sounds like the right approach is to sidestep them and fork the project yourselves. That way you'd clearly have a much more competent team maintaining it, and implementing all the features you need.

That is if you trust code written by someone of such standards in the first place. Really you should just rewrite it from scratch so that you know it's never been touched by anyone not at the competency level of your elite squad of code monkeys.

[untog]

> I'm talking about the dysfunctional Node.js ecosystem, which includes Typescript.

Deno is, by definition, not Node.js. Typescript can live outside of Node (like when it's compiled for and runs in the browser). So I think you're getting downvotes because it reads like a generic rant about the same things we've already heard about in a context where it doesn't apply. I'm not going to argue with the notion that Node has many poorly written community packages, it does, but this core piece of Deno functionality does not use any.