The sad fact is that the general public only seems to care about the fancy buttons. And from a business standpoint, cheap software (high level langs/tools that are bad for perf) and following current design trends are more important than CPU cycles.
Perhaps we'll see some kind of "back to the basics" movement in the future where UI and software becomes much more simpler.
The general public is (by our standards) astonishingly bad at using computers.
http://boingboing.net/2016/11/28/people-really-really-suck-a...
https://www.nngroup.com/articles/computer-skill-levels/
Perhaps most users need the fancy buttons, need the leading-users-by-the-nose-through-a-garden-of-visual-delights sort of experience that modern, beautiful, dumbed-down web UIs mostly provide.
The dense old interfaces the author champions are very rewarding and powerful for people who understand how to use them, but they're a huge turn-off for people who don't understand them and who aren't interested in investing the time needed to learn new tools.
Pretty much every web UI post-mortem you see finds the same thing: The more clicks you require of users to perform a function or use a feature, the less users engage with that function or feature. One click is often too much to ask.
Even so, the web as it stands today seems like (from a comp-sci point of view) a monumentally inefficient way of producing the functions it provides, with a ridiculous amount of hardware and software consumed by the problem of displaying, say, a news article which the reader has maybe a 5% chance of actually reading through and a 1% chance of commenting on.
I think general public does care. Every couple of years, people lament the lack of speed that their laptops have. All of your programs are beefy, because people want quick turn around. And then the devs never come back to cut the fat.
A friend of mine joked that 32GB of RAM was the new minimum standard, and someone else took a step further to say that disk I/O is the new RAM. We're still quite a ways away from that, but we're still trending in that direction.
Edit: This isn't to say that we'll be using disk I/O as RAM. It's a hyperbole, but there's no denying that it's now acceptable to ignore memory footprint of desktop apps.
If you try to run OSX on a machine with a magnetic drive, you'll see that this is the case now. :/
To make it clear, my Mac Mini was performant about three major OS releases ago, and went to crap after an OS upgrade, so it's not the hardware.
Edit: ooh, and shared HBM2 memory between the CPU and GPU. And make it socketed + upgradable :)
IMHO the web needs a movement akin to "nosql", but for bloated crap like JavaScript.
My web browsing experience has only improved after installing noscript.
Edit: Holy smokes, the site hosting the content is what I'm talking about http://weeb.ddns.net/1/gopher I'd still like a text/plain only Google though, I'd be willing to POST the search request for such a thing via cURL.
You can write badly performing code in C++, its dead easy.
But its our job as developers to challenge the managers when the expectations are unrealistic. They are very receptive when you put it in terms they understand.
I've also seen plenty of developers jumping head first into code with a very shallow understanding of the requirements or the tech stack they're working with.
For a large fraction of developers I worked with at previous jobs, the mention of "optimization" meant arcane low-level micro optimizations using techniques the compiler can mostly automate nowadays. Very, very few of them knew what cache lines or branch predictions are. I've seen entire game engines with shipped games on all prev and current generation consoles built that way. Then they wonder why a PS3 has trouble running a simple 2D game with 20 sprites on screen.
On my machine, especially if people are getting GIF emoticon happy, Hipchat will gladly consume a full core of my processor as well. Reinstalls, stops/starts, etc... none of these work to make it behave again. A real battery killer.
I guess it's modern software at its worst: we can't even display a plaintext file in the browser reliably.
Using punch cards and mainframes really forced the programmer to think his solution through and optimize the hell out of it. Once in a while your cards would not get entered properly, but in the end this made you a better programmer even if you are still in therapy for it.
When games had less than 16 colors, and all you needed were a few pixels on a cathod ray tube. Playing Pong, and Tennis and hockey all on the same machine! Sometimes you'd forget which one you where playing, but that was also part of the fun!
Progress entails transitions, and we are now transitioning. It is sometimes painful and ugly, but it's always necessary unless you stay static forever ...
Most of what we do was present for decades, and there's not so much change at all. E.g., there's not so much difference in requesting live data in a browser by the use of a hidden frame and reacting to its onload event (or using a mechanism, which became later known as padded JSON), like in the 1990s, and using a nifty AJAX library. (You're still requesting some data from a server to load it into the browser and eventually process it in an onload event handler in order to partially update the UI). The difference is really in the amount of processing and tooling involved in pulling this up.
And then, there's the bitter irony of the history that started with the iPhone. Before, there had been smart phones, too, like the SE's ones, perfectly capable of displaying a subset of HTML4, and even a wide range of feature phones, being perfectly able to display a subset of XHTML. The selling point of the iPhone was its ability of displaying perfectly normal websites without any further modifications or restrictions applied. Now, file sizes are shooting up (because mobile?) and even your 4K screen is restricted most of the time to what may be done on a 5 inch touch display at the cost of high processing loads implied by an abundance of abstraction layers that are never put to a sensible use in the first place.
So transition is nice and a good thing (like, if we had made use of multipart-http, as in HTTP1.1, but, yes, there was this MS bug regarding http chunks -- however, we may get now a second chance), but, nevertheless, we may question the direction of a particular transition from time to time.
Fantastic.
Related:
motherfuckingwebsite.com & bettermotherfuckingwebsite.com
Don't get me wrong, close-to-metal coding and native, fast UIs are wonderful where appropriate, but there's no sense in doing it for every small cookie bakery website.
This trend actually helps more people than ever use computers for an ever growing array of purposes. Back in the good old days you had to hire developers from a very small group of qualified individuals and then have them spend months on optimizing new code they just wrote instead of using an existing framework. Today you can just read a tutorial online and create a usable POC yourself. This opens so many doors to both developers and new users.
The resource heavy UI practices actually attract more users. Average users don't want dense console UIs or old fashioned native Windows forms. They want a touch app on their mobile that just works. All the tools we have today allow easily sharing and customizing UI components. This in turn fuels fast iteration and improvement of UI so that actual users actually want to use it.
All this doesn't mean you have to be lazy and just freely consume as many resources as you can. It also doesn't mean you shouldn't shame applications for being slow (I'm looking at you Slack for desktop...) or resource hungry like the examples in the article. But overall I think we are definitely going in the right direction.
I guess this might explain why it broke: Hello there! You are currently visiting gopherspace through a proxy.
