30 ms·

Can someone "sell me" on Deno? I'm still not sure why I should be interested in this versus for example NodeJS. Most of the features it lists seem rather dubiou

• ecmascript 5y ago
  Honestly for me it is: - Follows the ecmascript standard and supports browser apis - No npm, no Microsoft lock-in - So far, no political bs like node has had
  • FaisalAbid 5y ago
    Is Deno ready for production? What limitations have you run into?
    • lucacasonato 5y ago
      https://news.ycombinator.com/item?id=28131876 https://news.ycombinator.com/item?id=28131876
    • ecmascript 5y ago
      > Is Deno ready for production? Yes. > What limitations have you run into? Libraries that exist for node that can't easily be ported over that don't yet exist for Deno. But that is basically it. In the beginning it was a bit hard to keep up with the rapid changes as well but that seems like a positve thing anyway.
    • croes 5y ago
      No deno native MS SQL support
    • chovybizzass 5y ago
      Most of the 3rd party modules have been abandoned.
  • dmitriid 5y ago
    > No npm You still need packages > no Microsoft lock-in Does Deno implement its own TypeScript compiler? Even if it does, it's entirely at the mercy of Microsoft who are the only ones who develop Typescript specs.
    • ecmascript 5y ago
      > You still need packages Yes but with ES modules you can just import them straight into the code and there is really no need for a package manager. > Does Deno implement its own TypeScript compiler? Even if it does, it's entirely at the mercy of Microsoft who are the only ones who develop Typescript specs. This may be somewhat true. However I am not using typescript so I am not really sure about this. My point is not really tied to the language typescript which I am sure will continue just fine. What I am much more worried about is all the packages hosted on npm. At any time Microsoft could do something to restrict it in ways I can't control. Highly unlikely that something extreme will happen perhaps, but I don't trust Microsoft enough. For example, I could easily see them forcing everyone to use github for node packages in the future etc.
      • dmitriid 5y ago
        > you can just import them straight into the code "Just import them". From where? > What I am much more worried about is all the packages hosted on npm. At any time Microsoft could do something So, how does deno help?
        • ecmascript 5y ago
          From anywhere on the internet. > So, how does deno help? By decentralizing the package hosting.
          • dmitriid 5y ago
            > From anywhere on the internet. https://news.ycombinator.com/item?id=28284930 https://news.ycombinator.com/item?id=28284930 > By decentralizing the package hosting. These are empty words that literally mean nothing. The rest is at the link so as not to have the same conversation in several places.
• the_mitsuhiko 5y ago
  Why do you need to be sold on Deno?
  • jjice 5y ago
    I imagine the parent is confused as to why people care about Deno since it gets a decent bit if coverage on HN.
    • the_mitsuhiko 5y ago
      It's a different question why something is popular on hackernews or why someone should use something. Deno is interesting and worth paying attention to, that does not mean someone should be sold on it or build something with it (yet?).
      • spiderice 5y ago
        But clearly people are using it. GGGP is asking why people are choosing it. It’s a very straight forward conversation and I feel like you’re nitpicking word choices.
        • the_mitsuhiko 5y ago
          I don’t see this as a good faith conversation. It’s one thing to ask why people are using something, another thing entirely is to get people to convince one to use it. Particularly when the post already starts with a few statements of not liking it.
  • oauea 5y ago
    It's just an idiom[1]: > To be confident in or convinced about something's viability, veracity, etc., often to the point of being enthusiastically supportive of it. People on HN seem excited about it. I wanted to learn why, and have received a lot of great responses! [1] https://idioms.thefreedictionary.com/be+sold+on+something https://idioms.thefreedictionary.com/be+sold+on+something
• greghuels 5y ago
  It doesn't have to be server software. I created a cli tool with Deno so that it could run as a standalone binary. It runs a lot faster than if it were built with node and any user without node installed could still run it.
  • jamil7 5y ago
    I haven't worked with JS for a while so I'm not really up to speed on modern Deno and Node but can't you also package a node cli tool as a binary? Also how can Deno run a lot faster? I would imagine it at least suffering from a startup time hit due to the TS compiler. Maybe someone can explain?
    • wperron 5y ago
      Transpiling TS to JS on startup does incur a cold start penalty, you can minimize it by using the `--no-check` option to transpile with SWC instead of TSC but it's still there. On subsequent runs though, it'll start up instantly because the JS is cached locally after transpiling (you can even trigger this step yourself with `deno cache`) Beyond that, you still have the v8 engine running the JS, so yeah in most cases performance will be pretty much what you can expect from Node _except_ with regards to anything that reaches out of the sandbox (like filesystem or network access). These APIs are handled completely differently outside of v8, with Deno relying on a lot of Rust packages, and Promise-based APIs all the way down. For the builtin HTTP server for example you can expect higher throughput from Deno. Tail latencies also tend to be better with Deno. You're not immediately going to get "blazing fast, native speeds" but you can get some nice optimizations.
      • jamil7 5y ago
        > These APIs are handled completely differently outside of v8, with Deno relying on a lot of Rust packages Very cool, thanks for the detailed answer.
    • deleted 5y ago
      [deleted]
  • 5y ago
• guptaneil 5y ago
  I get the feeling it’s just meant to be a nicer development experience by including more out of the box. I tried it briefly and was impressed by how easy it was, it felt like I was in another language’s ecosystem rather than the complex duct tape approach JS has become infamous for. I think as it matures, it will help increase productivity and decrease complexity for new projects. There’s not a reason you’d migrate an existing node project to deno, but if you’re starting something new, why not use the nicer environment? FWIW, deno is also built by Ryan Dahl, the original creator of node, so I think of deno as more like a rewrite of node rather than a competitor.
• sieve 5y ago
  Deno has replaced shell scripts and Java in a lot of places for me. My reasons: - Types: I simply cannot program without them. Typescript is great. - Single executable: Write programs that run the same on Linux/Windows without forcing the user to download the entire universe like other runtime environments. - Built-in bundler: Write front-end code in Typescript and use a single command to bundle all dependencies. Native JSON support in cli applications is not something you can appreciate if you haven't dealt with the pain surrounding it on the Java side.
  • lpcvoid 5y ago
    This sounds like something you can get with other languages which compile to native x86_64 or arm or whatever - specially the single executable concept is ages old and predates the entire internet. Why use js, which is slow?
    • deleted 5y ago
      [deleted]
    • sieve 5y ago
      There is always something that doesn't fit either the use case or the aesthetic sense. > Why use js, For someone working with JS on the front end, the ability to not only use the same language, but also the same libraries/modules/functions is very valuable. > which is slow? Not that slow, once a JS engine takes over.
    • innocenat 5y ago
      This just don't make sense. People do scripting in sh, bash, python, etc all the time. Why not js?
  • specialist 5y ago
    Using Java for shell scripts (using a shebang) is on my todo list. IIRC, there's a GraalVM or Truffle or something interpreter that'd work.
  • toastal 5y ago
    > Types There are so many better options if you want a good type system (Elm, PureScript, Rescript, GHCjs, Scala.js, and many more). TypeScript is unsound, and necessarily by it's design, it has to take on weird issues to maintain compatibility with JavaScript (null/undefined, can run effect anywhere, a lot of codebases are filled with any types). Heck, TypeScript doesn't even come with ADTs and proper pattern matching.
• dane-pgp 5y ago
  > Will that not just bring about another npm situation in a few years? Speaking of which, I was wondering if it has an equivalent for "npm audit", and I've found a project which provides some of that capability: https://deno.land/x/audit@1.0.0 https://deno.land/x/audit@1.0.0 Rather than rely on a single source of truth for audits, it seems to rely on developers specifying a location which is trusted to make audit reports about their modules. That's a slightly different trust model, but it's better than nothing and at least prevents the controversial false positives problem of "npm audit": https://news.ycombinator.com/item?id=27761334 https://news.ycombinator.com/item?id=27761334
• jfbaro 5y ago
  For me the main selling points are: - Security; - More suitable for Serverless deployment (like running a full server on V8 Isolates) - Cloud Workers and Fastly (0ms cold starts)... check this out -> https://deno.com/blog/deploy-beta1 https://deno.com/blog/deploy-beta1 - Embraces Typescript as a first class citizen.
• snarfy 5y ago
  npm is hot garbage. If it fixes npm I'm all for it.
  • koolhaas 5y ago
    I would say, it doesn’t really fix npm. It has its own centralized npm repo, called deno land, and it’s own package.json, called deps.ts. Because it can accept any URL as a dep in the source files, you can in theory do some cuter, weirder things with it. But security wise I’d argue arbitrary URLs, for critical, high traffic deps, are harder to fix when bad things happen, without centralized control.
    • iainmerrick 5y ago
      This something I really don’t understand about Deno. I feel like I must be missing something. How do I pin the versions of my dependencies? i.e. where is the package lock file? If the idea is that every source file will specify the version it wants of every dependency, that seems unmanageable. Or if every source file just imports the latest version of its deps, how do I get reproducible builds? I want a lockfile with an explicit manual step to update dependencies. “npm ci” seems to work well. I don’t see how Deno improves on it, quite the reverse. Edit to add: hmm, there are some docs here that look relevant: https://deno.land/manual/linking_to_external_code/integrity_checking https://deno.land/manual/linking_to_external_code/integrity_... But this reads as “if you really want package integrity, here are some awkward commands you can run to do it”. I strongly feel this should be the default behaviour that the tools should steer you towards. And in the examples on this page, the source code does link to specific library versions; I have a hard time accepting that that’s a good idea, except possibly for major versions.
      • wperron 5y ago
        yeah, it's a bit awkward and you have to dig through the docs to find it. We're thinking about making it the default behavior.
        • 5y ago
• Jenk 5y ago
  Perhaps an alternative way to sell this might be that Deno is authored by the original author of node. He introduced Deno at a talk "What I regret about Node.js" and presented Deno as the product of his lessons.
• tinco 5y ago
  I've now done two small web services in Deno, both are in production serving very small amounts of requests (i.e. tens per week scale). The thing that attracted me to Deno is that it promises to be a more integrated Typescript experience on the backend while still leveraging a lot of value from the Node ecosystem. I've already forced my coworkers to use Typescript, so having better integrated tooling is just a big plus. That's when compared to Node.JS. When compared to other frameworks, I'll just say it's nice that all developers on my teams know Typescript, so they can all contribute when necessary. In absolute terms, I think Node.JS is the dumbest thing to ever happen in IT history, and I hope something like that never happens again. That Deno puts a small bandaid over that open wound in my heart is nice.
  • WanderPanda 5y ago
    > I think Node.JS is the dumbest thing to ever happen in IT history Did you already forget about PHP? :p
• mattlondon 5y ago
  1 - it is not just server software, but general purpose usage. 2 - personally I don't see why you'd want to use anything other than Typescript right now. It certainly feels like TypeScript has "won" and is now the defacto standard for anyone doing any kind of work in the JS-ecosystem. That of course may change in the future of course, but today it feels like TS is where its at. 3 - I've experienced a lot of annoyance shipping around huge node_modules/ directories, just to get a CLI app working. Sure these are not "problems", but it is a pain to have to compress up hundreds of thousands of files and then decompress again rather than just moving around one executable. 4 - deno is the "package manager", if you can call it that. You explicitly state the imports & versions you need in your code as import statements, and the deno runtiem handles sourcing the files for you transparently. So either from a cache, or at first run it will try and go out onto the network (internet or proxied IIRC) to get them for you.
  • franciscop 5y ago
    [deleted comment]
    • andrew_ 5y ago
      This is something often overlooked by fans of typing. On the surface it may appear to some as being strongly typed, but it's a mirage [1] and frequently requires a lot more lifting, e.g. writing specific typings to work around shortcomings, just to make the types play nice together. That's not a feature of a strongly typed language, it's a feature of statically type-checked languages or schemas. I still use TypeScript, and I understand the benefits, but I'm not always a fan and will write plain JS when it fits better than TS. [1] https://news.ycombinator.com/item?id=15090561 https://news.ycombinator.com/item?id=15090561
      • k__ 5y ago
        I didn't like TypeScript when writing frontend only code, because the the iteration speed is just so fast in the browser. But when I started using it for backend and infra, the iteration speed is much slower, so even TS only saves a few % of deploys, it's still a noticeable amount of absolute time.
• andrew_ 5y ago
  The more I learn about how it imports external/third-party code [1] the more I like it. It's got none of the hangups of NPM. No package.json nonsense (there are great script runners if you need them), and no cruft when importing external code (e.g. no need for yarnclean). The registry they do maintain is unique and immutable, which I was not sold on until I had this discussion [2]. I do still think they need some more guidance around how that works, and some contingencies in the event of bad actors, but it's just as good as NPM's registry imho. Native TS is a nice convenience for projects which call for it, and compiling is much more streamlined than bolting it onto a project yourself. It's worth noting that it does support plain JS, just the ESM flavor. And last but not least is the stdlib, which roughly aims to prevent the need for a million one-line packages spread out across the registry. Network throughput performance is impressive to say the least, and with leveraging Rust I can only see that getting better. The more I learn about Deno the more that I'm liking it. [1] https://deno.land/manual/linking_to_external_code https://deno.land/manual/linking_to_external_code [2] https://github.com/denoland/deno/discussions/11809#discussioncomment-1219406 https://github.com/denoland/deno/discussions/11809#discussio...
  • spankalee 5y ago
    It's quite a bit worse than npm. Without bare module specifiers (like `import {html} from 'lit-html'`) to act as an abstraction over location you have to import directly from a URL, but what URL? Packages either have to be self-hosted, or very often npm packages are loaded via CDNs. There are several CDNs that host the same packages (unpkg, Skypack, jspm, jsDelivr/esm.run) so there's no single canonical URL to load anything from and each module that loads a package could load from a different CDN, or simply load a slightly different but compatible version, causing multiple copies of the packages to be loaded. There's a huge benefit to abstracting over package names, and Deno mostly throws it all away. It does support import maps, but you'd need tooling that doesn't fully exist yet to crawl and dedupe a module graph and at that point it'd basically be npm but a lot slower with no registry to use for metadata.
    • andrew_ 5y ago
      > It's quite a bit worse than npm. That's a rather subjective take. The rest of your comment can be fulfilled by `trex` https://nicedoc.io/crewdevio/Trex https://nicedoc.io/crewdevio/Trex. Perhaps it's been a while since you took a good look at how the ecosystem has evolved. I just started giving Deno a hard look last week and I've already found answers for needs like this.
• forrestthewoods 5y ago
  It was made by the creator of NodeJS and fixes many issues he considers to be mistakes. Do you like NodeJS? This is NodeJS 2.0.
  • hn_throwaway_99 5y ago
    I've seen the original Dahl post about his mistakes with NodeJS, and why he wanted to do Deno, and to be frank, I'm not convinced. It's not that I disagree with Dahl on most of his recognized mistakes (though some I do, most especially that a standardized, embedded packaging system was a mistake, despite the legions of warts of NPM), it's that most of these mistakes feel like little nits or one-time costs that just don't bother me at all in the Node world. I mean, it feels like the best thing going for Deno is out-of-the-box TypeScript support, but with Node it's trivial to have a template project that integrates all this for you, then it's 1-and-done. Perhaps the other thing I like about Deno is it separates the standard library into its own package instead of being part of the Deno-runtime version, but again, this difference is definitely not enough to make me switch.
    • andrewmcwatters 5y ago
      Deno feels like past the peak technology to me. You've got years and years of labor put into the Node.js ecosystem, and then the guy comes out with something that totally drops all of that for some gimmick features. Could you not just build a URL loader and cache for importing in Node.js? Could sandboxing not just be a flag in Node.js? Do you really need TypeScript built in? I'm not going to throw years of my and other's work away for some gimmicks. It's just a bad investment.
      • ecares 5y ago
        > Could you not just build a URL loader and cache for importing in Node.js? Could sandboxing not just be a flag in Node.js? Do you really need TypeScript built in? There are open PRs on node for the first two parts ^^ It's 100% doable.
        • 5y ago
• DanielVZ 5y ago
  > Great, but we're talking about server software so the first thing any project is going to do is enable all of that. And it's not like you can trust this on the server, you'd still need to sandbox to process if you truly want isolation. Except that we aren't talking about server software. Node is a js runtime environment, and it is being used for other things like scripts and CLIs. > I guess that could be convenient but I'm struggling to think of a situation where installing node has ever been a problem. There are a ton of CLIs made with node that need to be installed globally. As someone that never uses node this feature would help me keep my binaries explicitly and tidily under `~/.local/bin`.
• zerkten 5y ago
  >> Secure by default. No file, network, or environment access, unless explicitly enabled. > Great, but we're talking about server software so the first thing any project is going > to do is enable all of that. And it's not like you can trust this on the server, you'd > still need to sandbox to process if you truly want isolation. These are not intended to be quick fixes for the masses nor replace sandboxes. They contribute to strength in depth and frustrate attackers looking to make pivots. I'd recommend taking some time to consider the threat models that these measures are align to. There is evidence that making changes like this contributes to the overall security of an ecosystem. You have a smaller percentage of people who will go ahead and do the wrong thing initially (if you support them with proper guidance), but it's only over time that you have projects based on the platform. More importantly, a change is being made that can sustain a culture of security over the long-term. When you have to maintain systems that aren't built on platforms with support for measures like these it becomes difficult to retrofit any meaningful level of security, or there is too much obfuscation in the system to justify improving it without rewriting it. Here you can see that the original implementers have enabled privileges unnecessarily and there is a clear angle of attack. Along the way you can also revert all other kinds of bad practices and hacks that previous developers implemented (random calls to external services you don't expect, loading configs from disk that should be loaded another way, etc.) These are not uncommon experiences when technology gets into the hands of the mainstream.
• flowerlad 5y ago
  See comparison here: https://deno.land/manual#comparison-to-nodejs https://deno.land/manual#comparison-to-nodejs The big one for me is, ability to use async/await instead of supplying callback methods.
• deleted 5y ago
  [deleted]
• boardwaalk 5y ago
  I think it probably makes more sense if you’re in the Node universe (and Dahl created the thing). If your window for the state of the art is… the range of what Node and its immediate surroundings can do, then Deno probably seems like a marked improvement. While people (well, me) look from the outside and think: This is how far you moved on a clean slate? Then you consider waiting for the ecosystem to mature (considering the mess the JavaScript has been and has only recently been slowing down) and go, “Ehh.” I don’t mean to denigrate; Node and Deno (already) are far bigger success stories than I’ll ever have.
• lucideer 5y ago
  > the first thing any project is going to do is enable all of that I'm sure many (most) will but the point is that for those who do care about security, Deno offers them the option of running their server app with such features selectively enabled according to need. > it's coupled to Microsoft's take on Javascript Deno supports Javascript too so there's no tight coupling here. It's also a second well-supported widely-used independent implementation of microsoft's syntax, which is no hard guarantee of anything but bodes well if vendor lock-in is a concern. > What about Flow Flow is significantly less popular so this decision seems understandable. I cannot see Deno being as popular as it is now if they had opted for Flow. Also, while Flow has some advantages, it's a lot less expressive and most reviews of both prefer TS for quite well-argued objective reasons. > What's wrong with using Babel with sourcemaps? Given the complaint about coupling just two sentences previous to this one, this makes your comment seem quite disingenuous. Are you serious??? > Will that not just bring about another npm situation in a few years? It might but your goalposts seem to be moving. Are you saying this makes it worse than npm somehow?
  • andrewmcwatters 5y ago
    Could you not reply this way?
    • lucideer 5y ago
      Not sure what you mean; is the formatting hard to read, or do you mean the content?
• fabiospampinato 5y ago
  I think you should look at it the other way around, assuming you are already using a mature version of Deno it most probably wouldn't make sense to switch to something like NodeJS: - Why using CommonJS over standard ESM modules? - Why using a package manager like NPM? Browsers don't have package managers, my code can run on the client without something like NPM, why should it be any different on the server? - Why having callback-based APIs in a world of promises and async/await? - Why having node-only APIs when today standardized browser equivalents exists? - For better or for worse as far as I'm concerned TypeScript is the de-facto successor of JavaScript, especially if you need to work on big codebases. Flow is irrelevant outside of Facebook. If something better pops up Deno could adopt that too or you could just compile that to JS yourself and Deno would work with it already. As things stand currently other compile-to-JS languages are way less important than TS. - Servers aren't the only kind of application that can be written on top of Deno, why on earth would I want eslint to be able to have access to the network or spawn child processes? Or even have global read/write access to my whole disk? Deno's model is a much better default than Node's from a security perspective. You can't even install something from NPM with reasonable certainty that that won't nuke your computer. Essentially switching from Node to Deno may not seem like an obvious improvement, but it is in many ways, switching from Deno to Node has only drawbacks basically, if you don't consider Node's advantage in ecosystem size I can't imagine why anybody would switch from Deno to Node in the future.
  • spankalee 5y ago
    Browsers generally are running code that came from a package manager these days. But devs expect to run a file server for their browser code. Do Deno devs need to expect to run a separate file server for their Deno code?
• handrous 5y ago
  > > Secure by default. No file, network, or environment access, unless explicitly enabled. > Great, but we're talking about server software so the first thing any project is going to do is enable all of that. And it's not like you can trust this on the server, you'd still need to sandbox to process if you truly want isolation. See below re: static builds, but they're making decisions that render Deno much more useful for cross-platform desktop distribution ("what do you mean, cross platform scripts are already easy to distribute" LOL I mean cross-platform including Windows) than Node, or most other scripting languages, for that matter. > > Supports TypeScript out of the box. > Okay so it's coupled to Microsoft's take on Javascript. What about Flow or any of the other compiles-to-Javascript languages? What's wrong with using Babel with sourcemaps? Having it built in means your JS build Jenga tower can be a little shorter, which is great, because the JS build ecosystem is batshit crazy. TypeScript's the right horse to back because it's become a de facto standard already—its tooling is much better than Flow, for one thing, and a lot of people seem to prefer its style. It's a better choice than other compile-to-JS languages because it's very close to vanilla Javascript, to the point that you can tell it to compile to JS that looks hand-written and clearly maps to what you wrote in the TS (this is because its compilation process is mostly just stripping out all the TS stuff). To adopt something like Elm would be to ask developers to develop a completely different language, not just JS-with-static-types. Why static types built-in at all? It can allow for good advances in tooling and performance that wouldn't be available without it. > > Ships only a single executable file. > I guess that could be convenient but I'm struggling to think of a situation where installing node has ever been a problem. This is, to be blunt, fucking wonderful if you're distributing to both Unixy operating systems and Windows, especially if you don't have tight administrative control over all machines involved. Vendoring in stuff like your script runtime is brilliant for preventing all kinds of problems, and if it's a single static binary or (even better) produces static bins that bundle your script, too, then that's very easy to do. Besides, dealing with NPM (or any other language package manager—pip, etc, they're all a pain in the ass when it comes to distribution) on the user end sucks, so you're going to want to bundle everything up in one file anyway, one way or another, if you can. > > Has built-in utilities like a dependency inspector (deno info) and a code formatter (deno fmt). > Is this not the job of the package manager? Or does deno force you to use itself as the package manager? Will that not just bring about another npm situation in a few years? This is one thing Go got very right. Building in the basic tools is the right thing to do.
• SkyMarshal 5y ago
  > Secure by default. No file, network, or environment access, unless explicitly enabled. > Supports TypeScript out of the box. > Ships only a single executable file. > Has built-in utilities like a dependency inspector (deno info) and a code formatter (deno fmt). Taken all together instead of individually, Deno is clearly designed to produce more secure and maintainable codebases than NodeJS over longer periods of time and team turnover. All of these "by default" additions better ensure a common, high-standard baseline for any arbitrary Deno codebase over any period of time. Individual developers often tend to focus on "how does this help me/improve my workflow right now?", instead of thinking like a CTO and focusing on "how does this technology make our IT systems more robust to long-term maintenance, developer turnover, and security threats?". Secure by default means you shift security from the developer team into the framework. Say your original security-focused developer team attritions over time, and due to a software engineer shortage you're forced to hire less experienced or less security-oriented folks. Even if you end up with a new team more oriented to "move-fast-and-break-things" than secure-by-design/correct-by-construction, your framework still provides a minimum security baseline they can't intentionally or accidentally violate. That works in reverse too - say you're a new startup that can't afford to hire the best of the best yet. If you choose a secure-by-default framework like Deno, you're getting security and correctness from the framework for free, rather than having to pay a premium for developer talent capable of that. Typescript instead of Babel means that all Deno codebases everywhere will use the same language, one that provides better correctness and security guarantees than most Babel options. Built-in dependency-inspector simply makes that function more available and apparent to developers. Maybe useful for new entry-level folks, not so much for more experienced ones. And I thought the value of a built-in code-formatter was demonstrated by Go with gofmt - all Go codebases everywhere are formatted the same way, making it easier for Go devs to get up to speed with a new codebase. One of things that used to really annoy me about both Rails and Nodejs was how they were not secure-by-default and left certain security details/holes to be implemented/fixed on an ad-hoc basis on every new project by individial dev teams. But the whole point of a framework is to provide common solutions to such common problems that all projects incur, so the dev team can focus on the custom and creative parts of the app, the value-added parts, the competitive edge. It's great to see Deno and others doing this.
• whimsicalism 5y ago
  Honestly what world are you living in where Flow is even remotely relevant in 2021?
• tills13 5y ago
  > Okay so it's coupled to Microsoft's take on Javascript I think your bias is showing.
• eyelidlessness 5y ago
  I had a very similar reaction at first (the exception being first class TypeScript support). I’ve since come around to being very interested in Deno and curious to use/support it more. Here’s what’s brought me there: - As I’ve adopted ESM, I’ve found Node’s ESM support difficult to deal with. Deno being ESM by default is a huge improvement, and makes portability to other environments much easier. - Similarly, Deno’s default deferral to existing JS/browser standards helps portability immensely. - TypeScript isn’t just supported, it’s very fast! Much faster than solutions like ts-node. Not limited/incomplete like current esbuild-based ESM loaders (though I’m actively working on solving that for Node). - Async APIs are all Promise-based. No legacy sync/callback/promisify. - Import maps allow complete flexibility with dependencies: you can use NPM or another package manager if you really want. You can customize package management however you prefer. You can completely sidestep NPM audit hell. - The standard library is good actually! And it’s ESM so it’s immutable by default. - Quite a lot of stuff that requires build tooling (eg isomorphic web) is not needed server-side at all. But I was curious about your questions about Babel/Flow and it looks like there are APIs that allow you to customize compilation if you need to.
  • TechBro8615 5y ago
    The module stuff is what has me looking at it. We’ve got a bunch of Node services that are relatively small and single purpose. Using tsnode, adding a build step, tinkering with ESM/CommonJS to work within the monorepo TS project reference graph... it feels like a huge PITA with mostly unnecessary overhead. Basically... we’re a “TypeScript native” project from day zero... so why do we need to be weighed down with all this cruft from historical JS ecosystem decisions? I’m planning to try swapping one of these services to Deno to see how much easier it is.
• daffl 5y ago
  One thing that I think is often overlooked when it comes to Deno is how the combination of secure defaults, web API compatibility and the dependency loading system can essentially eliminate the need for actual deployment builds and containers making it a great candidate for a truly open source and non-proprietary serverless platform. Especially in combination with content addressed file systems like IPFS (which gives you additional features like built-in checksums, immutability, de-duplication and storage resilience) you can have a Deno instance running and as the deployment step simply send it a file hash or URL to execute (of course with the appropriate security precautions like a signature or encryption on top). I built a prototype to see how it could work and a full Deno app deployment to my own VPS took less than 2 seconds. No git pushes, no container build pipelines, no proprietary cloud services.
• Already__Taken 5y ago
  Deno looks great to glue together CICD work