Live data from Hacker News

Modern Node.js Patterns

kashw1n.com

111–120 of 448 posts

Re: Modern Node.js Patterns

#112
post #108

Why bother with node when bun is a much better alternative for new projects?

Why bother with bun when deno 2 is a much better alternative for new projects?

Why bother with deno 2 when node 22 is a much better alternative for new projects?

(closing the circle)

Re: Modern Node.js Patterns

#113
Whoa, I didn't know about this:

  # Run with restricted file system access
  node --experimental-permission \
    --allow-fs-read=./data --allow-fs-write=./logs app.js
  
  # Network restrictions
  node --experimental-permission \
    --allow-net=api.example.com app.js
Looks like they were inspired by Deno. That's an excellent feature. https://docs.deno.com/runtime/fundamentals/security/#permiss...

Re: Modern Node.js Patterns

#114
post #95

I see two classes of emerging features, just like in the browser: 1. new technologies 2. vanity layers for capabilities already present It’s interesting to watch where people place their priorities given those two segments

One man's "vanity layers?" is another man's ergonomics.

And in many of the cases talked about here, the "vanity layers" are massive interoperability improvements.

Re: Modern Node.js Patterns

#115
post #84

Unless it changed how NodeJS handles this you shouldn't use Promise.all(). Because if more than one promise rejects then the second rejection will emit a unhandledRejection event and per default that crashes your server. Use Promise.allSettled() instead.

This didn't feel right so I went and tested.

    process.on("uncaughException", (e) => {
        console.log("uncaughException", e);
    });

    try {
        const r = await Promise.all([
            Promise.reject(new Error('1')),
            new Promise((resolve, reject) => {
                setTimeout(() => reject(new Error('2'), 1000));
            }),
        ]);

        console.log("r", r);
    } catch (e) {
        console.log("catch", e);
    }

    setTimeout(() => {
        console.log("setTimeout");
    }, 2000);
Produces:

    alvaro@DESKTOP ~/Projects/tests
    $ node -v
    v22.12.0

    alvaro@DESKTOP ~/Projects/tests
    $ node index.js 
    catch Error: 1
        at file:///C:/Users/kaoD/Projects/tests/index.js:7:22
        at ModuleJob.run (node:internal/modules/esm/module_job:271:25)
        at async onImport.tracePromise.__proto__ (node:internal/modules/esm/loader:547:26)
        at async asyncRunEntryPointWithESMLoader (node:internal/modules/run_main:116:5)
    setTimeout
So, nope. The promises are just ignored.

Re: Modern Node.js Patterns

#116

Be honest. How much of this article did you write, and how much did ChatGPT write?

What, surely you’re not implying that bangers like the following are GPT artifacts!? “The changes aren’t just cosmetic; they represent a fundamental shift in how we approach server-side JavaScript development.”

And now we need to throw the entire article out because we have no idea whether any of these features are just hallucinations.

Re: Modern Node.js Patterns

#117
post #76

The killer upgrade here isn’t ESM. It’s Node baking fetch + AbortController into core. Dropping axios/node-fetch trimmed my Lambda bundle and shaved about 100 ms off cold-start latency. If you’re still npm i axios out of habit, 2025 Node is your cue to drop the training wheels.

Tangential, but thought I'd share since validation and API calls go hand-in-hand: I'm personally a fan of using `ts-rest` for the entire stack since it's the leanest of all the compile + runtime zod/json schema-based validation sets of libraries out there. It lets you plug in whatever HTTP client you want (personally, I use bun, or fastify in a node env). The added overhead is totally worth it (for me, anyway) for sh…

Just last week I was about to integrate `ts-rest` into a project for the same reasons you mentioned above... before I realized they don't have express v5 support yet: https://github.com/ts-rest/ts-rest/issues/715

I think `ts-rest` is a great library, but the lack of maintenance didn't make me feel confident to invest, even if I wasn't using express. Have you ever considered building your own in-house solution? I wouldn't necessarily recommend this if you already have `ts-rest` setup and are happy with it, but rebuilding custom versions of 3rd party dependencies actually feels more feasible nowadays thanks to LLMs. I ended up building a stripped down version of `ts-rest` and am quite happy with it. Having full control/understanding of the internals feels very good and it surprisingly only took a few days. Claude helped immensely and filled a looot of knowledge gaps, namely with complicated Typescript types. I would also watch out for treeshaking and accidental client zod imports if you decide to go down this route.

I'm still a bit in shock that I was even able to do this, but yeah building something in-house is definitely a viable option in 2025.

Re: Modern Node.js Patterns

#118
post #110

Earlier quoted context omitted.

Agreed. It's surprising to see this sort of slop on the front page, but perhaps it's still worthwhile as a way to stimulate conversation in the comments here?

I learned quite a few new things from this, I don't really care if OP filtered it through an LLM before publishing it

Same, but, I'm struggling with the idea that even if I learn things I haven't before, at the limit, it'd be annoying if we gave writing like this a free pass continuously - I'd argue filtered might not be the right word - I'd be fine with net reduction. Theres something bad about adding fluff (how many game changers were there?)

An alternative framing I've been thinking about is, there's clearly something bad when you leave in the bits that obviously lower signal to noise ratio for all readers.

Then throw in the account being new, and, well, I hope it's not a harbinger.*

* It is and it's too late.

Re: Modern Node.js Patterns

#119

Anyone else find they discover these sorts of things by accident. I never know when a feature was added but vague ideas of "thats modern". Feels different to when I only did C# and you'd read the new language features and get all excited. In a polyglot world and just the rate even individual languages evolve its hard to keep up! I usually learn through osmosis or a blog post like this (but that is random learning).

I'm truly a fan of node (and V8) so once in a while (2-3 months?) I read their release notes and become aware of these things.

Sometimes I also read the proposals, https://github.com/tc39/proposals

I really want the pipeline operator to be included.

Re: Modern Node.js Patterns

#120

Don’t forget the native typescript transpiler which reduces the complexity a lot for those using TS

It's still not ready for use. I don't care Enum. But you can not import local files without extensions. You can not define class properties in constructor.
Post reply on HN