Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Modern Node.js Patterns

kashw1n.com

Post reply on HN
Print view View original

441–448 of 448 posts

Re: Modern Node.js Patterns

#441

Post by llamasushi »

xdennis wrote: post #284
fleebee wrote: post #41

Nice post! There's a lot of stuff here that I had no idea was in built-in already. I tried making a standalone executable with the command provided, but it produced a .blob which I believe still requires the Node runtime to run. I was able to make a true executable with postject per the Node docs[1], but a simple Hello World resulted in a 110 MB binary. This is probably a drawback worth mentioning. Also, seeing those…

Yeah, many people here are saying this is AI written. Possibly entirely. It says: "You can now bundle your Node.js application into a single executable file", but doesn't actually provide the command to create the binary. Something like: npx postject hello NODE_SEA_BLOB sea-prep.blob \ --sentinel-fuse NODE_SEA_FUSE_fce680ab2cc467b6e072b8b5df1996b2

Yeah, this one line gave it away for me: "you’re not just writing contemporary code—you’re building applications that are more maintainable..."

Look up dialectical hedging. Dead AI giveaway.

Re: Modern Node.js Patterns

#442

Post by goosejuice »

booleandilemma wrote: post #438
goosejuice wrote: post #386

Earlier quoted context omitted.

You can critique the writing without calling into question how it was written. Speculation on the tools used to write it serves no purpose beyond making a, possibly unfounded, value judgement against the writer. https://hbr.org/2025/08/research-the-hidden-penalty-of-using...

No, I think if someone is passing off an LLM's writing as their own they deserve to be shamed mercilessly. Normally I don't comment on a thread after so long (> 24 hours) but your take is just so bad, I couldn't help myself.

You don't know if the author used an LLM, and if they did why they used it. That's the whole point.

Help yourself to learn about how individuals with disabilities use technology to communicate. Shaming someone for using a tool purely based on speculation is problematic for that reason alone

Re: Modern Node.js Patterns

#443

Post by sroussey »

9dev wrote: post #413
sroussey wrote: post #111

Earlier quoted context omitted.

It strips TS, it does not transpile. Things like TS enums will not work.

Don’t use enums. They are problematic for a few reasons, but the ability to run TS code without enums without a build step should be more than enough of a reason to just use a const object instead.

Oh, I agree.

Re: Modern Node.js Patterns

#444

Post by mcv »

tracker1 wrote: post #395
mcv wrote: post #249

Earlier quoted context omitted.

That's very concise. Still, the double await remains weird. Why is that necessary?

It isn't, the following works fine... var data = await fetch(url).then(r => r.json()); Understanding Promises/A (thenables) and async/await can sometimes be difficult or confusing, especially when mixing the two like above.

Same thing. Maybe this doesn't make the double promise quite as visible, but it's still a double promise. You could probably replace the other await with a .then() too.

Re: Modern Node.js Patterns

#445

Post by const_cast »

int_19h wrote: post #236
sgarland wrote: post #145

Earlier quoted context omitted.

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

The difference is dotnet is both a much more feature complete runtime and a much more performant one. Its not like you're getting all too much with that node runtime - it was, and still is although to a lesser extent, pretty bare-bones.

Re: Modern Node.js Patterns

#446

Post by const_cast »

nedt wrote: post #336
palmfacehn wrote: post #230

Earlier quoted context omitted.

JS on the backend was arguably an even bigger mistake when the JS ecosystem was less sophisticated. The levels of duct tape are dizzying. Although we might go back even further and ask if JS was also a mistake when it was added to the browser. I often wonder about a what-if, alternate history scenario where Java had been rolled out to the browser in a more thoughtful way. Poor sandboxing, the Netscape plugin paradigm…

> JS on the backend was arguably an even bigger mistake when the JS ecosystem was less sophisticated. I see it being used since over 25 years for the Austrian national broadcaster. Based at least originally on rhino, so it's also mixed with the Java you love. Fail to see the big issue as it's working just fine for such a long time.

There's also many successful multi-natioksl banks built off of Cobalt.

Cobalt was a mistake.

Re: Modern Node.js Patterns

#447

Post by const_cast »

drewbitt wrote: post #169
jiggawatts wrote: post #129

Earlier quoted context omitted.

Recently? In my experience ASP.NET 9 is vastly more productive and capable than Node.js. It has a nicer developer experience, it is faster to compile, faster to deploy, faster to start, serves responses faster, it has more "batteries included", etc, etc... What's the downside?

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.

Node is a lot like PHP of old. Pretty bare-bones, but has lots of other people's code you can use. The problem is most of it doesn't work.

Dotnet is batteries included. It has all the features you'll need, almost. If you need something else, the packages you find are just much higher quality.

Re: Modern Node.js Patterns

#448

Post by seniorsassycat »

serguzest wrote: post #260
seniorsassycat wrote: post #235

Earlier quoted context omitted.

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

Most people (including the author apparently) don't know they can chain errors with cause option in-built way in node and in browser. It is not just arbitrary extending and it is relatively a new thing. https://nodejs.org/api/errors.html#errorcause

I've found that a lot of logging frameworks and patterns will not include cause which can absolutely fuck debugging
Post reply on HN