If cron is broken for you, than the logic solution would be to replace it with something that does work for you. But do so at the right place and abstraction. That's hardly ever the runtime or in the app.

Do One Thing (and do it well).

A special domain specific scheduler microservice? One of the many Cron replacements? One of the many "SaaS cron"? Systemd?

This problem has been solved. Corner cases ironed out. Free to use.

Same for ENV var as configurations (as opposed to inventing yet another config solution), file permissions, monitoring, networking, sandboxing, chrooting etc. the amount of broken, insecure or just inefficient DIY versions of stuff handled in an OS I've had to work around is mind boggling. Causing a trice a loss: the time taken to build it. That time not spent on the business domain, and the time to them maintain and debug it for the next fifteen years.

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

This is what process' mount namespace is for. Various container implementations use it. With modern Linux you don't even need a third-party container manager, systemd-nspawn comes with the system and should be able to do that.

The problem with the "solutions" s.a. the one in Node.js is that Node.js doesn't get to decide how eg. domain names are resolved. So, it's easy to fool it to allow or to deny access to something the author didn't intend for it.

Historically, we (the computer users) decided that operating system is responsible for domain name resolution. It's possible that today it does that poorly, but, in principle we want the world to be such that OS takes care of DNS, not individual programs. From administrator perspective, it spares the administrator the need to learn the capabilities, the limitations and the syntax of every program that wants to do something like that.

It's actually very similar thing with logs. From administrator perspective, logs should always go to stderr. Programs that try to circumvent this rule and put them in separate files / send them into sockets etc. are a real sore spot of any administrator who'd spent some times doing his/her job.

Same thing with namespacing. Just let Linux do its job. No need for this duplication in individual programs / runtimes.

"Any program you can run". But you should not run any program as YOU. Programs can run as separate limited user.

You need FreeBSD's Capsicum in your life. It's like what you describe.

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

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

OpenBSD pledge

https://man.openbsd.org/pledge.2

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 or script outside of the projects codebase to then load these files into the env.

In a team setting, it can be extremely helpful to have env/config loading logic built into the repo itself. It does not mean it has be loaded by the application process, but it can be part of the surrounding tooling that is part of your codebase.

If something is solved at the OS level it probably needs to vary by OS. Just like how an application layer solution to parsing data must vary slightly between nodeJS and java.

For a solution to be truly generic to OS, it's likely better done at the network level. Like by putting your traffic through a proxy that only allows traffic to certain whitelisted / blacklisted destinations.

Why would a desktop program need these sort of restrictions?

OK, I'll bite. Do you think Node.js implementation is aware of DNS search path? (My guess would be that it's unaware with 90% certainty).

If you don't know what DNS search path is, here's my informal explanation: your application may request to connect to foo.bar.com or to bar.com, and if your /etc/resolv.conf contains "search foo", then these two requests are the same request.

This is an important feature of corporate networks because it allows macro administrative actions, temporary failover solutions etc. But, if a program is configured with Node.js without understanding this feature, none of these operations will be possible.

From my perspective, as someone who has to perform ops / administrative tasks, I would hate it if someone used these Node.js features. They would get in the way and cause problems because they are toys, not a real thing. Application cannot deal with DNS in a non-toy way. It's the task for the system.

My experience with DevOps has been they know a lot about deploying and securing Java, or Kotlin, or Python but they know scant about node js and its tooling and often refuse to learn the ecosystem

This leads to the node js teams to have to learn DevOps anyway because the DevOps teams do a subpar job with it otherwise.

Same with doing frontend builds and such. In other languages I’ve noticed (particularly Java / Kotlin) DevOps teams maintain the build tools and configurations around it for the most part. The same has not been true for the node ecosystem, whether it’s backend or Frontend

Wouldn't "simplifying" or even awareness of the existence of such OS features be a much better solution than re-building it in a runtime?

If an existing feature is used too little, then I'm not sure if rebuilding it elsewhere is the proper solution. Unless the existing feature is in a fundamentally wrong place. Which this isn't: the OS is probably the only right place for access permissions.

An obvious solution would be education. Teach people how to use docker mounts right. How to use chroot. How Linux' chmod and chown work. Or provide modern and usable alternatives to those.

Nope, they don't add. They confuse. From administrator perspective, it sucks when the same conceptual configuration can be performed in many different places using different configuration languages, governed by different upgrade policies, owned by unintended users, logged into unintended places.

Also, I'd bet my monthly salary on that Node.js implementation of this feature doesn't take into account multiple possible corner cases and configurations that are possible on the system level. In particular, I'd be concerned about DNS search path, which I think would be hard to get right in userspace application. Also, what happens with /etc/hosts?

From administrator perspective I don't want applications to add another (broken) level of manipulating of discovery protocol. It usually very time consuming and labor intensive task to figure out why two applications which are meant to connect aren't. If you keep randomly adding more variables to this problem, you are guaranteed to have a bad time.

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)

Not necessarily, in selinux for example you would configure a domain for the "main process" which can transition into a lower permission domain for "app" code.

Even that doesn't protect you from bind mounts. The rationale seems to be that only root can create bind mounts. But guess what, unprivileged users can also create all sorts of crazy mounts with fuse.

The whole idea of a hierarchical directory structure is an illusion. There can be all sorts of cross-links and even circular references.

So security theatre is the best option? I'm not saying this to be cheeky, but it just seems to be an overly shallow option that is trivially easy to end run.

Node allows native addons in packages via the N-API so any native module aren't restricted by those permissions. Deno deals with this via --allow-ffi but these experimental Node permissions have nothing to disable the N-API, they just restrict the Node standard library.

Insane but worked well. At least we could get download progress.

  const supportsRequestStreams = (() => {
    let duplexAccessed = false;
  
    const hasContentType = new Request('http://localhost', {
      body: new ReadableStream(),
      method: 'POST',
      get duplex() {
        duplexAccessed = true;
        return 'half';
      },
    }).headers.has('Content-Type');
  
    return duplexAccessed && !hasContentType;
  })();

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/orpc

Do you need an LLM for this? I've made my own in-house fork of a Java library without any LLM help. I needed apache.poi's excel handler to stream, which poi only supports in one direction. Someone had written a poi-compatible library that streamed in the other direction, but it had dependencies incompatible with mine. So I made my own fork with dependencies that worked for me. That got me out of mvn dependency hell.

Of course I'd rather not maintain my own fork of something that always should have been part of poi, but this was better than maintaining an impossible mix of dependencies.

nvm I'm dumb lol, `ts-rest` does support express v5: https://github.com/ts-rest/ts-rest/pull/786. Don't listen to my misinformation above!!

I would say this oversight was a blessing in disguise though, I really do appreciate minimizing dependencies. If I could go back in time knowing what I know now, I still would've gone down the same path.

Agreed. Hono has been great for my usage, and very portable.

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 wrapper call that takes in the schema + fetch() params and validates the response.

Effect provides a pretty good engine for compile-time schema validation that can be composed with various fetching and processing pipelines, with sensible error handling for cases when external data fails to comply with the schema or when network request fails.

The schema definition is more efficient than writing input validation from scratch anyway so it’s completely win/win unless you want to throw caution to the wind and not do any validation

Agreed, but I think that in every project I've done I've put at least a minimal wrapper function around axios or fetch - so adding a teeny bit more to make fetch nicer feels like tomayto-tomahto to me.

You’re shooting yourself in the foot if you put naked fetch calls all over the place in your own client SDK though. Or at least going to extra trouble for no benefit

why don't they just set those as options

{ throwNotOk, parseJson }

they know that's 99% of fetch calls, i do t see why it can't be baked in.

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.

You don't need all those parens:

  await fetch(url).then(r => r.json())

why not?

    const data = await (await fetch(url)).json()

    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!");

    var data = await fetch(url).then(r => r.json());

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.

On init lambda funcs run a full core, but on invoke the 128MB run at 1/20 core.

Totally get that! I think it depends on your context. For Lambda where every KB and millisecond counts, native fetch wins, but for a full app where you need robust HTTP handling, the axios plugin ecosystem was honestly pretty nice. The fragmentation with fetch libraries is real. You end up evaluating 5 different retry packages instead of just grabbing axios-retry.

Sounds like there's space for an axios-like library built on top of fetch.

AI is going to bring that back like an 80s disco playing Wham. If you gonna do it do it wrong...

isn't upgrading node going to ba bigger challenge? (if you're on a node version that's no longer receiving maintenance)

No? Its last update was 12 days ago

I'm a small-ish time author, but it was really painful for a while since we were all dual-publishing in CJS and ESM, which was a mess. At some point some prominent authors decided to go full-ESM, and basically many of us followed suit.

The fetch() change has been big only for the libraries that did need HTTP requests, otherwise it hasn't been such a huge change. Even in those it's been mostly removing some dependencies, which in a couple of cases resulted in me reducing the library size by 90%, but this is still Node.js where that isn't such a huge deal as it'd have been on the frontend.

Now there's an unresolved one, which is the Node.js streams vs WebStreams, and that is currently a HUGE mess. It's a complex topic on its own, but it's made a lot more complex by having two different streaming standards that are hard to match.

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.

I maintain a library also, and the shift to ESM was incredibly painful, because you still have to ship CJS, only now you have work out how to write the code in a way that can be bundled either way, can be tested, etc etc.

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

I was thinking server-side where it's probably 90%+ POST. True, client-side a lot different (node the only player client-side, though).

It's into core but not exposed to users directly. you still need to install the npm module if you want to use it, which is required if you need for example to go through an outgoing proxy in your production environment

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

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 to libraries to cure their emotional fear of uncertainty. For really large problems, like complete terminal emulation, I understand that. However, when taken to an extreme, like the left pad debacle, it’s clear people are loading up on dependencies for irrational reasons.

It depends on the audience / environment where your app is used. Public, a library is better. Internal / defined company environment, you don't need extra dependencies (but only when it comes to such simple solutions, that could be replaced easy with a lib).

Arguably, using a library is also "copy it into every project".

Nice browser add-on https://johannhof.github.io/emoji-helper/

Why would you call that "ascii.txt"?

   cjk→⋰⋱| | ← cjk space btw | |
   thinsp | |
   deg° 
   ⋯ …
   ‾⎻⎼⎽ lines
   _ light lines
   ⏤ wide lines
   ↕
   ∧∨ 
 ┌────┬────┐ 
 │    │ ⋱  ⎸ ← left bar, right bar: ⎹
 └────┴────┘
    ⊃⊂ ⊐≣⊏
    ⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯⎯====›‥‥‥‥

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

> but Llms write it anyway

The problem isn't in the writing, but the reading!

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

Last time I tried it, IDE integration (e.g. Test Explorer in VSCode) was lacking compared to Jest.

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

It's not insane at all. Any binary that gets packed with the entire runtime will be in MBs. But that's the point, the end user downloads a standalone fragment and doesn't need to give a flying fuck about what kind of garbage has to be preinstalled for the damn binary to work. You think people care if a binary is 5MB or 50MB in 2025? It's more insane that you think it's insane than it is actually insane. Reminds me of all the Membros and Perfbros crying about Electron apps and meanwhile these things going brrrrrrr with 100MB+ binaries and 1GB+ eaten memory on untold millions of average computers

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

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

Considering that you are bundling an entire runtime not meant to be installed independently on other computers, 67mb isn't that bad.

Go binaries weight 20mb for example.

lol, yes absolutely it's bananas. I wouldn't even consider myself in the JS world!

Same, but, I'm struggling with the idea that even if I learn things I haven't before, at the limit, it'd be annoying if we gave writing like this a free pass continuously - I'd argue filtered might not be the right word - I'd be fine with net reduction. Theres something bad about adding fluff (how many game changers were there?)

An alternative framing I've been thinking about is, there's clearly something bad when you leave in the bits that obviously lower signal to noise ratio for all readers.

Then throw in the account being new, and, well, I hope it's not a harbinger.*

* It is and it's too late.

Cheers, it's gotta be the "I see this every day for hours" thing - I have a hard time mentioning it because there's a bunch of people who would like to think they have similar experience and yet don't see the same tells. But for real, I've been on these 8+ hours a day for 2 years now.

And it sounds like you have the same surreal experience as me...it's so blindingly. obvious. that the only odd thing is people not mentioning it.

And the tells are so tough, like, I wanted to a bang a drum over and over again 6 weeks ago about the "It's not X-it's Y" thing, I thought it was a GPT-4.1 tell.

Then I found this under-publicized gent doing God's work: ton of benchmarks, one of them being "Not X, but Y" slop and it turned out there was 40+ models ahead of it, including Gemini (expected, crap machine IMHO), and Claude, and I never would have guessed the Claudes. https://x.com/sam_paech/status/1950343925270794323

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.

i am desperately awaiting the butlerian jihad ;_;

Excellent update! Thanks!

Oh, I agree.

I have to admit I was a bit surprised when I was suddenly expected to get rid of all extensions in import. Sure, looks clean, but is it right?

Both are very common Typescript patterns.

Maybe there's an idea in here, a website that shows you all release notes since the last time you've used something, removing those that have been superseeded by later ones, ranked by importance.

Or YavaScript https://github.com/suchipi/yavascript

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

I've found that a lot of logging frameworks and patterns will not include cause which can absolutely fuck debugging

> Hasn't AsyncIterator been available in Node for several years? I used it extensively—I want to say—around 3 years ago.

Yes. It's been around and relatively stable in V8/Node.js for years now.

You don't know if the author knows what they're talking about with or without AI in the picture.

I think we have enough node developers here to know its truthfulness.

> If anything bun proves that both worlds can go together despite what proponents of web standards says

Sure, but Bun's implementation is a confusing mess a lot of times. I prefer them separate.

Note: This is no shade toward Bun. I'm a fan of Bun and the innovative spirit of the team behind it.

`import * as` is still treeshakeable and Browsers will do it in-memory as the imports form weak proxies.

Bundlers can treeshake it, it is just harder to do, and so it hasn't always been a priority feature. esbuild especially in the last few years has done a lot of work to treeshake `import * as` in many more scenarios than before. Sure it isn't treeshaking "all" scenarios yet, but it's still getting better.

There's also many successful multi-natioksl banks built off of Cobalt.

Cobalt was a mistake.

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?

> You can bundle it all into one file

This is the first I'm hearing of this, and a quick Google search found me a bunch of conflicting "methods" just within the NestJS ecosystem, and no clear indication of which one actually works.

    nest build --webpack
    nest build --builder=webpack

... and of course I get errors with both of those that I don't get with a plain "nest build". (The error also helpfully specifies only the directory in the source, not the filename! Wtf?)

Is this because NestJS is a "squishy scripting system" designed for hobbyists that edit API controller scripts live on the production server, and this is the first time that it has been actually built, or... is it because webpack has some obscure compatibility issue with a package?

... or is it because I have the "wrong" hieroglyphics in some Typescript config file?

Who knows!

> There's this thing called worker_threads.

Which are not even remotely the same as the .NET runtime and ASP.NET, which have a symmetric threading model where requests are handled on a thread pool by default. Node.js allows "special" computations to be offloaded to workers, but not HTTP requests. These worker threads can only communicate with the main thread through byte buffers!

In .NET land I can simply use a concurrent dictionary or any similar shared data structure... and it just works. Heck, I can process a single IEnumerable, list, or array using parallel workers trivially.

Perhaps you're confusing it with something else? I tried down to Node 8 (2017) and the behavior is still the same.

Maybe a bug in userspace promises like Bluebird? Or an older Node where promises were still experimental?

I love a good mystery!

    const p1 = makeP1();
    const p2 = makeP2();

    return await Promise.all([p1, p2]);

Oops, thanks! Should've seen the default handler anyways if it was really uncaught.

Yes, that's it. I don't want a cute runtime, I want a boring and reliable one.

Deno has a cute mascot, but everything else about it says "trust me, I'm not exciting". Ryan Dahl himself also brings an "I've done his before" pedigree.

right, those transformations are a little too tricky for a codemod, but definitely still mechanical enough for LLMs to chug through is my guess.

ESM is literally a standard. You can rant all you want, but you'll adopt it anyway.

Isn't that exactly the syntax being recommended? Could you explain what exactly in the article is a solution in search of a problem?

Did you read the article? Your comments feel entirely disconnected from its contents - mostly low level piece or things that can replace libraries you probably used anyway

I think there are several reasons. First, the abstraction of a stream of data is useful when a program does more than process a single realtime loop. For example, adding a timeout to a stream of data, switching from one stream processor to another, splitting a stream into two streams or joining two streams into one, and generally all of the patterns that one finds in the Observable pattern, in unix pipes, and more generally event based systems, are modelled better in push and pull based streams than they are in a real time tight loop. Second, for the same reason that looping through an array using map or forEach methods is often favored over a for loop and for loops are often favored over while loops and while loops are favored over goto statements. Which is that it reduces the amount of human managed control flow bookkeeping, which is precisely where humans tend to introduce logic errors. And lastly, because it almost always takes less human effort to write and maintain stream processing code than it does to write and maintain a real time loop against a buffer.

Hopefully this helps! :D

Streams have backpressure, making it possible for downstream to tell upstream to throttle their streaming. This avoids many issues related to queuing theory.

That also happens automatically, it is abstracted away from the users of streams.

A stream is not necessarily always better than an array, of course it depends on the situation. They are different things. But if you find yourself with a flow of data that you don't want to buffer entirely in memory before you process it and send it elsewhere, a stream-like abstraction can be very helpful.

Why is an array better than pointer arithmetic and manually managing memory? Because it's a higher level abstraction that frees you from the low level plumbing and gives you new ways to think and code.

Streams can be piped, split, joined etc. You can do all these things with arrays but you'll be doing a lot of bookkeeping yourself. Also streams have backpressure signalling