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

321–330 of 448 posts

Re: Modern Node.js Patterns

#321

Post by hollowturtle »

spixy wrote: post #317
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

Yes. Also CommonJS does not support tree shaking.

Nor does ESM if you import * as. Plus I believe it can be made to support tree shaking

Edit: the proof my point reside in the many libraries which have an open issue because, even if ESM, they don't support tree shaking

Re: Modern Node.js Patterns

#322

Post by hollowturtle »

gregoriol wrote: post #290
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

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

Re: Modern Node.js Patterns

#323

Post by ygritte »

Etheryte wrote: post #307
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?

This is a nice idea, but what do you do when the OS tooling is not that good? macOS is a good example, they have OS level sandboxing [0], but the docs are practically nonexistent and the only way to figure it out is to read a bunch of blog posts by people who struggled with it before you. Baking it into Node means that at least theoretically you get the same thing out of the box on every OS. [0] https://www.karltarva…

Thank you for this link, it saves me a lot of searching.

Re: Modern Node.js Patterns

#324

Post by hollowturtle »

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…

Bun proved both worlds can work together, the mess is all on the Node.js shoulder, and we, the devs, are blamed for not adopting

Re: Modern Node.js Patterns

#325

Post by plopz »

capt_obvious_77 wrote: post #279
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?

The two I find most annoying

Hoisting/import order especially when trying to mock tests.

Whether or not to include extensions, and which extension to use, .js vs .ts.

Re: Modern Node.js Patterns

#326

Post by plopz »

mcv wrote: post #313
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).

Could you expand on the shortcomings of Node test compared to jest?

Module support is still experimental and under a flag and doesn't have any mechanism for mocking.

Re: Modern Node.js Patterns

#327

Post by eviks »

pfg_ wrote: post #267
motorest wrote: post #261

Earlier quoted context omitted.

> Node allows native addons in packages via the N-API so any native module aren't restricted by those permissions. (...) Node permissions (...) just restrict the Node standard library. So what? That's clearly laid out in Node's documentation. https://nodejs.org/api/permissions.html#file-system-permissi... What point do you think you're making?

What is the point of a permissions system that can be trivially bypassed?

To check a box

> need to demonstrate security compliance.

Re: Modern Node.js Patterns

#328

Post by rikafurude21 »

CSSer wrote: post #268
CSSer wrote: post #210

Earlier quoted context omitted.

You can get download progress with fetch. You can't get upload progress. Edit: Actually, you can even get upload progress, but the implementation seems fraught due to scant documentation. You may be better off using XMLHttpRequest for that. I'm going to try a simple implementation now. This has piqued my curiosity.

It took me a couple hours, but I got it working for both uploads and downloads with a nice progress bar. My uploadFile method is about 40 lines of formatted code, and my downloadFile method is about 28 lines. It's pretty simple once you figure it out! Note that a key detail is that your server (and any intermediate servers, such as a reverse-proxy) must support HTTP/2 or QUIC. I spent much more time on that than the…

can we see a gist?

Re: Modern Node.js Patterns

#329

Post by nedt »

HNMocksUsers wrote: post #251
prmph wrote: post #38

I think slowly Node is shaping up to offer strong competition to Bun.js, Deno, etc. such that there is little reason to switch. The mutual competition is good for the continued development of JS runtimes

Starting a new project, I went with Deno after some research. The NPM ecosystem looked like a mess; and if Node's creator considers Deno the future and says it addresses design mistakes in Node, I saw no reason to doubt him.

I was really trying to use deno but it still is not there yet. Node might not be the cool kid, but it works and if you get stuck the whole internet is here to help (or at least stack overflow).

We once reported an issue and it got fixed really quickly. But then we had troubles connecting via TLS (mysql on google cloud platform) and after a long time debugging found out the issue is actually not in deno, but in RustTLS, which is used by deno. Even a known issue in RustTLS - still hard to find out if you don't already know what you are searching for.

It was then quicker to switch to nodejs with a TS runner.

Re: Modern Node.js Patterns

#330

Post by jech »

mcv wrote: post #249
mythz wrote: post #196

Earlier quoted context omitted.

why not? const data = await (await fetch(url)).json()

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

So you can say:

    let r = await fetch(...);
    if(!r.ok) ...
    let len = response.headers.get("Content-Length");
    if(!len || new Number(len) > 1000 * 1000)
        throw new Error("Eek!");
Post reply on HN