31 ms·

Deno 1.0

• mburns 6y ago
  404 not found
  • JadeNB 6y ago
    http://deno.land http://deno.land itself (without the trailing `/v1`) seems to work. It's "a secure runtime for JavaScript and TypeScript".
  • nerdkid93 6y ago
    it hadn't been deployed yet, it's up now
• seleniumBubbles 6y ago
  Congratulations on the 1.0 release! I've been using Deno as my primary "hacking" runtime for several months now, I appreciate how quickly I can throw together a simple script and get something working. (It's even easier than ts-node, which I primarily used previously.) I would love to see more focus in the future on the REPL in Deno. I still find myself trying things in the Node.js REPL for the autocomplete support. I'm excited to see how Deno can take advantage of native TypeScript support to make a REPL more productive: subtle type hinting, integrated tsdocs, and type-aware autocomplete (especially for a future pipeline operator).
  • indemnity 6y ago
    Seconded, a Deno TS REPL would be amazing, but they probably have a few bigger fish to fry yet :)
    • IggleSniggle 6y ago
      > bigger fish to fry > fish I see what you did there, and I approve.
  • damagednoob 6y ago
    I evaluated replacing ts-node with deno but if I use -T and install ts-node globally that seems equivalent to deno to me. I think stepping outside the npm ecosystem is going to be a bigger issue then people think.
  • feihcsim 6y ago
    i wonder if it's conceivable to ever write typescript in a REPL
    • regularfry 6y ago
      There are both ocaml and haskell repls, so it can be done with languages whose type systems are the focus. Not sure if there's anything specific about typescript that would make it hard, though.
  • Pyrodogg 6y ago
    Repl.it recently announced a Deno REPL https://repl.it/languages/deno https://repl.it/languages/deno
    • MuffinFlavored 6y ago
      I really wish they had docker-compose / Terraform support. Just not sure at what point that becomes "free" hosting.
• kalium-xyz 6y ago
  Finally we can use it on production, great work everyone involved in making this happen!
• ravenstine 6y ago
  Are imports async by default in Deno? That seems to be how it works given that you can import from a URL. This is interesting since async imports are currently a part of JavaScript(or at least a proposal?) by using the `import()` function.
  • snek 6y ago
    there are no "async" or "sync" imports in js. there are static and dynamic imports. An implementation is free to spend as much time as it likes between parsing a file to get the static imports and actually running the file doing whatever it likes, including fetching urls, reading the file system, etc. dynamic imports return a promise but the implementation is free to resolve that promise immediately (e.g. `return Promise.resolve(loadSync(module))`)
    • ravenstine 6y ago
      I suppose that makes sense since loading a module from a file on a disk isn't all that different from loading a file over a TCP connection.
• threatofrain 6y ago
  > Internally Deno uses Microsoft's TypeScript compiler to check types and produce JavaScript. Compared to the time it takes V8 to parse JavaScript, it is very slow. > Early on in the project we had hoped that "V8 Snapshots" would provide significant improvements here. Snapshots have certainly helped but it's still unsatisfyingly slow. We certainly think there are improvements that can be done here on top of the existing TypeScript compiler, but it's clear to us that ultimately the type checking needs to be implemented in Rust. > This will be a massive undertaking and will not happen any time soon; but it would provide order of magnitude performance improvements in a critical path experienced by developers. TSC must be ported to Rust. If you're interested in collaborating on this problem, please get in touch.
  • deleted 6y ago
    [deleted]
  • rvz 6y ago
    A note on Deno and the safety of its V8 bindings: > All of the V8 source code is distributed in the crate itself. Finally rusty_v8 attempts to be a safe interface. It's not yet 100% safe, but we're getting close. Being able to interact with a VM as complex as V8 in a safe way is quite amazing and has allowed us to discover many difficult bugs in Deno itself. We'll also have to wait on who will be the first to have a production ready Javascript Engine written in Rust that could replace V8, if you're talking about safety. Even with the "safe" bindings, you will still get the same C and C++ vulnerabilities found in V8 that will also be present in Deno.
    • ahupp 6y ago
      For this sort of problem Rust's safety guarantees don't buy you all that much. If you're generating machine code and implementing a GC that's not the sort of thing that Rust's typesystem can prove correct. That said, a rust JS runtime would be amazing just because it's easier to integrate into rust projects.
      • klodolph 6y ago
• gen220 6y ago
  For context: Deno's lead is Ryan Dahl, the creator of Node. In the past, Dahl's expressed regrets over choices he made early on in Node's development, and on the direction Node has gone since he left the project many years ago. He bravely presented on this topic at jsconf eu, 2018: https://www.youtube.com/watch?v=M3BM9TB-8yA https://www.youtube.com/watch?v=M3BM9TB-8yA, it's a fantastic talk. The last 10 minutes are a pitch for what a "better Node" would look like, if he were to start from scratch in 2018. The end result of that train of thought this project, which we should probably think of as bourne-again node. Deno's development is (presumably) strongly influenced by his experience and furstrations with Node's shortcomings in both performance and developer ux.
  • lghh 6y ago
    And now, he'll make a whole different set of good and bad choices to potentially regret later.
    • gen220 6y ago
      such is the curse of having the audacity to develop software :)
      • lghh 6y ago
        Not necessarily. I prefer trying to improve what we have verses making a new thing every time we have a relatively minor disagreement, even if that disagreement is with our past self. EDIT: I'd like to add that clearly he is able to spend his time as he wishes.
        • gen220 6y ago
          I generally agree. Although, some of these are pretty "opinionated" breaking changes (promises all the way down, package manager changes). It would be hard to convince the whole node community that these upgrades are worth the risk forking in a python 2/3-esque way. Forcing TS is a change node could adopt in the next major version if everybody agreed, but the node community might be too big and diverse at this point, to make such an opinionated switch.
• firloop 6y ago
  For the uninitiated, worth noting that one of the names on this post, Ryan Dahl, was the original node.js developer.
  • networkimprov 6y ago
    Who somehow still hasn't realized that backends written in Javascript don't scale very well. Automatic asynchronicity only buys you so much. I'm writing as a former Node.js user.
    • javajosh 6y ago
      "Automatic asynchronicity[sic]"?! Node and all async io is cooperative multi-tasking, the opposite of automatic. The node event loop is a thin wrapper around the epoll() system-call (or one of its equivalents), and leaves the details of multi-tasking to the app developer. It's no wonder you weren't able to scale under node if you thought something was happening automatically for you!
      • rubber_duck 6y ago
        Maybe he meant forced async as DOM/node blocking APIs are async/callback based since it's the only multitasking model available (or it was before workers)
    • root_axis 6y ago
      Why do you say this?
  • ignoramous 6y ago
    Also for the uninitiated, fly.io is migrating to deno for their Serverless functions: https://news.ycombinator.com/item?id=22621926 https://news.ycombinator.com/item?id=22621926
    • mahmoudimus 6y ago
      Precisely the use case that Deno should be used for. Serverless functions are a great use case for Deno right now.
• pvg 6y ago
  Some of the bigger previous threads: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&query=Deno%20&sort=byPopularity&type=story https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
• deleted 6y ago
  [deleted]
• cocktailpeanuts 6y ago
  if you require modules by URL, how does it make sure that the URL always contains the same library? I've read the docs and it says it caches on the initial execution and doesn't update unless it's forced to update, but what happens when you for example publish a deno module to github, and someone else downloads it and runs it, and turns out the URL contains completely different library at his execution point?
  • piscisaureus 6y ago
    This is something that we'll further work out in future versions. For now you can use a lockfile: https://deno.land/manual/linking_to_external_code/integrity_checking https://deno.land/manual/linking_to_external_code/integrity_...
    • hn_throwaway_99 6y ago
      > Deno can store and check module subresource integrity for modules using a small JSON file. Use the --lock=lock.json to enable and specify lock file checking. To update or create a lock use --lock=lock.json --lock-write. HALLELUJAH that there is a clear, simple separation of when (a) you expect a lock file to be checked to guarantee integrity and (b) when you want it to be generated. The complete insanity that was npm shrinkwrap and lockfiles for years, summed up in this stackoverflow post https://stackoverflow.com/questions/45022048/why-does-npm-install-rewrite-package-lock-json https://stackoverflow.com/questions/45022048/why-does-npm-in... , always baffled me in that it seemed like it could have just been so easily avoided about being explicit when you're writing a lockfile vs. when you're using it. That said, why not be even MORE explicit about it, i.e. "--use-lock=lock.json" vs. "--write-lock=lock.json"?
    • xg15 6y ago
      This looks really promising. However, it still seems risky to me in case a library is not available. Is there a central repository planned? Or are you expected to vendor everything and ship your project with dependencies included?
    • marktolson 6y ago
• chrysoprace 6y ago
  This is exciting news indeed. Deno hitting 1.0 still makes the ecosystem surrounding it quite young, but it's an important milestone and I'm excited to see what comes of it in the future.
• m00dy 6y ago
  Hi, I'm the co-founder of https://deno.services https://deno.services . We would like to make Deno first language in history comes with its own infrastructure.
  • omniscient_oce 6y ago
    Is there much point asking for signups when the only info there is is one sentence and a screenshot?
    • hello_moto 6y ago
      Don't you know? https://unbounce.com/landing-pages/test-new-products-and-ideas/ https://unbounce.com/landing-pages/test-new-products-and-ide... :)
  • fctorial 6y ago
    clojure.jar comes with tools.deps. It needs jvm as well though.
• swah 6y ago
  Why are we still treating dynamic languages as "scripting languages" as if you can't do the same thing one does in Go?
  • Gene_Parmesan 6y ago
    So at this fine grain of semantic detail, making strong statements about differing labels feels a little silly, but I have always thought that the difference is dynamic refers to typing, whereas scripting is usually a reference to the language being interpreted rather than compiled. Dynamically typed languages can certainly be compiled (I think Clojure qualifies here?).
    • IggleSniggle 6y ago
      And in that case, what do we make of QuickJS, which compiles JavaScript to bytecode?
  • deleted 6y ago
    [deleted]
  • throwaway894345 6y ago
    What does this comment even mean? I can’t make heads or tails of it.
• petercooper 6y ago
  If you're getting into Deno and want to keep up with new stuff from the ecosystem on a regular basis, we're now publishing https://denoweekly.com/ https://denoweekly.com/ .. issue 2 just went out minutes after the 1.0 release. I've been doing JavaScript Weekly for 487 issues now, so this is not a flash in the pan or anything :-D Of course, Deno has an official Twitter account as well at https://twitter.com/deno_land https://twitter.com/deno_land :-)
  • notjustanymike 6y ago
    Keep up the good work, JS weekly is a wonderful resource.
  • ArtWomb 6y ago
    I suppose .land is the new .dev now ;) Am curious how Parallelism could be handled in the runtime? Besides exposing WebWorkers, would shared memory be a possibility? V8 looks like its heading toward a portable WebAssembly SIMD accelerator. >>> Promises all the way down Async / await is a great pattern for render loops by resolving to continuous window.requestAnimationFrame calls. Here is a nifty example computing a Buddhabrot and updating new data quite smoothly: http://www.albertlobo.com/fractals/async-await-requestanimationframe-buddhabrot http://www.albertlobo.com/fractals/async-await-requestanimat...
  • wintorez 6y ago
    Good to see you here!
  • swyx 6y ago
    right on top of it Peter! nice
  • lenkite 6y ago
    Root certificate not trusted for https://denoweekly.com/ https://denoweekly.com/ on both chrome and firefox.
    • petercooper 6y ago
      Hmm, interesting! Thanks for the report. I just ran it through Qualys SSL Labs and everything passed. (We got a B though because we still support TLS 1.1.) It's a multi-domain Let's Encrypt X3 certificate and I believe most LE users will be in a similar boat now.
• VWWHFSfQ 6y ago
  > We believe JavaScript is the natural choice for dynamic language tooling; whether in a browser environment or as standalone processes. I disagree with this assessment. Lua is still far superior as an embed-able scripting language/runtime. I suspect the preference for JavaScript is mostly due to the Deno developers' familiarity and preference.
  • tills13 6y ago
    > Lua is far superior I disagree with this assessment.
    • VWWHFSfQ 6y ago
      LuaJIT is nearly 3x faster than V8 JavaScript the last time I checked. Just anecodal DDG search [0]. Maybe V8 has gotten faster since the last time I checked. [0] https://duckduckgo.com/?t=ffab&q=is+luajit+faster+than+v8+javascript%3F https://duckduckgo.com/?t=ffab&q=is+luajit+faster+than+v8+ja...
      • rosywoozlechan 6y ago
        Lua also has a smaller footprint I think.
        • hombre_fatal 6y ago
          It has a worse standard library than Javascript. And its static typing solutions don't compare to Typescript.
          • wyozi 6y ago
            Funnily enough the state of art in typed lua is typescript: https://github.com/TypeScriptToLua/TypeScriptToLua https://github.com/TypeScriptToLua/TypeScriptToLua
      • afiori 6y ago
        I think a big part of the point is to build a js runtime for existing js code and libraries. Probably it will not replace node soon, but it is a possible outcome. Also didn't luajit had the problem that it would never move to more recent version of lua? I remember that some years ago there was some talking about this.
• Jugurtha 6y ago
  This sentence, five paragraphs below, says what this is about: > Deno is a new runtime for executing JavaScript and TypeScript outside of the web browser.
• corndoge 6y ago
  > We seek a fun and productive scripting environment that can be used for a wide range of tasks. So Lua, but Javascript? Could be neat
• pedalpete 6y ago
  Does anyone else see the import directly from URL as a larger security/reliability issue than the currently imperfect modules? I'm sure I'm missing something obvious in that example, but that capability terrifies me.
  • mrkurt 6y ago
    It's basically the same "exposure" as importing a random npm, but it has the benefit if being explicit when you do it. It's also exactly what the websites you visit do. ;)
    • xg15 6y ago
      > It's basically the same "exposure" as importing a random npm, but it has the benefit if being explicit when you do it. I'm not sure how this works in detail here, but at least in NPM you got a chance to download packages, inspect them and fix the versions if so desired. Importantly, this gave you control over your transitive dependencies as well. This seems more like the curl | bash school of package management. Edit: This is explained in more detail at https://deno.land/manual/linking_to_external_code https://deno.land/manual/linking_to_external_code and indeed seems a lot more sane. > It's also exactly what the websites you visit do. ;) Well yes, and it causes huge problems there already - see the whole mess we have with trackers and page bloat.
      • mrkurt 6y ago
        The tldr is Deno also gives you a chance to download + inspect packages, and then lock dependencies. The mechanism for import is different, but the tooling is good.
      • thysultan 6y ago
        The good thing about this is you can effectively build a register service that serves the same level of trust that npm provides, because at the end of the day that is the only deferential in this scenario as npm can just as well return malicious code.
      • 6y ago
• cryptica 6y ago
  >> Internally Deno uses Microsoft's TypeScript compiler to check types and produce JavaScript. Compared to the time it takes V8 to parse JavaScript, it is very slow. >> We certainly think there are improvements that can be done here on top of the existing TypeScript compiler, but it's clear to us that ultimately the type checking needs to be implemented in Rust. Funny, I was just talking about something like this in an earlier TypeScript discussion today. I was saying that I don't understand why Microsoft doesn't have their own native TypeScript runtime engine by now. I have nothing against TypeScript as a language but I hate the TypeScript transpiler; it should be packaged as an engine, not as a transpiler. I just hate having to debug mangled transpiled code and dealing with sourcemaps. I want to be able to run and debug my own code, not some alternative mangled version of it. I think Deno is a promising project in the sense that they seem to understand the drawbacks of transpilation and are actually trying to provide TypeScript support which feels native. Everyone else seems to be ignoring this problem including the creators of TypeScript.
  • mrkurt 6y ago
    They have ChakraCore (which is js), but the thing about a "TypeScript runtime" is it's not that different from a JS runtime. TypeScript is a super set of JavaScript so it already has to do the JS runtime work. v8 is pretty good at that.
  • uryga 6y ago
    > I don't understand why Microsoft doesn't have their own native TypeScript runtime engine by now what would they do with it? ship it in Edge? great, now some small fraction of users can run TS natively. but most can't, so everyone would still transpile to JS anyway... it could work if Google did it, but i don't think MS has enough market share to have an influence here
    • noahtallen 6y ago
      It would work for server-side tools (like Deno). For example, cloud functions on various cloud platforms often support TS.
• perlpimp 6y ago
  I remember node stayed 0.11 or some sub 0.* numbers for the longest time. barely progressing version numbers, anything changed? Just wondering.
  • sintaxi 6y ago
    IMHO those were the golden years of developing with node.
• Avi-D-coder 6y ago
  This is fantastic. I would love to see vscode, coc, kde, gnome and other applications that use node extensions, to adopt Deno.
• tills13 6y ago
  I want that hoodie but $100 is a little steep for me...
• weeksie 6y ago
  This is super effing awesome. You know what would be extra amazing? Incorporating (at some point in the future) all of the very smart stuff that the unison people have been doing. That would be _tremendous_ for code re-use and guarantees about remote packages. What I wouldn't give for a JS vm that could do all that. . . . * https://www.unisonweb.org/docs/tour https://www.unisonweb.org/docs/tour
  • cdata 6y ago
    I like that Deno prefers URLs as module specifiers. Need immutable/content-addressed dependency graphs? Publish and consume modules via IPFS.
    • weeksie 6y ago
      Maybe I’m missing something but the reason why the concept behind unison is so neat is that identifying libraries by AST allows for the kind of code re use that Joe Armstrong was talking about. It’s not about urls as identifiers, that’s superficial. What’s the relevance of IPFS?
• _bxg1 6y ago
  So it's an alternative to Node? Sounds incredibly cool, honestly. This: > Supports TypeScript out of the box. Seems like a small thing, but it has me interested all on its own. It's a huge pain to set up a whole build process just for TypeScript (which is generally the only preprocessing you need outside of the browser).
  • mrkurt 6y ago
    Yes it's great! My deno projects are really simple directories, `deno run server.ts` is nice and tidy.
  • gunn 6y ago
    You'll like https://www.npmjs.com/package/ts-node https://www.npmjs.com/package/ts-node - it allows zero processing use of typescript
    • desert_boi 6y ago
      Zero processing is a little generous, for things like like ES Module support (and interop), ts-node can be a struggle to get going.
      • gunn 6y ago
        As in .mjs files? Personally, I just want to import my own .js / .ts files and external npm packages which works well - https://github.com/gunn/covid-19-scripts/blob/023579e1cf/get-population-data.ts https://github.com/gunn/covid-19-scripts/blob/023579e1cf/get... The catch for me is that it's probably not suitable for a sever in production as mentioned elsewhere in this thread.
    • bgdam 6y ago
      Word of warning though - ts-node can be excruciatingly slow. We recently switched a project from using ts-node in our dev environment to compiling with tsc and running with node, and shaved around 5 minutes from our startup time.
• squid_demon 6y ago
  And the very first line of sample code is adding a dependency on someone else's code. Reminds me of https://npm.anvaka.com/#/view/2d/react-native https://npm.anvaka.com/#/view/2d/react-native Good luck, though. Everyone lives in a different (mental) tribe I suppose...
  • kevinkassimo 6y ago
    The very first line of sample code is linking to Deno standard modules, basically the standard library for Deno, aiming to be feature complete enough to bring down the side of dependencies
  • Igelau 6y ago
    So, I've never seen this before, but I'm 99.9% sure that's just part of the standard library being imported...
• bgdam 6y ago
  The dependency management is highly questionable for me. Apart from the security concerns raised by others, I have huge concerns about availability. In it's current form, I'd never run Deno on production, because dependencies have to be loaded remotely. I understand they are fetched once and cached, but that will not help me if I'm spinning up additional servers on demand. What if the website of one of the packages I depend on goes down, just as I have a huge spike in traffic? Say what you want about Node's dependency management, but atleast I'm guaranteed reproducible builds, and the only SPOF is the NPM repositories, which I can easily get around by using one of the proxies.
  • ryanseys 6y ago
    It's just a URL right? So could you not mirror the packages to your own server if you're so concerned, or better yet import from a local file? Nothing here seems to suggest that packages must be loaded from an external URL.
    • bgdam 6y ago
      > or better yet import from a local file And this is different from NPM how? Except that I've now lost all the tooling around NPM/Yarn.
      • ryanseys 6y ago
        It's different because it doesn't rely on require() which is non-standard JavaScript.
        • bgdam 6y ago
          Node v14 supports ESM modules and the import syntax, which is standard Javascript.
        • akamaozu 6y ago
          setTimeout is non-standard JavaScript too but I bet your code base has multiple instances of its usage.
• sdan 6y ago
  What exactly does Deno do? I still can't figure it out: is it a secure version of Node, if so, how?
  • kennymeyers 6y ago
    It’s an alternative to node. If Node is Photoshop than Deno is Pixelmator. They both take in similar kinds of output and make similar things, but have a very different approach on how the tooling is built and used.
    • sdan 6y ago
      Good explanation, thanks!
  • blondin 6y ago
    using typescript makes it safer. also i believe we can trust the authors, because, they wrote node (or were heavily involved at the beginning)
• soperj 6y ago
  >JavaScript is the most widely used dynamic language Wouldn't that actually be python?
  • mrkurt 6y ago
    There are way more browsers in use than Python runtimes. ;)
  • buzzerbetrayed 6y ago
    What makes you think Python is more widely used than Javascript?
• pknopf 6y ago
  - "Rust has its own promise-like abstraction, called Futures. Through the "op" abstraction, Deno makes it easy to bind Rust future-based APIs into JavaScript promises." That's exciting! I wonder if that binding is public for end users to use, or if it's an internal design
  • steveklabnik 6y ago
    This exists for wasm too; it’s super easy with wasm-bindgen. I wrote a program with multiple layers, worked flawlessly. (Promise in a future in a promise created by Rust and passed back to JS)
• turblety 6y ago
  As a functional developer who doesn't care for TypeScript in any way, it's frustrating to see Deno has it "built-in". As a node developer writing pure none-compiled JavaScript, my run time is extremely fast from changing code to seeing its results. It takes milliseconds for me to run brand new code in my terminal. If I make an index.ts file simply adding two numbers together (with no TypeScript), there is a 1 to 2 second delay while it "compiles" my "TypeScript". (Again I don't write TypeScript so I don't need this feature). I should note, subsequent runs will be faster, but as I'm developing I don't want delays between my runs. Since it's not even native TypeScript, it's just embedded the tsc which builds and caches the compiled code, why not let TypeScript developers add their bundling pipeline in the same way as they've always done. Anyway, I'm very interested in the fact it's built in Rust and seems to be faster than node after compilation in many aspects. Congratulations to the Deno guys and thanks for all the effort. [edit] Correcting myself. I was wrong. As @jon889 informed me, you can actually run a `.js` file and it will skip compilation. Again I remain that the TypeScript compiler should not have been included, but the fact I don't have to use it completely mitigates my main concern.
  • mrkurt 6y ago
    > As a node developer writing pure none-compiled JavaScript, my run time is extremely fast from changing code to seeing its results. It takes milliseconds for me to run brand new code in my terminal. Deno runs JavaScript faster than node: echo "console.log(1 + 2)" > not-ts.js time deno run not-ts.js 3 0.01s user 0.01s system 89% cpu 0.025 total time node not-ts.js 3 0.03s user 0.08s system 53% cpu 0.203 total > Since it's not even native TypeScript, it's just embedded the tsc which builds and caches the compiled code, why not let TypeScript developers add their bundling pipeline in the same way as they've always done. You can!
    • turblety 6y ago
      > Deno runs JavaScript faster than node Yup, and that's really cool and exciting. My issue isn't with runtime timing. That's not what costs me money. Developer time is what costs money, and every change having to "recompile" my already raw JavaScript costs way more than saving 0.02s at runtime.
• aazaa 6y ago
  > ... Deno is (and always will be) a single executable file. Like a web browser, it knows how to fetch external code. In Deno, a single file can define arbitrarily complex behavior without any other tooling. > ... > Also like browsers, code is executed in a secure sandbox by default. Scripts cannot access the hard drive, open network connections, or make any other potentially malicious actions without permission. The browser provides APIs for accessing cameras and microphones, but users must first give permission. Deno provides analogous behaviour in the terminal. The above example will fail unless the --allow-net command-line flag is provided. The Deno feature that seems to draw the most fire is dependency management. Some skeptics may be latching onto the first point without deeply considering the second. Deno is just doing the same thing a browser does. Like a browser, there's nothing that JavaScript running on sandboxed Deno can do that a browser can't - in principle. So the security concerns seem a little over the top. The one caveat is that once you open the sandbox on Deno, it appears you open it for all modules. But then again, that's what NPM users do all the time - by default. As far as criticisms around module orchestration, ES modules take care of that as well. The dependency graph forms from local information without any extra file calling the shots. This seems like an experiment worth trying at least.
  • bgdam 6y ago
    See the thing about the sandbox is that it's only going to be effective for very simple programs. If you're building a real world application, especially a server application like in the example, you're probably going to want to listen on the network, do some db access and write logs. For that you'd have to open up network and file access pretty much right off the bat. That combined with the 'download random code from any url and run it immediately', means it's going to be much less secure than the already not-that-secure NPM ecosystem.
    • ricardobeat 6y ago
      Maybe this will develop into a standard of multi-process servers (real micro services you could say), where the permissions are only given to a slice of the application.
• anderspitman 6y ago
  > In Deno, sockets are still asynchronous, but receiving new data requires users to explicitly read() Interesting. If I understand correctly, they're essentially using pull streams[0]/reactive streams[1]. I compiled a few resources on this topic when I was digging into it a while back[2]. I've found the mental model to be very elegant to work with when needing backpressure in asynchronous systems. As for the dependencies-as-URLs, I don't mind it, and may prefer it. I've been experimenting with minimizing my dependencies lately, and vendoring them in git submodules. It's worked fairly well. [0]: https://github.com/pull-stream/pull-stream https://github.com/pull-stream/pull-stream [1]: https://github.com/reactive-streams/reactive-streams-jvm https://github.com/reactive-streams/reactive-streams-jvm [2]: https://github.com/omnistreams/omnistreams-spec https://github.com/omnistreams/omnistreams-spec
  • cakoose 6y ago
    Is this different from how streams work in most other languages, e.g. Java, Go, Python?
    • anderspitman 6y ago
      Most languages block by default, so backpressure is much easier to model: just don't read until you need more data and the sender will block. But in JS the receiving end will just keep firing off data events until you pause it, or use something like reactive streams to request data as you're ready for it. That's my understanding of the situation at least.
  • cakoose 6y ago
    When describing the input stream back-pressure problem: > To mitigate this problem, a pause() method was added. This could solve the problem, but it required extra code; and since the flooding issue only presents itself when the process is very busy, many Node programs can be flooded with data. The result is a system with bad tail latency. Are they saying that even with correct use of pause() there are still issues?
    • winrid 6y ago
• malkia 6y ago
  No. Without some kind of signature check (SHA256 or SHA512 or something more modern - just say No). it's tempting though :)
• deleted 6y ago
  [deleted]
• cphoover 6y ago
  I think Deno is a mistake at this point... Yes we thank Ryan Dahl for his huge contributions to integrating libuv and v8 outside of a browser to create node.js but a lot of work has been created by a huge ecosystem of developers after this. I think this de-facto fork of node.js will only serve to create fragmentation, and confuse product owners about which platform to use.
  • gutino 6y ago
    If We were all follow your rationale, We will be all programing in COBOL still. Accept the pain of experiment and growing up.
    • cphoover 6y ago
      Sometimes splitting a community is worth it, but it shouldn't be a decision made lightly. And Ryan Dahl should consider his words bear weight as the original creator of the platform. I think it's a fair issue for critique.
• cdnsteve 6y ago
  Is anyone else excited about a standard library out of the box?
• onemoresoop 6y ago
  Deno = no de, sorted ascending
• izelnakri 6y ago
  I would really like a testing framework like AVA on deno, same amazing API of seperating parallel and serial tests and running them on multiple threads. Also I will need npm compatibility soon, once these are in, why would I ever write code in node.js?
• tolmasky 6y ago
  Forget the (reasonable) security and reliability concerns people have already brought up with regard to importing bare URLs. How about just the basic features of dealing with other people's code: how am I supposed to update packages? Do we write some separate tool (but not a package management tool!) that parses out import URLs, increments the semver, and... cURLs to see if a new version exists? Like if I am currently importing "https://whatever.com/blah@1.0.1" https://whatever.com/blah@1.0.1", do I just poll to see if "1.0.2" exists? Maybe check for "2.0.0" too just in case? Is the expectation that I should be checking the blogs of all these packages myself for minor updates? Then, if you get past that, you have a huge N-line change where N is every file that references that package, and thus inlines the versioning information, instead of a simple and readable one-line diff that shows "- blah: 1.0.1, + blah: 1.0.2".
  • austincheney 6y ago
    You have to stop thinking in terms of NPM where it takes 1000000000 packages to do anything. A Deno application is designed to be distributed as a single file. You can override the default behavior to have NPM like stupidity, but if that is really your goal why bother moving to Deno in the first place?
    • tolmasky 6y ago
      Forget 10000000 packages. Many languages often make use of 10s of packages. If I have several projects, each with around 10 packages, and no automated way to just check if all my projects’ respective dependencies have security updates that could be applied, it seems to go against the stated security goal. Separately I’m not sure what is enforcing this “small dependency graph” aside from making it hard to import things I guess. I wouldn’t be surprised if you end up with the normal behavior of people coming up with cool things and other people importing them.
      • austincheney 6y ago
        > and no automated way to just check if all my projects’ respective dependencies have security updates Dependency management is a major cornerstone of any infosec program. There is more to that than just auto-installing a new dependency version. > I’m not sure what is enforcing this “small dependency graph” Because a large dependency graph is slow, insecure, and fragile.
• _bxg1 6y ago
  > A hello-world Deno HTTP server does about 25k requests per second with a max latency of 1.3 milliseconds. A comparable Node program does 34k requests per second with a rather erratic max latency between 2 and 300 milliseconds. Under-mentioned feature. I may migrate my personal site to Deno just for that latency drop.
  • ch4s3 6y ago
    Yeah it seems like the p99 latency of node, which isn’t great, doesn’t get mentioned much.
• stackzero 6y ago
  As someone not from a js background, when would I use this? is it a drop in replacement for node with TS support? or something else
  • sintaxi 6y ago
    Deno will likely be well suited for network oriented server-side programs. Deno is not a drop-in replacement for node. It is an alternative JS runtime.
  • drcode 6y ago
    I view it as a replacement for node that requires less overall handholding and ceremony.
  • KitDuncan 6y ago
    I think I'll use it for personal system scripts, as JS is the language I am most comfortable in.
• cambalache 6y ago
  FWIW I tried to install it in a) Windows 10 via PowerShell, success, it took 1 min. b) Linux (WSL1) with curl, 2 min, failed. 3) Linux(WSL1) via cargo.10 min failed with this jewel: > error[E0433]: failed to resolve: use of undeclared type or module `proc_macro` --> /home/user/.cargo/registry/src/github.com-1ecc6299db9ec823/swc_ecma_visit_macros-0.1.0/src/lib.rs:25:20 | 25 | pub fn define(tts: proc_macro::TokenStream) -> proc_macro::TokenStream { | ^^^^^^^^^^ use of undeclared type or module `proc_macro` error[E0433]: failed to resolve: use of undeclared type or module `proc_macro` --> /home/user/.cargo/registry/src/github.com-1ecc6299db9ec823/swc_ecma_visit_macros-0.1.0/src/lib.rs:25:48 | 25 | pub fn define(tts: proc_macro::TokenStream) -> proc_macro::TokenStream { | ^^^^^^^^^^ use of undeclared type or module `proc_macro` error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0433`. error: could not compile `swc_ecma_visit_macros`. warning: build failed, waiting for other jobs to finish... error: failed to compile `deno v1.0.0`, intermediate artifacts can be found at `/tmp/cargo-installFIkSV2` Caused by: build failed
  • deleted 6y ago
    [deleted]
• VWWHFSfQ 6y ago
  I guess I'm wondering why Deno is targeting V8 instead of Servo? Maybe I'm mistaken, but Servo [0] and Stylo [1] are both production-ready browser scripting and styling engines implemented in Rust. [0] https://servo.org/ https://servo.org/ [1] https://wiki.mozilla.org/Quantum/Stylo https://wiki.mozilla.org/Quantum/Stylo
  • steveklabnik 6y ago
    You’ve made a category error; Servo is not a JavaScript engine.
    • VWWHFSfQ 6y ago
      > Servo is a modern, high-performance browser engine designed for both application and embedded use. What does that mean? "browser engine" Does it execute JavaScript code? Edit: I bought your Rust book on Amazon, supposed to be delivered this Friday. I can't wait!
      • steveklabnik 6y ago
        Servo puts all the parts of a browser together. SpiderMonkey is what Servo uses to execute JavaScript. That’s shared with Firefox. Ah cool! I hope you like it! :)
• 29athrowaway 6y ago
  Would like to see a comparison between node and deno using http2 and TLS.
• todd3834 6y ago
  Is the name Deno a play on shifting noDe over two spaces?
  • CawCawCaw 6y ago
    Yes. Maybe the next framework will be called "Done".
• JOnAgain 6y ago
  It would be great if this line were at the top: >> Deno is a new runtime for executing JavaScript and TypeScript outside of the web browser.
  • abraxas 6y ago
    Thanks. Came looking for this post. Way too many web developers just assume that everyone follows every nook and cranny of their ecosystem.
• the_mango 6y ago
  Added to the resume already
• angel_j 6y ago
  Waiting for Denodify so I don't have to do anything to switch from node.js
• russellbeattie 6y ago
  I think Deno is fine, and I think the project is interesting, but I also think those who want to use Typescript should do so, and stop pretending they're doing anything with Javascript. If I wanted deal with repetitive code like "function add(x: number, y: number): number {...}" I'd just use Java. There's reasons I love JavaScript, and not dealing with types is one of them. When is Typescript going to have its own version of the V8 engine and just leave JavaScript out of it? Honestly, it harkens back to the classic Microsoft Embrace, Extend, Extinguish strategy that I though we left behind in the early 2000s... I like that Deno is resetting some of the underlying assumptions that Dahl made in Node. But I think he's throwing the baby out with the bath water. I actually like and prefer an explicit node_modules directory. Grabbing everything I need, and then being able to zip it up as needed to save or share is convenient and easy. Not sure why so much effort was made to avoid this module pattern. I really think using URLs is going to be a maintenance nightmare. Instead of changing one entry in package.json (great for testing new code or tweaking something locally), I have find/replace all the imports? Seems very odd unless I'm missing something big. Also, not a fan of the hidden .deno cache directory, but whatever. Having to send along a shell script in order to even start an app is another problem. "Here's a JavaScript file which will do some task. In order to run it, you need to make sure you include these 10 command-line flags for security purposes. To make sure you don't forget them, I've included various shell scripts you can run depending on your platform." That's not improving anything.
  • msndlensn 6y ago
    > If I wanted deal with repetitive code like "function add(x: number, y: number): number {...}" I'd just use Java. I don’t even like TS, but it’s pretty clear I can discount your opinion because you don’t even know what you’re talking about.
  • dnissley 6y ago
    > Grabbing everything I need, and then being able to zip it up as needed to save or share is convenient and easy Isn't there a risk of cross platform incompatibility with some of the packages that compile on install?
  • qudat 6y ago
• Youssefbekour 6y ago
  welcom brand-new iPhone 11 Pro flagship phones Free: iPhone 11Pro Click this link to participate in the contest for free https://bit.ly/2yEjwxD https://bit.ly/2yEjwxD
• oknoorap 6y ago
  Here we go again guys https://xkcd.com/927/ https://xkcd.com/927/
• avodonosov 6y ago
  I don't understand how Promises help with backpressure.
• gpm 6y ago
  Is there some deterministic way of measuring JS execution time? Explanation for why I want that: I've started making an game RTS game - think starcraft but you can program your units. Currently I'm trying to decide what language to expose to players. The two main requirements are that it's secure (I'll be running player A's code on player B's computer) and that it has a deterministic method of counting execution time (so that player A and player B's computer can both make the same decision on whether or not a script took too much time). I'd appreciate any hints towards other languages I should look at as well.
  • FunnyLookinHat 6y ago
    Lua is frequently used for interactions with game engines and programming basic logic. Maybe see if there's a Lua engine in whatever language your game engine will be written with?
    • gpm 6y ago
      I'm writing in rust, but am happy to deal with linking whatever runtime will work best for this. I have security concerns about all the lua runtimes I've seen. They (very understandably) do not seem to be particularly battle tested against malicious use, and they have a history of security issues when I check their bugs list. Otherwise I'd love to use lua.
  • proc0 6y ago
    I guess it would depend on the JS engine. If the player is the one writing JS, and you want a scaled down environment (since it's not an app in the browser), probably making your own JS parser/engine could be the way to go? You'd want the JS engine to be inside the game engine somehow.
    • gpm 6y ago
      > and you want a scaled down environment This is definitely a requirement, a very scaled down one since I don't want any interaction with the outside world apart from the game engine (for determinism purposes). > probably making your own JS parser/engine could be the way to go That sounds like a lot of work to do well. If I had infinite time I suppose re-implementing a common language would be the best way forwards, but I don't, especially for a hobby project.
• gitgud 6y ago
  So I can import using the URL "https://somekind.com/ofpackage.ts" https://somekind.com/ofpackage.ts", that's great but what if that random endpoint changes? The benefit of NPM is that every package version is immutable... Also first class Typescript support is great, but they are just using tsc internally... isn't that directly tying a typescript version to the DENO version?
• emtel 6y ago
  I don't want to be overly critical of a very well-intentioned and worthy effort, but it is looking less and less to me like Ryan and the rest of the Deno team understand what problems node.js developers care about. Specifically: 1. The sandboxing via --allow-net, --allow-fs, etc is very odd to me. I don't recall hearing about a lot of security issues that could have been prevented by this. I mean, I suppose this won't hurt anyone, but it's certainly never something that I've wanted. I expect most people will simply white-list most access by default in all new projects. 2. deno bundle: Initially, when I heard about this, I was excited. The need to bundle code via webpack and similar systems is one of the worst things about front end browser development. It introduces tons of complexity and makes debugging much harder. So I thought, wow, maybe deno is going to just give us a first-class solution to this problem that will just work. Nope. They are only concerned with bundling code such that it can be run elsewhere by deno. A friend put it thus: "we don't want bundlers anymore, so we're making deno bundle, the one true bundler!" "does it do any of the stuff that webpack does?" "mostly no, because it's not meant for that" Read the comments on https://github.com/denoland/deno/issues/2475 https://github.com/denoland/deno/issues/2475 to get a sense of what I'm complaining about. 3. URL Imports. Packages in node.js are stupendously easy to use. Making me import from a URL instead of typing `yarn add foo` and `import * as foo from 'foo'` does not make my life any easier. It certainly makes the implementation easier, and I'm glad to see the last of node_modules and path-climbing module resolution. But the URL-based system offers no equivalent that I can see to lock files and automatic upgrades (e.g. `yarn upgrade`), which are two crucial features. This is something that node developers need and want, and if Deno doesn't provide it, 3rd parties will. My worry is that we'll end up with competing third-party solutions and a fractured ecosystem, due to Deno's failure of leadership here. 4. Stack traces: The single worst thing about using node is the frequency with which you get utterly useless stack traces that tell you nothing about the true source of the error. It was easier to debug C++ programs 20 years ago that it is to debug node.js apps today. But as far as I can tell, deno isn't making any efforts to improve this. That's ok, they don't have to fix every problem. But it does make me worry that they don't know what node.js developers actually care about, if this wasn't on their "must fix" list. 5. Typescript by default. I really like typescript. I mostly want to use it instead of javascript these days. But tsc is slow. Slooooooow. Really really slow. I am worried that most deno programs are going to be very slow to start up in practice. (Before you say "caching", 99% of the time that you want to start a program, it's because you just changed the source code. caching can only do so much in this case). And I am extremely skeptical of the plan to build a new typescript compiler in rust. I'll conclude with praising a few things that I am very glad to see: No more node_modules, Web APIs, and a promise-based stdlib.
• jariel 6y ago
  "It's important to understand that Deno is not a fork of Node - it's a completely new implementation. " New implementation of WHAT? Is this a JS Engine, or a wrapper around V8? Which version? Guys - whatever it is - I love it (!!!), but this is a very long and wordy article that does not well summarize the most relevant things, and uses words, long explanations for issues that I think are just a little specific. "First Class Typescript" - does this mean just 'transpilation at runtime'? Or does it mean something more hardcore? What does it mean at all? This could be 1/2 as long a 2x more explanatory and precise. Finally - it all looks super cool - but why specifically am I interested in this over things like Node? Speed, security? Not to take away from the great work.
• greggman3 6y ago
  Just a random though but if they want speed they could consider making a typescript JIT instead of typescript -> javascript. Typed languages can run much faster than untyped. Maybe that's impossible with current typescript given anything can be changed, eg (30 minutes into running something does Math.floor = ... etc, but maybe some kind of escape analysis could help or maybe push for some new keyword to mark code as safe to optimize.
  • marijn 6y ago
    Building a new JIT for a dynamic language, if it is supposed to be competitive with JS compilers, is a project several orders of magnitude bigger than building a runtime like this. TypeScript's design is very much that of a typing layer over a dynamic language. It's unsoundness and various loopholes to escape typing mean it's not much of a help for typed compilation.
    • torb-xyz 6y ago
      Microsoft _do_ have the research project Static TypeScript that does try to do this with a subset: https://www.microsoft.com/en-us/research/publication/static-typescript/ https://www.microsoft.com/en-us/research/publication/static-... But your point stands I think this subset will be incompatible with how many (including myself) writes TypeScript.
• simonw 6y ago
  Question: deno run https://deno.land/std/examples/welcome.ts This works - it downloads the code from that URL, then compiles and runs it. But if you visit https://deno.land/std/examples/welcome.ts https://deno.land/std/examples/welcome.ts in your browser you get back HTML, not raw code. Anyone know how this works? Is deno.land a special case or is there some Accept header cleverness or something going on?
  • simonw 6y ago
    Figured this out myself: $ curl 'https://deno.land/std/examples/welcome.ts' console.log("Welcome to Deno "); So this is an Accept header trick. If I do this instead: $ curl 'https://deno.land/std/examples/welcome.ts' -H 'Accept: text/html' I get back the full HTML version of the page.
  • akamaozu 6y ago
    Was waiting for the first person to point out that what you get when you visit a url is not guaranteed to be the exact same on a subsequent visit. Not seeing how url-based package management is safer when a package host can use a server that sends a special payload to certain requester ips, headers, cookies or referrer. Until there are firm guarantees around what you get from a url, a trust-able third party is needed, even if just as an option.
• chrismorgan 6y ago
  Pet peeve: programming sites behind Cloudflare protection with email address protection enabled, because we regularly have things with at signs in them that aren’t email addresses, which it mangles, ruining my standard no-JS experience: import { serve } from "https://deno.land/[email protected]/http/server.ts"; I mean, std@0.50.0 is a syntactically valid email address, but… protecting email addresses on IP addresses? Why, Cloudflare, why?
• thayne 6y ago
  > it's clear to us that ultimately the type checking needs to be implemented in Rust I hope this results in a faster typescript compiler.
• itsarnavb 6y ago
  Congrats to the Deno team and community on reaching 1.0! We've launched Deno support on repl.it here (in beta): https://repl.it/languages/deno https://repl.it/languages/deno for folks to try out.
• omt66 6y ago
  I am happy to see Deno v1.0 is out now. I like the ES modules support, TS first approach, top level async/await, etc. It compiles and caches the TS files, don't need additional setup to support TS right away. I am not sure about not using the package.json though, I kinda like it as it is the central point to manage all dependencies in NodeJS projects. Looking forward to playing with it more.
• Rapzid 6y ago
  I feel explicit location imports are a step backwards. Node ecosystem is moving toward workspaces and Yarn Plug'N'Play style manifest lookups for deps. The de-coupled import from where physically the dependency is being satisfied from seems desirable and it is a common next-level pattern in project and dependency management across language ecosystems. Sure, I guess you could shim it somehow like is happening in the node ecosystem but then.. I'm not sure what the stock situation brings to the table TBH.
• chintan 6y ago
  Nice. seems Deno is an anagram of Node.
  • noisy_boy 6y ago
    In my mind, it came across as Deno(de) :)
• didip 6y ago
  I like what Deno is selling. URL like import path is great, I don't know why people are dismissing it. It is easy to get up-and-running quickly. Looks like my personal law/rule is in effect again: The harsher HN critics are, the more successful the product will be. I have no doubt Deno will be successful.
  • kreetx 6y ago
    This seems to be the case, yes. It's like the critics unconsciously know it's better, and that is where their energy comes from.
    • mekster 6y ago
      More like "There can't be a better stuff than what I'm accustomed to and like" feel.
  • oblio 6y ago
    > It is easy to get up-and-running quickly. Almost all successful, mainstream, techs are like that. From a purely technical perspective, they are awful (or where awful at launch), they were just adopted because they were easy to use. When I say awful, I mean for professional use in high impact environments: financial, healthcare, automotive, etc. Examples: VB/VBA, Javascript, PHP, MySQL, Mongo, Docker, Node. Few people would argue that except for ease of use and ubiquity, any of these techs were superior to their competitors at launch or even a few years after. After a while what happens is that these techs become entrenched and more serious devs have to dig in and they generally make these techs bearable. See Javascript before V8 and after, as an example. A big chunk of the HN crowd is high powered professional developers, people working for FAANGs and startups with interesting domains. It's only normal they criticize what they consider half-baked tech.
  • sradman 6y ago
    The GoLang-like URL import and dependency management are indeed an innovation in simplicity while simultaneously offering better compatibility with browser JavaScript. Perhaps the HN-hate is not about simplified greenfield tech as much as it is about breaking established brownfield processes and modules.
• zaro 6y ago
  Some compatibility with Npm modules would have been better choice for adoption.
• raibosome 6y ago
  Nice, I deno about this.
• stevehiehn 6y ago
  This is interesting. Can you ship the Deno runtime with your runtime code? That's the thing that kills me about Javascript; having to assume the consumer has a runtime setup.
  • lucasyvas 6y ago
    Compiling to a single binary is on the roadmap, but was dropped from 1.0
    • stevehiehn 6y ago
      Great, thx, I'll definitely be keeping an eye on this project!
• secondbreakfast 6y ago
  I'm drawn to the simple beauty of the deno.land website.
• uyuioi 6y ago
  Awesome!
• morenoh149 6y ago
  I do a lot of django. Does anyone know if it can handle backpressure as described in the deno announcement? Or is that typically seen only in a microservices context?
• jppope 6y ago
  Soooooo yea. I'm excited. (I've been using deno for ~6 months but I'm happy we hit 1.0!!!)
• ranguna 6y ago
  I'm probably just one more person among the hundreds who are missing something here but: if the big thing about deno is that you can directly fetch dependencies from source with, for example, a GitHub repo URL, instead of going to a package registry like npm, where the package is decoupled from the source, why don't you simply do this already by changing the package.json and swapping the npm identifier with a URL to the repo? You can already do decentralisation with npm by simply not using`npm i some-package --save` and instead, modify the package.json yourself. Now the problem with deno is that if I import 5 packages (locked to a specific version) across 50 files and I want to update them to a new version, am I really gonna need to go into every single file and change the URLs?? That's just insane, I get the whole idea of decentralisation but why can't we concentrate all packages into a single file?? Sire this is all good for distribution because you won't have to run `npm i` every time you want to run your program, but more often than not, I'm the one that's going to use my program and I don't mind running `npm i` beforehand and feel safe that I have all my packages downloaded and ready to go, instead of worrying that my program will fail at run-time because the URL for one of my packages is down..
• WatchDog 6y ago
  Of all the problems with NPM, it being centralized is the last of them imo. Having experienced the mess that is go's decentralized dependency management, I'm not sure why anyone would want to replicate it. Putting aside security, availability and mutability is a massive problem, anyone can stop hosting their module, or worse, change an existing published module at any time. Why not take some inspiration from maven central, and run a central repo that actually provides some validation on the quality of and consistency of published artifacts.
  • nesarkvechnep 6y ago
    > Why not take some inspiration from maven central, and run a central repo that actually provides some validation on the quality of and consistency of published artifacts. Because then it would be hard to have a new hot framework every day.
  • kinleyd 6y ago
    Maven is an excellent model to emulate, IMO as well.
  • appleflaxen 6y ago
    Deno has the best of both worlds, as I see it. Users who need centralization / QA from their packaging ecosystem can always opt in to a centralized repository.
• tiedemann 6y ago
  Seems like a good fit for bundling and/or containerization of js-apps.
• golergka 6y ago
  > for await (const req of serve({ port: 8000 })) { > req.respond({ body: "Hello World\n" }); > } It's not the first time I see js iterators used and abused this way, and every time I feel that js and it's users are ready for full-blown monads and do notation instead.
• DroitThemes 6y ago
  Its improved security model
• censoredbyleft 6y ago
  I won't be using Deno. For starters, I like javascript, not typescript, and I think Ryan was considering the idea of making Deno TypeScript only at one time. That is enough for me to never consider it alone. I think it falls into the same category as Koa (TJs successor to Express) and the upcoming "Rome" project. Someone creates a successful open-source project and then at some point in the future decides to make a better one with questionable tangible benefit and various downsides of its own. The downsides I can see of Deno so far are that it is slower than node, it is not compatible with any server-side node code because it has rewritten the standard library, and it is inspired and based on the Go standard library, seemingly using Go idioms and so on. Its benefits are questionable, vague, and not really proven.
• gridlockd 6y ago
  "Internally Deno uses Microsoft's TypeScript compiler to check types and produce JavaScript. Compared to the time it takes V8 to parse JavaScript, it is very slow" TypeScript is way too slow for what it does and that's ridiculous for a language that rejects useful features because it doesn't want to "stray too far" from ECMAScript. In my view, typechecking doesn't belong in the "compiler" part of TypeScript. It should stay in the IDE. The compiler should just strip type annotations and do other trivial transformations.
• bryanrasmussen 6y ago
  The import from url feature is drawing a lot of initial skepticism - but I think once you look closer at it there are even more things to be wary of. The initial thing is the fear "whoa, that is hella insecure!" which, I agree NPM is basically the same problem... although, with NPM - Git system, you can 1. fork a version and use that version (which you can do with this, just host different url) or two you can freeze version you are using and theoretically only update after checking stuff out (I guess you would have to do the same with host different url, seems more difficult process) Also NPM basically makes a local cache of the files you will be importing, I guess the first time you run your program it must get the files and then caching keeps them from updating until the resource updates? Maybe I'm missing something and it isn't like that but if it is like that I find that weird because you are arbitrarily adding extra performance overhead to parts of your system as code loads and sees it needs to get a resource that has updated? I guess what would end up happening is versioning would be in the url and an expires header set a long time in the future, like you might do with static assets now, but Deno doesn't require that, it will be an outgrowth of this import from url system. Will there be situations where someone has done the caching poorly, or set the header badly or whatever and you are loading a resource too often? I would expect so, anyway I guess there will have to be testing of Deno's caching https://www.mnot.net/blog/2017/03/16/browser-caching https://www.mnot.net/blog/2017/03/16/browser-caching Finally, in NPM's system if a module I'm importing is a little bit weird I can always just go into the folder quickly and start debugging and maybe fixing the code, and then when I've got things working the way I think they should with changes do an actual fork pull-request, or just fork and use my fork of the code, or if it turns out as it often does that I've misunderstood something revert my changes to their code and go fix my code instead. I can of course still achieve the same effect with Deno but the workflow would have to be different and I think would end up being more convoluted, at least in the beginning. These are the initial worries that I get when seeing import from some url. I suppose someone has already thought these things through and I'm unnecessarily worried so if that someone is you (the reader of this long post) you can maybe assuage my worries.
  • ecares 6y ago
    Well is has a huge security hole that ry wont fix https://github.com/denoland/deno/issues/1063 https://github.com/denoland/deno/issues/1063
• Vinnl 6y ago
  Does anyone know if there's an RSS feed somewhere for posts like these from the Deno project?
• nojvek 6y ago
  > TSC must be ported to Rust. If you're interested in collaborating on this problem, please get in touch. This is a massive undertaking. TSC is a moving target. I occasionally contribute to it. It’s a fairly complex project. Even the checker + binder (which is the core of TS) is pretty complex. One idea that comes to mind is to work with Typescript team that they are only using a subset of JS such that tsc can be compiled down web assembly and have llvm spit out a highly optimized binary. This not only benefits demo, but the rest of the internet. TSC has done some great architectural changes in the past like doing mostly functional code, rather than lots of classes. The target we should be aiming for is a powerful typed language like typescript that complies very quickly to webasshmbly that can run in guaranteed sandbox environments.
  • Tade0 6y ago
    I wonder how possible it would be to just use this: https://github.com/swc-project/swc https://github.com/swc-project/swc It's still not feature-complete, but there aren't any alternatives written in Rust that I know of.
    • a_humean 6y ago
      SWC does not do any typechecking. It is equivalent to babel.
      • Aeolun 6y ago
        Someone is working on it: https://github.com/swc-project/swc/issues/571 https://github.com/swc-project/swc/issues/571
  • torb-xyz 6y ago
    There already exists and experimental compiler that takes a subset of TypeScript and compiles it to native[1]. It might be able to target wasm instead of asm. Also: If I'm not entirely mistaken Microsoft initially planned to have a TypeScript-specific interpreter in Explorer. This also might indicate that something like that could be possible. 1: https://www.microsoft.com/en-us/research/publication/static-typescript/ https://www.microsoft.com/en-us/research/publication/static-...
• jslakro 6y ago
  NODE -> * swap * -> DENO
• ecares 6y ago
  Well, there is a known MITM vuln in Deno by design and the team refuses to fix it soooooo REF: https://github.com/denoland/deno/issues/1063 https://github.com/denoland/deno/issues/1063
  • crabmusket 6y ago
    Lockfiles should be used for production code, as per https://deno.land/manual/linking_to_external_code/integrity_checking https://deno.land/manual/linking_to_external_code/integrity_...
    • ecares 6y ago
      That is not enough at all and there are other attacks! I can't belive in 2020 some people still need to be explained why not enforcing https is a terrible thing! For instance, will a lockfile prevent someone from eavesdropping on the download of a modules through http? If so, please kindly tell me how!
      • 1_player 6y ago
        https prevents MITM but doesn't prevent the modules being backdoored or otherwise altered at the source. I would prefer https-only, sure, but it doesn't buy you very much security.
        • ecares 6y ago
          Well, diasabling http by default is basically "Internet 101" here. I don't want to write an full lecture on how many attacks are possible when people don't use https. It has been commmon knowledge for way more than a decade
    • realharo 6y ago
      Can checksums/hashes be specified directly in the source file? EDIT: I mean hashes of dependencies. That is important for single-file scripts, if this is meant to be useful as a bash replacement for scripting. Having to download two separate files for a script and execute it with special arguments already adds too much friction to that scenario.
• giorgioz 6y ago
  I have two questions: 1) How to port a node package to deno? 2) How to keep both a node and deno packages in the same repo? Clearly without packages we are not going to use deno. Also I don't want to switch from well-proven packages like express/koa to an new unknown http server just because it supports deno.
  • inimino 6y ago
    Deno is a new thing. It's not node, and not having the entire npm ecosystem already around it can be seen as a blessing. By the way a new http server doesn't "support" deno any more than Express "supports" node -- it's the other way around.
  • austincheney 6y ago
    There are some manual things you can do to ensure portability from Node to Deno: * separate out the Node APIs from the rest of your application logic as much as possible as those will be different unrelated API conventions. * convert your application from using require to using ES6 modules. This won’t work if you have more that few highly trivial dependencies as Node requires picking one way of importing files and that one way extends to your dependencies as well. * Node uses callbacks for asynchronous logic where Deno uses promises, so ensure all callback functions are passed by reference so that the difference is an API difference instead of a logic difference.
• torb-xyz 6y ago
  First-class TypeScript support is the thing that excites me the most about this. It's so annoying when you want to navigate TypeScript code from a dependency in Node and it kicks you to a TypeScript-definition file instead of the actual TypeScript source.
• fbn79 6y ago
  The claim "TypeScript is an extension of the JavaScript language that allows users to optionally provide type information" is misleading. Typescript is not an extension of Javascript (not all javascript code is valid TS code). Typescript is a subset of Javascript plus mild type checking. For more details a nice article https://medium.jonasbandi.net/here-is-why-you-might-not-want-to-use-typescript-50ab0d225bdd https://medium.jonasbandi.net/here-is-why-you-might-not-want...
  • alain_gilbert 6y ago
    Do you hav any example of valid javascript that is not valid typescript ?
    • fbn79 6y ago
      For example accessing static methods differ from vanilla Javascript. See https://stackoverflow.com/questions/33864167/accessing-static-methods-from-instance-in-typescript https://stackoverflow.com/questions/33864167/accessing-stati...
  • hombre_fatal 6y ago
    This is such a weird point to me, maybe pedantry at best. Typescript is, to 99% of people, just Javascript with types. With few exceptions, TS compiles 1:1 to JS. That blog article just looks like an intro for beginners who don't quite know what static typing entails. Yes, static typing is different from runtime checks, that's why it's static.
    • fbn79 6y ago
      The devil is in the detail
• sholladay 6y ago
  If you need a server framework for Deno, please take a moment to check out Pogo. It's got a powerful and friendly API. It also has the best documention and plenty of tests. https://github.com/sholladay/pogo https://github.com/sholladay/pogo
• HeavyStorm 6y ago
  Number of things come to mind: - How do you update dependencies? They are urls spread along many files which can be everywhere... Do I have to find and replace every import statement? - In some enterprise environments, we use mirroring of package distributors (Nexus, jfrog etc.). This give us the ability to audit what packages are being imported, create a cache of packages so that a single delete or unpublish (like good old leftpad) won't break all applications, etc. Since package locations are hard-coded in the package files, it becomes challenging to do this. The argument that deno is mimicking a browser is thin. Browsers are client side, they don't access databases or lives inside your firewall. Server applications are much more sensitive to security issues than browsers.
  • dwb 6y ago
    A lot of comments here can be answered by reading the documentation. https://deno.land/manual/linking_to_external_code#faq https://deno.land/manual/linking_to_external_code#faq
• joelbluminator 6y ago
  Even if this new thing has slightly nicer syntax or usage of promises or whatever, does this alone justify it's existence? Learning all this new tooling and ecosystem all over again? Dividing the web development ecosystem even more? I really don't see how the problem it's solving is big enough for us to care really. I mean - enough already. In 8 years I'm sure Ryan Dahl can come up with an even better runtime written in Grust, will we then all be migrating our codebases from Node -> Deno -> Dynamite?
  • BenoitEssiambre 6y ago
    Also you can get most of the benefits of async/await without all the downsides of promises: https://www.npmjs.com/package/casync https://www.npmjs.com/package/casync
• appleflaxen 6y ago
  This project looks really cool to me. I'm glad the link to the video is there, because my intuition about pronouncing the name was incorrect. It looks like it could be "deeno" OR "denno", and I was pushed to the former by the presence of the dinosaur graphic. Isn't that old fashioned dinosaur on the Flinstones pronounced deeno? Anywho... good name overall: short, no collisions (i think?), and no strong baseline associations. And only right this instant am I realizing that this is an anagram of node... oh my god i'm slow. Now it's a great name.
  • swrobel 6y ago
    What video? Mind linking directly?
    • ioncube 6y ago
      I think he meant Ryan Dahl's talk: Design Mistakes in Node https://www.youtube.com/watch?v=M3BM9TB-8yA https://www.youtube.com/watch?v=M3BM9TB-8yA
• genezeta 6y ago
  One question. > The browser provides APIs for accessing cameras and microphones, but users must first give permission. Deno provides analogous behaviour in the terminal. I read this and I started looking around for the camera API or maybe for the Audio API. And the thing is that I can't seem to find anything about it. I can't see anything about it in "The Manual" or in the API reference. Then I thought that there may not be documentation because it just mimics the browser's API. Ok, but... there must be some command-line flag to give permission to it, right? Can't find it either. Maybe "it was just an example; there's no media API just yet"? But then I set out to find available command-line flags in general. And I can't find those either. There's this [0] but is that all? There's just --allow-net, --allow-read and --allow-write? Or is there some other place where the available permission flags are listed? [0] https://deno.land/manual/getting_started/permissions https://deno.land/manual/getting_started/permissions
  • inglor 6y ago
    Confirming that there is no media API in Deno.
    • genezeta 6y ago
      Thanks.
  • DougBTX 6y ago
    I don't see it listed in the docs, but try running `deno run -h` to see the command line help. It should produce output like: -A, --allow-all Allow all permissions --allow-env Allow environment access --allow-hrtime Allow high resolution time measurement --allow-net=<allow-net> Allow network access --allow-plugin Allow loading plugins --allow-read=<allow-read> Allow file system read access --allow-run Allow running subprocesses --allow-write=<allow-write> Allow file system write access etc
    • genezeta 6y ago
• moron4hire 6y ago
  Given that all API calls in JS have to go through the interpreter, couldn't unsafe API calls have an implicit parameter added that requires a per-package token, with the API accessed through an interface requested by the package that pins that interface to that token? Additionally, you could allow package authors to set their token as a cryptographic public key from a package manifest, so they could grant access to the API to sub-packages within their own ecosystem. If you passed the API interfacing object to a package outside of your control, the calling code's token wouldn't match the API interfacing object's expected token and would kick a security access exception. This would be completely transparent to the package author. With such a system, access to unsafe APIs could be granted to only a shortlist of packages. Something like this is already done with only allowing access to certain APIs if they are called from certain types of event handlers, until the callstack of the event handler is left.
• pezo1919 6y ago
  What do you think which major projects will use deno in future and which not? React/React Native/Expo?
• wincent 6y ago
  I tried it briefly on a side project a couple of months ago. I like some of the ideas in it, but my editor tooling (which is TypeScript-ready but not Deno-ready) wasn't ready for it. I might revisit in a year or two.
• Keats 6y ago
  > TSC must be ported to Rust. If you're interested in collaborating on this problem, please get in touch. Have you talked with the TS people to see if maybe there are some bottlenecks that could be rewritten in Rust rather than rewriting everything? Even though I would love to have TSC in Rust, it seems like it would be a huge amount of work.
• devit 6y ago
  What is the reason for making a JavaScript runtime based on browser APIs that cannot also be a browser? Or in other words, wouldn't it have been easier and better to make an optionally headless version of the Servo browser with additional native APIs and some enhancements like being able to run JavaScript directly in addition to HTML? The choice made means that Deno can't be used, at least directly, to make desktop applications, and also doesn't have all the features that browsers have for free, like multiprocess and multiple sandboxes, network traffic inspector, local storage, GPU compute, etc.
  • mahmoudimus 6y ago
    This is a very interesting idea - basically the new JVM is a headless browser. Fascinating to think Of the possibilities.
  • timw4mail 6y ago
    The Javascript engine is a lot smaller code surface area than an entire browser rendering engine.
• kentf 6y ago
  Won’t Meteor.js make this project extinct?
  • mahmoudimus 6y ago
    Clever ;)
• seemslegit 6y ago
  Some people for the last decade: wouldn't it be great if node had a comprehensive, idiomatically coherent, thoroughly typed standard library ? Look, typescript is right here ! No-one, at all, for the love of jeebus: Do another node-like thing, but make it in rust on top of C++ (or is the other way around ?), somewhat similar but generally incompatible, have a whole different set of APIs, a bunch of new tools and yet another package/module system.
• VikingCoder 6y ago
  Hi, I've been thinking for a while that I want something like Deno that has something like WireGuard built in to it. 1) I make a public / private key pair. 2) I log on to a DNS-like system, and create an account for myself, upload my public key. 3) I start up a Deno server, giving it my private key, and I give it the address of the DNS. Deno uses my private key to inform the DNS that it exists and is serving traffic. (Much like any Dynamic DNS server.) 4) My friend does the same - makes a public / private key pair, finds a DNS he likes, uploads his public key, makes a Deno server and registers it with the DNS. 5) My friend and I trade DNS+public keys. It's a URL to the DNS that has the public key in it. 6) I go to some administrator page on my Deno, it looks a lot like this [1]. I create a new Connection, and plug in the DNS+public key of my friend. He does the same on his server. 7) On my admin page, I pick an app that I want to use to communicate with my friend. I can see a list of my Connections, and I just check off a box that the app has permission to communicate with that friend. 8) This app that I've picked, it only sees the world through an incredibly narrow API. It's like WireGuard. Deno handles all of the communication and permissions, much like Sandstorm.io. The first thing I want is just queued-up JSON messaging. The app can send and receive JSON messages. I envision that I want it to be in messaging mode (rather than "streaming online"), so it has something like ZeroMQ under the hood to pub/sub, client/server, all that. But roughly it has a bi-directional pipe for sending and receiving JSON and can queue up messages when the other server is offline. 9) I now have a sandboxed app that can't talk to the rest of the world, has its own private VPN-like connection to another process. All traffic is encrypted like WireGuard. The DNS aspect lets my friend move his server if the IP changes. I feel like if some project kind of like Sandstorm, kind of like Dynamic DNS, kind of like WireGuard, and kind of like Deno all got together, they would make a beautiful thing. When I think about how I wish Diaspora worked, as a way to replace Facebook, this is it. I wish it was built on top of something like this. This is the atomic unit of distributed, yet safe, that I wish internet apps were made out of. I imagine that I would be setting up hosting of the Deno server nodes for my friends and family, since I'm their tech support guy. But they'd be in charge of their own connections and apps in their nodes. So, HN, time for you to tell me that it's 1) a terrible idea, 2) already exists, 3) why don't I just make it myself. Right? =) [1] https://alpha.sandstorm.io/demo https://alpha.sandstorm.io/demo
  • 6y ago
• goofballlogic 6y ago
  Main thing that would prevent me investing in this stack is that the runtime has been designed with typescript in mind. In a few years if the typescript thing blows over, you're left with a runtime and conventions skewed toward statically-typed programming patterns.
  • Vinnl 6y ago
    As someone who works with TypeScript extensively, TypeScript patterns are basically Javascript patterns - although perhaps with slightly fewer runtime type checks.
  • Zooper 6y ago
    I used to dislike typescript, until I was hired to write it. It has warts, but the benefits outweigh them, and you aren't forced to use the parts you may not find beneficial. I think it's a good way to prototype a typed version of javascript, at the least.
• z3t4 6y ago
  Could take that one step further and run apps from URL's like the browser does. eg. deno https://my.app https://my.app
• homakov 6y ago
  Basically better node by creator of node?
  • mathiasrw 6y ago
    Yes
• frouge 6y ago
  ELI5: why is this so much upvoted?
• dilandau 6y ago
  Based on the number of votes, hns audience must skew overwhelmingly JavaScript/web developer. I guess that explains quite a bit. Web developer fascination with NIH and tooling has produced a fragmented, unstable ecosystem. But I guess one more thing won't hurt them. They seem to have unnaturally high tolerance for pain.
• ausjke 6y ago
  The key is, can it re-use all those npm modules? otherwise the ecosystem is too large to take on these days.
• ausjke 6y ago
  Installed and run the REPL deno, hit TAB twice there is nothing, node REPL give you auto-complete but there seems no for deno, not beginner friendly unfortunately.
• lame88 6y ago
  I briefly looked over this project when this link first popped up and didnt think much of it, but then i was surprised to see this huge surge in votes. I dont do much in the javascript and related world - can someone explain what in particular about this project has generated such interest? Even after reading the top comments, I feel like im missing the bigger pitcure.
  • otoburb 6y ago
    >>I dont do much in the javascript and related world - can someone explain what in particular about this project has generated such interest? The majority of the interest lies in the fact that Ryan Dahl[1] was the original creator of Node.JS[2], which is currently a very popular Javascript runtime and web backend. Dahl released the initial version of Node.JS in 2009[3]. After a decade of experience working on Node.JS and growing the community, Dahl decided to create an alternative Javascript (and Typescript) runtime in mid/late 2018 called Deno which is now v1.0. [1] https://en.wikipedia.org/wiki/Ryan_Dahl https://en.wikipedia.org/wiki/Ryan_Dahl [2] https://nodejs.org/en/ https://nodejs.org/en/ [3] https://en.wikipedia.org/wiki/Node.js https://en.wikipedia.org/wiki/Node.js
    • jkrems 6y ago
      > After a decade of experience working on Node.JS and growing the community, Dahl decided to create an alternative Javascript (and Typescript) runtime in mid/late 2018 called Deno which is now v1.0. Just to nit-pick: Ryan Dahl had stepped away from node and the surrounding ecosystem in 2012. So for the vast majority of node's lifetime, he hasn't really been involved. Node in 2012 was a very different project. (That doesn't take away from his observations or from the things that deno does differently. Just trying to reduce confusion.)
  • z3t4 6y ago
    I think the goal was to eradicate JavaScript (Deno was originally TypeScript only. But in order to run fast, TS first need to compile to JavaScript). After buying Github and NPM, moving people over from Node.JS to Deno would be the final blow to the JavaScript community.
• tmvnty 6y ago
  For anyone that's interested, here's a list of projects I'm interested in or use with new major versions in 2020: http://maker.sh/2020 http://maker.sh/2020
• ajnin 6y ago
  The fundamental problem of dependency management, as anyone who ever kept bookmarks knows, is that the external sources might go away at any time. It's not a problem unique to Deno or Go. Take Java for example, its standard dependency management tool is Maven, which relies on external repositories of artefacts to function. From time to time, a repository might go down, or it might be moved to another address, or a library might be migrated to another repository. Whenever this happens, your build might break. The solution is to proxy all requests at the organizational level through your own server which keeps a mirror of any package that has been referenced once. That way, if it become unavailable externally, then you can still use it internally. You can also override packages with patched versions if they misbehave. I think that Deno should define a standard dependency fetching protocol, and allow proxying transparently at a native level. If it does, that kind of dependency management will be fine.
• sequoia 6y ago
  I am a long-time Node.js user. My question about Deno is "is there any indication that this project will have a different trajectory from the node.js project (also started by some of the same people as Deno), or should I expect Deno to also follow a 10 year arc?" I think evolution & starting over can both be appropriate steps forward, I don't question the Deno project, but to have the exact same people who created Node.js say "OK here's the new new JS hotness," I think "how can we expect this time to be different" is a reasonable question. Or perhaps these ecosystems are not meant to last/be supported more than 10ish years?
• diffrinse 6y ago
  I predict cdnjs/jsdelivr types will explode in use for Deno packages since they can make bandwidth and security guarantees behind what's actually returned from the URL as well will be able to accomodate versioning in the path. That seems to be what this dep system is built for, unless I'm missing something.
• sergiomattei 6y ago
  This is pretty fantastic. excited to try it.
• peartips 6y ago
  This is fantastic news!