It is exactly the failure of Microsoft and Apple to propose any meaningful cross-platform API. Both are fighting to increase vendor lock-in - it is in their best interests that apps written on Windows don't work on macOS/iOS and the other way round. Linux/OS folks themselves are unable to solve this problem on their own and it becomes a mouse-and-cat game.
The popularity of web apps helped to reduce the problem, but it still exists. Electron is only half a measure because the technology used is inefficient resource-wise and a platform optimized for the desktop would do the job better. If someone cared enough, they would allocate the necessary resources to minimize this problem (I don't believe solving it is effectively possible because of the complexity and bloat of current web technologies).
Microsoft has destroyed the Windows desktop singlehandedly on their own. Since Win8 and “Metro” they moved away from having consistent UI widgets like it was in Windows 2000 or XP but instead made the Windows desktop a Wild West if different UI paradigms. Even the ribbon introduced a new UI paradigm that wasn’t available to third party devs.
If even MS themselves doesn’t bother to be consistent then developers certainly won’t.
I am a long time Windows desktop dev but all my new projects are either web or Electron. I am done with the mess in Windows.
I don't get this. I've used GTK, Qt, Tk and FLTK software in OSX, Windows and Linux. The rest is usually covered by standard libraries and third party libraries.
So I take it this approach is disqualified on your terms for not being meaningful, which raises the question about what "meaningful" means.
My own guess is that it's a matter of convenience of distribution: enter an URL and you can start using the app.
I don't think that's the reason. Webapps got widespread when the Internet was still mostly consumed on the Desktop, which essentially meant Windows.
The main reason in my opinion is ease of distribution: it has always been painful and full of friction for the end user on Windows, and the web made it much easier.
You can see how on mobile platforms, where app distribution is not a big problem, native applications are still doing well.
Microsoft made .NET platform
cross platform years ago but a UI has been missing. They have a cross platform UI project now too
https://github.com/dotnet/maui
I don't know what you are talking about. Microsoft built a Linux compatible subsystem for Windows and also built (well, acquired) .NET VMs for OSX/Linux. It's trying hard to keep people on the desktop - any desktop.
Did you see that the top post on HN for a decent chunk of yesterday was celebrating that they were getting 200 rps? 200 rps was not something to brag about to your parents 15 years ago, but half of HN seems to have never heard of serving a static file through Nginx.
I don't want to be overdramatic but it confused the hell out of me and it made me worry about the industry. How can you have all these people cargo-culting into frameworks and languages and they don't know the fundamentals?
Development / product culture. Electron should have a fix time quantum, for example 6 weeks, and make performance:feature ratio 4:1. Otherwise, floods of ongoing features development will also produce "Bug as a Denial of Service", and performance improvement yields negative result.
What a lot of people don't appreciate is that a GUI platform is a essentially a marketplace like eBay.
There are "sellers" and "buyers". The sellers are the developers. The buyers are the users. Real money is often involved in the transaction.
Where do sellers go? Where there are the most buyers!
Where do buyers go? Where there are the most sellers!
Hence, marketplaces with no physical constraints are natural monopolies. This includes auction houses (eBay) and GUI platforms.
Previously, Windows had an over 90% market share, and it was glorious as a developer. You write your code once, and it works "everywhere", because everywhere is just Windows. The 9% Mac users are out of luck, and nobody cared about the mish-mash of 1% other.
Now the web is the new 90%. Or more specifically, Chromium is, with over 80% and climbing.
What saddens me is that Microsoft threw what they had away, and continue to do so. I've never seen a company more keen to undermine their own market position.
Microsoft's big money probably isn't Windows anymore, but Azure. Given that they make so much more money off their cloud offerings, I suspect that they actively want to kill off personal computing entirely. If so, they're doing a good job with recent Windows releases.
This is a bit of an aside - but can anyone explain why Electron apps use so much memory/system resources? Is this a fundamental thing or accidental thing and could be remedied rather easily? I wonder why there hasn't been significant effort directed toward this, as this is the number 1 issue of desktop applications today.
I have a few guesses/questions:
- What kind of data is causing the GBs of memory usage? Is it JS objects, cached content, intermediate rendering data?
- Chrome is architected as a multi-process app, in order to isolate and share resources between websites. Since Electron runs as a single app, it doesn't need this overhead, how hard would it be to turn it off?
-Would it gain us a lot if we removed v8/minimized JS on the 'frontend' and just pushed all the html from the 'backend'?
-Is using node as the backend the cause of excess resource usage, would using something else be better?
If desktops could make a platform where I can write my app in one language, host it on my own server and get global distribution running in a sandboxed environment then I'd consider it.
The web distribution model is just so much nicer for users and devs. No app stores, no install/uninstall process, no access to system internals.
I can deploy an app today and just send a link to my friends for them to use it. It takes a day just to put together an app store submission with all the necessary screenshots and configuration, not to mention the lengthy review process which could then deny me permission to launch.
The difficulty and uncertainty means that many MVPs launch web first where there's less risk, and more reach, for the same amount of effort. Only after a successful web launch are native apps developed.
Sure there are exceptions if the app requires features not yet available on the web (persistence, actually good multithreading, low level access) but the feature gap is closing slowly.
> If desktops could make a platform where I can write my app in one language, host it on my own server and get global distribution running in a sandboxed environment then I'd consider it.
It was called Java and ironically people hated it because it was sluggish and didn't use native widgets. Now we have webapps which reinvent the GUI on almost every site and have built in 100ms+ latencies. Go figure.
> The web distribution model is just so much nicer for users and devs. No app stores, no install/uninstall process, no access to system internals.
No ability to use it at all in an area with shitty network, no consistency, no integration, no respect for OS themes, no ability to continue using old versions if something is wrong with the new one...
> I can deploy an app today and just send a link to my friends for them to use it. It takes a day just to put together an app store submission with all the necessary screenshots and configuration, not to mention the lengthy review process which could then deny me permission to launch.
On Windows you could put your binary and libraries in a zip file and distribute to users in any variety of ways, including via web hosting. Macs could do the same thing with Application Bundles or their single-file applications before that.
> No app stores, no install/uninstall process, no access to system internals
the problem with app-stores is lock-in, but there's nothing wrong with repos in general e.g. linux package repositories.
What we really are missing is good sandboxes. We got there in browser/js-land, but it was hard progress; the constant attacks on web architecture and the value in overcoming it for e.g. online banking and purchase incentivised the effort to provide a solution.
If we had properly isolated executions environments, with whatever permissions model that implies, then that could be the basis of proper remote/auth-less execution; but even VMs/containers can't meet that guarantee.
Then we wouldn't need so much review process around app, or locked-down stores; installs could be pre-emptive and automatic, and system calls managed.
I suppose than rather make just a single one-off language, it would make more sense as a abstract/virtual-machine on which bytecode is executed, as the basis for other, proper language (ala the JVM).
A lot of players entered this space and some are actually profitable companies, but are none are as popular as Electron. aside from Javascript and WebAPIs, Electron is also free as in free beer.
Qt: is truly cross-platform, supporting Mac, Windows, Android, iOS, and even LG TV webOS. VLC uses Qt and is rock solid on all platforms it runs. It is very expensive for commercial development.
Xamarin: run on all major operating systems, and mobile, they were profitable. C# is much better language that C++ or Javascript. They became free to use once Microsoft acquired them
Web still has by far the best developer experience + cross platform stability, not to mention the lowest barrier to entry. I would be really interested to see what happens with Tauri[1] as that looks like a more promising alternative to Electron.
I do want to see a return to native apps but there are no worthwhile incentives to do so outside of "our customers demanded a native app."
> I do want to see a return to native apps but there are no worthwhile incentives to do so outside of "our customers demanded a native app."
I work in the public sector of Denmark, which has always had native Windows apps for most of our systems. The past few years of suppliers moving to web based solutions have been such a blessing.
Out of the around 300 it-systems we operate, the ones running in a browser are build on a web-front of some sort, electron, included are by far the favoured experience among our 10.000 users. We’ve run a benchmark on our major systems for the past decade, and the only ones to break a 8/10 rating among 500+ users are based on angular, react, electron or vue.
One of our old documenting systems has a Windows application and is also moving to a web-client. The old application scored a 1.2/10 the web client scored a 8.5/10. Covid had a massive impact on this, as the native client worked horribly over a DNS, but it never scored a rating over 5/10.
You can certainly put up the argument that Danish development houses should get better at building native applications, and that’s a fair point. Reality is that they aren’t, however, so the fact that these same developers are also building the new and well received web-based UIs is a good way to show how the impact goes far beyond developer experience.
I think Microsoft is the only company that has continually scored well on native applications that see massive usage, because the office package has always been popular. But isn’t much of the modern office UI build with react?
It doesn't help that for the major consumer platform (Windows), Microsoft can't make their mind up about how to replace Win32 or WinForms. It seems like every other week there is some new framework announced, so even if you have a need to make a native app, choosing how to do it has become near impossible. Is it .NET Maui? Should I try Electronize? or take a huge punt on Avalonia? It's easier just to wrap up a web app and hand it over. Sure, that is kicking the can down the road a bit, but until Microsoft can manage to provide something other than vague, half finished plans we're all in limbo.
> Web still has by far the best developer experience + cross platform stability, not to mention the lowest barrier to entry. I would be really interested to see what happens with Tauri[1] as that looks like a more promising alternative to Electron.
Compared to what?
C code I wrote in the 90s in middle school still compiles. JS code I wrote two weeks ago probably doesn't because the mountain of dependencies has shifted somewhere.
Even for 2017, this is extremely late thinking. Back in '10 it was clear the consumer desktop was dying a rapid death. Now professional and business software are going the same way, and it is no wonder because nobody respects desktop development anymore. The advent of tools like Cosmopolatan libc are looking too late and too "hard" for new developers to catch on, so far...
Why would anyone use Hyper? It's not like there aren't better terminal emulators out there for each platform. Using Electron to emulate a terminal is plain insanity to me, you are trading off performance and system resources for the js hype.
It feels like some point within the last few years tech became a place where you are identified by the tools you choose (ok, vim and emacs have been around). Not just that, but you sell your project based on those tools. So you can have that revolt app that showed up yesterday that for some ungodly reason disabled text selection on their website (user hostile as fuck) but it was getting advertised because it was Rust. The top selling point was theming via Electron. They have to sell the project before it's actually ready.
Blog posts like this are very thinly disguised advertisements for people like this guy who tweet all day about what tools they use. Which, he's successful, and more people are aware about this stuff than before. It used to be bad form to quote yourself, but tweet yourself? That's content.
I blame a big part of it on YC and the VC ethos of big big big instead of better better better.
Same reason Rust people use a package manager made in Rust, JS people use a package manager made in JS and Java people use a package manager made in Java, because it's close to the context you're already in and if you need to extend/modify/remove something for your own use/for the community, you already know how to do it.
I myself would never use Hyper, but I can see why people would. If there was a comfortable terminal in/for/with Clojure, I'd at least try it.
While I tend to agree that Electron is going to be more and more relevant, I'd like to counter-argument that native apps these days are accompanied by powerful vendor services. For example, if you target the Apple ecosystem you get CloudKit and can deploy syncing between devices very easily and translating operational infrastructure costs to the user. Need crypto? You have CryptoKit, and so on.
What this means: any app will try to expand to become multiplatform and multidevice but if that's the business case you are bound to be challenged by niche players that can execute better and with less cost for a single platform. I think both models can coexist, but niche players will always be niche players.
You can always extend Electron apps with platform-native capabilities.
Things like Neon [1], a wrapper for writing node bindings in Rust, make this particularly convenient. You can then use Rust to call into platform native APIs.
It's more work, but you can still benefit from cross platform UI development and augment it with native code where appropriate.
I want native apps because I want a native experience: Keyboard shortcuts and UX patterns should be consistent throughout most applications. I'm fine with some exceptions (e.g. video editing, photo editing, etc.), but generally I want consistency.
I want native apps because my bought RAM and CPU cycles are precious resources: they shouldn't be treated like a "free for all" by lazy devs. Not every native dev uses these sparingly, but in my professional experience, web devs often don't even consider it being a factor during development.
I want web apps to run in my web browser, so I can apply privacy-enabling plugins to them like uBlock. I also don't want web apps implementing dark patterns to get me into their hybrid app. (e.g. MS Teams forcing me to reconsider every time I open the website)
There’s nothing wrong with the industry wanting to switch to layout engines for desktop applications.
The problem is that this type of runtime environment is still fairly new. Desktop OS’s should have HTML/JS runtime built into the application layer, maybe even deeper. It’s such a dominant user functionality these days.
Instead we get a bunch of headless chrome instances. There needs to be an engine that maybe isn’t as performant as Electron, but is much smaller in memory and can handle these apps like Discord.
Gsuite, office365, etc, offer this as a _feature_. People have noticed.
Even as far as election goes, tons of people complain about the higher ram usage, bloat, etc. Sure, non technical users may not know why, but technical users do, and almost everybody notices a difference in some form or another.
All of the replies here seem to agree that the desktop market was shattered because it wasn't in any one parties interest to be cross platform, even Linux has multiple GUIs.
All of the solutions that are web based are resource hogs.
Mobile users are going to be stuck using "apps", and thus shouldn't be considered as part of general purpose computing.
All of this tells me there is a market opportunity for a capability based OS to sweep in and offer a desktop environment that allows running old programs, and even operating systems, in a sandbox. It has to be at least as good as Win32/Windows 2000/NT in terms of UI, and run on any modern CPU.
The sandboxes would have to be both secure and transparent enough normal users can get their work done. Hardware support would also be a huge factor. I doubt it's possible by anyone less than a FAANG company, and there isn't much money in the prospect, IMO.
We have been doing multiplatform development for a long time. It is in our company's interest not to depend on a single provider(like Apple, MS or Google) for anything.
It is also in those single provider interests to make you depend on them as much as they can, because every company wants to become a monopoly. If you can not change provider overnight, they have a virtual monopoly over you.
E.g MS spent literarily billions in order to make game developers to develop exclusively for Windows using technologies like DirectX and when people started using graphic cards for everything, like CAD, CAE, crypto, Microsoft(and Nvidia as her partner) benefited immensely from their virtual monopoly.
Technologies like objective C, C sharp, Azure or swift are designed so you can not escape the company platform. So easy to get in, so hard to move your code to other platforms once you have been programming for years on them.
Unless you spend as many Billions as Microsoft or Apple or Google has spent in alternative platforms, those alternative platforms will have significant caveats.
What we do is compromise, like with so many things in engineering. We use Linux, we use web technologies, but we also create native programs in Macs and Windows and tablets(Including Android NDK) because there is no way around it. You must use native for things that must be efficient and are extremely demanding, or some times it is just way easier. Most of our code, like 90-98% is portable libraries that we could use in every platform, but that 2% to 10% must be done native.
One of the great things of our approach is that we are not opinionated. We generate automatically code for different platforms, or different OS and we could just compare without prejudices. If tomorrow the Web backbend were as good as native we would shift our focus on that platform. But it is not today, very far from it.
If the only thing that you do is using programs like text editors that were available in the 90s, then sure, you can use electron for everything, spending gigabytes of memory for opening a single file.
But if you don't you are better served if you remember that it is going to be a constant fight. The price of freedom is eternal vigilance. Companies are never going to stop trying to lock you in, and you should never stop wanting more freedom.
"Technologies like objective C, C sharp, Azure or swift are designed so you can not escape the company platform. So easy to get in, so hard to move your code to other platforms once you have been programming for years on them."
FYI, Swift is available on Linux and Windows along with a significant chunk of its core libraries (e.g. https://github.com/apple/swift-corelibs-foundation) and app frameworks such as Vapor (used for writing web apps and APIs).
This approach works, and the user experience may be great. But it is very costly to build, and very costly to maintain. Compared to Electron, you need a few Javascript devs to spin up an app that runs on every major operating system AND in browser.
I think economics is the real reason they won. And Google pumped a lot of money in this space, too.
I have been using desktop applications for more than 30 years and web for more than 20 years now. I loathe web based applications as the next guy but can appreciate the convenient it provides.
As anything in life, it comes like a cycle and and after web it will probably be desktop again with a twist. Most likely a desktop with local-first software paradigm [1]. That will not happen until the two important issues are solved, firstly seamless distributed data replication and security.
The first issue can probably be solved by Commutative Replicated Data Type (CRDT) and/or Operational Transformation (OT) but not merely for editors but also for more general applications [2].
The second security issue could be solved by enabling working seamlessly for offline and online, and it will probably adhere to the zero trust architecture [3]. Personally I'm working on trying to solve on this issue now, and the Global Area Networking (GAN) initiatives for examples ZeroTier and Tailscale are going in the right direction.
The last desktop app I wrote was in Delphi 5, so I guess it was around 20 years ago. Back then my impression was that it's already a done deal, desktop is no more - so I'm a bit surprised that someone waited until 2017 to write this text?
Actually last few years I think desktop is having a bit of a come back with a plethora of cross-platform tools like electron becoming more usable and popular...
This is absolutely great, because it allows cross platform usage, often without the developers doing anything at all.
For example, it meant that I was able to join a Microsoft Teams meeting from my phone, without installing any apps (I prefer to rely on my browser's sandbox to protect me from abusive behavior apps like to engage in). They do refuse to work in Firefox and you need to switch Chrome to desktop mode, but it works. Not perfectly, but well enough.
It also means that teams with limited resources can reuse a lot of code across platforms, making cross-platform development much more likely to happen.
The technological change is following the changes in the nature of software development.
Perhaps the most important one is the wide-spread contamination with the poisonous mix of VC money with the start-up "move fast and break things" mentality. Notice how the arguments pro Electron always include speed of development, speed of deployment, etc. (dev-focused) and the counter-arguments include performance, usability, etc. (user-focused). Using Electron is mainly beneficial for the developers - they don't need to have so much experience, there's plenty of JS developers available, they don't need to try hard.
Another one is the voracity for control and captive user bases. Nowhere does it become more clear that one has no say in the direction a piece of software is going than when using a web app. Today when you load the app the menu's on top, tomorrow it's hidden on the left, next week you're part of an A/B test and so on. Enjoy the ride and consider yourself lucky if you can at least export your data.
On the native side, both Apple and Google have tried hard (and succeeded) to reduce the value of software to about 1 EUR. This has led to bogus subscription models and an extreme proliferation of ads and tracking. Microsoft have gone crazy years ago and made a complete mess of their desktop offering - one wouldn't know what to develop in even if they wanted to build a native application. And most Windows apps have such mediocre looks, that an Electron app may even be an upgrade. :-)
Finally, the thing that bothers me the most - way too many developers are working on building an online public image, an attractive GitHub profile (and it has to be GitHub), a following. We're in the era of performative software development. The peacocking and the drama reserved for the silliest of the artistic domains are now firmly entrenched in the online world of software development. What the front-end development community lacks in experience and common sense more than makes up for in numbers and willingness to quarrel.
Here's something funny in closing: the Nylas Mail project mentioned in the article has been meanwhile abandoned. But apparently one of the orignal authors created a fork called Mailspring. Directly quoted from the first paragraph of the GitHub README:
"It replaces the JavaScript sync code in Nylas Mail with a new C++ sync engine based on Mailcore2. It uses roughly half the RAM and CPU of Nylas Mail and idles with almost zero "CPU Wakes", which translates to great battery life. It also has an entirely revamped composer and other great new features."
There's an elegance and beauty to the raw power of a program running natively on the CPU that a bumbling hippo like Electron can never dream of. Commercial software development always had a survival of the fittest aspect to it, but now we're stuck in a local optimum where mediocre but easier to develop solutions are able to evolve fast enough and make enough money or draw enough of a community to survive and thrive - at least until the VC money runs out or the devs get tired of the clumsiness of the hippo.
[+] [-] hdjjhhvvhga|4 years ago|reply
The popularity of web apps helped to reduce the problem, but it still exists. Electron is only half a measure because the technology used is inefficient resource-wise and a platform optimized for the desktop would do the job better. If someone cared enough, they would allocate the necessary resources to minimize this problem (I don't believe solving it is effectively possible because of the complexity and bloat of current web technologies).
[+] [-] spaetzleesser|4 years ago|reply
If even MS themselves doesn’t bother to be consistent then developers certainly won’t.
I am a long time Windows desktop dev but all my new projects are either web or Electron. I am done with the mess in Windows.
[+] [-] boomlinde|4 years ago|reply
So I take it this approach is disqualified on your terms for not being meaningful, which raises the question about what "meaningful" means.
My own guess is that it's a matter of convenience of distribution: enter an URL and you can start using the app.
[+] [-] mrighele|4 years ago|reply
You can see how on mobile platforms, where app distribution is not a big problem, native applications are still doing well.
[+] [-] alkonaut|4 years ago|reply
[+] [-] HWR_14|4 years ago|reply
[+] [-] _nhh|4 years ago|reply
[+] [-] swiley|4 years ago|reply
[+] [-] preommr|4 years ago|reply
What was less obvious was that electron would grow this big and still be this bad. How is the memory usage still so inefficient?
[+] [-] crazy_horse|4 years ago|reply
I don't want to be overdramatic but it confused the hell out of me and it made me worry about the industry. How can you have all these people cargo-culting into frameworks and languages and they don't know the fundamentals?
[+] [-] Existenceblinks|4 years ago|reply
tldr; just pay tech debt ASAP.
[+] [-] jiggawatts|4 years ago|reply
There are "sellers" and "buyers". The sellers are the developers. The buyers are the users. Real money is often involved in the transaction.
Where do sellers go? Where there are the most buyers!
Where do buyers go? Where there are the most sellers!
Hence, marketplaces with no physical constraints are natural monopolies. This includes auction houses (eBay) and GUI platforms.
Previously, Windows had an over 90% market share, and it was glorious as a developer. You write your code once, and it works "everywhere", because everywhere is just Windows. The 9% Mac users are out of luck, and nobody cared about the mish-mash of 1% other.
Now the web is the new 90%. Or more specifically, Chromium is, with over 80% and climbing.
What saddens me is that Microsoft threw what they had away, and continue to do so. I've never seen a company more keen to undermine their own market position.
[+] [-] AnIdiotOnTheNet|4 years ago|reply
[+] [-] cxr|4 years ago|reply
Mozilla.
[+] [-] torginus|4 years ago|reply
I have a few guesses/questions:
- What kind of data is causing the GBs of memory usage? Is it JS objects, cached content, intermediate rendering data?
- Chrome is architected as a multi-process app, in order to isolate and share resources between websites. Since Electron runs as a single app, it doesn't need this overhead, how hard would it be to turn it off?
-Would it gain us a lot if we removed v8/minimized JS on the 'frontend' and just pushed all the html from the 'backend'?
-Is using node as the backend the cause of excess resource usage, would using something else be better?
[+] [-] admax88qqq|4 years ago|reply
The web distribution model is just so much nicer for users and devs. No app stores, no install/uninstall process, no access to system internals.
I can deploy an app today and just send a link to my friends for them to use it. It takes a day just to put together an app store submission with all the necessary screenshots and configuration, not to mention the lengthy review process which could then deny me permission to launch.
The difficulty and uncertainty means that many MVPs launch web first where there's less risk, and more reach, for the same amount of effort. Only after a successful web launch are native apps developed.
Sure there are exceptions if the app requires features not yet available on the web (persistence, actually good multithreading, low level access) but the feature gap is closing slowly.
[+] [-] AnIdiotOnTheNet|4 years ago|reply
It was called Java and ironically people hated it because it was sluggish and didn't use native widgets. Now we have webapps which reinvent the GUI on almost every site and have built in 100ms+ latencies. Go figure.
> The web distribution model is just so much nicer for users and devs. No app stores, no install/uninstall process, no access to system internals.
No ability to use it at all in an area with shitty network, no consistency, no integration, no respect for OS themes, no ability to continue using old versions if something is wrong with the new one...
> I can deploy an app today and just send a link to my friends for them to use it. It takes a day just to put together an app store submission with all the necessary screenshots and configuration, not to mention the lengthy review process which could then deny me permission to launch.
On Windows you could put your binary and libraries in a zip file and distribute to users in any variety of ways, including via web hosting. Macs could do the same thing with Application Bundles or their single-file applications before that.
[+] [-] Chris2048|4 years ago|reply
the problem with app-stores is lock-in, but there's nothing wrong with repos in general e.g. linux package repositories.
What we really are missing is good sandboxes. We got there in browser/js-land, but it was hard progress; the constant attacks on web architecture and the value in overcoming it for e.g. online banking and purchase incentivised the effort to provide a solution.
If we had properly isolated executions environments, with whatever permissions model that implies, then that could be the basis of proper remote/auth-less execution; but even VMs/containers can't meet that guarantee.
Then we wouldn't need so much review process around app, or locked-down stores; installs could be pre-emptive and automatic, and system calls managed.
I suppose than rather make just a single one-off language, it would make more sense as a abstract/virtual-machine on which bytecode is executed, as the basis for other, proper language (ala the JVM).
[+] [-] sally1620|4 years ago|reply
Qt: is truly cross-platform, supporting Mac, Windows, Android, iOS, and even LG TV webOS. VLC uses Qt and is rock solid on all platforms it runs. It is very expensive for commercial development.
Xamarin: run on all major operating systems, and mobile, they were profitable. C# is much better language that C++ or Javascript. They became free to use once Microsoft acquired them
[+] [-] hresvelgr|4 years ago|reply
I do want to see a return to native apps but there are no worthwhile incentives to do so outside of "our customers demanded a native app."
[1] https://tauri.studio/en/
[+] [-] moksly|4 years ago|reply
I work in the public sector of Denmark, which has always had native Windows apps for most of our systems. The past few years of suppliers moving to web based solutions have been such a blessing.
Out of the around 300 it-systems we operate, the ones running in a browser are build on a web-front of some sort, electron, included are by far the favoured experience among our 10.000 users. We’ve run a benchmark on our major systems for the past decade, and the only ones to break a 8/10 rating among 500+ users are based on angular, react, electron or vue.
One of our old documenting systems has a Windows application and is also moving to a web-client. The old application scored a 1.2/10 the web client scored a 8.5/10. Covid had a massive impact on this, as the native client worked horribly over a DNS, but it never scored a rating over 5/10.
You can certainly put up the argument that Danish development houses should get better at building native applications, and that’s a fair point. Reality is that they aren’t, however, so the fact that these same developers are also building the new and well received web-based UIs is a good way to show how the impact goes far beyond developer experience.
I think Microsoft is the only company that has continually scored well on native applications that see massive usage, because the office package has always been popular. But isn’t much of the modern office UI build with react?
[+] [-] smackeyacky|4 years ago|reply
[+] [-] xvector|4 years ago|reply
Every native app I have ever used has been many times snappier than its Electron/Web equivalent. Think on why customers demand native apps.
[+] [-] kongin|4 years ago|reply
Compared to what?
C code I wrote in the 90s in middle school still compiles. JS code I wrote two weeks ago probably doesn't because the mountain of dependencies has shifted somewhere.
[+] [-] vbezhenar|4 years ago|reply
Isn't customer demands are the main incentive for any developer?
[+] [-] bsenftner|4 years ago|reply
[+] [-] SPBS|4 years ago|reply
[+] [-] crazy_horse|4 years ago|reply
Blog posts like this are very thinly disguised advertisements for people like this guy who tweet all day about what tools they use. Which, he's successful, and more people are aware about this stuff than before. It used to be bad form to quote yourself, but tweet yourself? That's content.
I blame a big part of it on YC and the VC ethos of big big big instead of better better better.
[+] [-] capableweb|4 years ago|reply
I myself would never use Hyper, but I can see why people would. If there was a comfortable terminal in/for/with Clojure, I'd at least try it.
[+] [-] pantulis|4 years ago|reply
What this means: any app will try to expand to become multiplatform and multidevice but if that's the business case you are bound to be challenged by niche players that can execute better and with less cost for a single platform. I think both models can coexist, but niche players will always be niche players.
[+] [-] the_duke|4 years ago|reply
Things like Neon [1], a wrapper for writing node bindings in Rust, make this particularly convenient. You can then use Rust to call into platform native APIs.
It's more work, but you can still benefit from cross platform UI development and augment it with native code where appropriate.
[1] https://github.com/neon-bindings/neon
[+] [-] refactor_master|4 years ago|reply
Who are these users? Under what circumstances do they “want” such things?
[+] [-] ByteWelder|4 years ago|reply
I want native apps because my bought RAM and CPU cycles are precious resources: they shouldn't be treated like a "free for all" by lazy devs. Not every native dev uses these sparingly, but in my professional experience, web devs often don't even consider it being a factor during development.
I want web apps to run in my web browser, so I can apply privacy-enabling plugins to them like uBlock. I also don't want web apps implementing dark patterns to get me into their hybrid app. (e.g. MS Teams forcing me to reconsider every time I open the website)
[+] [-] mastrsushi|4 years ago|reply
The problem is that this type of runtime environment is still fairly new. Desktop OS’s should have HTML/JS runtime built into the application layer, maybe even deeper. It’s such a dominant user functionality these days.
Instead we get a bunch of headless chrome instances. There needs to be an engine that maybe isn’t as performant as Electron, but is much smaller in memory and can handle these apps like Discord.
[+] [-] hyperhopper|4 years ago|reply
Gsuite, office365, etc, offer this as a _feature_. People have noticed.
Even as far as election goes, tons of people complain about the higher ram usage, bloat, etc. Sure, non technical users may not know why, but technical users do, and almost everybody notices a difference in some form or another.
[+] [-] MattGaiser|4 years ago|reply
How many people would know that Slack and Spotify are basically just web apps too?
[+] [-] mikewarot|4 years ago|reply
All of the solutions that are web based are resource hogs.
Mobile users are going to be stuck using "apps", and thus shouldn't be considered as part of general purpose computing.
All of this tells me there is a market opportunity for a capability based OS to sweep in and offer a desktop environment that allows running old programs, and even operating systems, in a sandbox. It has to be at least as good as Win32/Windows 2000/NT in terms of UI, and run on any modern CPU.
[+] [-] paulryanrogers|4 years ago|reply
Still, it could be marvelous.
[+] [-] bumbada|4 years ago|reply
We have been doing multiplatform development for a long time. It is in our company's interest not to depend on a single provider(like Apple, MS or Google) for anything.
It is also in those single provider interests to make you depend on them as much as they can, because every company wants to become a monopoly. If you can not change provider overnight, they have a virtual monopoly over you.
E.g MS spent literarily billions in order to make game developers to develop exclusively for Windows using technologies like DirectX and when people started using graphic cards for everything, like CAD, CAE, crypto, Microsoft(and Nvidia as her partner) benefited immensely from their virtual monopoly.
Technologies like objective C, C sharp, Azure or swift are designed so you can not escape the company platform. So easy to get in, so hard to move your code to other platforms once you have been programming for years on them.
Unless you spend as many Billions as Microsoft or Apple or Google has spent in alternative platforms, those alternative platforms will have significant caveats.
What we do is compromise, like with so many things in engineering. We use Linux, we use web technologies, but we also create native programs in Macs and Windows and tablets(Including Android NDK) because there is no way around it. You must use native for things that must be efficient and are extremely demanding, or some times it is just way easier. Most of our code, like 90-98% is portable libraries that we could use in every platform, but that 2% to 10% must be done native.
One of the great things of our approach is that we are not opinionated. We generate automatically code for different platforms, or different OS and we could just compare without prejudices. If tomorrow the Web backbend were as good as native we would shift our focus on that platform. But it is not today, very far from it.
If the only thing that you do is using programs like text editors that were available in the 90s, then sure, you can use electron for everything, spending gigabytes of memory for opening a single file.
But if you don't you are better served if you remember that it is going to be a constant fight. The price of freedom is eternal vigilance. Companies are never going to stop trying to lock you in, and you should never stop wanting more freedom.
[+] [-] sciprojguy|4 years ago|reply
FYI, Swift is available on Linux and Windows along with a significant chunk of its core libraries (e.g. https://github.com/apple/swift-corelibs-foundation) and app frameworks such as Vapor (used for writing web apps and APIs).
[+] [-] sally1620|4 years ago|reply
I think economics is the real reason they won. And Google pumped a lot of money in this space, too.
[+] [-] teleforce|4 years ago|reply
As anything in life, it comes like a cycle and and after web it will probably be desktop again with a twist. Most likely a desktop with local-first software paradigm [1]. That will not happen until the two important issues are solved, firstly seamless distributed data replication and security.
The first issue can probably be solved by Commutative Replicated Data Type (CRDT) and/or Operational Transformation (OT) but not merely for editors but also for more general applications [2].
The second security issue could be solved by enabling working seamlessly for offline and online, and it will probably adhere to the zero trust architecture [3]. Personally I'm working on trying to solve on this issue now, and the Global Area Networking (GAN) initiatives for examples ZeroTier and Tailscale are going in the right direction.
[1] https://martin.kleppmann.com/papers/local-first.pdf
[2] https://arxiv.org/abs/1810.02137
[3] https://csrc.nist.gov/publications/detail/sp/800-207/final
[+] [-] ivanhoe|4 years ago|reply
Actually last few years I think desktop is having a bit of a come back with a plethora of cross-platform tools like electron becoming more usable and popular...
[+] [-] MisterBastahrd|4 years ago|reply
Hooray indirect wins!
[+] [-] asperous|4 years ago|reply
[+] [-] soniman|4 years ago|reply
[+] [-] tgsovlerkhgsel|4 years ago|reply
For example, it meant that I was able to join a Microsoft Teams meeting from my phone, without installing any apps (I prefer to rely on my browser's sandbox to protect me from abusive behavior apps like to engage in). They do refuse to work in Firefox and you need to switch Chrome to desktop mode, but it works. Not perfectly, but well enough.
It also means that teams with limited resources can reuse a lot of code across platforms, making cross-platform development much more likely to happen.
[+] [-] siproprio|4 years ago|reply
Also very importantly: Are users paying premium for the Nylas Electron Qwality, or is it cheaper to just use Office 365/AWS/Google?
[+] [-] blub|4 years ago|reply
Perhaps the most important one is the wide-spread contamination with the poisonous mix of VC money with the start-up "move fast and break things" mentality. Notice how the arguments pro Electron always include speed of development, speed of deployment, etc. (dev-focused) and the counter-arguments include performance, usability, etc. (user-focused). Using Electron is mainly beneficial for the developers - they don't need to have so much experience, there's plenty of JS developers available, they don't need to try hard.
Another one is the voracity for control and captive user bases. Nowhere does it become more clear that one has no say in the direction a piece of software is going than when using a web app. Today when you load the app the menu's on top, tomorrow it's hidden on the left, next week you're part of an A/B test and so on. Enjoy the ride and consider yourself lucky if you can at least export your data.
On the native side, both Apple and Google have tried hard (and succeeded) to reduce the value of software to about 1 EUR. This has led to bogus subscription models and an extreme proliferation of ads and tracking. Microsoft have gone crazy years ago and made a complete mess of their desktop offering - one wouldn't know what to develop in even if they wanted to build a native application. And most Windows apps have such mediocre looks, that an Electron app may even be an upgrade. :-)
Finally, the thing that bothers me the most - way too many developers are working on building an online public image, an attractive GitHub profile (and it has to be GitHub), a following. We're in the era of performative software development. The peacocking and the drama reserved for the silliest of the artistic domains are now firmly entrenched in the online world of software development. What the front-end development community lacks in experience and common sense more than makes up for in numbers and willingness to quarrel.
Here's something funny in closing: the Nylas Mail project mentioned in the article has been meanwhile abandoned. But apparently one of the orignal authors created a fork called Mailspring. Directly quoted from the first paragraph of the GitHub README:
"It replaces the JavaScript sync code in Nylas Mail with a new C++ sync engine based on Mailcore2. It uses roughly half the RAM and CPU of Nylas Mail and idles with almost zero "CPU Wakes", which translates to great battery life. It also has an entirely revamped composer and other great new features."
There's an elegance and beauty to the raw power of a program running natively on the CPU that a bumbling hippo like Electron can never dream of. Commercial software development always had a survival of the fittest aspect to it, but now we're stuck in a local optimum where mediocre but easier to develop solutions are able to evolve fast enough and make enough money or draw enough of a community to survive and thrive - at least until the VC money runs out or the devs get tired of the clumsiness of the hippo.
[+] [-] WA|4 years ago|reply
You kinda oversimplify the multi-platform reality of 2021 and its requirements from a user perspective.
Most apps used to be Windows-only. Nowadays, most apps need to be Windows, macOS, iOS and Android. This is a user-focused requirement.
"It's either a multi-platform Electron app or it is no macOS app, because we don't have the resources". See this post linked here a couple days ago: https://nielsleenheer.com/articles/2021/why-electron-apps-ar...