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

341–350 of 448 posts

Re: Modern Node.js Patterns

#341

Post by homebrewer »

austin-cheney wrote: post #320
xbbdbd wrote: post #224

Earlier quoted context omitted.

This is the problem with people trying to be clever. Now you output escape sequences regardless of terminal setting. Using a library which handles that (an a thousand other quirks) makes much more sense

There is no cleverness involved. The escape sequences are decades old and universally supported as a de facto standard. In this case the escape sequences are assigned to variables that are attached to other strings. This is as clever as using an operator. These escape sequences are even supported by Chromes dev tools console directly in the browser. The real issue is invented here syndrome . People irrationally defer…

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 empty strings to escape code variables when the output is not an interactive shell.

Re: Modern Node.js Patterns

#342

Post by realityking »

hollowturtle wrote: post #289

Am I the only one believing common js was super ok and don't like esm? Or put differently I didn't see the necessity of having esm at all in Node. Let alone the browser, imagine loading tons of modules over the wire instead of bundle them

The fact that ESM exports are static - and imports are mostly static - allows for a lot more dead code removal during bundling. That alone is a big win IMHO.

Re: Modern Node.js Patterns

#343

Post by pjmlp »

bilekas wrote: post #255
pjmlp wrote: post #239

Earlier quoted context omitted.

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.

Maybe I'm wrong and it's been updated but doesn't axios support progress indicators out of the box and just generally cleaner? That's said there are npm packages that are ridiculously obsolete and overused.

May be, however I seldom see those things being used, it is always just request response kind of workflow.

Re: Modern Node.js Patterns

#344

Post by ramesh31 »

yawnxyz wrote: post #27
farkin88 wrote: post #16

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.

node fetch is WAY better than axios (easier to use/understand, simpler); didn't really know people were still using axios

Interceptors (and extensions in general) are the killer feature for axios still. Fetch is great for scripts, but I wouldn't build an application on it entirely; you'll be rewriting a lot or piecing together other libs.

Re: Modern Node.js Patterns

#345

Post by vlovich123 »

berkes wrote: post #242
simonw wrote: 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?

Except, the OS hasn’t actually solved it. Any program you can run can access arbitrary files of yours and it’s quite difficult to actually control that access even if you want to limit the blast radius of your own software. Seriously - what software works you use? Go write eBPF to act as a mini adhoc hypervisor to enforce difficult to write policies via seLinux? That only even works if you’re the admin of the machine which isn’t necessarily the same person writing the software they want to code defensively.

Also modern software security is really taking a look at strengthening software against supply chain vulnerabilities. That looks less like traditional OS and more like a capabilities model where you start with a set of limited permissions and even within the same address space it’s difficult to obtain a new permission unless your explicitly given a handle to it (arguably that’s how all permissions should work top to bottom).

Re: Modern Node.js Patterns

#346

Post by bavell »

berkes wrote: post #332
hk1337 wrote: post #304

Earlier quoted context omitted.

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

Entirely. The argument often heard though is 'but windows'. Though if windows lacks env (or Cron, or chroot, etc) the solution would be to either move to an env that does support it, or introduce some tooling only for the windows users. Not build a complex, hierarchical directory scanner that finds and merges all sorts of .env .env.local and whatnots. On dev I often do use .ENV files, but use zenv or a loadenv tool o…

I use .env files and have a small bash script to load them into env for dev, or load them into a k8s configmap for deployment.

Re: Modern Node.js Patterns

#347

Post by nmeofthestate »

epolanski wrote: post #298
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?

What's there to dislike? They don't replace the restrictions at OS level, they add to it.

It's similar to the refrain "they shouldn't add that feature to language X, people should just use language Y instead" ("just" when said by software developers is normally a red flag IME)

Re: Modern Node.js Patterns

#348

Post by bavell »

hmcdona1 wrote: post #205
hnroo99 wrote: post #117

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…

ts-rest doesn't see a lot of support these days. It's lack of adoption of modern tanstack query integration patterns finally drove us look for alternatives. Luckily, oRPC had progressed enough to be viable now. I cannot recommend it over ts-rest enough. It's essentially tRPC but with support for ts-rest style contracts that enable standard OpenAPI REST endpoints. - https://orpc.unnoq.com/ - https://github.com/unnoq/o…

First time hearing about oRPC, never heard of or used ts-rest and I'm a big fan of tRPC. Is the switch worth the time and energy?

Re: Modern Node.js Patterns

#349

Post by austin-cheney »

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

Earlier quoted context omitted.

There is no cleverness involved. The escape sequences are decades old and universally supported as a de facto standard. In this case the escape sequences are assigned to variables that are attached to other strings. This is as clever as using an operator. These escape sequences are even supported by Chromes dev tools console directly in the browser. The real issue is invented here syndrome . People irrationally defer…

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 features a no-color option that replaces the ANSI control string values with empty strings.

Re: Modern Node.js Patterns

#350

Post by chamomeal »

upcoming-sesame wrote: post #124
hungryhobbit wrote: post #80

Earlier quoted context omitted.

Eh, the Node test stuff is pretty crappy, and the Node people aren't interested in improving it. Try it for a few weeks before diving headfirst into it, and you'll see what I mean (and then if you go to file about those issues, you'll see the Node team not care).

still I would rather use that than import mocha, chai, Sinon, istanbul. At the end it's just tests, the syntax might be more verbose but Llms write it anyway ;-)

On a separate note, I’ve found that LLMs have been writing me really shitty tests. Which is really sad cause that was the first use case I had for copilot, and I was absolutely smitten.

They’re great at mocking to kingdom come for the sake of hitting 90% coverage. But past that it seems like they just test implementation enough to pass.

Like I’ve found that if the implementation is broken (even broken in hilariously obvious ways, like if (dontReturnPancake) return pancake; ), they’ll usually just write tests to pass the bad code instead of saying “hey I think you messed up on line 55…”

Post reply on HN