> 600MB/sec SSDs are kind of 'fast enough' with regards to app loading and boot times

Don't worry, Electron apps are working hard on saving us from 60 Hz.

Two months ago, there was a text editor benchmark on the front page, wherein Atom and VS Code were multiple magnitudes behind all the other editors, leading to this conversation:

Commenter: "Can anyone speak to the difference the underlying hardware makes with Atom or Code? Presumably a top-end desktop processor (~4GHz) and latest-generation NVME storage would offer really good performance, but perhaps not."

Me: "A year ago, people made fun about how programs will get proportionally slower once all the developers have switched to SSDs. Now we're already talking about having to upgrade to NVMe disks for a decent code editing experience."

Source: https://news.ycombinator.com/item?id=13935235

I'm not sure if this was from the same thread. Someone was arguing that people who say Electron apps (that is, process intensive apps) shouldn't exist are the same ones trying to stifle innovation. I wound up not replying, but that belief is a crock of shit. It's not that Electron apps shouldn't exist. It's that Electron apps can be a huge trade-off between idea => product ship date and resource use for an end user.

I understand that abstraction comes with a cost. You tend to lose a little bit of control of exactly what your code does, and there will likely be more cycles used (sometimes trivial, other times not so much) to accomplish the same task. It's one thing to push the boundaries of existing hardware for the sake of productivity. It's another to say, "Yeah using Electron apps for text editing is fine. Just make sure you can bankroll bleeding edge computer builds, and you won't see any performance degradation."

How does that seem like a sane line of reasoning to anyone?

Electron apps strike me as the 201x's Visual Basic application. It's more polished looking, prettier, and uses a (debatable) better language. But it's mistaking a prototyping system for something meant for releases. It's easy for people to get it up and running and do lots of neat things. Fine, now you've got that out of the way, get the underlying code to be fast and memory efficient and you have a deliverable application. Don't do that, you're just shipping a prototype.

I see something similar in the hobby hardware space. Everyone using microcontrollers (and some really powerful ones) for tasks like homemade smart lights. It's way overkill, but it gets the job done and done quickly. And as a hobbyist it's great because it's infinitely reusable. But that doesn't make it the right thing to use for a shipping product.

Brings to mind Cstross' story about how he ended up writing scifi. At one point it involves pressing a massive proof of concept perl script for a UK online payment service into production, and keeping it afloat as companies and banks piled on.

For many applications, it isn't financially viable to ever make them fast and memory efficient because compute time is just far, far cheaper than programmer time. Electron is perfect for that type of application.

Is that really true? I mean, is it cheaper to write programs using javascript and Electron than a native GUI? It's cheaper to port, I'll grant you, compared to something written to target a native GUI. But, hell, even java and flash had a better memory and CPU story than Electron.

EDIT: Ok, to expand on this. Running a small number (< 5) of Electron-based applications on my MBP with 16GB of memory feels like running the same number of instances of Eclipse circa 2005 on my shitty, cheap HP laptop. Nothing else can run alongside them because they're so memory/CPU hungry. But here's the thing, computers have gotten better since 2005. What's the rationale for such poor performance with these apps? my computer has 8x the memory today (maybe more) than that one had. The clock is up by 2-3x. Cores increased by 4x.

There's no excuse for this in final, deliverable products.

> There's no excuse for this in final, deliverable products.

There is an excuse for it if you aren't willing to pay for faster software. Cheap is more important than fast for most software products.

Major video codecs still change every 5 to 10 years. Even Youtube can be largely unusable on otherwise serviceable old hardware because there is no or outdated hardware assist for decoding video.

Since CPUs and soon GPUs will level out, then at least crypto and video will be pushed into hardware blocks meant to encode/decode them. Churn in functionality requiring hardware assist will probably keep us buying some new hardware at least once and probably twice a decade.

> Major video codecs still change every 5 to 10 years. Even Youtube can be largely unusable on otherwise serviceable old hardware because there is no or outdated hardware assist for decoding video.

Something that is downright crazy given how long NTSC and PAL stayed in use.

But then i live in Norway, where we are in the process of shutting down FM broadcasts in favor of DAB. Except that DAB has already been superseded by DAB+, and if you go a DAB radio early on you will have to toss that one and get a new one.

They wont be good enough for light-field-based mixed-reality computing just like command line computers weren't good enough for GUIs.

How many more computers will we probably buy before mixed-reality jumps the chasm and goes mainstream? I don't think it's more than 2.

I think you're right, but at the current rate of progress it's going to take a while to get there.

We're currently in the modern equivalent of the mid-90s DOS plateau, where an experience that's actually quite mediocre has become the default user expectation.

Getting past this requires an order of magnitude increase in processor power. Given what's happening in hardware that seems unlikely any time soon.

It's more likely tablets will gradually catch up and merge with desktops - but there won't be any dramatic change in the UX offered by either. That needs speed and UI technologies that are at least a generation away.

The new UX will come from voice, AI, and robotics, which will make computing more physically interactive, and less tied to the glass typewriter/document library model.

I largely agree, although I think mixed-reality will be the new UX, with voice & AI being a big part of it as well. But we may need 2 orders of magnitude in GPU/Watt performance before light-field glasses replace 2D screens.

Given the gargantuan data/compression requirements of light-fields (Lytro's cameras capture >300GB/sec of lightfield data!!!), plus rendering, persistent SLAM, etc, we'll need the power of a GTX1080Ti or better, but able to run flat out using only 1-3Watts of power instead of ~250W.

The good news is this is what the global smartphone manufacturing ecosystem is working towards, with a relatively short device life-cycle to finance the huge effort that will be required to get there. But mid to late 2020s will be all about mixed reality. I am convinced that it will be so incredibly compelling, that any 2D screen, no matter the size, resolution, dynamic range, or refresh rate, will be like command line compared to GUI today.

And yet what do we see time and time again, tiling UIs used to multiplex CLIs.

When we really want to get things done with a computer, we keep coming back to the keyboard and the CLI.

Even high end math/design/engineering packages have a CLI in them.

I think that is because, at their core, computers parse language (be it computer or human). At some point you need to input that language, which is a task keyboards and command-lines excel at. It's the lowest common denominator, so it will always exist.

At the same time, there are ways that you can program a computer that do not rely on pure text input. We've already seen things like Scratch, GameMaker, and Unreal Engine's blueprint system explode in popularity. When the tools are built, people will use them, and they can supplant the previous paradigm.

I think there are advantages VR/MR can have for simple text input, too. I would love to have a virtual work environment where my files live in "physical" locations, where I can visit them as if they were sheets of paper or trinkets, arranging files or bits of code in front of me into graphs I can walk around and draw on like a whiteboard.