6 ms·

I see (and have participated in) a lot of this "just copy this thing, trust me it works" type of content related to Node and TypeScript. It makes me wonder why

• mark_and_sweep 3y ago
  Being using Deno for new projects for years now. Not looking back.
  • robbywashere_ 3y ago
    What are the advantages of deno over node?
    • flohofwoe 3y ago
      Not the parent, but one very nice aspect is that an entire working Deno installation is just one file: the actual deno executable. ...when installing via homebrew on Mac you get 3 more files which look like shell-completion definitions: bin/deno etc/bash_completion.d/deno share/fish/vendor_completions.d/deno share/zsh/site-functions/_deno
      • e1g 3y ago
        Both Node.js and Bun are also single executables. Node.js doesn't (yet) transpile TS for you, and that's a single dependency away.
        • flohofwoe 3y ago
          Yeah I was confused that the Node installation directory was showing me 18k files in several thousand directories, but these seem to be global npm installs which npm seems to put into the node installation directory (which tbh is weird, I would expect those somewhere in my user directory).
• flohofwoe 3y ago
  I prefer Deno over Python now for "cross-platform shell scripting", because the "import directly from a github repository" is very nice for that use case. Haven't tried it yet as direct replacement for npm/node.js though (mainly because I'm unsure yet how well it works as a drop-in replacement when other people continue using npm and node.js).
• vinibrito 3y ago
  Deno still has quirks, like not running on ARM processors.
  • mmastrac 3y ago
    I work on Deno, specifically the CLI. We support both Mac and Linux ARM, though the Linux ARM builds are currently produced by a third party contributor. If you have specific issues with ARM, I'm certainly interested in fixing those. I don't have any timeline for when we'll add Linux ARM as a binary release target but I'm happy to ensure any ARM-only bugs get the proper attention.
    • no_wizard 3y ago
      Does that mean deploying Deno to AWS Graviton is an issue currently? Thats the use case I have in mind to cut costs
      • mmastrac 3y ago
        I haven't specifically tested it but it _should_ be supported. I don't have easy access to graviton instances at this moment, but I've previously used https://github.com/LukeChannings/deno-arm64 https://github.com/LukeChannings/deno-arm64 with great success. As long as your ARM OS is 64-bit, Deno should function properly. 32-bit _might_ be supported, but TBH we don't do any testing of those configurations as far as I'm aware.
  • flohofwoe 3y ago
    Weird, when I run 'file deno' on my ARM Mac I get: deno: Mach-O 64-bit executable arm64 ...also haven't experienced any problems so far.
    • spion 3y ago
      How about in Docker on ARM Mac?
      • deleted 3y ago
• willsmith72 3y ago
  I've tried both, and love their potential. I would highly advise any startup considering using them to reconsider. You don't want your business to being running into rough edges all day. You don't want to be reinventing things all day. They're fun, and especially deno is really fun. It feels more like go, where you control everything. But they're still not nearly as productive as node
  • monooso 3y ago
    Can you expand on what you mean by "not nearly as productive as node"? I've found the opposite to be true, because of the simplified tooling. That said, most of my Deno projects have been fairly basic, so I'm curious if there's a point at which the early wins give way to hidden pain points.
• ravenstine 3y ago
  Yeah, I use it for anything new, though so far it's been primarily hobby projects, including a sort of larger one I haven't gotten off the ground yet. I wouldn't necessarily suggest that a newbie programmer go right to Deno yet because today you still have to be prepared to deal with some differences and quirks. But here is why I like Deno: - Typescript pretty much Just Works (TM) out of the box without having to think about it - More web/browser APIs right out of the box with less Node-specific weirdness. Anything that is Deno-specific (such as anything that lives on the Deno global) is, in my opinion, better designed than Node's APIs. - Requiring file extensions in import specifiers makes total sense to me. Some people think this is stupid, but I see no reason not to make them actual file paths and not this sort of pseudo file path that omits the extension. - I like how Deno can bundle your application into a single executable. - Testing framework and linter are built right in. Which is great because, let's face it, most of us have been using such things for a very long time now. - Being able to pull in modules from the web without NPM is fantastic. - Node.js and NPM compatibility has gotten way better recently. - Binary data is handled as Uint8Array rather than using a non-standard Buffer like in Node. Makes total sense. Skip the middle-man and just give me the bytes in a widely compatible form. - Granular security with strict permissions by default is really nice. Sometimes I do want to import a module but then have a guarantee that third-party code won't phone home. It's also flexible enough that you can allow your own code to reach your own domains but then some module you import from elsewhere doesn't send data to some other domain. I'd still choose to not use such modules, but it's good that you can mitigate the risk of malicious code without having to do anything. And sure, Node has improved a lot since the inception of Deno and will continue to improve. It can probably do some of these things and may end up having more parity with Deno. I don't think that Node is bad. I still use Node, primarily at work, and in cases where a package has maintainers that refuse to support Deno (ex. Playwright).
• conaclos 3y ago
  I would love to use Deno, however it is not totally compatible with the TypeScript ecosystem: it is not possible to import a TypeScript file using the `js` extension. This is a dealbreaker for me because by adopting the `ts` extension you make your code deno-specific; You can no longer use TSC, ESbuild and the like.
  • wrs 3y ago
    Not sure what you mean? Our whole codebase is .ts files, and we use tsc and esbuild without apparent difficulty.
    • conaclos 3y ago
      I mean, if you have a file `mod.ts`, in Deno you cannot import `mod.ts` using the following import: import {} from "./mod.js" You have to write: import {} from "./mod.ts" ESbuild doesn't transform source imports. Thus, by transpiling your code using ESbuild, you get an erroneous import that leads to a runtime error in browsers and Node. The case is worse for TypeScript, because it refuses to tarnspile this code. By the way, bundling with ESbuild is possible, however when you write a library you generally want to transpile the code, not to bundle it.
      • pipe01 3y ago
        I use esbuild to import .ts regularly, I'm not sure how you came to that conclusion
        • conaclos 3y ago
          ESbuild correctly resolves the path, however it doesn't rewrite the import path. Thus, you end with a javascript file that tries to import a typescript file (this leads to a runtime error in the browser and Node).
      • iainmerrick 3y ago
        ESbuild has handled “.ts” imports for as long as I’ve used it. TSC recently added a flag that allows “.ts” imports too.
• methodical 3y ago
  This may be a luddite-esque take, but personally, I'm very hesitant to use Bun on any meaningful project at the moment. It screams too-good-to-be-true right now. I also believe that I may have heard of some people running across issues with it recently, although I maybe conflating my memory of it with something else. That, and, while I understand the namespace pollution with JS packages, saying that I use "Bun" for my projects is a bit of a turn-off, to be quite honest. I may try it for some pet project in the near-term future but if I was to make a choice for anything else I see operating long term I'd be much more inclined to use Deno, although I still think even that is probably a bit less established then I'd prefer, so I'd probably still use Node until Deno matures a bit more.
  • plopz 3y ago
    i think its reasonable to hesitate on using something less than 2 years old. it does a lot of things that look good to me, but im happy to wait a few years and see. it still needs to get buy in from people who maintain packages, for example just try using puppeteer with it. and its also not clear to me how its going to make money.
• davedx 3y ago
  Because deno is strongly opinionated on things other than the language and module system. I don’t want to use golang style dependencies. I don’t want all the upsells that come with using deno. It’s an island unto itself.
  • monooso 3y ago
    Upsells?
    • yencabulator 3y ago
      They are pushing their SaaS pretty hard, these days.
      • imbnwa 3y ago
        Bun is gonna prolly end up doing the same thing though
• toastercat 3y ago
  Deno is great, and I use it where I can, but a lot of front-end tooling still treats it like a second-class citizen including esbuild.
• talkingtab 3y ago
  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.
  • petre 3y ago
    While I mostly agree with you, I hope deno removes at least part of the nodejs mess when becomes ready for prime time. It's already better designed in so many ways. Then I can safely ignore the typescript functionality that, like you said, ads too little value for me. This is mostly wishful thinking. If deno doesn't deliver, maybe bun will. The funny thing is they are trying to improve deno by adding compatibility to the same nodeisms that make node such a messy experience, like package.json and node_modules. Once these will get used out of habbit, there is no going back.