Hacker News Reader

Comment by djhaskin987 | Hacker News Reader

> Yes, computers have gotten faster and memory and disks much larger. That doesn't mean we should be wasting it to do the same or even less functionality we had with the machines of 10 or 20 years ago.

With Moore's law being dead, efficiency is going to get a lot more popular than it has been historically. I think we're going to start seeing an uptick in the popularity of more efficient GUI programs like the ones you describe.

We see new languages like Nim and Crystal with their only value proposition over Python being that they're more efficient.

Similarly, I predict we will see an uptick in popularity of actually native frameworks such as Qt over Electron for the same reason. We may even start seeing wrapper libraries that make these excellent but complicated frameworks more palatable to the Electron crowd, similar to how compiled languages that look like Python or Ruby are getting bigger.

View on HN

I said that 20 years ago, but so far I've been proven completely wrong. Skype/etc just keep getting bigger and slower despite, from what I can tell adding absolutely no additional functionality. In fact if you consider it can't seem to do peer to peer anymore, its lost features.

Very few companies are rewritting their electron apps in win32 (although they should be). Instead it continues moving in that direction, or worse. Crashplan rewrote their java GUI a while back in electron. Java UI's are mostly garbage, but compared with the electron UI it was lightweight and functional. The electron UI (besides shipping busted libraries) has literally stripped everything out, and uses a completely nonsensical paradigm/icon set for the tree expand/file selection. Things like slack are a huge joke, as they struggle to keep it from dying under a load my 486 running mIRC could handle. So blame it on the graphics and animated gif's people are posting in the chat windows, but the results speak for themselves.

Without a way for end-users to actually make judgements about application efficiency, there will never be any real pressure to make efficient, native apps.

Though the only measurement I think people would actually care about is battery impact, and even that is pretty much hidden away on phones except to the few people who actually look.

But the other problem is: who cares if Discord or a browser's HN tab aren't optimally efficient? You're just going to suck it up and use it. With this in mind, a lot of the native app discussion is technical superiority circlejerk.

Without a way for end-users to actually make judgements about application efficiency, there will never be any real pressure to make efficient, native apps.

I'd say it's more of a "without a way for end-users to compare" --- the average user has no idea how much computing resources are necessary, so if they see their email client taking 15 seconds to load an email and using several GB of RAM, they won't know any better; unless they have also used a different client that would do it instantly and use only a few MB of RAM.

Users complain all the time when apps are slow, and I think that's the best point of comparison.

There is an economic theory that's escaping me right now, but the gist is that with certain goods, the market will hover at the very edge of efficiency; they have to become just scarce enough to break a certain threshold, then the market will realize that they are in fact a scarce resource, then correct to achieve a high efficiency equilibrium.

Even further: without a way for end users to take action based on that comparison.

If I decide that I don't want to use Slack because it drains my battery, then I can't take part in Slack conversations.

Because Slack is the go-to chat application for so many teams, excluding myself from those conversations is not feasible.

End result: I carry on using Slack.

THIS. I do remember outright revelations in user experience, as I showed people how much better Firefox 2.0 was, compared to IE6 (and looking back, version 2.0 wasn't all that wonderful, from present point of view - tells you more about IE than about FF).

edit: it was 2.0, I misremembered.

Instacart website has dreadfully slow search. Looks like instant search update takes forever to update with each character. The whole site is so slow. It makes my Mac Safari complain that the page uses significant resources.

This weekend I noticed that Amazon Fresh now delivers the same day—-for the past few months they had no slots. I switched to Amazon away from Instacart at once. The Amazon website lacks some bells and whistles compared to Instacart but it is completely speedy. If Instacart website were satisfactory I would never have switched.

Slow, bloated websites can absolutely cost companies money.

I think the other major, major thing people discount is the emergence of viable sandboxed installs/uninstalls, and the accompanying software distribution via app stores.

Windows 95 never had a proper, operating-system supported package manager, and I think that's a big part of why web applications took off in the late 90s/early 2000s. There simply wasn't any guarantee that once you installed a native app, you could ever fully remove it. Not to mention all the baggage with DLL hell, and the propensity of software to write random junk all over the filesytem.

Mobile has forced a big reset of this, largely driven by the need to run on a battery. You can't get away with as much inefficiency when the device isn't plugged into the wall.

> [the absence of a package manager was] a big part of why web applications took off in the late 90s/early 2000s.

Of course apt-get is very convenient but I can't see a Microsoft version of it letting companies deliver multiple daily updates.

Based on my experience of the time the reasons were, in random order

- HTML GUIs were less functional but easier to code and good enough for most problems

- we could deploy many times per day for all our customers

- we could use Java on the backend and people didn't have to install the JVM on their PCs

- it worked on Windows and Macs, palmtops (does anybody remember them?) and anything else

- it was very easy to make it access our internal database

- a single component inside the firewall generates the GUI and accesses the db instead of a frontend and a backend, which by the way is the modern approach (but it costs more and we didn't have the extra functionality back then, js was little more than cosmetic)

There simply wasn't any guarantee that once you installed a native app, you could ever fully remove it. Not to mention all the baggage with DLL hell, and the propensity of software to write random junk all over the filesytem.

Bloated, inefficient software is certainly present on the native side too, but it's also possible to write single-binary "portable" ones that don't require any installation --- just download and run.

OS API sets have evolved toward more sandboxing. Things are more abstract. Fewer files on disk, more blob-store-like things. Fewer INI files in C:\Windows, more preference stores. No registry keys strewn about. .NET strong naming rather than shoving random DLLs into memory via LoadLibraryA()

(Hi, I'm a windows dev)

IMHO web applications took off because developers learned pretty fast how useful "I can update any time without user consent" is, especially when your software is a buggy mess (or a "MVP" if you like buzzwords) and you need to update every five minutes.

> Similarly, I predict we will see an uptick in popularity of actually native frameworks such as Qt over Electron for the same reason.

I would predict that if only Qt didn't cost a mind-boggling price for non-GPL apps. They should really switch to pay-as-you-earn e.g. like the Unreal engine so people would only have to start paying as they start earning serious money selling the actual app. If they don't Qt popularity is hardly going to grow.

Qt through the LGPL license is free for non-GPL apps. Tesla is using it as LGPL in their cars without paying a dime to Qt Company (which is, imho, super shitty given the amount of money they make).

Reply on news.ycombinator.com