Excuse me, but what's this "bad ecosystem in npm" you're talking about? Every single JS lib, pipeline tool, framework is on npmjs.com (react, webpack, bootstrap, expressjs, and 100'000s others). It's the ecosystem that every contender would love to be.
And the lack of a "stdlib" is exactly how and why npm started over ten years ago, via the community-driven CommonJs initiative (JSCI, connect/express.js, the package.json format, middlewares, etc). The idea being that the core packages on npmjs.com are the stdlib on top of what Node.js/CommonJs provides.
> Every single JS lib, pipeline tool, framework is on npmjs.com (react, webpack, bootstrap, expressjs, and 100'000s others). It's the ecosystem that every contender would love to be.
This is only a strength if you accept that those libs (and their dependencies, and their dependencies' dependencies, and so on...) are adequately scanned for malicious behavior. If you don't accept that, then the incredibly deep dependency graph that is typical of frontend projects these days is a liability.
While that's true, this is really orthogonal to the argument. Especially since Deno's API is also anemic, as complained about elsewhere in this thread.
Could you share some examples of ecosystems that are 1) vibrant and active 2) have working, open source, ergonomic tooling of a comparable caliber to VSCode, typescript and friends 3) can target almost any platform, including but not limited to server, mobile, desktop and web?
I’m trying hard to think of any, Java and Python come closest but both fall short.
There are vibrant and active communities around good projects, but npm is the greatest known repository of abandoned, obsolete, not very good and potentially malicious libraries. The bad scales up along with the good; great tools on npm don't make the Leftpad fiasco more forgivable or technical shortcomings less bad.
Fair enough, but I have no idea how that can be avoided if we take Sturgeon’s Law as a given: 90% of everything is garbage.
I’d argue an essential quality in a modern software engineer is ‘good taste in dependencies’, if you will. Adding a dependency for padding a string with whitespace would have gotten you a friendly but stern lecture from a senior dev, in every good team I’ve been a part of so far.
Npm together with the ergonomics of JavaScript/TypeScript is what keeps me in the Node.js ecosystem. Never understood the hate for a massive ecosystem of community build libraries that you can contribute to, fork or modify at will.
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 Node in that example was that I didn't have to run `npm install`. Yay, great.
*: adding two dates together, converting to and from UTC, given a Date find the next midnight. And as expected the most popular JS library couldn't even get one of these simple tasks correct, there's a bug report open since 2017. Incredible stuff from this ecosystem.
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.
In Java, Joda-Time was a third party library for ages. It was the dominant date-time lib for enterprise development. Then, it was standardised and added to the stdlib: java.time (JSR-310). The Joda-Time project lead, Stephen Colebourne, ran the standardisation process. It was well received by most, even the breaking API changes that SC was adamant were flaws in the original Joda-Time API. I can vouch for it: Both Joda-Time and the java.time libs are excellent. (In my job, I regularly need to perform complex date-time transformations, including time zones.)
I have also used Howard Hinnant's C++ date-time lib: https://github.com/HowardHinnant/date It is also very good. (He was the guy behind move semantics in C++ 11.)
In Python, the stdlib has a function to get UTC now, that does not include UTC timezone... so it weirdly and surprisingly acts like local time zone! There is endless shit-posting about it. I feel bad for Guido van Rossum et al. To be fair, the original Java date-time lib was horrible, so Joda-Time was created. And JDBC (Java database) dates are still horrible.
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.
So what? Should we all give up now and stop doing whatever we're doing now, just because we might not succeed? That's how people learn, advance and improve the world around us - through failure and mistakes.
> 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 apis which are buggy a lack of vision with the language , which have been core to the language since it's origin.;.
Deno doesn't seems to address those at all...
Again it's just seems to be "npm is bad , and i want to use typescript natively with web apis"...
I just know very well that Ryan is redoing exactly the same mistakes as Node with the same obsession he had on "EPOLL"[0] back then that will end up in a new fiasco.
> I just know very well that Ryan is redoing exactly the same mistakes as Node with the same obsession he had on "EPOLL"[0] back then that will end up in a new fiasco.
"epoll" is a Linux API for listening on multiple file descriptors. Different platforms have equivalent APIs, and these are normally core of any scalable non-blocking I/O network program.
Can you elaborate why do you think he had an obsession with "epoll"? More importantly, can you elaborate what was the fiasco? Epoll is still used under the hoods by Node.js (through libuv) and many other network servers such as Nginx
