10 ms·

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.

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 having 1000+ dependency from NPM you'll have 1000+ dependency from remote URL with everything set at "read/write" because they need to read one file from your ".env" folder or perform an arbitrary post install process... The way Ryan managed Node and how the ecosystem as turned to chaos because of is lack of vision and strategy make me not want to try any of it's tech again. Ryan is the kind of guy that gets obsessed over ONE THING and goes berserk for 5 years on that topic until he overdose and quit abruptly. I don't think that's how you manage a language , when I look at Zig I'm way more confident of what's being done that the current state of Deno... Node.JS is one of my main language , but the ecosystem around it is an absolute disaster.

kigiri 5y ago
But the bad ecosystem in npm is one of the main reason he made deno, that's what deno/std is for. While not stable yet, they are working to address this very issue Zig is looking great but also, solving a different problem
- rapsey 5y ago
  Just because they are attempting to address it does not mean they will succeed.
  - HatchedLake721 5y ago
    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.
  - valtism 5y ago
    Yes but let’s not get that cynical about it. People are working hard on these problems.
  - echopom 5y ago
    > 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. [0]https://youtu.be/M3BM9TB-8yA https://youtu.be/M3BM9TB-8yA Can't find the specific part where he mentioned "EPOLL"
    - tarruda 5y ago
      > 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
    - gadrev 5y ago
      re-[0]: 15:43
    - e12e 5y ago
      > (...) will end up in a new fiasco. Are you saying nodejs is a fiasco?
    - v8dev123 5y ago
      npm maybe bloated but I'd say it's better than pip. pip is insane, you have to set up virtual env (hurts UX) but with node you don't have to.
  - noir_lord 5y ago
    If they don't attempt to address it they'll certainly fail.
- hnbad 5y ago
  Deno has passed 1.0. Having the standard library still be "not stable yet" doesn't spark much confidence in me for something meant to replace node.
  - 1_player 5y ago
    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.
    - grumple 5y ago
      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.
      - throwaway2037 5y ago
        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 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.
- tannhaeuser 5y ago
  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.
  - Octoth0rpe 5y ago
    > 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.
    - tannhaeuser 5y ago
      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.
  - mmbleh 5y ago
    > It's the ecosystem that every contender would love to be. Trying to clarify - do you mean other JS ecosystems? Outside of JS, NPM is usually used as what not to do, not as an aspiration.
    - doteka 5y ago
      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.
- adevx 5y ago
  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.
cztomsik 5y ago
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 of the universe for a simple thing. Now nodejs is pulling the whole universe. Yet the problem, in my opinion, is not package manager but rather "look I made a package, it does one small thing and it does it well and I dont want it to do more" which leads to many more packages because you really need that thing so what you are going to do? you will add a package on top of package. rinse and repeat and there we are
- oblio 5y ago
  If the standard library would be richer you'd just ignore half a million of those packages. They'd just die a quiet death.
  - seumars 5y ago
    Exactly this. If anything, Deno can help introduce the use of standard libraries as a source of truth to webdevs who may not be familiar with the concept to begin with.
  - littlestymaar 5y ago
    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”
    - oblio 5y ago
      Python packages, in general, are much bigger though. And you'd probably be surprised how much the stdlib is used. In many environments third party libraries have to be vetted by security, or the developers are junior and can't probably check/understand a third party library so they just take the safe option and use the stdlib and hand-code a bit to make it do what they want, etc. Plus, the third party packages that are used generally have to offer much higher convenience or quality or scope (or all three) to be adopted over the stdlib alternative. So the bar is much higher than leftpad or is-odd.
austincheney 5y ago
> all the APIS seems again so barebone.. What is an example of something you are hoping for?
spamalot159 5y ago
I am trying to expand my horizons from only node to other frameworks. I've seen so much hype around Deno so I looked into it the other day and I feel the same as you. It doesn't seem different enough from Node from a user standpoint. I also agree that the package system seems messy. For right now I'm going to steer clear and get out django and rails.
- nesarkvechnep 5y ago
  Try Elixir and thank me later.
  - polytely 5y ago
    Elixir's standard library is so pleasant to use. Coming from the JavaScript world it is such a breath of fresh air,
    - klibertp 5y ago
      Elixir's stdlib is great. It's small, based on a just a handful of concepts, but thanks to how powerful the concepts are it covers a lot of use cases. Every module contains pretty much everything you'd ever need to work with the concept that module implements, be it a String, an Enumerable, a Stream, or anything else in the stdlib. But, Elixir is cheating. It can stay clean and compact in part because it sits on top of 30 years of development of Erlang stdlib. Erlang stdlib is messy, spread across multiple applications and modules, with module interfaces inconsistent with each other, not to mention parts of it still include compatibility layers for Erlang/OTP version so old that they didn't have lambdas yet. But, the functionality is there, which enables Elixir to have a small, focused stdlib - because when something is missing, you can just grab an Erlang equivalent. This is similar to what Clojure does on the JVM. JS doesn't have the luxury of sitting on top of a battle tested stdlib, and trying to cover all the functionality of such stdlib is what results in incomplete and unstable APIs and reliance on so many external packages.
  - rapsey 5y ago
    Even as a long time Erlang user, the rise of node.js was just sad to watch. I understand why it happened, but looking from the outside what kind of nonsense they were doing when there are such better solutions was sad.
tehbeard 5y ago
What about Deno's API is still so barebone? Are you comparing Deno to PHP? Should Deno have all the various database drivers baked in? SDKs to call out to Salesforce/Stripe/Zoom? Should I pay a performance penalty for my app because you need to be able to read XML and make SOAP calls and want a tool that does that out of the box? Would you be happy to take a hit if the roles were flipped and I wanted Excel read/write? I will not say Deno's perfect, I am still concerned/uneasy enough about how the whole dependency tree resolves for complex dependencies and is managed to not want to try it in production right now, but w.r.t to the ecosystem I'd say it's as good if not better than Node's, albeit smaller, given the focus on building a stdlib within this ecosystem for common usecases (http middleware, database drivers, common file formats etc) > everything set at "read/write" because they need to read one file from your ".env" folder or perform an arbitrary post install process... the CLI args allow for tighter scoping that, and atleast the topic of sandox by default is being discussed and the painpoints/edge cases are coming to light, rather than the node/npm model of execute as user and done.
jeswin 5y ago
> Ryan is the kind of guy that gets obsessed over ONE THING and goes berserk for 5 years on that topic until he overdose and quit abruptly. My problem with that statement is: if you knew him personally it's unlikely you'd have said it. And if you didn't, do you have enough samples to be sure he's 'that kind of guy'? Or are you extrapolating from N=1?
- seumars 5y ago
  There’s something funny in talking about “samples” to sound smarter.
ranguna 5y ago
I personally like to have a few dependencies in my projects and a simple runtime vs having a monster of a language with a huge amount a unrelated and specialised APIs (java) and still need to install some additional dependencies. I think the barebone nature of nodejs and javascript is what makes it great. If you don't like it, don't use it, there are other languages and runtimes out there and node is a really good fit for a lot of people.
- 1_player 5y ago
  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 quickly approaches 100%. Have we already forgotten left-pad?
  - runarberg 5y ago
    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 it when making fun stuff at home. I might even open an issue or a pull request. Dealing with a random guy in Albania sounds way more fun then dealing with a language committee in Silicon Valley.
    - Octoth0rpe 5y ago
      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.
tarruda 5y ago
> 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. coverage/test: Builtin test/coverage framework. fmt/lint: Builtin lint/formatter. IMO these provide basic tools that are likely necessary for any JS project, yet with Node.js you need a few hundred NPM deps to achieve the same functionality. Not to mention the builtin Typescript compiler. Starting a few of years ago, I don't even consider the possibility of creating a Javascript project without using Typescript as the main language. With Deno you have it builtin.
- vagrantJin 5y ago
  > 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?
  - tarruda 5y ago
    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.
    - peterthehacker 5y ago
      Isn’t typescript a superset of javascript so any ts compiler must also run js?
  - uhhhhhhhhhhhhhh 5y ago
    The Tao is formless, and gradually typed.
- 5y ago
mirekrusin 5y ago
Comparing node, deno and zig is like comparing red apple, green apple and sushi.
- littlestymaar 5y ago
  But deno is written in Rust, so obviously the Zig squad had to chime in. /s
golergka 5y ago
> 1000+ dependency from NPM I've been working with Node in hobby projects since around 2012, been paid for it since 2016, and still don't understand why is that such a problem. Compared to other language ecosystems, each of those dependencies is smaller and more atomic. If anything, it's closer to the "unix way" of small tools that do one thing and doing it well, rather then developing huge mega-libraries. Since these libraries are smaller, it's easier to change one for another. Because of that, community is much less likely to settle on one standard way of doing things just because of "how things are done here", and ecosystem continues to evolve and find better ways of writing code. Would any other language ecosystem that is widely used in production go from callbacks to different promise libraries, to standard promise api to async? I don't think so. (Edit: strike that, Rust seems to have done it too. Well, Rust is also awesome). Of course, it means that you have to learn more; but it also leads to things actually becoming better, and not because of some central mandate by language committee, but as a result of a more decentralised gradual evolution. (Not completely decentralised, just compared to alternatives). In any other ecosystem, pushing a pull request to any framework or library feels like something that you would do only after spending a couple of days of learning all the ropes of this codebase; in NPM, I've done meaningful contribution to a library less then an hour after learning about it's existence.
- smt88 5y ago
  > still don't understand why is that such a problem Some reasons it's a problem: - it's slows and disrupts the development process - packages get abandoned very easily; not many packages are highly popular/active - security audits are essentially impossible > Of course, it means that you have to learn more JavaScript takes this to an extreme. It literally takes daily effort to keep up. > In any other ecosystem, pushing a pull request to any framework or library feels like something that you would do only after spending a couple of days of learning all the ropes of this codebase So you prefer an ecosystem created by amateurs? After years of working with PHP and JavaScript, I don't.
- BenoitEssiambre 5y ago
  At least if they would have cleaned up the unnecessary promises from the async/await implementation: https://es.discourse.group/t/callback-based-simplified-async-await/343 https://es.discourse.group/t/callback-based-simplified-async...
hackerbrother 5y ago
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 unreasonable in this case given that Node.JS and Deno mostly get their JS implementation from a separate program: V8. In that sense, Deno isn't throwing all of Node.JS away. It's just a different attempt to make V8 a command line tool. And of course, competition is good. Maybe Typescript will become more convenient in Node because of Deno. Additionally: as someone who uses Linux in their day to day job, I think it's a phenomenal scripting tool and replacement / supplement for Perl / Python. I mentioned this in a comment here the other day, but with this short wrapper, you can execute a bunch of SSH commands simultaneously using the Promise.all JS function (familiar to web devs). Just an example of a cool thing you can do with Deno scripting. https://github.com/gpasq/deno-exec https://github.com/gpasq/deno-exec
- noseratio 5y ago
  Totally this, and not just for basic shell tasks but also as as scripting tool for CI/CD pipelines.
- runarberg 5y ago
  > use of browser APIs whenever possible Correct me if I’m wrong, but isn’t Node.js aligning more and more with the browser APIs. For example if you `import { URL } from 'url'` you get the WHATWG standard URL object (it is also available as a global object). Node.js now has EventTarget and event listeners aligned with the DOM Event API. `crypto` is now a global object with the same API as the Web Crypto API. You have ArrayBuffer and Blob in Node.js just like in the browser. What is it that Deno is doing differently then node here?
  - styfle 5y ago
    fetch() is a notable web feature missing from Node.js core
m00dy 5y ago
I setup my business entirely around those remote urls. https://deno.services https://deno.services
Jean-Philipe 5y ago
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.
- runarberg 5y ago
  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 past mistakes and were able to improve on it significantly.
  - anw 5y ago
    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.
intrasight 5y ago
Still not tempted by NodeJS or Deno
gbourne 5y ago
I use NodeJS daily, but I do agree some fundamental APIs are missing. For example, calling remote URLS is critical for most apps, yet Node only offers the "http" and "https" packages (and why different packages!). It should at least have "fetch" support and require installing the "node-fetch" dependency. I'm glad Deno is here trying to push the ecosystem forward, at least with Typescript, and hopefully Node will learn from them.
BatteryMountain 5y ago
I don't understand all the hate towards .Net. The included libraries are amazing.. about 80% of what you will ever need is provided by the framework. It basically provides you with a massive selection of tools, ready to go. The rest you can either build yourself or pull in a (precompiled) nuget package. It is my main gripe with JavaScript (and with typescript): a lack of a standard library that everyone uses and trusts. Something that should be predictable and boring, is absolute chaos in the js world. I think it's half the reason things like jQuery, momentjs, lodoash and others exist, because people got frustrated with the lack of built-in functionality. npm has just made everything worse. Can't we have a .Net type framework for javascript? Minus the CLR and compilers of coarse, just the framework bits. Or if we need some kind of CLR type layer, why not build it with webassembly? Then all flavours of javascript can call into that? There has to be a clean way forward.
- tarruda 5y ago
  > It is my main gripe with JavaScript (and with typescript): a lack of a standard library that everyone uses and trusts. Something that should be predictable and boring, is absolute chaos in the js world This is something that Deno is attempting to build with its stdlib: https://deno.land/std https://deno.land/std While the stdlib is not shipped with Deno (it is downloaded like any other third party dep), the code there is reviewed and audited by the core team.
- ithrow 5y ago
  I don't understand all the hate towards .Net. Because it's the same over-abstracted over-engineered life-sucking ecosystem as the Java world.
  - cylon13 5y ago
    I think that's more a property of the C# code that's out there rather than a property of .NET or C# themselves. A lot of (most?) C# and Java code in the world is over-abstracted over-engineered and life-sucking just by virtue of them being popular corporate languages and most code being boring. Using C# with Unity, for instance, is a pretty good experience though.

kigiri 5y ago

But the bad ecosystem in npm is one of the main reason he made deno, that's what deno/std is for. While not stable yet, they are working to address this very issue Zig is looking great but also, solving a different problem

rapsey 5y ago
Just because they are attempting to address it does not mean they will succeed.
- HatchedLake721 5y ago
  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.
- valtism 5y ago
  Yes but let’s not get that cynical about it. People are working hard on these problems.
- echopom 5y ago
  > 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. [0]https://youtu.be/M3BM9TB-8yA https://youtu.be/M3BM9TB-8yA Can't find the specific part where he mentioned "EPOLL"
  - tarruda 5y ago
    > 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
  - gadrev 5y ago
    re-[0]: 15:43
  - e12e 5y ago
    > (...) will end up in a new fiasco. Are you saying nodejs is a fiasco?
  - v8dev123 5y ago
    npm maybe bloated but I'd say it's better than pip. pip is insane, you have to set up virtual env (hurts UX) but with node you don't have to.
- noir_lord 5y ago
  If they don't attempt to address it they'll certainly fail.
hnbad 5y ago
Deno has passed 1.0. Having the standard library still be "not stable yet" doesn't spark much confidence in me for something meant to replace node.
- 1_player 5y ago
  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.
  - grumple 5y ago
    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.
    - throwaway2037 5y ago
      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 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.
tannhaeuser 5y ago
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.
- Octoth0rpe 5y ago
  > 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.
  - tannhaeuser 5y ago
    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.
- mmbleh 5y ago
  > It's the ecosystem that every contender would love to be. Trying to clarify - do you mean other JS ecosystems? Outside of JS, NPM is usually used as what not to do, not as an aspiration.
  - doteka 5y ago
    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.
adevx 5y ago
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.

cztomsik 5y ago

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 of the universe for a simple thing. Now nodejs is pulling the whole universe. Yet the problem, in my opinion, is not package manager but rather "look I made a package, it does one small thing and it does it well and I dont want it to do more" which leads to many more packages because you really need that thing so what you are going to do? you will add a package on top of package. rinse and repeat and there we are

oblio 5y ago
If the standard library would be richer you'd just ignore half a million of those packages. They'd just die a quiet death.
- seumars 5y ago
  Exactly this. If anything, Deno can help introduce the use of standard libraries as a source of truth to webdevs who may not be familiar with the concept to begin with.
- littlestymaar 5y ago
  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”
  - oblio 5y ago
    Python packages, in general, are much bigger though. And you'd probably be surprised how much the stdlib is used. In many environments third party libraries have to be vetted by security, or the developers are junior and can't probably check/understand a third party library so they just take the safe option and use the stdlib and hand-code a bit to make it do what they want, etc. Plus, the third party packages that are used generally have to offer much higher convenience or quality or scope (or all three) to be adopted over the stdlib alternative. So the bar is much higher than leftpad or is-odd.

austincheney 5y ago

> all the APIS seems again so barebone.. What is an example of something you are hoping for?

spamalot159 5y ago

I am trying to expand my horizons from only node to other frameworks. I've seen so much hype around Deno so I looked into it the other day and I feel the same as you. It doesn't seem different enough from Node from a user standpoint. I also agree that the package system seems messy. For right now I'm going to steer clear and get out django and rails.

nesarkvechnep 5y ago
Try Elixir and thank me later.
- polytely 5y ago
  Elixir's standard library is so pleasant to use. Coming from the JavaScript world it is such a breath of fresh air,
  - klibertp 5y ago
    Elixir's stdlib is great. It's small, based on a just a handful of concepts, but thanks to how powerful the concepts are it covers a lot of use cases. Every module contains pretty much everything you'd ever need to work with the concept that module implements, be it a String, an Enumerable, a Stream, or anything else in the stdlib. But, Elixir is cheating. It can stay clean and compact in part because it sits on top of 30 years of development of Erlang stdlib. Erlang stdlib is messy, spread across multiple applications and modules, with module interfaces inconsistent with each other, not to mention parts of it still include compatibility layers for Erlang/OTP version so old that they didn't have lambdas yet. But, the functionality is there, which enables Elixir to have a small, focused stdlib - because when something is missing, you can just grab an Erlang equivalent. This is similar to what Clojure does on the JVM. JS doesn't have the luxury of sitting on top of a battle tested stdlib, and trying to cover all the functionality of such stdlib is what results in incomplete and unstable APIs and reliance on so many external packages.
- rapsey 5y ago
  Even as a long time Erlang user, the rise of node.js was just sad to watch. I understand why it happened, but looking from the outside what kind of nonsense they were doing when there are such better solutions was sad.

tehbeard 5y ago

What about Deno's API is still so barebone? Are you comparing Deno to PHP? Should Deno have all the various database drivers baked in? SDKs to call out to Salesforce/Stripe/Zoom? Should I pay a performance penalty for my app because you need to be able to read XML and make SOAP calls and want a tool that does that out of the box? Would you be happy to take a hit if the roles were flipped and I wanted Excel read/write? I will not say Deno's perfect, I am still concerned/uneasy enough about how the whole dependency tree resolves for complex dependencies and is managed to not want to try it in production right now, but w.r.t to the ecosystem I'd say it's as good if not better than Node's, albeit smaller, given the focus on building a stdlib within this ecosystem for common usecases (http middleware, database drivers, common file formats etc) > everything set at "read/write" because they need to read one file from your ".env" folder or perform an arbitrary post install process... the CLI args allow for tighter scoping that, and atleast the topic of sandox by default is being discussed and the painpoints/edge cases are coming to light, rather than the node/npm model of execute as user and done.

jeswin 5y ago

> Ryan is the kind of guy that gets obsessed over ONE THING and goes berserk for 5 years on that topic until he overdose and quit abruptly. My problem with that statement is: if you knew him personally it's unlikely you'd have said it. And if you didn't, do you have enough samples to be sure he's 'that kind of guy'? Or are you extrapolating from N=1?

seumars 5y ago
There’s something funny in talking about “samples” to sound smarter.

ranguna 5y ago

I personally like to have a few dependencies in my projects and a simple runtime vs having a monster of a language with a huge amount a unrelated and specialised APIs (java) and still need to install some additional dependencies. I think the barebone nature of nodejs and javascript is what makes it great. If you don't like it, don't use it, there are other languages and runtimes out there and node is a really good fit for a lot of people.

1_player 5y ago
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 quickly approaches 100%. Have we already forgotten left-pad?
- runarberg 5y ago
  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 it when making fun stuff at home. I might even open an issue or a pull request. Dealing with a random guy in Albania sounds way more fun then dealing with a language committee in Silicon Valley.
  - Octoth0rpe 5y ago
    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.

tarruda 5y ago

> 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. coverage/test: Builtin test/coverage framework. fmt/lint: Builtin lint/formatter. IMO these provide basic tools that are likely necessary for any JS project, yet with Node.js you need a few hundred NPM deps to achieve the same functionality. Not to mention the builtin Typescript compiler. Starting a few of years ago, I don't even consider the possibility of creating a Javascript project without using Typescript as the main language. With Deno you have it builtin.

vagrantJin 5y ago
> 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?
- tarruda 5y ago
  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.
  - peterthehacker 5y ago
    Isn’t typescript a superset of javascript so any ts compiler must also run js?
- uhhhhhhhhhhhhhh 5y ago
  The Tao is formless, and gradually typed.
5y ago

mirekrusin 5y ago

Comparing node, deno and zig is like comparing red apple, green apple and sushi.

littlestymaar 5y ago
But deno is written in Rust, so obviously the Zig squad had to chime in. /s

golergka 5y ago

> 1000+ dependency from NPM I've been working with Node in hobby projects since around 2012, been paid for it since 2016, and still don't understand why is that such a problem. Compared to other language ecosystems, each of those dependencies is smaller and more atomic. If anything, it's closer to the "unix way" of small tools that do one thing and doing it well, rather then developing huge mega-libraries. Since these libraries are smaller, it's easier to change one for another. Because of that, community is much less likely to settle on one standard way of doing things just because of "how things are done here", and ecosystem continues to evolve and find better ways of writing code. Would any other language ecosystem that is widely used in production go from callbacks to different promise libraries, to standard promise api to async? I don't think so. (Edit: strike that, Rust seems to have done it too. Well, Rust is also awesome). Of course, it means that you have to learn more; but it also leads to things actually becoming better, and not because of some central mandate by language committee, but as a result of a more decentralised gradual evolution. (Not completely decentralised, just compared to alternatives). In any other ecosystem, pushing a pull request to any framework or library feels like something that you would do only after spending a couple of days of learning all the ropes of this codebase; in NPM, I've done meaningful contribution to a library less then an hour after learning about it's existence.

smt88 5y ago
> still don't understand why is that such a problem Some reasons it's a problem: - it's slows and disrupts the development process - packages get abandoned very easily; not many packages are highly popular/active - security audits are essentially impossible > Of course, it means that you have to learn more JavaScript takes this to an extreme. It literally takes daily effort to keep up. > In any other ecosystem, pushing a pull request to any framework or library feels like something that you would do only after spending a couple of days of learning all the ropes of this codebase So you prefer an ecosystem created by amateurs? After years of working with PHP and JavaScript, I don't.
BenoitEssiambre 5y ago
At least if they would have cleaned up the unnecessary promises from the async/await implementation: https://es.discourse.group/t/callback-based-simplified-async-await/343 https://es.discourse.group/t/callback-based-simplified-async...

hackerbrother 5y ago

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 unreasonable in this case given that Node.JS and Deno mostly get their JS implementation from a separate program: V8. In that sense, Deno isn't throwing all of Node.JS away. It's just a different attempt to make V8 a command line tool. And of course, competition is good. Maybe Typescript will become more convenient in Node because of Deno. Additionally: as someone who uses Linux in their day to day job, I think it's a phenomenal scripting tool and replacement / supplement for Perl / Python. I mentioned this in a comment here the other day, but with this short wrapper, you can execute a bunch of SSH commands simultaneously using the Promise.all JS function (familiar to web devs). Just an example of a cool thing you can do with Deno scripting. https://github.com/gpasq/deno-exec https://github.com/gpasq/deno-exec

noseratio 5y ago
Totally this, and not just for basic shell tasks but also as as scripting tool for CI/CD pipelines.
runarberg 5y ago
> use of browser APIs whenever possible Correct me if I’m wrong, but isn’t Node.js aligning more and more with the browser APIs. For example if you `import { URL } from 'url'` you get the WHATWG standard URL object (it is also available as a global object). Node.js now has EventTarget and event listeners aligned with the DOM Event API. `crypto` is now a global object with the same API as the Web Crypto API. You have ArrayBuffer and Blob in Node.js just like in the browser. What is it that Deno is doing differently then node here?
- styfle 5y ago
  fetch() is a notable web feature missing from Node.js core

m00dy 5y ago

I setup my business entirely around those remote urls. https://deno.services https://deno.services

Jean-Philipe 5y ago

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.

runarberg 5y ago
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 past mistakes and were able to improve on it significantly.
- anw 5y ago
  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.

intrasight 5y ago

Still not tempted by NodeJS or Deno

gbourne 5y ago

I use NodeJS daily, but I do agree some fundamental APIs are missing. For example, calling remote URLS is critical for most apps, yet Node only offers the "http" and "https" packages (and why different packages!). It should at least have "fetch" support and require installing the "node-fetch" dependency. I'm glad Deno is here trying to push the ecosystem forward, at least with Typescript, and hopefully Node will learn from them.

BatteryMountain 5y ago

I don't understand all the hate towards .Net. The included libraries are amazing.. about 80% of what you will ever need is provided by the framework. It basically provides you with a massive selection of tools, ready to go. The rest you can either build yourself or pull in a (precompiled) nuget package. It is my main gripe with JavaScript (and with typescript): a lack of a standard library that everyone uses and trusts. Something that should be predictable and boring, is absolute chaos in the js world. I think it's half the reason things like jQuery, momentjs, lodoash and others exist, because people got frustrated with the lack of built-in functionality. npm has just made everything worse. Can't we have a .Net type framework for javascript? Minus the CLR and compilers of coarse, just the framework bits. Or if we need some kind of CLR type layer, why not build it with webassembly? Then all flavours of javascript can call into that? There has to be a clean way forward.

tarruda 5y ago
> It is my main gripe with JavaScript (and with typescript): a lack of a standard library that everyone uses and trusts. Something that should be predictable and boring, is absolute chaos in the js world This is something that Deno is attempting to build with its stdlib: https://deno.land/std https://deno.land/std While the stdlib is not shipped with Deno (it is downloaded like any other third party dep), the code there is reviewed and audited by the core team.
ithrow 5y ago
I don't understand all the hate towards .Net. Because it's the same over-abstracted over-engineered life-sucking ecosystem as the Java world.
- cylon13 5y ago
  I think that's more a property of the C# code that's out there rather than a property of .NET or C# themselves. A lot of (most?) C# and Java code in the world is over-abstracted over-engineered and life-sucking just by virtue of them being popular corporate languages and most code being boring. Using C# with Unity, for instance, is a pretty good experience though.