I hate almost all software (2011)
tinyclouds.org
tinyclouds.org
It's quite amazing that we've put layer after layer of leaky abstractions on top of each other and managed to make systems that mostly work.
I don't hate all the software. I think it's awesome. It can be hell to develop, though.
>>> The Programmer-Archaeologist churns through this maddening nest of ancient languages and hidden/forgotten tools to repair existing programs or to find odd things that can be turned to unanticipated uses. - lambda-the-ultimate.org
At the time, I was a freshman in college studying "Classics" - dead languages and history, like Latin and Ancient Greek.
I dropped out that same year, flabbergasted and excited that I could experience the same archeological thrill on a much shorter time scale. All I needed to learn was some system engineering...
So I did that. Been here ever since, loving every day that I got to make some beautiful jank soup of software work for another epoch.
P.S. I was on the IRC server trying to pirate some music and textbooks I couldn't afford to buy. Wound up gainfully employed throughout my 20s, able to retire in my 30s (programmer / data archeology pays well)
One was to dig through a system that was built a decade ago and modernize it. I just wrapped that up. The end result has eliminated multiple points of failure and unnecessary process, and has enabled my team to completely own the solution end to end.
The other task is to dig into and modernize a system that was originally started over 2 decades ago. I've got some other, minor tasks to get through this month and next and am excited to get onto this next task around August.
I'm ~20 years into this career and I am have more fun in the job today than I ever have before.
It was live history working in my hands and in a usable way after Euclid and Newton.
No need to buy hardware and materials to do technical stuff, a computer was enough. And not even a good one. My cwm+tmux setup would still work in a Pentium 2.
I can only imagine the people working on the actual chips are screaming in silence somewhere at the complete waste of energy we've made.
The old canard that programmer time was worth more than processing time that bad coders quote is less and less true by the year; SWEs who are able to wring better performance out of less hardware resources are going to become more valuable in the future.
As much as I'd like for this prediction to come true, I think it's wishful thinking. Compute capacity continues to increase exponentially while (human) cognitive resources, for all practical purposes, do not, which means less efficient code will continue to be the more economically viable option as far as I can tell.
Even with AI, where we're essentially trading compute (used for running code) for extended cognitive resources (used for writing code), what incentive exists to channel those resources into writing faster code rather than writing the same code faster?
https://www.st.com/resource/en/errata_sheet/es0182-stm32f405... https://www.nxp.com/docs/en/errata/IMXRT1170CE.pdf https://www.nxp.com/docs/en/errata/IMX8_1N94W.pdf
As a dev, this bothers me a great deal. We have miracle machines on our desks and in our pockets, and 80% of the capabilities of that hardware are pissed away by terribly inefficient software.
Some of the experiences are downright magical like being able to copy something from my MacBook and paste it on my phone.
Software is just buggy in general. I mostly agree with the parent comment. The amount of software that I've never had a negative experience with is close to zero.
The ctrl key randomly stops working, tested by pressing ctrl-C at random intervals. Sometimes it's perfect, sometimes not.
I worry about complacency with overcomplexity and over-reliance on software, and our fast-growing trigger finger to automate everything....
Personal responsibility and training backed by a human touch will not be beat by code any time soon in my opinion. Citing that code is almost always deeply influenced if not forged and maintained by human hands, any credible singularity is far from our currently over-marketed Ai reality at the moment in my opinion as well... Google can't even get it's assistant and spell check to work properly, and they've been one of the largest companies on the block for decades now.
I have seen too much software to ever trust software with an automobile.
Automobile is as broken as software and hardware.
Things will start falling apart one day.
Is there a hidden assumption in "unnecessary"? None of the tech unfolded in a deliberate, methodical manner. It was random people doing various things over time and a plethora of details.
To assume that the aggregate would have a tidy structure seems unrealistic.
And much goes into RFCs.
But is there much internet-wide engineering going on to squeeze out the entropy?
Repackaged: the engineering that occurs is more bottom-up than top-down. Google, for example, has enough heft to say: "QUIC: here is a bit of top-down engineering." But that example bolsters my general point, in my opinion.
The problem is that they're not layers of abstraction, they're just layers.
An actual layer of abstraction should allow you to replace or combine the lower layers. But we just have layers without abstractions.
It just barely hangs together enough to sort of function most of the time.
I'm just saying the remaining 10% can be pretty impressive considering the complexity and cruft developers deal with to make it.
Software that fully works is too expensive to build.
But the end users got screwed. We forgot about consent, from "yes/maybe later" options, to obligatory apps, and shrinking features. Then offline applications became unfashionable, and now every action takes two seconds. The final nail is suicidal monetization, like seemingly every game publisher, Google Maps, Twitter, and recently Reddit.
I found https://handmade.network/ a breath of fresh air, but so far it's been too little, too late.
Here's to the next 12 years.
When you installed an app, it usually just went in a folder. Sometimes it was just one file. There wasn't a mass of dependencies and complex systems to manage them. Just some libraries built into the system.
Modern macOS is a bit like that too, except it has all the unix under there too, so there's a mess of files all over the place. There are many files hidden from the user (which the user wouldn't understand anyway). Whereas classic macOS had a beautiful simplicity where you clicked on the system folder and there was Finder and other things which were at least somewhat understandable to me as a kid.
I had Strata 3D, which I got with an educational discount. That was the software used to make Myst. Our Quadra 700 only had 8mb of RAM and I was trying to render a spaceship flying through mountains on a distant planet. I managed to replace the Finder with Strata (using RezEdit) and boot into Strata. The machine would crash if I clicked on the apple menu, but this got me a bit more RAM.
Anyway, something like NixOS addresses the flaws of Unix package management, but it requires quite some complex machinery to do so. AFAIK, we didn't have the versionitis issues on classic macOS, but again, I was just a kid. It was a simpler time.
Look at the demoscene for an example of the exact opposite culture.
With the rise of the Web/Mobile computing things have gotten exponentially worse. And i don't even want to think about where we are headed with AI/ML.
And not much has changed since then.
Previous discussion:
I hate almost all software (2011) - https://news.ycombinator.com/item?id=28181632 - Aug 2021 (247 comments)
I hate almost all software (2011) - https://news.ycombinator.com/item?id=15142316 - Aug 2017 (8 comments)
I hate almost all software (2011) - https://news.ycombinator.com/item?id=13586596 - Feb 2017 (144 comments)
I hate almost all software. (2011) - https://news.ycombinator.com/item?id=10553408 - Nov 2015 (2 comments)
“I hate almost all software” — Ryan Dahl - https://news.ycombinator.com/item?id=3055154 - Sept 2011 (292 comments)
But then you start buying screws and realize the entire screw isle at building supply store is bigger than many small grocers. And probably isn't complete. Heaven help you if you want to do something aesthetically pleasing like a pocket door.
Or, far worse, heaven help you if you want to fix a pocket door. Finding a compatible wheel mechanism is usually most easily done with, "rip it out and use a new mechanism."
Then there is car maintenance. Check engine light says something about the eco subsystem isn't working right? Here is a book mechanics use that list the common reasons for the code. Not standard across makes. Or models, even...
I could probably go on. Point is nothing is greenfield lacking in complexity. I agree we probably could do better with software. But having done embedded work, I think it is easy to be ignorant of exactly how much has to coordinate in a computer system.
This is the idea that people who have learned one thing discount the knowledge of experts in other domains.
Nothing can be as fantastically complicated as my own work, surely! Building a house is just nailing a few sticks together. Fixing a car is just undoing a bolt with a spanner. Running a farm is just driving around on a tractor.
That kind of troubleshooting is about as software as it gets.
Was it what any of the mechanics I talked to thought it was? Nope! Did anyone carry the part, or was anyone even able to identify the correct part number, even with a diagram? Nope! Did I have to hunt all over for some marine fuel line that happened to have the same inside diameter so that I could jury-rig a new part? Yep!
Diagnosis and repair actually felt a bit like working with third party libraries: all the documentation is wrong, the problem is never your first guess, and you end up rolling your own solution in the end.
Quickly slapping some Vaseline on the has cap gasket has worked in my Ford.
A couple of German cars later, that CEL is always much much more expensive.
And the pipes/hoses! Having your software update cause your server to fail is _absolute joy_ compared to discovering that your improperly rated pipe burst and is how dumping gallons of water on the ground.
And most software ppl are quite useless at group formation and maintenance, hence the perpetual drama and tantrums.
I mean, sometimes software development is enjoyable as an end in itself, otherwise Shenzhen I/O wouldn't be a thing.
That said, it's a lot more enjoyable when the blocks you're building with are nice self-contained things that work well together like LEGO bricks. As opposed to a bunch of double-clawed hammers that are all invisibly connected with strings under the floor so that when you try to pick one up your drill automagically turns on as it falls off the shelf (I am borrowing some PHP-fractal-of-bad-design metaphor but it applies just as well to Spring Boot or whatever-the-f&^& somebody with too much time on their hands thinks is fun to inflict on me).
Abstractions are great so long as they don't leak. But software development seems to have become the art of not going insane while trying to maintain castles in the sky that are oozing spaghetti sauce from every crack.
So anyway, I agree with the author, but maybe for slightly different reasons.
But to be the devils advocate here, the unix abstraction is only beautiful if your living in a single process, single user, teletype environment. Add multiple users, network programming, multiple processes/threads, async IO, etc, etc, etc. and the whole thing starts to look like the layered monstrosity full of edge states, and broken promises the author is arguing against.
Although frankly, there aren't many better choices. NT being nearly 3 decades newer and with the forethought of VMS is actually much better at a systems programming level but you have to be willing to dedicate significantly more effort upfront to understand the more complex task/io/user/permissions model. In the end there is probably less of a learning curve on windows, but its steeper because you end up having to learn how to do all this stuff on the various *nix clones as well, just using bolt on interfaces that frequently vary slightly between the different flavors.
In a way this applies to much of the windows ecosystem now that vb6/delphi aren't popular and the similar attempts at web co-design utilities have largely died.
The problem is, for most users, to have a decent experience you need... COMPLEXITY.
See, there are roughly two groups of people when it comes to computers:
* Real Human Beings. Your mom. Your sister. The CEO of the company you work for. People who have real needs that computers might help with, but don't want to futz with them to get them working.
* Lizard People. People who love programming and don't mind futzing with a computer or its software. It's an open secret that they're not really human because it's all over the marketing. When Ubuntu called itself "Linux for humans" they were a) trying to assure their customer base that theirs was not a scary product intended for Lizard People; b) lying. Unix is a Lizard Person OS. Apple, who had already invented and perfected[0] the Real Human OS, did more or less the same to Unix by adding layers of complexity, but even then some of the ancient Lizard Person tech shows through.
If you like building pipelines to process data, you are a Lizard Person.
If you are concerned about how much resources a program is taking, you are a Lizard Person. If you hate that all this memory and CPU time is being WASTED to do something you could do with a couple of Unix commands, you are a Lizard Person. Real Humans may notice when their computer is slow; if it's a persistent problem they throw it away and go down to Best Buy to buy a new one.
Do you see what I'm getting at? Most users are not computer literate, don't value becoming so, and get scared when they see the ancient underpinnings of Lizard Person technology. So in order for them to have a good experience, hiding the details, automating pain points like configuration, and putting a nice friendly face and good presentation on everything is an absolute MUST. That requires engineering complexity and layers of software working together. They are TABLE STAKES for a good experience. So while I find myself quoting Ryan Dahl an awful lot about the experience of users, I think 99% of the time I mean the exact opposite of what he means.
[0] No, shut up. The Xerox Star sucked, and Smalltalk was a propaganda tool for indoctrination into the Lizard Person way of life. Inasmuch as computers are usable by Real Humans, the fact that they are so is an Apple invention entirely.
Now there's 40. Each one needs it's own networking library. 8 different kinds of databases - with each language needing it's own adapter. 5 different web frameworks for each one. 3 different json libaries.
It's a classic cartesian product. And instead of "I'll help fill in the gaps", its "I'll solve the problem by writing a new language!" -- which just makes the cartesian product bigger.
I personally wouldn't want to live in a world in which I could only use "one of these 5 languages", whatever those are. But I would love to live in a world where things weren't so deep in abstraction and complexity. These are two very different problems.
One aspect is that it would make an interesting situation at the borders between states. And that's kinda sorta what we have now with programming languages.
> Stuff on top of stuff on top of stuff.
Couldn't that also be too many choices? Like if you specialize in JS instead of C, you're not going to have all the knowledge a C expert might know. Instead of utilizing proven, existing C libraries, you're going to write stuff from scratch in JS?
If everyone uses the "proven" libraries and languages and whatever we'll have no innovation. I don't want to live in a rigid world where we somehow ended up choosing a set of things and nobody uses anything else; I want to see more software written in weird languages. Arguments that go like "but nobody is gonna learn a whole language to contribute to your stuff" are depressing - if it's good, I, like many others, would. Without experiments like these we'd still be in the 60s using COBOL because it's "industry proven" or "battle tested" or "blazingly fast" or whatever. That world is boring.
This is Hacker News after all.
What absolutely shatters us is that we almost never have enduring & exposed bases. Software is endless layers of abstraction reaching upwards. Very few layers expose themselves at all. So we are all strangers to most software.
For software to be simple elegant & minimal, we would have to be able to deploy existing knowledge, be able to leverage the fundamentals we know. But that's not where we are, but we are all adrift:
> In the past year I think I have finally come to understand the ideals of Unix: file descriptors and processes orchestrated with C. It's a beautiful idea. This is not however what we interact with.
Isn't the user experience subjective though? For example, to solve the problem of sending an email, all one needs is a set of commands on a terminal. I love this approach, but would this qualify as solving the problem in a way that meets the user experience criterion?
I agree with the thesis of the post, though.
That's kind of the point, software encapsulates a process so you don't have to do it.
In 2011, we didn't have SSDs(Or at least I sure didn't) compilers were not as good, and people said "Premature optimization is the root of all evil" way too much.
I'm willing to tolerate just about any amount of complexity if it's well factored, reliable, performance, and the abstractions aren't leaky.
Even for very small tasks... Because chances are, if I'm bothering to use software for a small task, it's because it's something I do every day and it's fairly important.
If it drags in 10 million lines of code from 1000 devs to make sure my notes app syncs reliably without manual intervention.... then that's fine. Almost all hardware still in use seems to be fast enough.
We have built amazing things with software. The only thing I don't like is that the FOSS scence has a tendancy to be less innovative and more Kackzynki, and all the cool stuff is proprietary cloudware.
That, and that things are getting harder and harder to develop. Not even because the languages or APIs are hard, those are amazing these days, it's that you have 50 layers of DevOps nightmare time with Docker to get a hello world running because everything is microservicy, and developers have a high amount of tolerance for manual setup, and programmers really think it's worth breaking a whole ecosystem just to rename a function.
"Getting started with X" used to be a half a page, now it's 5 pages.
I have a lot more complaints about hardware than software. Almost everything has a few missing things that would only cost a few dollars to add. Limiting charging to 80% to save battery, reporting status on Bluetooth, a tiny metal ring to protect the plastic bit that wears, a cheap molded case instead of sharp sheet metal that collects dents...
I have one disagreement with this... There is another thing that matters in software --- the experience of the developer making it.
IMHO, I agree that libraries, languages, tooling,... etc. are not art whose complexity should be admired. But they are a necessary intermediate tool for _developers_ to make their work easier.
We can apply the same logic to something like construction. You can build a house with hand tools and man power, just like you can write code in machine language. It's not enjoyable but you can do it. The work around developer tooling is like a builder working with scaffolding, an excavator, a crane, an electric drill... You spend effort to set it up, and before the final product is delivered, you have to tear it down. But it was still worth it because it serviced the developer in some transient way.
[1] Whenever I hear that word, I think "is that the best adjective you can come up with to convince people to use it?" because it often has no other advantages.
FWIW, I'd probably be considered a JavaScript luddite these days lol. When I build my own projects, I write vanilla ES5 (yes, 5). No tooling. No frameworks. No compiler. Just edit and hit refresh.
But when I work with others I will respect their choice of framework. Because the goal of frameworks and libraries and encapsulation in general is to trade-off extra individual work in exchange for smoother between-developer "compatibility" (reduced communication friction). I don't need to understand someone else's code, and neither do they need to for mine.
I don't understand this take. Client-side JavaScript is hard because of cross-browser / cross-platform / cross-device challenges. Server-side JavaScript is hard because of the nature of the language and the runtimes, the lack of standard library and the myriad attempts to "fix" it, ranging from inventing new languages to transpilers to runtime rewrites.
May be you mean to say, a lot of complexity could have been avoided? Unfortunately, that ship has sailed.
Is it really? Or is it hard because people are under the impression that it's hard and thus jump into the quagmire of others "selling" grossly overcomplicated "solutions" hoping it'll be easier (when in fact it isn't)?
When I can replace something that a team of about a dozen needed several months to create using a few MB of frameworks that work only in the latest version of Chrome and somehow needs multiple seconds to load over a gigabit LAN (internal tool) with an HTML form and a few lines of JS written in an afternoon that will work in any browser newer than ~IE5 (and will mostly work even without JS at all), I don't think that's the answer.
I don't understand this take.
As the saying goes, "It is hard to get a man to understand something when his salary depends on him not understanding it."
I think that's ultimately what it comes down to: Developers justifying their existence. They're all enamored with the new and shiny, resume-padding crap that they forget the problem they were hired to solve and instead create more problems that they then solve to show how "smart" they are.
...then they all get thrown out when the company downsizes. That's why I ended up having to do some JS work. I don't normally work with JS but I can use it if I need to.
I never had a need to do server-side JS so I won't comment on that in specifics, but I suspect it's much of the same situation.
The software serves the user. Period.
The user only matters in so far as the keep coming back and paying money (or attention, which is also money).
Developer experience only matters in so far as it keeps costs low, creating better margins.
If that sounds kind of gross to hear, it's because it is. Businesses are made up of people. Customers are people. Every interaction on both sides of the equation should take that into account. If you ruthlessly maximize like the human part doesn't exist, your optimization strategy will fail.
Making big assumptions about what the software project here. Given the article was mostly complaining about software developed for developers by developers, I don't think we can blame the suits for this one.
I somewhat think there's a huge error here though, a massive mistake in computing that we have such a huge divide between user and developer. A couple small vim tricks or enough shell knowledge to be a little dangerous, or even someone ok at excel macros blends the line so much here.
We have been building more and more totalistic apps, which afford less & less view of computing & developer-ish sensibilities. It keeps getting harder to see because we are so entrenched in pro application anti computing paradigms, but I think some day consumeristic computing will be worn thin. I New-old dynamics can re-start, embracing systems that also try to offer more developer-like sensibilities & capabilities.
Douglas Engelbart's idea of augmenting intellect to me speaks of the need for people to get great at toolbending, I at taking some good existing tools & capabilities, and being greatly empowered to bend create & explore different configurations & possibilities. Soft systems, with malleability, where users can ad-hoc cross over the aisle & become developers: that's a strong culture, where softwares real hidden noble purpose lies.
And where we can stop hating, stop being adrift & trapped, amid unyielding prisons of hard computing.
All they care about is does it do what I want+expect it to do when I want it done while it solving my problem? That makes money.
There's lots of scenarios where the end user is in fact another developer, but I think the spirit is talking about the general populous.
Tooling does not get complex because engineers are somehow magically attracted to complexity. They get complex because the world is complex. To "hate [the complexity of] the tooling" is really just indirectly saying you hate the complexity of the world... which, I mean, I guess is fair, but not that interesting.
Is a infrequent commonly one time thing that pales in comparison to operating it.
Is that how software development works today?
The author should look into golang which amazingly gives you one fully static binary (without dynamic linking glibc) and builds directly on top of kernel APIs. They will find reasons to rant about go itself though, I'm sure.
Writing software - is an act of self-expression like it is for an artist or writer.
Everybody wants to write his/her masterpiece in his/her own way, and not always agree with the way others do it.
same with scientific community - two scientists cant agree on two ways to conduct scientific experiment, because they want to express themselves in this act
Others just want to write literally anything to get the job done and be on with it.
Others resent the fact they're being forced to write it in the first place.
There are likely many other archetypes I'm ignoring too. But even reconciling these 3 together is what leads to everything regressing to the mean amount of suckiness.
this is not compatible in team-based software development. Once you want to collaborate with others, the #1 priority becomes not "anything that gets job done", but "anything that team can read, maintain, support, and continue developing"
if you are solo dev or writing bash scripts for your own workflow - then of course you can use anything literally, as long as it is on your computer and nobody sees it
https://www.linkedin.com/in/tinyclouds
Looks like he's still all in on Javascript with Deno? Interesting.
I wonder what, if anything, has changed in his perspective.
Also a lot of that C code in Unix, you know, actually like works and has worked for a long time! 50 year old C code in a Unix operating system isn't going to be unheard of here shortly.
We mostly don't actually use the OS though. We write code that gets deployed on some managed cloud system, and to the extent that there's anything in between (a unix process, kernel and virtual machine to run the code) we probably cargo cult it and don't worry about the details unless it breaks. Building unikernels (which is increasingly practical, with OCaml leading the way but other options available) would sidestep many of those layers of junk.
("Serverless" is another way to achieve the same thing, and may well be the one to succeed; even if serverless systems don't currently use unikernels, they could be transparently upgraded to them in the future, if they're strict enough about the interfaces they offer at the moment).
Oh hey, yeah. A bunch of small utilities that communicate and interoperate. I can see it working out. You could even have them communicate with each other via some sort of universal interface.
The key is to have that interface be narrow and well defined - something like gRPC. Allowing them to communicate via a huge, poorly specified, non-concurrency-safe swathe of shared state (filesystems with all their ad-hoc semantics, shared memory, signals, pipes, KAME sockets, namespaces, goodness knows what else two processes on a Unix system can do to fuck with each other) is a recipe for disaster.
You really can't use a mesh of unikernels for this then. You need an external system to enforce the types (like a compiler does for a single program).
At runtime, so far as the computer cares, there's really just arrays of bytes (or machine words depending on if your system is really byte-addressable or just faking it).
You can do input validation, but unix cli utilities can already do that. You'd need, rather than a bunch of unikernel utilities, an all encompassing environment that the utilities can register their constraints with, and the system would prevent them from being called if the constraints were not met.
Main contender is probably emacs, just because it's already ahead on the "all encompassing environment" part of this.
The problem isn't arrays of bytes. The problem is all the other semi-structured cruft that the OS has accumulated, the squillion different system calls you can make with almost-but-not-quite standardised effects.
> You can do input validation, but unix cli utilities can already do that. You'd need, rather than a bunch of unikernel utilities, an all encompassing environment that the utilities can register their constraints with, and the system would prevent them from being called if the constraints were not met.
Or you just don't give them the interfaces to mess with each other's internals. You have your hypervisor isolate them from each other except for a narrow communications channel obtainable in a narrowly specified way. Ideally the hypervisor also enforces that what you send/receive is well-formed gRPC (which is not hard), but that's not essential - the main benefit comes from just closing off all the other random OS-level ways that Unix processes communicate with each other.
who is the user anyhow?
What if all these "users" do not agree on some point or other?
It seems like a conundrum with a likely non-ideal outcome.
I do too. In fact, I'm writing my own framework that replaces most of libc.
It builds a better foundation, and I'm better off for it.
I'd love to see your work if you're willing to share it here!
This framework is not meant to be shared really; it's more building my own software stack from scratch, kind of like [1].
For me it's still by far the best runtime to do anything event-alike/http/json/web. It's quick to develop small things and quick to deploy (if you omit the whole transpilation shenanigans which of course help if you have dozens of engineers working together).
Great winning move, where a ton of the hard part of language optimization & growth is other people's problems, & Ryan could focus on making a great developer experience, which he and izs (npm author) did.
I agree. Though to be fair software is doing more these days. Or at least it feels that way!
You only have to configure this once. Don't install too many things. Just what you need. This level of complexity is needed because this is not TempleOS in which all software is made by one person. Most software exists to bridge the Tower of Babel lost in translation scenario.
NixOS is also a subjective take on packaging, heavily luring people into a functional programming world, where one set of problems is merely replaced by another set of problems. I tried NixOS, so no, thank you. There are better ways to isolate packages and have multiple versions of libraries. The simplest of which that come to mind are things like Flatpak and containers. There's almost 0 usecase for NixOS - it merely replaces one set of problems with another. And forces you to learn something, that does not justify the time it'd take to learn it. I feel like people who built it just wanted to be smart, not create things that are seemingly simple and beautiful (which is what true artists strive for, I think). I learned Vim in two weeks. I gave NixOS the same time and it was almost a waste of it. Not a complete waste, however, because, I recall, I discovered an extremely useful, but unrelated thing (zfs), but I don't remember how come it worked out this way.
Today I had to use Node.js and grunt (first time I hear about it) which installed npm packages and "compiled" it all into the Chromium extension I needed. The extension's actually good, but it itself uses Angular and ton of other packages, 50 or 70 maybe. What in the actual...?
On the backend side... Why do you need a framework? Learn yourself some CGI, write small programs. Sure, use libraries, but also maybe try a compiled language, so it runs faster, isn't as simple to hack if someone breaks in. Besides, Cloudflare and the likes of them (also hated by me and many) protects from most attacks anyway (and that would be one single positive aspect of the existence of these captcha racket-companies). So you won't need to learn much at first. You don't want spam? Maybe ask your users to pay first. Then it's much harder to perform a DDoS if most of your website is behind a paywall. Nothing is free. Everyone complained about how Bitcoin mining is bad for the environment etc... yea yeah. Next time don't use React and Ruby On Rails for your Blog with two and a half articles in it.
P.S. My sincere recommendation for anyone: find and listen to Jonathan Blow's interviews and talks (not the twitch streams - they're too long and boring). This man understands many important things, not the least of which is that game devs, somehow, manage to waste less resources while people are playing their pretty demanding games, less than certain websites do. Or that Twitter's engineers being let go is because you don't need that many engineers to build a micro-blogging platform that hasn't even changed all that much over the years. It appears to me there's a lot of scamming going on in the startup/VC industry. You get a $2mil check and hire expensive devs - also pay yourself nicely, of course - to build something I can probably build in 3 months for $15k and it'd be better. I had founded and financed a company myself. And even when we finally got external funding (not much) we never paid ourselves as founders, not the once. VCs in the US don't care (not their money and the inflation forces them to just stuff it into whatever comes their way) and founders are happy to be sort of "working for themselves". No wonder the success rate is low.
A lucky few have a come to Jesus moment and realize that nothing is perfect and that fighting the tide by swimming upstream is a fool's errand, they swim sideways to the shore.
All software reflects the environment in which it exists, including the time pressures involved in its creation and the complex, messy reality it is trying to model.
We’re all familiar with a “90% MVP” that is small and elegant and solves the main use case sort of ok. Beyond that, reality has a lot of detail and edge cases and that’s when software gets nasty.