Prefer not to use Deno. First, my personal choice is not to use TypeScript. For me it just adds a layer of complexity that adds very little. That I am a sole d

Prefer not to use Deno. First, my personal choice is not to use TypeScript. For me it just adds a layer of complexity that adds very little. That I am a sole developer certainly is a factor in that decision. And history. I worked with Java for a long time, with all the safety it provides, only to find that PHP and JavaScript programmers could ship in 1/4 the time with the same level of functionality. I find that passing named parameters: `foo({animal: "duck"})` makes my plain old javascript much more robust, with very little cost. So strike #1 against Deno is that it puts typescript much more in the foreground. Strike #2 is that Node works. Not because it is right, but because services make sure they work with node. They don't put the same effort into making things work with Deno. I needed to write code using Deno that talked to a Digital Ocean managed Postgres database. I spent three days. Then I decided not to use Deno. Was this Deno's fault? No. But if you need to get things done and one in 1000 of those things works in Node but not in Deno, then the choice is straight forward. I'm not saying these are good reasons, but I did try Deno and wanted it to work.