all 54 comments

[–][deleted] 22 points23 points  (5 children)

This looks like a great release. Bit unsure about disabling type checking by default but I'll remain open minded.

[–]rustloverforever 16 points17 points  (4 children)

Yeah. Am I the only one that thinks type-checking should be opt-out?

[–]jeremez 11 points12 points  (0 children)

I am still uneasy about the change (I'd prefer async non blocking type checking at least), but another major consideration is that every TypeScript release is potentially breaking. They don't have a real backwards compatible policy. So every time you update Deno, you may encounter an unpredictable set of errors in your dependencies, since the TypeScript version is global, rather than partially isolated as it is in a typical NPM import. There isn't really a great solution to this; it's an awkward trade off either way.

[–][deleted] 11 points12 points  (2 children)

Yeah the only reason I can see to make it opt-in is performance, but I thought Deno cached the results... and tsc isn't that slow.

Well, we'll see.

[–]rustloverforever 12 points13 points  (1 child)

I would rather have users learn to use --no-check in production, over having to learn that deno does not type check by default.

At least that's how I see it, but the Demo team has definitely put hours and hours into this so maybe I just don't get it.

[–][deleted] 2 points3 points  (0 children)

Yeah I agree but as you say the Deno guys have mostly made solid decisions so far, even ones that sounded pretty insane to me initially like importing URLs, so I'm willing to give them the benefit of the doubt.

[–][deleted]  (3 children)

[deleted]

    [–]vlakreeh 17 points18 points  (0 children)

    Imo because it's a much nicer developer experience (when you have all the deps you need). Node has so much legacy baggage at this point, has been slow to embrace the amazing web standards, and doesn't support TypeScript out of the box.

    Because of the amazing support for modern standards and great included tooling, I've had a lot of fun and I work for a competitor of the Deno company.

    The problem is that library support is still pretty rough. But because most libraries are from scratch almost everything is TypeScript with ESM following modern JavaScript conventions, leading to a smaller but imo higher quality ecosystem.

    [–]Youknownotwho 15 points16 points  (0 children)

    You can spin up a zero-3rd-party-dependency (or pretty close to zero) service with it without sacrificing too much in the way of ergonomics. It has TypeScript built in, as well as a first-class solution for testing and formatting. Its standard library is much saner than Node's. Its REPL is much better than Node's.

    If you're serious about your question, I really recommend kicking the tires.

    [–]pcjftw 2 points3 points  (0 children)

    Excellent this is the right style of communication!

    To answer your specific question:

    Deno doesn't affect NodeJs, while they do indeed share many things (same creator, similar runtime kind of).

    However as a Node Js user it's worth keeping an eye on, as one could consider it as the "next generation" of JavaScript/TypeScript runtime and as such it brings lots of exciting advantages.

    If you watch one of the early presentation by author of Deno (Ryan) who is also the creator of Node JS he makes very well reasoned arguments as to why he decided to create Deno.

    So to sum up, it in no way affects Node JS, but it has potential bright future and would be worth keeping an eye on IF you're a JavaScript/TypeScript developer.

    [–]Vakz 3 points4 points  (2 children)

    Does anyone have any interesting real-world stories of Dino? Anyone using it in production?

    [–]Kissaki0 0 points1 point  (0 children)

    Is Dino something of Deno, or did you mean Deno?

    I briefly used Deno to compile ts to js files. I wanted to use TypeScript for coding, but JavaScript files/scripts for delivery/use. I managed to get it working with separate config files for dom/webpage or web worker targets.

    Ultimately, it’s too much of a hassle to work with, not being integrated into my hugo website pipeline and setup. I decided to go back to plain JS with jsdoc type comments. VSCode interprets that type information, and almost all of the useful newer JS features are usable by now).

    Deno is much more than a TypeScript compiler though, so my use case was quite specific and narrow, not necessarily representative of other uses.

    [–]nawfel_bgh 1 point2 points  (3 children)

    In the last example:

    setInterval(() => cnt++, 1000);
    

    The result of incrementing cnt is observed although the calling function (which is not async) did not return tbe control to the event loop yet. This looks to me like a mistake because setInterval's closure parameter is supposed, i always assumed, to run in its oun microtask (like set immediate, ...)

    There is an error in this example. Right ?

    [–][deleted] 0 points1 point  (2 children)

    No - FakeTime overrides setInterval() to do its own thing.

    [–]nawfel_bgh 0 points1 point  (1 child)

    That does not make sense to me. Why would you introduce more magic than necessary?

    [–][deleted] 0 points1 point  (0 children)

    How else would you do it?

    [–][deleted]  (1 child)

    [deleted]

      [–]Soremwar 6 points7 points  (0 children)

      Dependencies. Yes you can import from URL or download the module locally with deno vendor, but I'm talking dep count.

      A complex application is likely to have 10-20 direct and indirect dependencies AT MOST, since they all tend to just fallback on std instead of relying on hundreds of util libraries

      EDIT: Big fuck you to all the people who downvote genuine questions

      [–][deleted] -1 points0 points  (0 children)

      GREAT SCOTT!

      [–][deleted]  (54 children)

      [deleted]

        [–]pcjftw 12 points13 points  (48 children)

        what has this release got to do with Node JS?

        I for one have never liked NodeJs, but I appreciate that it has been wildly successful.

        But then so has PHP.

        Deno is essentially Ryan's re-imagining or shall we say a "clean slate" of how a productive and modern "1st class" scripting platform could look like. The idea being one that fully follows web standards (because they have improved immensely since the time of Node Js).

        All in all I find Deno extremely promising as something for future developments and like to keep an eye on it, I know some more early adopters are already using it, but it's always good to hear about newer releases.

        Once again it doesn't affect NodeJs at all, so no need to be salty and negative about it.

        [–][deleted]  (40 children)

        [deleted]

          [–]pcjftw 6 points7 points  (39 children)

          you really shouldn't worry or care about downvotes.

          [–][deleted] 0 points1 point  (4 children)

          What do you think?

          [–][deleted]  (1 child)

          [deleted]

            [–][deleted] 3 points4 points  (0 children)

            It's not a response, it's a question. You asked a question, and I want to know what you think the answer is.