!links2@lemmy.sdf.org

React is probably overkill for most simple sites. You could still use JavaScript for some cool stuff without needing all the libraries and frameworks

The dependency hell of JS is caused by React. It's an ironic turn because node gained popularity in part because it was one of the first to have a coupled package manager with a massive public contribution model, full of a billion packages that follow the unix philosophy of "everything should do only one thing, and do it well" Dependency hell would disappear if people stopped popularizing competing swiss army knives. It's made worse by people trying to mash these swiss army knives together just to improve portfolio.

We've gotten to the point where you aren't considered a real professional unless you start even the smallest projects with maximum technical debt.

It should never be impressive that you used a tool. If the tool made programming it easier then it's not a mental feat. If the tool made programming it harder, then people should think you are kind of slow for using a tool that made development harder. This is why brag culture over what tools are used makes no sense. Just use tools that make life easier. If it doesn't make life easier, stop using it.

And some super advanced LLM powered text compression so you can easily store a copy of 20% of them on your PC to share P2P.

Nothing can be that advanced and zstd is good enough.

The idea is cool. With pure p2p exchange being a fallback, and something like trackers in bittorrent being the main center to yield nodes per space (suppose, there's more than one such archive you'd want to replicate) and per partition (if it's too big, then maybe it would make sense, but then some of what I wrote further should be reconsidered).

The problem of torrents and other stuff is that people only store what's interesting to them.

If you have to store one humongous archive, and be able to efficiently search it, and avoid losing pieces - then, I think, you need partitioned roughly equal distribution of it over nodes.

The space of keys (suppose it's hashes of blocks of the whole) is partitioned by prefix so that a node would store equal amount of blocks of every prefix. And first of all the values closest to the node's identifier (a bit like in Kademlia) should be stored of those under that space. OK, I'm thinking the first sentence of this paragraph might even be unneeded.

The data itself should probably be in some supercool format where you don't need to have it all to decompress only the small part you need, just the beginning with the dictionary and some interval.

There should also be, as a separate functionality of this system, search by keywords inside intervals, so that search would yield intervals where a certain keyword is encountered. With nodes indexing continuous intervals they can decompress and responding to search requests by those keywords. Ideally a single block should be possible to decompress having the dictionary. I suppose I should do my reading on compression algorithms and formats.

Probably search function could also involve returning Google-like context. Depending on the space needed.

Would also need some way to reward contribution, that is, to pay a node owner for storing and serving blocks.