Live data from Hacker News

Deno 1.14

deno.com

61–70 of 111 posts

Re: Deno 1.14

#61

One of the most exciting opportunities IMO that Deno opens up, compared to most traditional server-side frameworks, is the possibility for simple url-based live-reload workflows in production. I'd love to be able to develop backend services by pushing source code to some url as I develop, and then have the production instances of the service notified of the changes and reload themselves immediately for a super-tight…

This is a really old concept with interpreted languages, Capistrano in Ruby came out in 2006 for this sort of workflow:

  https://en.wikipedia.org/wiki/Capistrano_(software)
10 year old gist for this exact thing:

  https://gist.github.com/rchampourlier/1281506/a22148264c457ebb69259261f117548569be6bef
Same exists in Node, using PM2 process monitor via rsync/ssh:

  https://pm2.keymetrics.io/docs/usage/deployment/
Run a command, new code is pushed to server files, you have a file-watcher daemon monitoring the directory and stopping + restarting the app, or you run stop/start as part of the deploy command.

Re: Deno 1.14

#62
post #39

Looks good. Interesting that they are "bringing back" mutual tls (after browsers pretty much axed it..). Is there support on the (deno http) server-side too? Eg: easy to set up mutually trusted, private-/non-ca tls between a deno client and deno server? Perhaps via a self-signed/private CA?

The server does not support mutual TLS as of yet. Feel free to open an issue on denoland/deno though, so we can look into this :-)

Re: Deno 1.14

#63

One of the most exciting opportunities IMO that Deno opens up, compared to most traditional server-side frameworks, is the possibility for simple url-based live-reload workflows in production. I'd love to be able to develop backend services by pushing source code to some url as I develop, and then have the production instances of the service notified of the changes and reload themselves immediately for a super-tight…

I built this https://webcode.run/

Re: Deno 1.14

#64
post #2

Only tangentially related, but what's the point of a static class block? What problem does it solve that's not covered by either the class constructor or a static const? Doesn't it introduce a weird (stateful!) computation that's hard to reason about? There's probably a use-case I'm missing, because intuitively I'd automatically classify it as bad a practice.

Off the top of my head it's probably useful for implementing The Singleton Pattern, which reduces to one single instance of a class: https://en.wikipedia.org/wiki/Singleton_pattern

Singletons in JS/TS are done by creating and exporting an instance of a class:

  class MyClass {}
  export const myClassSingleton = new MyClass()
Static initialization blocks = "Constructors, for static class members/values"

Static blocks only run once, like the class declaration itself:

  class User {
    constructor(public name: string, public age: number) {}

    static {
      console.log("Hello from class User static block")
    }
  }

  const a = new User("a", 1)
  const b = new User("b", 2)
Is transpiled to:

  class User {
    constructor(name, age) {
        this.name = name;
        this.age = age;
    }
  }
  (() => {
    console.log("Hello from class User static block");
  })();
  const a = new User("a", 1);
  const b = new User("b", 2);

Re: Deno 1.14

#65
post #34

Earlier quoted context omitted.

I also tried it out recently, because I wanted to make a small utility for myself and liked the idea of it providing a single executable (and bypassing the node/NPM ecosystem for learning a JS/TS based system appealed to me). It delivered on that beautifully, as all I did is switch from running "deno run" as I was for testing to "deno compile" and it delivered to me exactly what I was looking for. A bit large at 57 M…

That's interesting. 57mb is big, but not an issue when it's for personal use. Somewhat related, I haven't used rust, but I read that it can produce an executable including the run time for edge that is less than 1mb,. I couldn't find the source, but this article shares how an extension was reduced from 12mb to 4.5mb.

> 57mb is big

Honestly, I think most the time you're looking at 10MB+ for interpreted languages that are turned into executables (through a bundling of the runtime and scripts, that is, not through compiling to something else which is likely much smaller if offered).

The complexity and size of the runtime is going to necessarily influence that size. V8 is fairly complex compared to most runtimes I think, with the JVM and maybe Mono being notable exceptions, and if you were to bundle the JVM with an app instead of just expecting them to have it installed, I imagine that would be quite large as well.

> Somewhat related, I haven't used rust, but I read that it can produce an executable including

That's actually the other thing I wanted to do with the project I built in Deno. Since it was very simple, but actually useful for me, I was also going to implement it in Rust. I've played with it a few times over the years, but never really had anything real that needed to be built in it, so this seemed like a good chance to build something real in it.

In case anyone is wondering because I mentioned it twice, the project is just reading an ini file which defines browsers, pattern matches to apply to URLs to determine which browser to load based on the URL, and a default browser. The idea being that I can send work URLs to the browser I dedicate to work that's proxied through a SOCKS connection, and other URLs get handled automatically by the browser I use for personal stuff, and I can just make the application my default URL handler. Dead simple, but very useful for my current workflow.

Re: Deno 1.14

#66
post #28

I tried out Deno last weekend for a fun little hack project (syncing a local Markdown file to a formatted Google Doc), and it was awesome. Writing TypeScript code for Deno feels a lot like writing Go (which is a very good thing to me): - opinionated build/fmt/deps - well-designed stdlib - no need for scaffolding files (.eslintrc, babel.config.js, jest.config.js, mocha.opts, etc.) If that sounds good to you, try Deno!

It's also great for scaffolding CRUD sites. I used it a while ago on a MERN stack project in order to loop over a directory of game files -- Stepmania simfiles if anyone's wondering -- cleaning them up, parsing their metadata, and then POSTing it to my Express server. While I didn't avail myself of its CSV/YAML/etc parsing (JSON was a builtin and is now a third-party library), the stdlib's walk function made this generally painless.

And to top it off there's yet another bonus to this approach: having Fetch included out of the box enabled me to mock out what eventually became my frontend requests, by running them headlessly and worrying about the form logic later.

I haven't actually gotten to using TypeScript with it personally (it's among a few things built into Deno that I've been meaning to try now that I can run them with zero config), but when writing JS I've found myself reaching for it in some of the same scenarios I (anecdotally) see people point to for Python -- bulk file manipulation, scraping, programmatic requests, etc.

Re: Deno 1.14

#68
post #56

https://github.com/denoland/deno/discussions/11771 > NodeJS compatibility, what is our high-level strategy, goals, next steps? > Do we see Node and Deno co-existing, or do we want to think of Node as "legacy"? (Note, there was no clear decision on this question, it was just a conversation) > If we could say "you can run your Express server under Deno faster than Node" would that encourage adoption? No clear answer I…

Choose one:

1. Same. 2. Better.

You can't have both. Since getting better involves change, which is the opposite of staying the same.

Re: Deno 1.14

#69

Deno is awesome, and it's great to see the WebCrypto additions! My current top feature request is that I wish Deno would have the same permission model for the repl. I highly recommend listening to this recent podcast with Ryan Dahl: https://changelog.com/podcast/443

That would make REPL difficult to use, since you would need to know in advance what you want to do to pass the right permission flags.

REPL is particularly useful when trying out things "live" as they come into your mind.

Re: Deno 1.14

#70
I know it's a bit superficial, but I love Deno's branding. Their logo is cute and evokes a sense of calm, and the variations on the mascot are nice.
Post reply on HN