Live data from Hacker News

Modern Node.js Patterns

kashw1n.com

231–240 of 448 posts

Re: Modern Node.js Patterns

#231

Earlier quoted context omitted.

Compile speed and a subjective DX opinion are very debatable. The breadth of npm packages is a good reason to use node. It has basically everything.

It has terrible half-completed versions of everything, all of which are subtly incompatible with everything else. I regularly see popular packages that are developed by essentially one person, or a tiny volunteer team that has priorities other than things working . Something else I noticed is that NPM packages have little to no "foresight" or planning ahead... because they're simply an itch that someone needed to scr…

If your willing to stick to pure MS libraries…

I used to agree but when you have libraries like Mediatr, mass transit and moq going/looking to go paid I’m not confident that the wider ecosystem is in a much better spot.

Re: Modern Node.js Patterns

#232

Earlier quoted context omitted.

I still like jest, if only because I can use `jest-extended`.

If you haven't tried vitest I highly recommend giving it a go. It is compatible with `jest-extended` and most of the jest matcher libraries out there.

Last time I tried it, IDE integration (e.g. Test Explorer in VSCode) was lacking compared to Jest.

Re: Modern Node.js Patterns

#233
post #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...

I wouldn't trust it to be done right. It's like a bank trusting that all their customers will do the right thing. If you want MAC (as opposed to DAC), do it in the kernel like it's supposed to be; use apparmor or selinux. And both of those methods will allow you to control way more than just which files you can read / write.

> I wouldn't trust it to be done right.

I don't understand this sort of complaint. Would you prefer that they didn't worked on this support ever? Exactly what's your point? Airing trust issues?

Re: Modern Node.js Patterns

#234

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.

Why not import files with extensions? That's the way JS (and TS) import is actually supposed to work.

Re: Modern Node.js Patterns

#235

One thing you should add to section 10 is encouraging people to pass `cause` option while throwing new Error instances. For example new Error("something bad happened", {cause:innerException})

It's wild that that's not what the section is about. Extending error is not new at-all.

Re: Modern Node.js Patterns

#236

Earlier quoted context omitted.

I have a blog post[1] and accompanying repo[2] that shows how to use SEA to build a binary (and compares it to bun and deno) and strip it down to 67mb (for me, depends on the size of your local node binary). [1]: https://notes.billmill.org/programming/javascript/Making_a_s... [2]: https://github.com/llimllib/node-esbuild-executable#making-a...

> 67 MB binary I hope you can appreciate how utterly insane this sounds to anyone outside of the JS world. Good on you for reducing the size, but my god…

Have you looked at the average size of, say, a .NET bundled binary.

Re: Modern Node.js Patterns

#237

Earlier quoted context omitted.

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.

You don't know if the author knows what they're talking about with or without AI in the picture.

Re: Modern Node.js Patterns

#238

I'm just happy to see Node.js patterns as a #1 on HN after continually being dismissed from 2012-2018.

Between browsers and Electron, even those of us who hate this ecosystem are forced to deal with it, and if one does, at least one can do it with slightly more comfort using the newer tooling.

Re: Modern Node.js Patterns

#239

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.

It kills me that I keep seeing axios being used instead of fetch, it is like people don't care, copy-paste existing projects as starting point and that is it.

Re: Modern Node.js Patterns

#240
post #108

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

Because Bun is still far less mature (and the stack on which it builds is even less so - Zig isn't even 1.0).

Because its Node.js compat isn't perfect, and so if you're running on Node in prod for whatever reason (e.g. because it's an Electron app), you might want to use the same thing in dev to avoid "why doesn't it work??" head scratches.

Because Bun doesn't have as good IDE integration as Node does.

Post reply on HN