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

391–400 of 448 posts

Re: Modern Node.js Patterns

#391

Post by DiddlyWinks »

nedt wrote: post #329
HNMocksUsers wrote: post #251

Earlier quoted context omitted.

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

Interesting. Do you think Deno has made questionable choices in the components it uses?

Re: Modern Node.js Patterns

#392

Post by tracker1 »

bikeshaving wrote: post #133
farkin88 wrote: post #47

Earlier quoted context omitted.

Interesting to get a library author's perspective. To be fair, you guys had to deal with the whole ecosystem shift: dual package hazards, CJS/ESM compatibility hell, tooling changes, etc so I can see how ESM would be the bigger story from your perspective.

The fact that CJS/ESM compatibility issues are going away indicates it was always a design choice and never a technical limitation (most CJS format code can consume ESM and vice versa). So much lost time to this problem.

There were some legitimate technical decisions, that said, imho, Node should have just stayed compatible with Babel's implementation and there would have been significantly less friction along the way. It was definitely a choice not to do so, for better and worse.

It's interesting to see how many ideas are being taken from Deno's implementations as Deno increases Node interoperability. I still like Deno more for most things.

Re: Modern Node.js Patterns

#393

Post by tracker1 »

franciscop wrote: post #257
8n4vidtmkvmk wrote: post #202

Earlier quoted context omitted.

It was a pain, but rollup can export both if you write the source in esm. The part I find most annoying is exporting the typescript types. There's no tree-shaking for that!

For simple projects you needed now to add rollup or other build system that didn't have or need it before. For complex systems (with non-trivial exports), now you have a mess since it wouldn't work straight away. Now with ESM if you write plain JS it works again. If you use Bun, it also works with TS straight away.

This is where I actually appreciated Deno's start with a clean break from npm, and later in pushing jsr. I'm mixed on how much of Node has come into Deno, however.

Re: Modern Node.js Patterns

#394

Post by vlucas »

sgarland wrote: post #145
llimllib wrote: post #55

Earlier quoted context omitted.

I have a blog post[1] and accompanying repo[2] that shows how to use SEA to build a binary (and compares it to bun and deno) and strip it down to 67mb (for me, depends on the size of your local node binary). [1]: https://notes.billmill.org/programming/javascript/Making_a_s... [2]: https://github.com/llimllib/node-esbuild-executable#making-a...

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

This packages the entire Node runtime and all project dependencies. It's not that insane.

Re: Modern Node.js Patterns

#395

Post by tracker1 »

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?

It isn't, the following works fine...

    var data = await fetch(url).then(r => r.json());
Understanding Promises/A (thenables) and async/await can sometimes be difficult or confusing, especially when mixing the two like above.

Re: Modern Node.js Patterns

#396

Post by tracker1 »

pbreit wrote: post #74
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.

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.

Node was created with first-class native http server and client support. Wrapper libraries can smooth out some rough edges with the underlying api as well as make server-side js (Node) look/work similar to client-side js (Browser).

Re: Modern Node.js Patterns

#397

Post by tracker1 »

int_19h wrote: post #236
sgarland wrote: post #145

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…

Have you looked at the average size of, say, a .NET bundled binary.

Not sure why the down vote(s)... My main work project isn't that big yet, and the bin directory is like 96mb.

Not that I find it particularly egregious, but my rust (web-server) apps not even optimized are under 10mb easily.

Re: Modern Node.js Patterns

#398

Post by bjacobso »

exhaze wrote: post #76
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.

Tangential, but thought I'd share since validation and API calls go hand-in-hand: I'm personally a fan of using `ts-rest` for the entire stack since it's the leanest of all the compile + runtime zod/json schema-based validation sets of libraries out there. It lets you plug in whatever HTTP client you want (personally, I use bun, or fastify in a node env). The added overhead is totally worth it (for me, anyway) for sh…

I migrated from ts-rest to Effect/HttpApi. It's an incredible ecosystem, and Effect/Schema has over taken my domain layer. Definitely a learning curve though.

Re: Modern Node.js Patterns

#399

Post by fmorel »

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…

Except you might want different error handling for different error codes. For example, our validation errors return a JSON object as well but with 422.

So treating "get a response" and "get data from a response" separately works out well for us.

Re: Modern Node.js Patterns

#400

Post by CSSer »

throwitaway1123 wrote: post #361
CSSer wrote: post #359

Earlier quoted context omitted.

https://github.com/hu0p/fetch-transfer-progress-demo/

Which browsers have you tested this in? I ran the feature detection script from the Chrome docs and neither Safari nor Firefox seem to support fetch upload streaming: https://developer.chrome.com/docs/capabilities/web-apis/fetc... const supportsRequestStreams = (() => { let duplexAccessed = false; const hasContentType = new Request('http://localhost', { body: new ReadableStream(), method: 'POST', get duplex() { duple…

Oops. Chrome only! I stand very much corrected. Perhaps I should do less late night development.

It seems my original statement that download, but not upload, is well supported was unfortunately correct after all. I had thought that readable/transform streams were all that was needed, but as you noted it seems I've overlooked the important lack of duplex option support in Safari/Firefox[0][1]. This is definitely not wide support! I had way too much coffee.

Thank you for bringing this to my attention! After further investigation, I encountered the same problem as you did as well. Firefox failed for me exactly as you noted. Interestingly, Safari fails silently if you use a transformStream with file.stream().pipeThrough([your transform stream here]) but it fails with a message noting lack of support if you specifically use a writable transform stream with file.stream().pipeTo([writable transform stream here]).

I came across the article you referenced but of course didn't completely read it. It's disappointing that it's from 2020 and no progress has been made on this. Poking around caniuse, it looks like Safari and Firefox have patchy support for similar behavior in web workers, either via partial support or behind flags. So I suppose there's hope, but I'm sorry if I got anyone's hope too far up :(

[0] https://caniuse.com/mdn-api_fetch_init_duplex_parameter [1] https://caniuse.com/mdn-api_request_duplex

Post reply on HN