Electron is flash for the desktop (2016)

My first computer saved data to a cassette tape; today, terabyte hard drives are nearly give-away prizes in cereal boxes (yeah, I know they don't do that anymore, either). We have machines in our pockets which are arguably (in some ways) more powerful than the machines only government-funded agencies and such could afford when I was a kid (and they took up entire rooms).

I hope I live long enough to think of 850 MB as a small amount of memory (and 8-cores at 4 GHz each a slow machine; actually, there are some multi-cpu server mobos I'd love to have as a desktop, but I can't afford it - yet).

Honestly, I'm amazed that we do have enough memory to support these huge apps. Sure they're bloated; I won't argue that - but at the same time its amazing that we can run them at all - a decade ago it would have seemed ludicrous!

Could it be better? Sure - but in my mind, all software is bloated - because even the simplest piece of compiled code I can't run on my old TRS-80 from when I was a kid (heck, even an Arduino has better specs!).

1. Delivering your app with electron 2. Writing a web app versus writing a 'native' app

Yes, delivering an app with electron might be subpar as it brings code to your computer which it probably already has. Most Computers which are targeted by electron apps already have a browser and lots of them have up-to-date chrome or firefox browsers which offer features very similar to electron. So I don't say there is no reason why one should use electron, but I urge every developer to make their web apps accessible to browsers too and let people use their browser if they want. Even offlines usage is no problem anymore as we have serviceworkers in the majority (by market share) of browsers nowadays.

The second point, however, is very poorly laid out in the blog post. Web apps do not have a general problem with performance as suggested by the article. Maybe some are badly developed but in the end, they are all backed by the tremendous efforts that were put into browser performance in the past years. The question if web apps can deliver the required performance was answered by the 60 FPS discussion a few years ago.

At the moment, the web is the only truly OS independent platform I know of. That is a very valuable feature and one we should treat with the deserved respect. So please write quality web apps and do us all a favor, instead of just choosing one specific platform. Yes, react-native is an option too, but I think it is a bit limiting to define just one framework as the one true way.

Couldn't your team learn the technologies? These days there is an abundance of resources available (online tutorials, books, bootcamps, etc), especially for ecosystems as popular as the Appleverse.

I can't pretend to know your situation, but as a reference point we had an iOS project come up at work a couple years ago and I was able to pick up Objective-C and the Apple libs in a few weeks while still being productive on other projects. I followed Apple's official tutorials[0] and built some toy apps, then learned the rest as I went on the real project. This is after having never owned an iDevice and doing mostly web and devops work in scripting languages for many years prior. A few peers of various experience levels were able to ramp up in about the same amount of time, so I'm not special.

[0]: https://developer.apple.com/library/content/referencelibrary...

Other tips I've ritualized, use /collapse very often when on slack, and avoid message reactions with animated gifs. Animated things are why Slack will idle at 5%+. Lots of them and you're going to idle even higher.

Don't leave slack open on a channel where people frequently use /giphy or post lots of animated emojis (#random, etc). Reactions to comments with animated gifs are the worst, because /collapse wont hide them.

In my test locally, a chat window with no animated things is idling at 0-1.5% CPU. I just added 1 animated gif reaction to a comment and it's idling at 4-6%. It's absolutely horrible. I removed that comment and then posted using /giphy, now it's idling at 2-3%. A Slack Helper task started to run at 12%. Ran /collapse and both are back down to 0-1%.

Reacted to a message with 10 animated gifs, slack is idling at 9-12%. Slack Helper is at 26.9%. Brutal. Can't /collapse to fix this, either.

- In Advanced Settings, just turned on "Disable Emoji Spritesheet" and slack is idling at 7-9%, Slack Helper at 27-30%.

- In Accessibility Settings, disabled "Allow animated images and emoji" and Slack is idling at 0-1% and Slack Helper at 0-1%.

The point is the web is the most active platform.

The point is doing things right is not winning.

The reason you are missing the point is that you think it's only a technical problem.

It is not. It's technical + cultural + societal + historical + economical.

> It's hilariously easy to build an app in Qt Creator.

You fail to put yourself in a web dev shoes:

- they are the majority on the most popular plateform

- they don't have the time to lear a hole new tech or API. You don't realize the ton of stuff you need to learn to do half of what you can do with HTML + CSS + JS with QT. It's huge.

- then you have to learn all the edge cases for packaging, distributing, updating and maintaining this software. On multiple OS.

- then if you need a tutorial or a doc to help you, how does it compare to the web stack ?

- then if you need to have new people added to the team ?

- then if you need a custom widget ? reuse something that has been done ?

- then the licence ? The versions conflicts ?

And if only QT was much easier than the web stack. But as a Python dev, I did PyQT dev. And Web dev. And the ratio power/easiness/flexibility is not on QT side at all, it's a mess of a badly documented powerhouse with abstractions everywhere. You want to get the value of a cell in a table as a date ? Unwrap 3 layers of composed classes, each of them with their own API.

Then of course you will end up creating a client/server architecture (with threads, multiprocessing or else) for your app eventually to deal with background tasks, an MVC layer on top of QT's, and then some DB for persistance. And use their markup to generate the UI in a declarative way.

So basically all what constitute a web app.

Basically, you have to put all that in the balance VS speed, memory and battery life. What do you think won ?

If we want native clean apps back in the game, we need to make it easy and convenient for the new generation of devs to provide the features the new generation of users want.

Otherwise, we have lost and we'll be dinosaurs, while people will just buy more powerful computers because "32gb of ram is not enough to display all those albums, you need to upgrade".