Why? The (ultimately unsuccessful) quest for the silver bullet. Nobody wants programming, they want programs - so anything that promises to deliver programs faster looks like a holy grail. Inevitably, though, the promise boils down to a pre-packaged implementation of an existing approach that does something relatively specific, with some options for customization. If you want to step outside that customization, you not only have the assumptions baked into the new "silver bullet", you also have to understand all the nuances of the layers upon layers of other approaches (and all of their assumptions), to the point where it would be faster to just shed all the layers and do it yourself (but you can't because noooo, you're a dinosaur, you don't understand anything, it's the future, it's the modern way of doing things).

Seriously though, there is an equilibrium somewhere, and on top of that a lot of stuff that is more about business and work than programming.

I may be getting out of my depth here but, am I wrong to say that a good deal as to why webdev in Java is even a thing is because there were people around who knew Java to begin with? That a good deal of people learning PHP did it just because Wordpress is a thing? That react native for desktop is about people with expertise in react native being able to develop for desktop?

Workers want paychecks. Society wants products. Workers will learn to make products so they earn paychecks and if they can spend less time learning they will, obviously, do so.

I notice that this mentality isn’t as common in circles of people with their nose to the grindstone building things.

Right now I have some game modding Discord servers in mind where everyone has crappy tools but is focused on building things regardless, and complaining about the state of things just feels trite, as if the entire ecosystem is responding “Ok, in Utopia things are better, but what are you building today?”

For some reason people confuse sour grapes with some sort of high brow eureka they need to dump onto the world.

I agree with you. I agree with the author. I put my own idea into practice:

https://htmx.org

The funny thing is, 20 years ago the same arguments were being made.

"Windows MFC is a nightmare to write against!"

"X11 is terrible, why are we using it?"

"Everything we write is built on so many abstractions developers don't know what they are doing."

"VB6 is dumbing down development"

"Developers writing in Java don't understand what is really going on."

"Java is too slow!"

OK the last one was true. UIs in Java were obscenely memory intensive relative to computers back when Java was first introduced.

But yeah, more things change, the more the complaints stay the same.

Then Java developers heard this, confused it for "Java executes slowly" and so they never fixed it, until Java applets just became obsolete.

"Amazing new IDE has just come out! Good luck running it!"

Also local Swing apps were memory hogs compared for the time. 20MB was a lot on a machine that had 256 or 512MB in total.

I'm not a fan of it. I understand the author's complaints and frustrations (I am also "chronologically-challenged"), but I have found that complaining doesn't really buy me much. I'll do a minor whine, from time to time (usually about the ageism in tech), but, for the most part, I try to bring some light to the conversation.

I write native (Swift) apps for Apple systems. I tend to avoid the "bleeding edge," as that isn't really where Ship lives, but I think that the way I do things, results in very good software (note that I didn't say "better software," as comparing against others only pisses people off, and doesn't buy me anything -unlike a lot of folks, I'm not in competition with anyone).

Of course, that doesn't prevent others from sneering at me, but that's their burden. I'm not exactly sure what benefit it gives them, as I am no threat.

If people like the way I do things, and want to improve that, then I am often fairly helpful, but I am not really into standing in the street, yelling at passing cars. I have better things to do.

Swift is only 7 years old, one of the newest languages/tools in existence. This is an implicit argument against the author's case.

One might perhaps argue that Swift's newness/modernness is an exception, that it's "one of the good ones" when it comes to new systems. But this doesn't really work. Using Swift for native GUI app building is platform-specific, and writing native apps for other platforms requires other tools. If Swift represents an improvement on what came before, it implies that such improvements are needed on other platforms also. (If it doesn't represent an improvement, why are you using it?) This also implies that cross-platform solutions might be useful - like Electron or React Native!

Being chronologically challenged doesn't actually prevent one from understanding the driving forces behind modern software technology. Certainly, fads and cargo cults exist, driven in part by people's inevitably incomplete understanding and desire to follow practices that others seem to be using successfully. But to be able to distinguish between the fads and the useful advancements requires a better understanding than the OP exhibits.

Complaining seems like a perfectly fine activity to me if there's some valid content in it. But it becomes fairly useless otherwise, except possibly as you say for driving social media engagement.

New is not necessarily bad. Old is not necessarily good. It all depends on what we are doing, and what our goals are.

I also use PHP to write my backends. It works nicely, for the scope of my needs. I’ve been writing in that, for over twenty years. My servers work quite well, but aren’t particularly “buzzword-compliant.”

I’m not really a server programmer, though. If I need a backend to be more intense than what I’m capable of doing, then I’ll hire someone to write it, using a more robust stack, and I need to be prepared to open my wallet, as I have high standards. Good engineers will always cost more. They’re worth it. They will frequently also have gray hair; regardless of the tech.

Which ones do you dedicate your precious time to as a direction to keep earning a paycheck?

LAMP.

I'm pretty convinced my future grandchildren will be maintaining legacy LAMP systems.

Most of these solutions that the author complains about came about to solve real problems, and without addressing how we can continue to solve those real problems with a simpler set of solutions, it's really just noise.

The bad side is because passionate young people come in hordes and they will gladly program anything for a penny. For the company is cheaper to hire a team of those youngsters and let them make your program in every (ugly) way they can, rather than pay a fortune for a veteran programmer that takes their time to deal with code that manually handles memory.

The good side is that you no longer need a computer degree or 20+ years into programming to make something decent.

Because in the time that OP spends tracking down segfaults and getting a dozen native libraries to compile for his native app, the JS dev has already finished XYZ feature. And because the environment is so high level, he can use the extra brain capacity for things like UX, business logic, and accessibility (things people actually care about) rather than meaningless implementation details.

This stuff won out for a reason. HTML/CSS/JS is literally a 10x improvement in iteration speed versus native.

QML gives you JS for the view layer (and some logic if you desire), and a declarative way to lay out your UI. I think it's worth a comparison as a reasonable way to quickly iterate on a UI while having something very lean and portable as the output product.

There seems to be a dearth of actually open, native, and cross-platform GUI toolkits.

When you need to release your application across multiple platforms? Yes. Not much else even begins to compare on that front.

Compared to native development on a single platform? Not even close. HTML/CSS/JS development is painfully slow in comparison.

I find it's often not, largely because the amount of focus on web apps means the native frameworks often are less productive by comparison than what is available for the web.

How? Do you send pull requests to thousands of projects to delete their codebase?

Or not.

He is complaining about unnecessary churn and unnecessary software and you obviously don't reduce it by writing even more stuff.

Nothing kills software as effectively as creating alternative software that works way better.

Would it have anything to do with coding boot camps teaching people how to code specific to these frameworks vs deeper learning into broader coding?

[1]: [Electron apps] constantly crash and has no value over a native desktop application what so ever

All those examples could or do work just as well as web apps, right? I don't think that's the authors message, but I'd rather have those type of apps be web-based instead of electron-based or native.