"SlopDetector has detected 2 x seamlessly and 7 x em-dash, would you like to continue?"
fwiw i use em-dashes
Modern Node.js Patterns
171–180 of 448 posts
Re: Modern Node.js Patterns
#172Earlier quoted context omitted.
Agreed. It's surprising to see this sort of slop on the front page, but perhaps it's still worthwhile as a way to stimulate conversation in the comments here?
I have an increasing feeling of doom re: this. The forest is darkening, and quickly. Here, I'd hazard that 15% of front page posts in July couldn't pass a "avoids well-known LLM shibboleths" check. Yesterday night, about 30% of my TikTok for you page was racist and/or homophobic videos generated by Veo 3. Last year I thought it'd be beaten back by social convention. (i.e. if you could showed it was LLM output, it'd m…
There's just so many tells in this one though and they aren'tn new ones. Like a dozen+, besides just the entire writing style being one, permeating through every word.
I'm also pretty shocked how HNers don't seem to notice or care, IMO it makes it unreadable.
I'd write an article about this but all it'd do is make people avoid just those tells and I'm not sure if that's an improvement.
Re: Modern Node.js Patterns
#173Earlier quoted context omitted.
That's a category error. Fetch is just refers to making a request. POST is the method or the HTTP verb used when making the request. If you're really keen, you could roll your own const post = (url) => fetch(url, {method:"POST"})
I read this as OP commenting on the double meaning of the category. In English, “fetch” is a synonym of “GET”, so it’s silly that “fetch” as a category is independent of the HTTP method
That makes sense.
Re: Modern Node.js Patterns
#174Be honest. How much of this article did you write, and how much did ChatGPT write?
To the latter: Absolutely all of it, though I put my money on Claude, it has more of its prominent patterns.
Re: Modern Node.js Patterns
#175Earlier quoted context omitted.
Recently? In my experience ASP.NET 9 is vastly more productive and capable than Node.js. It has a nicer developer experience, it is faster to compile, faster to deploy, faster to start, serves responses faster, it has more "batteries included", etc, etc... What's the downside?
Compile speed and a subjective DX opinion are very debatable. The breadth of npm packages is a good reason to use node. It has basically everything.
It has terrible half-completed versions of everything, all of which are subtly incompatible with everything else.
I regularly see popular packages that are developed by essentially one person, or a tiny volunteer team that has priorities other than things working.
Something else I noticed is that NPM packages have little to no "foresight" or planning ahead... because they're simply an itch that someone needed to scratch. There's no cohesive vision or corporate plan as a driving force, so you get a random mish-mash of support, compatibility, lifecycle, support, etc...
That's fun, I suppose, if you enjoy a combinatorial explosion of choice and tinkering with compatibility shims all day instead of delivering boring stuff like "business value".
Re: Modern Node.js Patterns
#176Earlier 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…
lol, yes absolutely it's bananas. I wouldn't even consider myself in the JS world!
Re: Modern Node.js Patterns
#177Earlier quoted context omitted.
I always try to throw schema validation of some kind in API calls for any codebase I really need to be reliable. For prototypes I'll sometimes reach for tRPC. I don't like the level of magic it adds for a production app, but it is really quick to prototype with and we all just use RPC calls anyway. For procudtion I'm most comfortable with zod, but there are quite a few good options. I'll have a fetchApi or similar wr…
How do you supply the schema on the other side? I found that keeping the frontend & backend in sync was a challenge so I wrote a script that reads the schemas from the backend and generated an API file in the frontend.
Write them both in TypeScript and have both the request and response shapes defined as schemas for each API endpoint.
The server validates request bodies and produces responses that match the type signature of the response schema.
The client code has an API where it takes the request body as its input shape. And the client can even validate the server responses to ensure they match the contract.
It’s pretty beautiful in practice as you make one change to the API to say rename a field, and you immediately get all the points of use flagged as type errors.
Re: Modern Node.js Patterns
#178Earlier quoted context omitted.
If you haven't tried vitest I highly recommend giving it a go. It is compatible with `jest-extended` and most of the jest matcher libraries out there.
I've heard it recommended; other than speed, what does it have to offer? I'm not too worried about shaving off half-a-second off of my personal projects' 5-second test run :P
Jest is just not modern, it can't handle modern async/ESM/etc. out of the box. Everything just works in Vitest.
Re: Modern Node.js Patterns
#179The 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.
There has to be something wrong with a tech stack (Node + Lambda) that adds 100ms latency for some requests, just to gain the capability [1] to send out HTTP requests within an environment that almost entirely communicates via HTTP requests.
[1] convenient capability - otherwise you'd use XMLHttpRequest
Re: Modern Node.js Patterns
#180Earlier quoted context omitted.
I always try to throw schema validation of some kind in API calls for any codebase I really need to be reliable. For prototypes I'll sometimes reach for tRPC. I don't like the level of magic it adds for a production app, but it is really quick to prototype with and we all just use RPC calls anyway. For procudtion I'm most comfortable with zod, but there are quite a few good options. I'll have a fetchApi or similar wr…
How do you supply the schema on the other side? I found that keeping the frontend & backend in sync was a challenge so I wrote a script that reads the schemas from the backend and generated an API file in the frontend.
I'll almost always lean on separate packages for any shared logic like that (at least if I can use the same language on both ends).
For JS/TS, I'll have a shared models package that just defines the schemas and types for any requests and responses that both the backend and frontend are concerned with. I can also define migrations there if model migrations are needed for persistence or caching layers.
It takes a bit more effort, but I find it nicer to own the setup myself and know exactly how it works rather than trusting a tool to wire all that up for me, usually in some kind of build step or transpiration.