My #1 annoyance these days, because it is so egregious, is Electron apps.

I guess because the only language some programmers know is Javascript, of which I know little but what little I know places it marginally above PHP in intrinsic horror.

So people write standalone apps in a language intended for tweaking web pages, meaning that to deploy those apps requires embedding an entire web browser into every app.

And entire popular businesses, for example Slack, do not as far as I can tell have an actual native client. The only way to access the service is via a glorified web page, running inside an embedded browser. Despite which, it can't actually authenticate on its own and needs ANOTHER web browser to be available to do that.

Electron apps make Java ones look lean and mean and efficient.

Apparently, expecting a language that can compile to native machine code that executes directly on a CPU, and which makes API calls to the host OS in order to display a UI, is quaint and retro now.

And it's perfectly acceptable to have a multi-billion-dollar business that requires a local client, but which does not in fact offer native clients of any form for any OS on the market.

It's enough to make me want to go back to DOS, it really is. Never mind "nobody will ever need more than 640kB"... if you can't do it in 640kB and still have enough room for the user's data, maybe you should reconsider what you are doing and how you are doing it.

It doesn't require it, that's just what they choose, and it has little to do with the language. (Besides, if you actually observe them—and ignore what they tell you about liking JS—then it's clear that most of them hate their preferred language.) Languages and the bindings that a particular runtime exposes are orthogonal. You can have GTK apps written in JS, for example, or you can write a program in JS that compiles into a binary that runs on a microcontroller[2].

This is much more of a problem with the culture of Electron and the adjacent NPM ecosystem than it is anything else. Conflating the source of these problems is a great way to tank any would-be activism meant to solve them.

1. <https://en.wikipedia.org/wiki/GNOME_Shell>

2. <https://github.com/Moddable-OpenSource/moddable/blob/public/...>

I will do a bit more reading up on this.

Cheers!

It is readable unlike php, dynamic as root from lisp, wide use and hence accessible.

But given its original history and neglect, it takes decade to fix all issues it presented in other area.

Still I would not dismiss it. Yes it is slow. But it is not Java type.

It can be better is the motto.

That is a good thing, yes.

But TBH I wish Eich had just embedded Lisp in Mozilla instead.

> wide use and hence accessible.

"Everyone uses it" is not a good argument for anything at all, really.

> it takes decade to fix all issues it presented in other area.

Well, yes, it has had a lot of R&D done upon it to make it quicker, but again, that is not an endorsement.

> Still I would not dismiss it. Yes it is slow.

It seems to me that in the 2nd sentence there you contradict your own previous sentence.

> But it is not Java type.

What is so wrong with Java?

More OSes support JVMs than support Javascript. JVMs have few requirements and can even run on DOS. JVMs too have a ton of R&D into making them faster and better. There is rich tooling and support to make Java apps scale, such as Enterprise Service Buses, e.g. JBoss FUSE, which allows apps with clashing namespaces to run on the same host at the same time, and even communicate.

There are tools for writing native UIs for Java apps.

I would rather have Java apps than a Javascript one, frankly. At least with Java apps, one JVM in your OS supports all your apps, whereas JS needs one per app, or even one per window or tab in some apps.

> It can be better is the motto.

That is not a good motto. That is in fact a really bad one.

And the VBScript threat was later, from Microsoft doing it in IE3. If I'd missed the Netscape 2 boat, it's likely VBScript would prevail (Netscape 3 was originally 2.1, and 4 was originally 3 but delayed a year; find "Collabra-driven" in https://www.jwz.org/doc/groupware.html).

Seriously, I have to really think about when was the last time there wasn't some degree of unnecessary friction in an application. It really feels like being an end user of modern tech is like being in an abusive relationship.

I've come to realize that a lot of modern developers consider users of their tech to be little more than cattle. The tech is cattle feed, meant to fatten and ensnare the user, so they can be sold off and slaughtered.

There's really only one party in that kind of relationship that benefits.

At first programmers were able to resist all that and have a voice, but lately it seems that the only prestige we retained was the salary, so we must play the same tune as the rest of the band. Agile was an attempt at being "self managed" and have a bit more independence, but that was also corrupted and lots of devs hate it with a passion too, so we're mostly back to practicing non-iterative, Steve-Jobsian-gut-feeling-centric development. Programmers have bought into that toxic mentality too.

And even in better situations, such as my current job, the tasks that cause the most issues, take more developer time and annoy the user the most are always the same: non-idiomatic features (for the web or for desktop apps), often concocted by designers totally disconnected with the audience, who at most did two or three "interviews" where the user said "yeah I could see myself using that".

This is a misunderstanding of Jobs. It’s true that he had a disdain for what users would _say_ they wanted, but he was very focused on providing the, with something intuitive and easy to use. He wanted to make their lives better, and to ‘surprise and delight’.

He was also very iterative. He regularly saw demos of in-production software (and hardware), and would ask for anything from small tweaks to complete rewrites. He was completely unafraid of throwing away work, and would change his opinions on a dime if they didn’t work out.

But the copycats that don't believe in iterative development or in user research love to pretend they got all figured out before it's out for development.

The disdain for "lusers" came from BOFH sysadmin types, well before it was adopted by the non-"tech", business-focused folks.

Basically, pests.

Business types look at users as a resource to be exploited to make money.

Basically, livestock.

Different outlook. We try to discourage pests, but we breed and incubate livestock. In neither case, are we particularly interested in the long-term benefit to our users. If anything, the BOFH types are actually working towards the benefit of their "lusers," because that's their job.

I write software that is targeted at a demographic that I actually respect, and sincerely want to benefit with my work (so, naturally, I don't get paid for it).

I'm constantly fighting with "modern software types" that want to treat users of the software that I write as livestock. They -quite literally- can't understand my PoV.

It's fairly discouraging, really. I'm treated like an idiot, because I actually want to help the users of my software.

Edit: Consider being told something along the lines of "Your DNA sequence has to wait, the CEO has important Facebook posts to read..."

Based on the definitions in the thread, I'd say the BOFH attitude is more the inverse: it is contemptuous towards users, whereas the modern practice is more condescending towards users.

The latter still has a notional ethos of catering to the user, but the Monkey's Paw corruption caters towards the user's most superficial desires, particularly at a first impression, while de-optimizing for the acclimated or "power" user.

But the treatment itself is first class, unlike with sysadmins of yore.

The former is generalized misanthropy plus specific hostility to the individuals who bother them.

The latter is more akin to the feudal lord or the cattle farmer: a lack of empathy plus an eagerness to stuff one's own pockets such that they build exploitative systems.

Sysadmins ultimately just wanted to be left alone to pursue their techie interests. But the MBA types are the opposite. You can't have an upper class without a set of lower classes to provide you with income and feelings of power.

My take is that launch times are on average better but still not great. And I think that's because something else that's constant is that programs first get written for the convenience of the programmer, and then optimized until people stop complaining about the speed.

The waste of resources bothers me too, of course. But on the other hand, computing resources have become radically cheaper while programmer time has gotten much more expensive. While at the same time, writing software had gotten radically more complex. So I suspect me getting bothered here is sort of like when my grandmother, who grew up in the Great Depression, got bothered when I didn't wash and reuse aluminum foil.

What keeps happening is-- we get an upgrade, and then have some old applications, and they become "instant" in comparison to our experience with both newer stuff and the application in the past. Then we watch that win clawed away from us.

Of course, it was never instant, even with the old or newer hardware.

My brother spoke a few weeks ago of being awestruck and programs starting "instantly" when he got a hard disk on DOS on the XT. But now I have a better-than-XT-equivalent (9.54MHz V20) with a very fast IO subsystem and I can tell you that it is very much not actually instant.

Good algorithms are far more important than instruction level optimization, which is to a large degree pointless anyway, since new CPUs come out all the time, and change the tradeoffs involved.