I recently buddied up with someone who has a CS degree to try and make a desktop app, as a side project. I asked if he is familiar with MariaDB and whether or not he's used C++ ODBC.

Our discussion quickly turned into choosing libraries / existing code. He uses Spring and Hibernate and was bewildered by the concept of tying columns to application variables "manually". After I told him I have some CentOS servers where we could put a shared database, he bought a Windows Server because he "needs a GUI". He added, "Ideally, after it's setup, we'll never even have to remote in to it." For the actual desktop application, he wants to use Electron.

It seems there are two distinct branches of computing emerging - one where performance matters, and one where it doesn't. Performance will always matter in places like the stock market or on IBM mainframes. In the consumer-facing world, All that seems to matter is perceived performance. Slack and Discord seem fast, when you watch how quickly a new message pops up on your laptop screen after you sent it on your phone. They seem egregiously slow when you open up task manager and see just how much overhead the chromium-based engine adds -- but most people won't care.

Applications made for "consumers" tend to be made like a cheap car - corners are cut, the end result isn't pretty, but things in the category are what makes up 90% of ordinary use cases. Slack isn't meant to be open on your work machine while you're compiling code in the same way a Prius isn't meant to chauffeur top-level executives. It doesn't mean that the Prius is bad or unimportant - it will do far more for more people than the entire lineup of many luxury car brands.

But I am damn sure that I'd rather be engineering a Bentley than a Prius.

Edit: In the metaphor, luxury and performance are sacrificed, not efficiency. I probably should've used Fiat Chrysler, but unlike Fiat Chrysler, consumer-facing software has its place. I just don't enjoy working on it myself.

And the thing is that connectivity has little shit to do with the layers of abstraction to idk render a button on a screen. Even developers, as your anecdote shows, lack the creativity to imagine better things! Christ if that doesn't show something is wrong than what will?

I started my career as a software engineer writing C, then C++ working on desktop software. Things made sense back then, and that was just 10 years ago.

I’ve tried contributing features to two Electron-based apps. I gave up on both. I just can’t make sense of it.

I’ve sat down countless times over the last decade telling myself I’m going to teach myself this damn frontend web stuff. I gave up every time. It’s ridiculous.

Young folks who have only been exposed to modern garbage have no idea how good it was before the web took over.

I often wonder how this came to be. How we went from well-documented, efficient, sound APIs and libraries to the monstrosity that we have now. I have nothing to offer though.

Charity Majors said about reliability: "Nines don’t matter if users aren’t happy."

I'd propose an alternative view here: "Bloat doesn't matter if users are happy."

My other current product custom made for a customer in C++ is business server that receives various commands over http, does lots of calculations and delivers data that are used to generate a report (I wrote a report generator in JavaScript and it runs on a browser). The whole thing is again single exe that needs nothing but connection to a database. The exe itself is around 1MB vs again gigabytes for the old mess they were using before and is more than 100 fold more performant. The customer was simply shocked when they saw a result.They did not think it was possible.

Today bloat doesn’t matter, tomorrow you’re are a fat dinosaur

You should not outsource your main product. And if your product is a chat application that is supposed to be fast and always on the background, then you’re outsourcing your main area of expertise.

The unfortunate corollary being that the prevalence of developers who treat it as if it doesn't makes it darned hard to find one who treats as if it does when you need one.

> "Applications made for "consumers" tend to be made like a cheap car"

Not really a great analogy. The Prius has a reputation for quality and reliability; it's often seen used in taxi fleets, where those qualities are a must. Luxury cars often have high maintenance requirements and poor reliability since cost is not a concern to their owners.

This is absolutely a nit and does not disqualify your overarching statement at all, but generally these attributes are due to the constraints of technology-- for example, fitting large, high performance engines necessarily increases the frequency of maintenance intervals as well as the difficulty (and therefore, cost) of maintenance. If luxury car manufacturers could make cars with the handling and performance characteristics of their flagship models but with the maintenance costs and intervals of a Toyota Corolla, they absolutely would.

Luxury models are used by the manufacturer as a proving ground for the tech they're going to filter down to the mass market models next. Luxury model customers are relatively price-insensitive but want to be able to show off shiny features, so they get the exclusive new tech that's not been tried at scale yet. Thus the unreliability. It's not the technical constraints, it's the maturity of the technology.

(Also, the point about your someone "with a CS degree" - it's completely irrelevant that they had a CS degree, AFAICT. It mostly comes down to their prior experience, and they clearly didn't have a lot of it. That's mostly orthogonal to education.

I also wouldn't pick C++ for a CRUD app, not without very specific requirements. I'd choose C# if there's no existing web app, but if there's an existing web app, or there's going to be one, Electron makes a lot of sense.)

The thing is - there is no need to address performance if it does not matter. That would lead you to Knuth:

"The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil (or at least most of it) in programming." - Knuth

So I think there is actually a dial: if performance matters you turn it one way and optimize as necessary; if it doesn't go onto the next project that is fighting to get out of your head.

These are also very cheap devices, but they rarely have the resources to run something as bloated as an Electron app.

meant by who ? Because I certainly keep slack open while I am compiling. And it seems to me that it is meant to be kept open in the background while you do other stuff.

When i first installed Win8 on that laptop i was so impressed i even took a video[0] of it (and yes, it seems like they kept that performance in 8, though sadly by 8.1 it became slower).

[0] https://www.youtube.com/watch?v=Ti3LQHXZ0Qg

I'd rather windows uses my SSD to the fullest, than that it makes concessions to spinning disks.

Windows 10 is for newer hardware anyway, it runs slow on older hardware.

In 2018 Microsoft disbanded the Windows team and moved engineering efforts to its cloud and AI teams. Windows 10 is on life support by engineers who aren't intimately familiar with its codebase. Performance and usability will only degrade in this situation and the specifications of newer hardware don't excuse constant deterioration in performance.

Windows 10 is probably slow on HDDs because it's updating a load of UWP apps in the background, resmon.exe disk tab will show what's going on.

https://mobile.twitter.com/id_aa_carmack/status/193480622533...

The point is that a dependency is a dependency, and making software needlessly complex in any way is bad.

I've run into this a lot with open source stuff (not even JavaScript, just native code): I want to fix/modify something, and I know it's open-source, so it should be easy, right? After looking at the sprawling dependency tree, and the effort it would take to set up a build environment --- which might not even give me the same output as the original binaries, which are working perfectly fine except for the part I want to change --- I decide I'll just find the locations with a debugger and patch the binary directly.

tl;dr: the complaint is equally valid when applied to build tools, which are themselves also software and becoming bloated.

I believe all pieces of technology have similar dependency graphs.

In the same way, the "dependencies" required to build my hardware aren't counted in that number. What counts is the extra stuff that isn't already part of the running system.