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

271–280 of 448 posts

Re: Modern Node.js Patterns

#271

Post by fuzzythinker »

tyilo wrote: post #262
fuzzythinker wrote: post #248

Earlier quoted context omitted.

I have a "ascii.txt" file ready to copy/paste the "book emoji" block chars to prepend my logs. It makes logs less noisy. HN can't display them, so I'll have to link to page w/ them: https://www.piliapp.com/emojis/books/

Why would you call that "ascii.txt"?

Caz it has more than those book emojis. It makes writing geometric code docstrings easier. Here's the rest of it (HN doesn't format it good, try copy/paste it).

   cjk→⋰⋱| | ← cjk space btw | |
   thinsp | |
   deg° 
   ⋯ …
   ‾⎻⎼⎽ lines
   _ light lines
   ⏤ wide lines
   ↕
   ∧∨ 
 ┌────┬────┐ 
 │    │ ⋱  ⎸ ← left bar, right bar: ⎹
 └────┴────┘
    ⊃⊂ ⊐≣⊏
    ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯====›‥‥‥‥
◁ ◿ ◺ ◻ ◸ Λ ╱│╲ ╱ │ ╲ ──┼── ╲ │ ╱ ╲│╱ V ┌ ─┏━━┳━━━━━━━┓ │ ┃ ┃ ┃ ├ ─┣━━╋━━━━━━━┫ │ ┃ ┃ ┃ └ ─┗━━┻━━━━━━━┛ ┌ ─ ┬ ─ ┐ ├ ─ ┼ ─ ┤ └ ─ ┴ ─ ┘ ┌───┬───┐ ├───┼───┤ │ │ │ └───┴───┘ . ╱│╲ ↘╱ │ ╲ ↙ ╱ │ ╲ →‹───┼───›← ╲ │ ╱ ↗ ╲ │ ╱ ↖ ╲│╱ ↓↑ ╳ . ╱ ╲ ╱ ╲ ╱ ⋰ ╲ ╱⋰______╲

Re: Modern Node.js Patterns

#272

Post by Cthulhu_ »

tanduv wrote: post #78
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.

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…

While true, in practice you'd only write this code once as a utility function; compare two extra bits of code in your own utility function vs loading 36 kB worth of JS.

Re: Modern Node.js Patterns

#273

Post by Cthulhu_ »

freeopinion wrote: post #161
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…

I somehow don't get your point. The following seems cleaner than either of your examples. But I'm sure I've missed the point. fetch(url).then(r=>r.ok ? r.json() : Promise.reject(r.status)) .then( j=>console.log('Fetch Data:', j), e=>console.log('Fetch Error:', e) ); I share this at the risk of embarrassing myself in the hope of being educated.

Depends on your definition of clean, I consider this to be "clever" code, which is harder to read at a glance.

You'd probably put the code that runs the request in a utility function, so the call site would be `await myFetchFunction(params)`, as simple as it gets. Since it's hidden, there's no need for the implementation of myFetchFunction to be super clever or compact; prefer readability and don't be afraid of code length.

Re: Modern Node.js Patterns

#274

Post by captn3m0 »

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

Can't seem to find an official docs link for allow-net, only blog posts.

Re: Modern Node.js Patterns

#275

Post by Cthulhu_ »

stevage wrote: post #162
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…

I usually write it like: const data = (await fetch(url)).then(r => r.json()) But it's very easy obviously to wrap the syntax into whatever ergonomics you like.

Honestly it feels like yak shaving at this point; few people would write low-level code like this very often. If you connect with one API, chances are all responses are JSON so you'd have a utility function for all requests to that API.

Code doesn't need to be concise, it needs to be clear. Especially back-end code where code size isn't as important as on the web. It's still somewhat important if you run things on a serverless platform, but it's more important then to manage your dependencies than your own LOC count.

Re: Modern Node.js Patterns

#276

Post by Deestan »

Cthulhu_ wrote: post #269
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?

How would you do this in a native fashion? I mean I believe you (chroot jail I think it was?), but not everyone runs on *nix systems, and perhaps more importantly, not all Node developers know or want to know much about the underlying operating system. Which is to their detriment, of course, but a lot of people are "stuck" in their ecosystem. This is arguably even worse in the Java ecosystem, but it's considered a se…

> but not everyone runs on *nix systems

Meaning Windows? It also has file system permissons on an OS level that are well-tested and reliable.

> not all Node developers know or want to know much about the underlying operating system

Thing is, they are likely to not feel up for understanding this feature either, nor write their code to play well with it.

And if they at some point do want to take system permissions seriously, they'll find it infinitely easier to work with the OS.

Re: Modern Node.js Patterns

#277

Post by phendrenad2 »

Javascript is missing some feature that will take it to the next level, and I'm not sure what it is.

Maybe it needs a compile-time macro system so we have go full Java and have magical dependency injection annotations, Aspect-Oriented-Programming, and JavascriptBeans (you know you want it!).

Or maybe it needs to go the Ruby/Python/SmallTalk direction and add proper metaprogramming, so we can finally have Javascript on Rails, or maybe uh... Djsango?

Re: Modern Node.js Patterns

#278

Post by lelanthran »

Cthulhu_ wrote: post #269
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?

How would you do this in a native fashion? I mean I believe you (chroot jail I think it was?), but not everyone runs on *nix systems, and perhaps more importantly, not all Node developers know or want to know much about the underlying operating system. Which is to their detriment, of course, but a lot of people are "stuck" in their ecosystem. This is arguably even worse in the Java ecosystem, but it's considered a se…

> How would you do this in a native fashion?

I dunno how GP would do it, but I run a service (web app written in Go) under a specific user and lock-down what that user can read and write on the FS.

For networking, though, that's a different issue.

Re: Modern Node.js Patterns

#279

Post by capt_obvious_77 »

bilalq wrote: post #219

I really wish ESM was easier to adopt. But we're halfway through 2025 and there are still compatibility issues with it. And it just gets even worse now that so many packages are going ESM only. You get stuck having to choose what to cut out. I write my code in TS using ESM syntax, but still compile down to CJS as the build target for my sanity. In many ways, this debacle is reminiscent of the Python 2 to 3 cutover. I…

Can you elaborate on the compatibility issues you ran into, with ESM, please? Are they related to specific libs or use-cases?

Re: Modern Node.js Patterns

#280

Post by wiseowise »

austin-cheney wrote: post #67

I see two classes of emerging features, just like in the browser: 1. new technologies 2. vanity layers for capabilities already present It’s interesting to watch where people place their priorities given those two segments

> vanity layers for capabilities already present

Such as?

Post reply on HN