Live data from Hacker News

Deno 1.14

deno.com

51–60 of 111 posts

Re: Deno 1.14

#51
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.

Forgot the link https://arusahni.net/blog/2020/03/optimizing-rust-binary-siz...

Re: Deno 1.14

#52
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.

Another perspective on static blocks is what they replace/help migrate away from. Static blocks are one of the last pieces of the puzzle holding some projects (or at least some particularly old legacy objects in those projects) from migrating to the new class syntax. For better or worse the classic Constructor Function pattern of building objects in JS was full of static initialization code (as it was an easy thing t…

Yeah, this makes a lot of sense. ES6 classes are restrictive if you look at them from a pre-ES6 perspective. Of course many of those restrictions are "right", but they are restrictions nonetheless.

I guess it's a good way to bring back that behavior with the added bonus of being useful by itself in some limited but legitimate cases (sibiling comment mentioned cache initialization, also a good point).

Re: Deno 1.14

#53
> This release allows deno lint and deno fmt to be configured.

That's good news. The main thing holding me back from seriously looking at Deno was the lack of config for the formatting. The default settings weren't right for me, and I tend to avoid projects where you have to fight the tools. I'm going to take another look now.

Re: Deno 1.14

#55
post #29
post #18

Earlier quoted context omitted.

"Easy" is highly subjective. If you're proficient at picking up new architecture paradigms for familiar languages, you're adept with ESM syntax, and refactoring is a skill; then you might consider it easy. It's a paradigm shift, so there's always going to be some friction in migration. For your express needs, check out Oak https://deno.land/x/oak@v9.0.0

Could you clarify what is the paradigm shift? Static types? (If so I agree, but using Node does not imply not using TS)

This is my first day obviously, but what I can see are the following interesting syntax, bare server.

   const server = Deno.listen({ port: 8080 });
   console.log(`HTTP webserver running.  Access it at:  http://localhost:8080/`);

    // Connections to the server will be yielded up as an async iterable.
    for await (const conn of server) {
     // In order to not be blocking, we need to handle each connection individually
     // without awaiting the 
    function
  serveHttp(conn);
}

     async function serveHttp(conn: Deno.Conn) {
      // This "upgrades" a network connection into an HTTP connection.
      const httpConn = Deno.serveHttp(conn);
      // Each request sent over the HTTP connection will be yielded as an async
      // iterator from the HTTP connection.
      for await (const requestEvent of httpConn) {
       // The native HTTP server uses the web standard `Request` and `Response`
       // objects.
    const body = `Your user-agent is:\n\n${requestEvent.request.headers.get(
      "user-agent",
    ) ?? "Unknown"}`;
    // The requestEvent's `.respondWith()` method is how we send the response
    // back to the client.
    requestEvent.respondWith(
      new Response(body, {
        status: 200,
      }),
    );
  }
}

Everything async await. There is an option to use a library, but it's to be deprecated,the native option is stable. Interesting import code:

    import { serve } from "https://deno.land/std@0.105.0/http/server.ts";
So, Deno supports typescript out of the box or just plain JS. Deno doesn't support npm packages, imports are done via url. There is a window object, for whatever that's supposed to be used. Runs sandboxed, access to filesystem etc runs on permission basis. Access to the browser API without installing anything else. Packages are cached, this was very annoying in nodeJS.

Sounds and looks pretty damn good.

Re: Deno 1.14

#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 really wish they go for a better compatibility with Node and sell themselves as a replacement that is strictly better.

Re: Deno 1.14

#57
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 feedback loop.

In theory, building this kind of workflow in Deno should be very feasible, so I'm hoping to give it a shot in the not too distant future, but I'm wondering if anyone else has already tried it?

Re: Deno 1.14

#58
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…

Node is from the days before ES6 and uses a different API. Should just kill it and start fresh. Deno conforms to modern JS standards and is much more pleasant to use in pretty much every way.

Re: Deno 1.14

#59
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!

mind sharing that project? I have a similar need.

Re: Deno 1.14

#60

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 the biggest upside I see for Deno. I imagine a lot of fat could be trimmed in service orchestration with something that simply resembles a headless browser, and all it takes to deploy new code to your running service is giving it the equivalent of an `f5` and you're on your way.

Heck lets get this headless browser running in Ring 0 and skip to the end of Gary Bernhardt's dream.

Post reply on HN