Live data from Hacker News

Modern Node.js Patterns

kashw1n.com

401–410 of 448 posts

Re: Modern Node.js Patterns

#401
post #242
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 very much dislike such features in a runtime or app. The "proper" place to solve this, is in the OS. Where it has been solved, including all the inevitable corner cases, already. Why reinvent this wheel, adding complexity, bug-surface, maintenance burden and whatnot to your project? What problem dies it solve that hasn't been solved by other people?

In Deno you can make a runtime that cannot even access the filesystem.

That's a cool feature. Using jlink for creating custom JVMs does something similar.

That's a good feature. What you are saying is still true though, using the OS for that is the way to go.

Re: Modern Node.js Patterns

#402
post #353

Earlier quoted context omitted.

How would you solve this at the OS level across Linux, macOS and Windows? I've been trying to figure out a good way to do this for my Python projects for a couple of years now. I don't yet trust any of the solutions I've come up with - they are inconsistent with each other and feel very ironed to me making mistakes due to their inherent complexity and lack of documentation that I trust.

Why would a desktop program need these sort of restrictions?

Because I don't trust the developer not to have security holes in their code.

Re: Modern Node.js Patterns

#403

Earlier quoted context omitted.

It's definitely ai slop. See also the nonsensical attempt to conditionally load SQLite twice, in the dynamic imports example. The list of features is nice, I suppose, for those who aren't keeping up with new releases, but IMO, if you're working with node and js professionally, you should know about most, if not all of these features.

Hasn't AsyncIterator been available in Node for several years? I used it extensively—I want to say—around 3 years ago. It's definitely awesome but doesn't seem newsworthy. The experimental stuff seems more along the lines of newsworthy.

> Hasn't AsyncIterator been available in Node for several years? I used it extensively—I want to say—around 3 years ago.

Yes. It's been around and relatively stable in V8/Node.js for years now.

Re: Modern Node.js Patterns

#404

Earlier quoted context omitted.

You can still bundle them, maybe you even should. Webpack still does a good job. Can also remove unused parts.

If anything bun proves that both worlds can go together despite what proponents of web standards says

> If anything bun proves that both worlds can go together despite what proponents of web standards says

Sure, but Bun's implementation is a confusing mess a lot of times. I prefer them separate.

Note: This is no shade toward Bun. I'm a fan of Bun and the innovative spirit of the team behind it.

Re: Modern Node.js Patterns

#405
post #253

Earlier quoted context omitted.

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 woul…

Do you need an LLM for this? I've made my own in-house fork of a Java library without any LLM help. I needed apache.poi's excel handler to stream, which poi only supports in one direction. Someone had written a poi-compatible library that streamed in the other direction, but it had dependencies incompatible with mine. So I made my own fork with dependencies that worked for me. That got me out of mvn dependency hell.…

For forking and changing a few things here and there, I could see how there might be less of a need for LLMs, especially if you know what you're doing. But in my case I didn't actually fork `ts-rest`, I built a much smaller custom abstraction from the ground-up and I don't consider myself to be a top-tier dev. In this case it felt like LLMs provided a lot more value, not necessarily because the problem was overly difficult but moreso because of the time saved. Had LLMs not existed, I probably would have never considered doing this as the opportunity cost would have felt too high (i.e. DX work vs critical user-facing work). I estimate it would have taken me ~2 weeks or more to finish the task without LLMs, whereas with LLMs it only took a few days.

I do feel we're heading in a direction where building in-house will become more common than defaulting to 3rd party dependencies—strictly because the opportunity costs have decreased so much. I also wonder how code sharing and open source libraries will change in the future. I can see a world where instead of uploading packages for others to plug into their projects, maintainers will instead upload detailed guides on how to build and customize the library yourself. This approach feels very LLM friendly to me. I think a great example of this is with `lucia-auth`[0] where the maintainer deprecated their library in favour of creating a guide. Their decision didn't have anything to do with LLMs, but I would personally much rather use a guide like this alongside AI (and I have!) rather than relying on a 3rd party dependency whose future is uncertain.

[0] https://lucia-auth.com/

Re: Modern Node.js Patterns

#406
post #74

Earlier quoted context omitted.

It has always astonished me that platforms did not have first class, native "http client" support. Pretty much every project in the past 20 years has needed such a thing. Also, "fetch" is lousy naming considering most API calls are POST.

“Most” is doing a lot of heavy lifting here. I use plenty of APIs that are GET

I was thinking server-side where it's probably 90%+ POST. True, client-side a lot different (node the only player client-side, though).

Re: Modern Node.js Patterns

#407

Earlier quoted context omitted.

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 yo…

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

I think this is both valuable, and yet, it is also the key to why the forest will become dark.

I'm not speculating - I have to work with these things so darn much that the tells are blindingly obvious - and the tells are well-known, ex. there's a gent who benchmarks "it's not just x - it's y" shibboleths for different models.

However, in a rigorous sense I am speculating: I cannot possibly know an LLM was used.

Thus, when an LLM is used, I am seeing an increasing fraction of conversation litigating whether is appropriate, whether it matters, if LLMs are good, and since anyone pointing it out could be speculating, now, the reaction hinges on how you initially frame this observation.

Ex. here, I went out of my way to make a neutral-ish comment given an experience I had last week (see other comment by me somewhere down stream)

Lets say I never say LLM, instead, frame it as "Doesn't that just mean it's a convention?" and "How are there so many game-changers?", which is obvious to audience is a consequence of using an LLM, and yet, also looks like you're picking on someone (are either of those bad writing? I only had one teacher who ever would take umbrage at somewhat subtle fluff like this)

Anyways this is all a bunch of belly-aching to an extent, you're right, and its the way to respond. There's a framing where the only real difficulty here is critiquing the writing without looking like you're picking on someone.

EDIT: Well, except for one more thing: what worries me the most when I see someone using the LLM and incapable of noticing tells and incapable of at least noticing the tells are weakening writing is...well, what else did they miss? What else did the LLM write that I have to evaluate for myself? So it's not so much as somewhat-bad writing, 90%+ still, that bothers me: its that idk what's real, and it feels like a waste of time even being offered it to read if I have to check everything.

Re: Modern Node.js Patterns

#408
post #170

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 too find it unreadable, I guess that's the downside of working on this stuff every day, you get to really hate seeing it. It does tell you that if even 95% of HN can't tell, then 99% of the public can't tell. Which is pretty incredible.

Cheers, it's gotta be the "I see this every day for hours" thing - I have a hard time mentioning it because there's a bunch of people who would like to think they have similar experience and yet don't see the same tells. But for real, I've been on these 8+ hours a day for 2 years now.

And it sounds like you have the same surreal experience as me...it's so blindingly. obvious. that the only odd thing is people not mentioning it.

And the tells are so tough, like, I wanted to a bang a drum over and over again 6 weeks ago about the "It's not X-it's Y" thing, I thought it was a GPT-4.1 tell.

Then I found this under-publicized gent doing God's work: ton of benchmarks, one of them being "Not X, but Y" slop and it turned out there was 40+ models ahead of it, including Gemini (expected, crap machine IMHO), and Claude, and I never would have guessed the Claudes. https://x.com/sam_paech/status/1950343925270794323

Re: Modern Node.js Patterns

#409

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…

It's not insane at all. Any binary that gets packed with the entire runtime will be in MBs. But that's the point, the end user downloads a standalone fragment and doesn't need to give a flying fuck about what kind of garbage has to be preinstalled for the damn binary to work. You think people care if a binary is 5MB or 50MB in 2025? It's more insane that you think it's insane than it is actually insane. Reminds me of…

The fact that it’s normalized to use obscene amounts of memory for tiny apps should not be celebrated.

I assure you, at scale this belief makes infra fall apart, and I’ve seen it happen so, so many times. Web devs who have never thought about performance merrily chuck huge JSON blobs or serialized app models into the DB, keep clicking scale up when it gets awful, and then when that finally doesn’t work, someone who _does_ care gets hired to fix it. Except that person or team now has to not only fix years of accumulated cruft, but also has to change a deeply embedded culture, and fight for dev time against Product.

Re: Modern Node.js Patterns

#410

Yet more architecture astronaut behavior by people who really should just be focusing on ifs, fors, arrays, and functions.

Architecture astronaut is a term I hadn't heard but can appreciate. However I fail to see that here. It's a fair overview of newish Node features... Haven't touched Node in a few years so kinda useful.

The term originates from a Joel Spolsky article (or at least it's where I know it from). It's a great read: https://www.joelonsoftware.com/2001/04/21/dont-let-architect...

Feels unrelated to the article though.

Post reply on HN