On libraries, Rust, and node_modules depression

Introduction

I am sure that I am not the only one that cringes at the size of every node_modules folder that I come across. Every frontend project somehow "needs" megabytes of dependencies. Even this very website, that avoids all types of frontend frameworks, is still plagued by a 100MB+ node_modules folder mostly to transpile some Typescript.

Even the backend of our work website (or web application, I guess), our main product, is filled with tons of PHP dependencies, and out of all of those I only know Laravel

And for what I can see online, this is the way for most serious projects. I always presumed that this was because of the high speed of development required in the web app development market, where re-inventing the wheel was simply too slow.
However, a series of episodes challenge this notion:

Part 1: node_modules depression

A few weeks back, our web development consultant (whose team set up our main website, since we are a truly tiny startup, which includes a grand total of 2 in-house developers) was working on data gathering for analytics, for which I had to provide some data.
Now, this wasn't happening in our mainline repository, this was happening in a small, separated web application that I manage, designed with only the bare minimum of dependencies (3D rendering with Three.js, and Typescript for my sanity).
We got in a call to look at what data needed to be sent, but at the end he was struggling to call the API. In this repository there is no "axios" library, so I had to walk through a "senior web developer" how to write a simple fetch().

The other knocks to my beliefs were a bunch of articles, old and new, that popped into my feed. The most relevant of the bunch is this one from all the way back in 2016 about the left-pad fiasco.

These two episodes made me start to think about "library abuse" in a more serious manner, compared to simply laughing at "node_modules big" memes.
It cannot possibly be the optimal option, long term, to have an entire library for such a simple task as a straight-forward POST call, right?
Is having a NPM package for 11 lines of code really necessary?

Part 2: Rust depression

After those episodes, I got to work on my personal project during end-of-year vacation

I am in the process of re-writing my hobby web server in Rust. Not just to brag to the world that I am, in fact, writing Rust, but mostly to improve my memory management skills from a life of managed, garbage-collected languages.
I purposefully chose to use as few libraries as possible, to familiarize myself with the core of the language.
My web server (which runs this very website! Not the Rust version yet tho, for reasons explained later) uses Lua for the couple of simple redirects that I sometimes set up on the back-end.
While writing the original backend implementation in C++, I was struggling with response times due to generating LUA VMs on the fly for every request. In C++, I fixed it by pre-loading all the registered LUA handlers, then fork()ing on requests, de-facto duplicating the pre-loaded LUA VM without having to go through initialization or parsing each time.*

So, while trying to recreate this in Rust, I was fairly surprised when I found no fork() in the standard library. Crap.
I found the first-party "libc" crate (which I guess it's not part of the standard library because of platforms like Windows?). This has an "unsafe" version of fork(). Crap x2.
I am rather new to Rust, so I don't know how to treat "unsafe" yet. Is it the reincarnation of regex? Is it fine to use for stuff like this? I am still not sure...

And my sadness goes deeper. There are no pipes in the standard library (or rather, they only seem to exist for stuff launched via std::process). Crap x3. Here I go wrapping unsafe libc calls again.
Named pipes? Nope. Timeouts for file read/write? Nope.

Am I off-base? Is this really that much to ask of a standard library? This is not a retorical question, I genuinely have no idea....
Looking on Google I found plenty of 3rd party crates implementing the various functionality that I am looking for, libraries often recommended to other people in search of my same solutions.

Part 3: Auto-depression (Self-depression? The regular kind, you get the idea...)

Playing devil's advocate against myself, however, all this worrying about crates is a bit strange, since I already have a 3rd party dependency: the LUA wrapper, or hell, even LUA itself is a dependency.
However however, I think that those things are not the same:

• - fork(), poll() and mkpipe() have been components of UNIX system programming for decades, part of the target UNIX system that my program CANNOT run without (And for non-UNIX platforms, there are most likely equivalent calls).
• - LUA is a functional dependency of my project, a choice I made that is not part of the target system, so even comparing to standard UNIX functions feels absurd.
• - The wrapper? I don't know. My "anti node_modules reflex" did not kick in when installing it, but reliably starts screaming at me when looking at libraries to possibly not having to wrap poll() myself, since it's all unsafe code that I still don't know how to handle properly.

So what the hell do I do now? I feel like I am missing something big. Am I making a mountain out of nothing? Did I find a small hole in the Rust standard library and got waaay to worked up about it? I still need to write all the IPC timeouts for my server, since I can't wait on pipes for a certain amount of time.
This library mess has stuck into my brain enough that I am writing this instead of writing the code that I want to write. So let me know what you think, what you would do, and how much of an idiot I am, if necessary.

Thank you for reading,
- John

Footnotes

• *: more info on why I did that here

I'm still very new to this "writing about development" thing, so if I said something hideously wrong, feel free to let me know.