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

411–420 of 448 posts

Re: Modern Node.js Patterns

#411

Post by _heimdall »

crabbone wrote: post #370
_heimdall wrote: post #338

Earlier quoted context omitted.

OS level checks will inevitably work differently on different OSes and different versions. Having a check like this in the app binary itself means you can have a standard implementation regardless of the OS running the app. I often hear similar arguments for or against database level security rules. Row level security, for example, is a really powerful feature and in my opinion is worth using when you can. Using RLS…

OK, I'll bite. Do you think Node.js implementation is aware of DNS search path? (My guess would be that it's unaware with 90% certainty). If you don't know what DNS search path is, here's my informal explanation: your application may request to connect to foo.bar.com or to bar.com, and if your /etc/resolv.conf contains "search foo", then these two requests are the same request. This is an important feature of corpora…

Oh I'd be very surprised if Node's implementation would handle such situations.

I also wouldn't really expect it to though, that depends heavily on the environment the app is run in, and if the deployment environment intentionally includes resolv.conf or similar I'd expect the developer(s) to either use a more elegant solution or configure Node to expect those resolutions.

Re: Modern Node.js Patterns

#412

Post by 9dev »

austin-cheney wrote: post #349
homebrewer wrote: post #341

Earlier quoted context omitted.

I despise these microlibraries as much as anyone, but your solution will also print escape codes when they're not needed (such as when piping output to e.g. grep). If it's something that makes sense only in interactive mode, then fine, but I've seen enough broken programs that clearly weren't designed to be run as a part of a UNIX shell, even when it makes a lot of sense. It's easy to solve though, simply assign empt…

That is not a string output problem. That is a terminal emulator problem. It is not the job of an application to know the modes and behaviors of the invoking terminal/shell. This applies exactly the same for all other applications that write to stdout. There is no cleverness here. But, if you really really want to avoid the ANSI descriptors for other reasons, maybe you just don't liked colored output, my applications…

The terminal emulator is not involved in piping to other processes. Grep will search over escape codes if you don’t suppress them in non-interactive environments, so this most definitely is a string output problem.

If you want to do it yourself, do it right—or defer to one of the battle-tested libraries that handle this for you, and additional edge cases you didn’t think of (such as NO_COLOR).

Re: Modern Node.js Patterns

#413

Post by 9dev »

sroussey wrote: post #111
gabrielpoca118 wrote: post #13

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

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.

Re: Modern Node.js Patterns

#414

Post by austin-cheney »

9dev wrote: post #412
austin-cheney wrote: post #349

Earlier quoted context omitted.

That is not a string output problem. That is a terminal emulator problem. It is not the job of an application to know the modes and behaviors of the invoking terminal/shell. This applies exactly the same for all other applications that write to stdout. There is no cleverness here. But, if you really really want to avoid the ANSI descriptors for other reasons, maybe you just don't liked colored output, my applications…

The terminal emulator is not involved in piping to other processes. Grep will search over escape codes if you don’t suppress them in non-interactive environments, so this most definitely is a string output problem. If you want to do it yourself, do it right—or defer to one of the battle-tested libraries that handle this for you, and additional edge cases you didn’t think of (such as NO_COLOR).

How do you define battle tested?

Typically JS developers define that as assuming something must be safe if enough people use it. That is a huge rift between the typical JS developer and organizations that actually take security more seriously. There is no safety rating for most software on NPM and more and more highly consumed packages are being identified as malicious or compromised.

If you do it yourself and get it wrong there is still a good chance you are in a safer place than completely throwing dependency management to the wind or making wild guesses upon vetted by the community.

Re: Modern Node.js Patterns

#415

Post by theozero »

For a more modern approach to .env files that includes built-in validation and type-safety, check out https://varlock.dev

Instead of a .env.example (which quickly gets out of date), it uses a .env.schema - which contains extra metadata as decorator comments. It also introduces a new function call syntax, to securely load values from external sources.

Re: Modern Node.js Patterns

#416

Post by theozero »

hk1337 wrote: post #304
berkes wrote: post #242

Earlier quoted context omitted.

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?

> The "proper" place to solve this, is in the OS. This is my thought on using dotenv libraries. The app shouldn’t have to load environment variables, only read them. Using a dotenv function/plugin like in omz is far more preferable.

In a team setting, it can be extremely helpful to have env/config loading logic built into the repo itself. It does not mean it has be loaded by the application process, but it can be part of the surrounding tooling that is part of your codebase.

Re: Modern Node.js Patterns

#417

Post by jameshart »

int_19h wrote: post #237
jameshart wrote: post #116

Earlier quoted context omitted.

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.

True! But writing an egregiously erroneous blogpost used to take actual effort. The existence of a blogpost was a form of proof of work that a human at least thought they knew enough about a topic to write it down and share it.

Now the existence of this blogpost is only evidence that the author has sufficient AI credits they are able to throw some release notes at Claude and generate some markdown, which is not really differentiating.

Re: Modern Node.js Patterns

#418

Post by goosejuice »

refulgentis wrote: post #407
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...

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

Critique of the output is fine in my eyes. If you don't enjoy the style, format, choice of words, etc I think that's fair game even if it's superficial/subjective. It often is with art.

Placing a value judgement on someone for how the art was produced is gatekeeping. What if the person is disabled and uses an LLM for accessibility reasons as one does with so many other tools? I dunno, that seems problematic to me but I understand the aversion to the output.

For example maybe it's like criticising Hawking for not changing his monotone voice vs using the talker all together. Perhaps not the best analogy.

The author can still use LLMs to adjust the style according to criticism of the output if they so choose.

Re: Modern Node.js Patterns

#419

Post by Tokumei-no-hito »

farkin88 wrote: post #89
tanduv wrote: post #78

Earlier quoted context omitted.

I never really liked the syntax of fetch and the need to await for the response.json, implementing additional error handling - async function fetchDataWithAxios() { try { const response = await axios.get('https://jsonplaceholder.typicode.com/posts/1'); console.log('Axios Data:', response.data); } catch (error) { console.error('Axios Error:', error); } } async function fetchDataWithFetch() { try { const response = awa…

Yeah, that's the classic bundle size vs DX trade-off. Fetch definitely requires more boilerplate. The manual response.ok check and double await is annoying. For Lambda where I'm optimizing for cold starts, I'll deal with it, but for regular app dev where bundle size matters less, axios's cleaner API probably wins for me.

why don't they just set those as options

{ throwNotOk, parseJson }

they know that's 99% of fetch calls, i do t see why it can't be baked in.

Re: Modern Node.js Patterns

#420

Post by eddd-ddde »

austin-cheney wrote: post #349
homebrewer wrote: post #341

Earlier quoted context omitted.

I despise these microlibraries as much as anyone, but your solution will also print escape codes when they're not needed (such as when piping output to e.g. grep). If it's something that makes sense only in interactive mode, then fine, but I've seen enough broken programs that clearly weren't designed to be run as a part of a UNIX shell, even when it makes a lot of sense. It's easy to solve though, simply assign empt…

That is not a string output problem. That is a terminal emulator problem. It is not the job of an application to know the modes and behaviors of the invoking terminal/shell. This applies exactly the same for all other applications that write to stdout. There is no cleverness here. But, if you really really want to avoid the ANSI descriptors for other reasons, maybe you just don't liked colored output, my applications…

It is 100% the job of the application. This is why a lot of programs have options like --color=auto so it infers the best output mode based on the output FD type e.g. use colours for terminals but no colours for pipes.
Post reply on HN