The web is swallowing the desktop whole (2017)(char.gd)
char.gd
The web is swallowing the desktop whole (2017)
https://char.gd/blog/2017/the-web-is-swallowing-the-desktop-whole-and-nobody-noticed
255 comments
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.
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'm in the same boat. I was asked recently to develop a small custom app for a library that would need to be maintained for decades. This left me scratching my head as to which GUI technology to choose to minimize the danger of it being broken/unsupported after 10 years. Paradoxically, I think Win32 might be the safest choice as MS can't really innovate (=break) too much here anymore (although I might underappreciate their skills in this regard).
Emacs Lisp would probably rank even higher.
Or DOS. You can run DOSBox on anything including a web browser.
Parent said GUI though.
You can run GUIs on DOS. A lot of DOS software had GUIs.
Well that's all well and good but it doesn't explain why even Mac OS devs are moving en masse to building for the web.
SwiftUI keeps breaking stuff constantly.
Maybe they want their programs to be useable by non Mac users too?
Mac devs have been complaining for a long time that Xcode and the entire developer experience sucks. It sucks (1) in the way that most native development sucks, and (2) an extra layer of suck on top of that.
The Mac platform also used to be very insulated; the culture meant that the prospect of creating an app or simple utility and selling it was viable much longer than it was on Windows, where the culture is that everything is either gratis-style free or warez-style free. The invasion of the Web means that Mac users are increasingly being conditioned to get things for free, too, so the viability of paid apps has taken a big hit. SaaS is the way to make money now.
The Mac platform also used to be very insulated; the culture meant that the prospect of creating an app or simple utility and selling it was viable much longer than it was on Windows, where the culture is that everything is either gratis-style free or warez-style free. The invasion of the Web means that Mac users are increasingly being conditioned to get things for free, too, so the viability of paid apps has taken a big hit. SaaS is the way to make money now.
Yes. I would argue that it is precisely the obsession with cross-platform that has destroyed native desktop applications. If all you are offering with your native desktop framework is a dumbed-down experience, because it has to also run on tablets and phones and TVs and game consoles and smart refrigerators, then you quickly get to a place where there are few advantages in going native over shipping a webapp in a Chrome wrapper.
Windows 8 was a catastrophic failure, and Apple seems to be leaning into the same failed philosophy now.
Windows 8 was a catastrophic failure, and Apple seems to be leaning into the same failed philosophy now.
It is not really "obsession", it is economics. There is a high cost with maintaining different apps for different platforms.
“and Apple seems to be leaning into the same failed philosophy now.”
I agree but when you look at their profits it seems MS and Apple are doing the right thing even if I don’t like it as a developer.
I agree but when you look at their profits it seems MS and Apple are doing the right thing even if I don’t like it as a developer.
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.
You're kidding, right? WSL is not related to cross-platform GUIs we're talking about, and .NET Core doesn't support Windows Forms/WPF - and probably never will, for the reasons mentioned above.
That's not completely true, while WSL doesn't help Windows GUI apps to be more cross-platform, it does help Linux GUI apps to work on Windows[0]
So to refer back to the top comment we could say that Microsoft is proposing WSL as a cross-platform API for GUI apps.
[0] https://docs.microsoft.com/en-us/windows/wsl/tutorials/gui-a...
So to refer back to the top comment we could say that Microsoft is proposing WSL as a cross-platform API for GUI apps.
[0] https://docs.microsoft.com/en-us/windows/wsl/tutorials/gui-a...
The real bonus are the TUI apps tho. No idea what Windows users did all the years without proper command line commands, now if they include a proper shell they could really make a dent in the Linux desktop stats
W11 only, sadly.
Hmm, you're right, I didn't see that part. It seems their original plans[0] have changed...
[0] https://devblogs.microsoft.com/commandline/the-initial-previ...
[0] https://devblogs.microsoft.com/commandline/the-initial-previ...
>.NET Core doesn't support Windows Forms/WPF
It does actually although you are correct in your general point.
It does actually although you are correct in your general point.
WSL lets people run their Linux apps with Linux GUIs on Windows. It makes Linux apps cross-platform, which makes sense if your business proposition is "literally all software runs on windows, and some software also runs on non-Windows. Choose wisely"
And, IIRC, .NET Core doesn't support WPF forms for legal/trademark reasons. But other MSFT supported .NET Forms libraries that happen to be API/feature compatible work on Windows/OSX/Linux/Android/iOS.
And, IIRC, .NET Core doesn't support WPF forms for legal/trademark reasons. But other MSFT supported .NET Forms libraries that happen to be API/feature compatible work on Windows/OSX/Linux/Android/iOS.
Microsoft is also driving the development of React Native for Windows and MacOS.
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.
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.
Isn’t it that most software written today has to target the web? So you have two distinct platforms to write to: web, and non-web. Even if Microsoft and Apple came up with a brilliant, singular API, that’s still one more API that has to be coded to. With solutions like Electron, you have a very fast time-to-market with a “desktop” app, and your engineering team only needs to target the web. Customers will only notice the fundamental issues with the solution after it’s too late (or they won’t care.)
Sadly, the solution seems very business-driven. The ROI threshold to making a desktop-native app is quite high.
Sadly, the solution seems very business-driven. The ROI threshold to making a desktop-native app is quite high.
Why do you have to target the web as a platform if you already have sufficient platform-native support in your application?
That's a good question. I can think of a handful of reasons, but I am sure there are more. 1) ease of use. It's much easier to tell a prospective customer a URL than instructions on how to download/install/run a local application (if they even have permission to do so.) 2) Ecosystem. If your customers are generating content that needs searching, sharing, or collaboration, it has to be on the web in some capacity. 3) (Unfortunately) Shiny object syndrome. Browser-based applications have an innate appeal that outmoded desktop applications lack.
None of those UI libs work on Android or iOS.
I think that's a huge part of it. Most of the users nowadays are using smartphones and tablets.
Qt does.
It is very niche, and again only if you go with C++. For most Apps that are not games, using C++ is probably overkill on mobile just so you can use Qt. And you will still have to come up with a mobile optimized UI, as a standard desktop UI layout will just not work on 5" screens.
https://wiki.qt.io/Language_Bindings
> And you will still have to come up with a mobile optimized UI, as a standard desktop UI layout will just not work on 5" screens.
No tool will magically solve this problem for you. Qt has excellent support for responsive design if that's how you'd propose to solve it.
And no, Qt is not very niche.
> And you will still have to come up with a mobile optimized UI, as a standard desktop UI layout will just not work on 5" screens.
No tool will magically solve this problem for you. Qt has excellent support for responsive design if that's how you'd propose to solve it.
And no, Qt is not very niche.
Qt has done a fantastic job in this space. It is also isn't cheap. It is only free for GPLv3 software.
I use Qt for anything cross-platform. The main problem is that C++ is not an easy language for UI developments. also consider the fact that C++ devs are paid higher that Java, JS or C# devs. Most other UI toolkits are really terrible for cross-platform development.
> GTK, Qt, Tk and FLTK
Aren't all of those C/C++? There's time and place for manually managing memory, figuring out UB and segfaults. If you're trying to render a frame full of AAA graphics in under 15 milliseconds, or go through a million requests a second, then I don't mind it. But if I'm just writing an email client...
Aren't all of those C/C++? There's time and place for manually managing memory, figuring out UB and segfaults. If you're trying to render a frame full of AAA graphics in under 15 milliseconds, or go through a million requests a second, then I don't mind it. But if I'm just writing an email client...
> Aren't all of those C/C++?
No.
> If you're trying to render a frame full of AAA graphics in under 15 milliseconds
Irrelevant.
> But if I'm just writing an email client...
Use bindings.
No.
> If you're trying to render a frame full of AAA graphics in under 15 milliseconds
Irrelevant.
> But if I'm just writing an email client...
Use bindings.
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
They almost always have a cross platform UI project going until they abandon it and start a new one :(
No, they always had a Windows-only UI project going until they abandon it and start a new one. Having a cross-platform UI project going until they abandon it and start a new one is something new under Satya.
Satya seems a true visionary and disrupter :)
I'm not sure he's a visionary. He's more into going with the flow, mimicking successful competitors. Amazon went big with AWS? Let's try to do the same! Google and FB are tracking everybody? We can do it, too! Apple is pushing updates on their mobile devices? We can do it on our desktops but in a way that makes everyone mad! All phone manufacturers add fluff to their devices? We can bundle adware, too! People love Linux? Let's add it to to Windows! They also like open source? Well, we can't buy that, but we can buy GitHub!
The list could go on but the point I doubt Nadella is a visionary, he's just following others. Not necessarily a bad thing for the company and its shareholders, it's a fairly safe approach. I miss the days when they actually had original ideas, like the Kinect.
The list could go on but the point I doubt Nadella is a visionary, he's just following others. Not necessarily a bad thing for the company and its shareholders, it's a fairly safe approach. I miss the days when they actually had original ideas, like the Kinect.
I didn't even know maui existed. Pretty ambitious - unlike the Jetbrains initiative, this one is for desktop and mobile.
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.
You can see how on mobile platforms, where app distribution is not a big problem, native applications are still doing well.
You certainly see that in business. My corporate customers don't want to install anything on the desktop other than Office (and I don't think they like that very much).
This isn't new, I remember talking to the CIO of a big bank twenty years ago about this.
On top of that users quite like software delivered through a browser as it allows them to bypass their IT department.
From the consumer side it's more about costs, people will tolerate all sorts of shit as long as it's free.
This isn't new, I remember talking to the CIO of a big bank twenty years ago about this.
On top of that users quite like software delivered through a browser as it allows them to bypass their IT department.
From the consumer side it's more about costs, people will tolerate all sorts of shit as long as it's free.
Web applications didn't see wide-spread use until after the release of the iPhone. Prior to that most applications were native or Java.
It has to do with mobile networks rolling out usable broadband (3G) that enabled people to be connected anywhere all the time, which coincided with the iPhone 3G release in 2008.
I still remember how awesome it was I could stream music sitting at a train station while browsing the internet.
I still remember how awesome it was I could stream music sitting at a train station while browsing the internet.
Apple shipped X11. It’s really just Microsoft.
Jetbrains cares. https://github.com/HumbleUI/JWM
That comparison is pretty weird. Electron is more extensible than JavaFX? How does that work? Browser engines are not exactly famous for their sophisticated API extensibility or advanced text/graphics APIs.
I love JetBrains products and their approach. If I had any interest in writing Java (or desktop) I would love to work there and be part of the mission.
I like their approach, too. Just by looking at this project GitHub page, one can clearly see the list of supported features and not yet working/planned, which is essentially all I need from such a project. Seems obvious, but very few projects realize this/care enough to make it crystal clear like JB did.
Everyone noticed.
What was less obvious was that electron would grow this big and still be this bad. How is the memory usage still so inefficient?
What was less obvious was that electron would grow this big and still be this bad. How is the memory usage still so inefficient?
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?
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?
Frameworks are there to make development more accessible. So I can completely understand how one might trade on a framework without understanding the fundamentals.
Whats Nginx. Is that AWS.
(Kidding)
As has been the case since the emergence of MicroSoft, companies in software/internet rely on general ignorance of users/developers for their business plans to succeed. Making people smarter and more self-reliant, running their own software for themselves, is not part of the plan. Making them reliant on someone else is the plan.
Desktop has too much potential for user control. Web is safely under the control of a handful of gatekeeper companies. Earlier HN submission today was promotion of a book by Microsoft Chief Legal Officer about how people are not competent to run their own software and should therefore let companies like MS run it for them in the cloud. Foreward written by Chief Marketing Officer, Microsoft. (Kidding again)
(Kidding)
As has been the case since the emergence of MicroSoft, companies in software/internet rely on general ignorance of users/developers for their business plans to succeed. Making people smarter and more self-reliant, running their own software for themselves, is not part of the plan. Making them reliant on someone else is the plan.
Desktop has too much potential for user control. Web is safely under the control of a handful of gatekeeper companies. Earlier HN submission today was promotion of a book by Microsoft Chief Legal Officer about how people are not competent to run their own software and should therefore let companies like MS run it for them in the cloud. Foreward written by Chief Marketing Officer, Microsoft. (Kidding again)
> Whats Nginx. Is that AWS.
Nah, it's Kubernetes
Nah, it's Kubernetes
Put it this way - most websites probably never reach single digit rps. And it really doesn't matter if the limit is 200 rps when a website is only serving 1 rps.
Then there will be so many people involved in website building that the 1-2% who know what is going on will be enough to overwhelm the demand of people who need to run high-scale websites.
People might waste an order of magnitude more resources than they need in the process, but realistically the absolute value lost is small.
Then there will be so many people involved in website building that the 1-2% who know what is going on will be enough to overwhelm the demand of people who need to run high-scale websites.
People might waste an order of magnitude more resources than they need in the process, but realistically the absolute value lost is small.
Requests aren't made equal. I don't have an opinion about the manga hosting site, but I have worked on a website where many read requests required a lot of heavy joins other data work for actual useful work and weren't really cacheable, as every used requested his own data. Here's an example: https://cs.fastcup.net/match6279498/stats
Manga hosting is the poster child for slowly-changing, largely read only static content. A bunch of thumbnails and some text, with a basic search function.
The site you linked is more interesting. It's the type of thing where the obvious optimisation would be to perform the complex processing in-memory for live games, and then return a single precomputed static document blob for old games. (I assume the match results don't change over time.)
Most sites have data that isn't anywhere near as "live" as the developers assume it is...
The site you linked is more interesting. It's the type of thing where the obvious optimisation would be to perform the complex processing in-memory for live games, and then return a single precomputed static document blob for old games. (I assume the match results don't change over time.)
Most sites have data that isn't anywhere near as "live" as the developers assume it is...
> I assume the match results don't change over time.
In this example of one match they don't, but there's a lot of aggregates that are functions of live data.
In this example of one match they don't, but there's a lot of aggregates that are functions of live data.
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.
tldr; just pay tech debt ASAP.
tldr; just pay tech debt ASAP.
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.
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.
Yes, this chart tells you everything:
https://static.seekingalpha.com/uploads/2019/7/31/49654246-1...
https://static.seekingalpha.com/uploads/2019/7/31/49654246-1...
With the move to subscription services like Office 365, and the startling number of incompetents that think VDI terminals are acceptable workstations for users, I could definitely see Windows desktop disappearing in the next decade or so, the OS merely being a bootloader for a browser.
Everything will be either a Chromebook or EdgeBook, basically.
Everything will be either a Chromebook or EdgeBook, basically.
Modern OSes are little more than bootloaders and thin driver layers for Discord and Chrome anyway.
> a company more keen to undermine their own market position
Mozilla.
Mozilla.
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?
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?
As I understand it, the chrome team have tended towards using more memory as a way of improving performance (i.e. trading space for time), with the feeling being that most systems have quite a lot of memory (relatively speaking) so why not use it.
This isn't a one off thing so would be challenging to change. It's more a case of many small decisions about increasing memory usage that in aggregate add up.
This isn't a one off thing so would be challenging to change. It's more a case of many small decisions about increasing memory usage that in aggregate add up.
Tk and gtk2 apps were performant and used way less memory so that doesn’t seem like it should be necessary.
I might be wrong here so someone correct me but I believe it's because every time you open a new electron app, you are opening another instance of Chrome. So if you have Chrome, VSCode and Figma running, that's 3 instances of Chrome each eating their respective 2-3GB of memory and associated CPU cycles.
You are not wrong, but there are multiple billion dollar companies that build their products on top of Electron. Presumably they could afford to hire engineers or Google could step in and optimize Chrome's renderer for Electron's use cases.
I may be wrong, but as things are now, Electron, more or less packages an unmodified, headless Chromium.
I may be wrong, but as things are now, Electron, more or less packages an unmodified, headless Chromium.
Fundamental architectural decisions in the Chromium code cannot be solved via patching no matter how many billions are thrown at it. Would likely need a large rewrite which is effectively a new project.
Yes, and if you allow it, an Electron app can just open the chrome debugger you know on the browser part of the app. There is a messaging system between that and the node part, to provide stuff like file access.
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.
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.
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
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
> 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.
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.
You have a lot of gripes.
> It was called Java and ironically people hated it because it was sluggish and didn't use native widgets.
First, Java is in use on plenty of systems. It has all but disappeared as a serious client side system - but not because of performance. Java failed more because it failed to meet market expectations, especially in ease of use. Other solutions were more agile in creating better platforms on the client side.
> Now we have webapps which reinvent the GUI on almost every site
This is not an impediment to adoption. This is clearly seen on such successful historical software like winamp which intentionally abandoned fitting the mold. X has not historically had much consistency at all for GUI. Xlib, Motive, GTK, Qt/KDE, at any given time there has been many options to pick from.
You do lose system-consistency, and that can be a negative. However, you gain platform consistency in your application appearing the same on pretty much every device. It's not a total negative.
> and have built in 100ms+ latencies. Go figure.
Webapps do not need to hit the backend for every little thing. That latency requirement really depends on how much data is appropriate to send to the client and the development philosophy of the developer. For personally owned data it can certainly live on the client and have a replication stream to the cloud system and have no built-in network latency. This is not a hard requirement for a webapp.
> 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...
Webapps (PWAs, electron, cordova, and websites for that matter) can all work offline if they are designed that way. Just like native software can be built to require the mothership to do anything and behave just like a traditional website. This issue is more mindset than fundamental to the technology.
You hit the OS integration side pretty hard. The software solves a problem, its success depends on that. All this integration is simply a list of "nice to haves". The market has shown time and time again that spending too much on your hobby features rather than what the customer's actually want is not a long term winning devopment strategy.
Look at it from the user side. If some slightly slower, loud looking software solves my problem 200% better than my current native solution - I'm switching.
> It was called Java and ironically people hated it because it was sluggish and didn't use native widgets.
First, Java is in use on plenty of systems. It has all but disappeared as a serious client side system - but not because of performance. Java failed more because it failed to meet market expectations, especially in ease of use. Other solutions were more agile in creating better platforms on the client side.
> Now we have webapps which reinvent the GUI on almost every site
This is not an impediment to adoption. This is clearly seen on such successful historical software like winamp which intentionally abandoned fitting the mold. X has not historically had much consistency at all for GUI. Xlib, Motive, GTK, Qt/KDE, at any given time there has been many options to pick from.
You do lose system-consistency, and that can be a negative. However, you gain platform consistency in your application appearing the same on pretty much every device. It's not a total negative.
> and have built in 100ms+ latencies. Go figure.
Webapps do not need to hit the backend for every little thing. That latency requirement really depends on how much data is appropriate to send to the client and the development philosophy of the developer. For personally owned data it can certainly live on the client and have a replication stream to the cloud system and have no built-in network latency. This is not a hard requirement for a webapp.
> 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...
Webapps (PWAs, electron, cordova, and websites for that matter) can all work offline if they are designed that way. Just like native software can be built to require the mothership to do anything and behave just like a traditional website. This issue is more mindset than fundamental to the technology.
You hit the OS integration side pretty hard. The software solves a problem, its success depends on that. All this integration is simply a list of "nice to haves". The market has shown time and time again that spending too much on your hobby features rather than what the customer's actually want is not a long term winning devopment strategy.
Look at it from the user side. If some slightly slower, loud looking software solves my problem 200% better than my current native solution - I'm switching.
> 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.
Would you really do that though? Or would you run a random exe from a random zip hosted from a random website?
Would you really do that though? Or would you run a random exe from a random zip hosted from a random website?
If you trust a developer - why not? And if not then an app store model is not a panacea - there are examples of pushing fraudulent/malicious app into them.
Better sandboxing would be welcome, but it coming to desktop slowly (and it typically can only limit damage from a malicious app, but not prevent it fully).
Web-apps come with own security trade-off: infrastructure can have poor security and data can be leaked (and or destroyed) by hackers, a government can request all you data without you knowing about this, your data can be abused by an web-app creator e. g. sold to an Ad targeting company.
Better sandboxing would be welcome, but it coming to desktop slowly (and it typically can only limit damage from a malicious app, but not prevent it fully).
Web-apps come with own security trade-off: infrastructure can have poor security and data can be leaked (and or destroyed) by hackers, a government can request all you data without you knowing about this, your data can be abused by an web-app creator e. g. sold to an Ad targeting company.
Literally all the time.
Don't get me wrong, I'd much prefer if Windows had implemented proper application sandboxing.
Don't get me wrong, I'd much prefer if Windows had implemented proper application sandboxing.
> 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).
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).
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."
[1] https://tauri.studio/en/
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/
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.
That train left long back; nobody wants a Windows-only app when half the management are using Macs.
Unless of course you're taking about pro apps like AutoCad or Photoshop; but they have never been electron and unlikely to ever be.
Unless of course you're taking about pro apps like AutoCad or Photoshop; but they have never been electron and unlikely to ever be.
We have plenty of Windows-only customers. We're still giving them wrapped web apps when they ask for desktop applications.
Because even if the customer is all-Windows, developers sure aren't (unless you're a C#-exclusive sweatshop, maybe?), and stuff like Bootstrap+jQuery is more stable than Windows GUI toolkits these days. Lower development costs and lower ongoing maintenance costs, win-win.
Because even if the customer is all-Windows, developers sure aren't (unless you're a C#-exclusive sweatshop, maybe?), and stuff like Bootstrap+jQuery is more stable than Windows GUI toolkits these days. Lower development costs and lower ongoing maintenance costs, win-win.
There are cross-platform toolkits that render using native controls. Bootstrap+jQuery and Win32 are not the only two possible options.
GTK, which we can't use easily due to licensing headaches and deprecates useful widgets faster than we can try to use them, or Qt, which we can't use due easily to licensing headaches and with QtQuick is just web apps in more complicated, or smaller frameworks, which already looked terrible when they were new?
And outside a hard, but small core of Mac users, native controls also aren't a selling point to end users. They're harder to work with, more difficult to style, to no advantage to an end user who more often than not couldn't even tell you what the native controls of Windows are. (And I suspect most Microsoft employees can't either, if Windows 10/11 is any indication.)
And outside a hard, but small core of Mac users, native controls also aren't a selling point to end users. They're harder to work with, more difficult to style, to no advantage to an end user who more often than not couldn't even tell you what the native controls of Windows are. (And I suspect most Microsoft employees can't either, if Windows 10/11 is any indication.)
https://docs.microsoft.com/en-us/dotnet/maui/what-is-maui
.NET Multi-platform App UI (.NET MAUI) is a cross-platform framework for creating native mobile and desktop apps with C# and XAML. Using .NET MAUI, you can develop apps that can run on Android, iOS, macOS, and Windows from a single shared code-base.
.NET Multi-platform App UI (.NET MAUI) is a cross-platform framework for creating native mobile and desktop apps with C# and XAML. Using .NET MAUI, you can develop apps that can run on Android, iOS, macOS, and Windows from a single shared code-base.
No linux. Where 25% of .net developers are. Its not going to fly.
25% of .NET developers are on Linux!? Got an actual statistic to back that up? I would estimate more like 0.25%...
I thought I did but I misread one of the graphs on the Stack Overflow 2021 survey. So no.
I use Debian as my daily driver for .NET core and was looking to see how many other developers had dropped Visual Studio for VSCode, but the graph was not how many had switched, but how many want to. My mistake.
I still think ignoring linux for gui apps will hurt microsoft, we all see the success of VSCode and want to build universal apps like that for our clients too.
I use Debian as my daily driver for .NET core and was looking to see how many other developers had dropped Visual Studio for VSCode, but the graph was not how many had switched, but how many want to. My mistake.
I still think ignoring linux for gui apps will hurt microsoft, we all see the success of VSCode and want to build universal apps like that for our clients too.
The app that kills Photoshop will run on Electron. Figma has 100% convinced me of this, if you can make an app where the UI remains responsive and fluid like Figma and graphics heavy lifting is done in a way that doesn’t choke the UI I think you’ll pretty much eat their lunch like Figma did to Sketch, Illustrator and XD.
You have to remember that Photoshop is pretty poorly optimized for modern hardware, a ton of it is single core constrained and they just haven’t cared about regressions, on Windows at least the whole app chokes for a second every time you drag the window around, it’s laughable.
You have to remember that Photoshop is pretty poorly optimized for modern hardware, a ton of it is single core constrained and they just haven’t cared about regressions, on Windows at least the whole app chokes for a second every time you drag the window around, it’s laughable.
Figma is written in C++. I guess all web-devs should learn C++ ?
For some platforms the official way to do things now is to make it a web app. Consider Microsoft Word Add Ins. The official way to do them now is with JS, React or Angular.
I have seen this indecision as a death knell on a few projects. You really just have to pick something, especially if you stop developing the soon to be deprecated tooling.
If it takes you two years to pick a new method, then all your developer community has to sit on their laurels. They can't invest in the old platform, they can't invest in novel tooling of their own, and they can't build with the new thing because you haven't chosen it yet.
If it takes you two years to pick a new method, then all your developer community has to sit on their laurels. They can't invest in the old platform, they can't invest in novel tooling of their own, and they can't build with the new thing because you haven't chosen it yet.
I honestly feel like this is it for native Windows apps. It's over. GTK+ and Wayland will be more supportable in the future if WSLg gets pushed out far enough.
Ha, and on the mac side we now have AppKit, SwiftUI and Catalyst and any combination of those you feel like.
The big difference is that all three of them are still fully supported, and continue to receive updates.
On Windows, 90% of UI toolkits are deprecated with no support, no bug fixes, nor migration guides.
On Windows, 90% of UI toolkits are deprecated with no support, no bug fixes, nor migration guides.
That's fair. The fact that updates and fixes are shipped with OS versions makes it less useful (for us at least). People just don't upgrade their desktops like they do their phones.
> 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."
Every native app I have ever used has been many times snappier than its Electron/Web equivalent. Think on why customers demand native apps.
Every native app I have ever used has been many times snappier than its Electron/Web equivalent. Think on why customers demand native apps.
How can you say that customers are demanding native apps when only a minuscule number of users can tell if an app is native or not? Most are not even familiar with the term native; desktop installed app (of all types) vs browser app at best.
Don't confuse ignorance with indifference. Most people can't tell you anything about engines but they certainly can feel that a Porche drives better than a Camry. When you talk about Electron you'll hear things like "why is my computer so slow" or "my fans are always on" or "my battery life is terrible": people will know, but they won't know it's Electron.
We’re not demanding native apps at all. We’re demanding apps that work on our system of choice and get regular updates.
If Electron is what it takes then I’ll use an Electron app and not care.
If Electron is what it takes then I’ll use an Electron app and not care.
> get regular updates.
Most non-tech people I know detest auto-updates.
Most non-tech people I know detest auto-updates.
Updates are the last thing I want as a user, thank you very much. Windows and constantly shifting UI of various apps have soiled this concept altogether in the minds of many users.
But are you willing to pay 2x for that extra snappiness?
So you started writing crappy apps because it was easier for you and now you want to be paid double to fix your shit?
Quality is generally more expensive, particularly the finely tuned kind.
Depends on how bad it is and how important snappiness is. Apps that aren't snappy cause all kinds of cognitive problems with attention.
They will ask for Open Source alternatives, we have seen this for more than a decade. I only saw a few comments that say "you should get rid of free tier" per year.
$5 -> this looks cheap, probably poor quality
$49 -> this is quite too much
$99 -> are you kidding me> our customers demanded a native app
Isn't customer demands are the main incentive for any developer?
Isn't customer demands are the main incentive for any developer?
It is not enough that customers demand. Customers also need to be willing to quit the product over it.
> 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.
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.
Command-line C-application is "simple". But if you want to give access to your centrally managed (and updated) app to anybody in the world who has browser and internet, it gets more complicated. It gets complicated because you have to program both the client and the server and make sure it works on multiple browsers including cell-phones.
So even though basic command-line C-apps are great in terms of maintainability they also typically do less than modern web-apps.
So even though basic command-line C-apps are great in terms of maintainability they also typically do less than modern web-apps.
JavaScript is the lingua franca of the web. Therefore Node.js is a great platform for web-apps. There is also DENO which allows you to compile your JavaScript. For Node.js there is something similar in terms of Vercel/Pkg.
There are benefits to using the same language for both the front-end and back-end.
There are benefits to using the same language for both the front-end and back-end.
> 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?
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?
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...
Re: cosmopolitan libc: As cool as it is, I don't think the barrier to widespread adoption of C as a greenfield language for application development was ever that things didn't run cross-platform, it was, you know, the footguns and complexity of building anything significant in C.
I don't know how old you are, but at 57 and having been "computing" for 35 years, I'd say that this is wrong, on two levels.
1. C has been the green field language for application for decades.
2. The major obstacle is precisely cross-platform development; without a fairly thick layer to abstract away the OS API/platform, it's very difficult.
In addition to those two, there's the detail that lots of development projects want in-browser capabilities, and that essentially rules out compiled languages (ignoring the developing options for webasm, even though they still do not take it as far as native C/C++).
1. C has been the green field language for application for decades.
2. The major obstacle is precisely cross-platform development; without a fairly thick layer to abstract away the OS API/platform, it's very difficult.
In addition to those two, there's the detail that lots of development projects want in-browser capabilities, and that essentially rules out compiled languages (ignoring the developing options for webasm, even though they still do not take it as far as native C/C++).
I'm a developer in my mid 20s with a few friends who are software engineers. None of them worked with C for years.
The jobs here are JavaScript, Java, Python, etc.
The jobs here are JavaScript, Java, Python, etc.
Depends on where you live I guess ? When I was in Bordeaux there were almost as many c/c++ jobs than java/php/js jobs, and more than Python jobs.
The modern reality is that most, 99.99%, of all software does not need the performance nor engineering flexibility that is C/C++. couple that with multiple generations of new developers being told "memory management is too hard for your poor little brains" and similar bullshit - nowadays it is rare to find a young developer that is not downright afraid of C/C++. Plus, the greybeard C/C++ guru is not at all helpful in many locations, having been corporate abused for decades at this point...
Cosmopolitan libc is fun as a toy but not something you can ship software on. Its design is just fundamentally disconnected from how operating systems work today.
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.
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.
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.
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.
[1] https://github.com/neon-bindings/neon
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
So now you get all the bloat of a bundled web browser and the completely-non-native GUI of a website plus the all the security of a native application?
Are there any solid statistics on what “users” demand? This keeps being thrown around: “users want, demand and need native desktop applications”.
Who are these users? Under what circumstances do they “want” such things?
Who are these users? Under what circumstances do they “want” such things?
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)
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)
Thank you! I prefer native applications for the same reasons. Whenever we hear advocacy of web apps, it’s always from devs about dev problems. “I don’t have to learn more than one language!” and “Distribution is easier!” and “no AppStore rules!” and “It’s easier to monetize + no sharing revenue with the store vendor!” and “I don’t have to worry about supporting multiple versions floating around!” These are all developer problems, not user’s problems. I think we are shifting to more web based software simply because users really don’t have much pull—they take whatever junk is available.
Dev problems can also reasonably be construed to mean extra cost/schedule to produce the item. Customers also care about cost and availability.
I agree with the browser sandbox. I think PWAs are a better approach than electron for most desktop oriented webapps. Retains the full browser sandbox including extensions, and you don't need a full 2nd browser running - faster launch and lower footprint. Just a website with a native-ish looking install and skin.
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.
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.
Chrome is not memory-hungry. Webapps are.
I didn’t think of it that way, It’s probably a tug war
Chrome has stellar engineering work done on it. It'd bet it's in the top 10 of the most optimized pieces of software ever. It's because of this work that modern web applications are even possible.
The consequence - perhaps unintended - is that the web application practices all settled around extremely wasteful but "fast enough" patterns. It takes extra work and going against the grain to make web applications performant, and rarely anyone bothers.
The consequence - perhaps unintended - is that the web application practices all settled around extremely wasteful but "fast enough" patterns. It takes extra work and going against the grain to make web applications performant, and rarely anyone bothers.
In my experience what you're describing is true. JIRA Scrum is abused by businesses to implicitly blackmail teams into delivering ASAP, that means shortcuts and dependencies to "get shit done". All else is secondary. Tech debt? Put it in the backlog. "Good enough" is king. Every fault attributed to "stupid web devs" is just a projection to mask the true anxiety that the market has deemed expert, artisanal engineering irrelevant to profit and success. A comment above was lauding a fork of an open source electron app for implementing a C++ backend: good luck convincing a business to do that. Microsoft probably does this for VS Code precisely because their demographic are people who profess sensitivity to these types of details, but the broader population is not.
I don't even care about the memory footprint personally. I can buy more RAM. It's that every Electron app makes up all of it's own navigation paradigms, doesn't integrate well into the OS, and always feels slow.
I find this pretty funny.
In the 00s and early 10s, the Linux desktop was criticized because of the inconsistency in the look and feel, e.g. using Firefox (GTK) in KDE (Qt) plus random apps in Motif, TK, or straight up Swing. The consistency of Windows and OS X desktops was desired and looked for: people migrated themes across toolkits, synchronized font settings, etc.
Now every Electron app does their own thing and people don't seem to care one bit, but when I need to use one of them I feel like I'm using a different CSS-enhanced, antialias-enabled 90s Winamp skin for each app.
In the 00s and early 10s, the Linux desktop was criticized because of the inconsistency in the look and feel, e.g. using Firefox (GTK) in KDE (Qt) plus random apps in Motif, TK, or straight up Swing. The consistency of Windows and OS X desktops was desired and looked for: people migrated themes across toolkits, synchronized font settings, etc.
Now every Electron app does their own thing and people don't seem to care one bit, but when I need to use one of them I feel like I'm using a different CSS-enhanced, antialias-enabled 90s Winamp skin for each app.
yes, this sort of objection is always fake
It's not fake, it's just that it's been drowned out by a wave of people who are indifferent or ignorant.
Or have simply learned helplessness. Developers actually listening to users is so 90s.
Ironically, look and feel consistency on Linux is now excellent. Most things are written in GTK or Qt, and it's not hard to get them looking identical. It's even possible to run a system that uses entirely Qt apps on top of KDE, which gets you Win95 levels of consistency.
People got used to having every UI be its own special snowflake thanks to 20+ years of web. Consistency is now more of a niche demand.
yea but chromium has been ported to everything so your app will work exactly the same on any device chromium runs, that's the issue with writing native apps.. you then have to port it to all the devices and update on OS changes.
Qt works in more places than chromium and is much more native - it's even the native platform for multiple OSes
Case in point: Qt works on Haiku, Chrome doesn't.
Qt also since recently started working on Serenity :)
I love building UIs with HTML and I am ok with building JavaScript.
BUT this would not be the solution. People would still run different html and js engines and everything would be a mess. Not to mention the js ecosystem with its dependency creeps isn't known to be efficient. There have been and are plenty of other multi platform languages that have less platform issues. Like: Java or Haxe.
That said I am pretty sure gnome shell comes with a complete js API.
BUT this would not be the solution. People would still run different html and js engines and everything would be a mess. Not to mention the js ecosystem with its dependency creeps isn't known to be efficient. There have been and are plenty of other multi platform languages that have less platform issues. Like: Java or Haxe.
That said I am pretty sure gnome shell comes with a complete js API.
> 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.
They all do but good luck convincing any developer to develop something they have to test in multiple places with different engines when they can just only test in chrome and ship a bloated executable and the problem is negated.
They all do but good luck convincing any developer to develop something they have to test in multiple places with different engines when they can just only test in chrome and ship a bloated executable and the problem is negated.
> good luck convincing any developer to develop something they have to test in multiple places with different engines
Ooh, this is such a good point! I am one such developer.
Ooh, this is such a good point! I am one such developer.
... "And nobody noticed"???
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.
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.
I’m not sure that is the point of the article. Gsuite and Office 365 run in the browser, so people know that those are web apps.
How many people would know that Slack and Spotify are basically just web apps too?
How many people would know that Slack and Spotify are basically just web apps too?
For people well acquainted with computers, it's obvious in every little UI interaction. Web views feel different to native toolkits.
For everyone else, all doubt is removed when the app presents you a 501 or 404 error.
For everyone else, all doubt is removed when the app presents you a 501 or 404 error.
[deleted]
People complain 50x more when there is no mac or Linux version. There is no realistic solution that suits everyone.
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.
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.
Still, it could be marvelous.
Still, it could be marvelous.
It's possible, and for 15 years I've been saying it'll be here in 20... so 5 more to go.
Don't drink the Kool Aid.
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.
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).
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).
C# is also cross-platform. .NET Framework has been completely replaced with .NET Core now (and renamed to simply .NET).
The only part of cross-platform support that's a little wonky is the GUI, but that's because Forms is just a thin wrapper over the Win32 forms API and WPF was built around DirectX. But that should get a lot better in a couple months when Microsoft releases MAUI (Multi-Platform App UI).
The only part of cross-platform support that's a little wonky is the GUI, but that's because Forms is just a thin wrapper over the Win32 forms API and WPF was built around DirectX. But that should get a lot better in a couple months when Microsoft releases MAUI (Multi-Platform App UI).
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 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.
[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
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
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...
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...
The Linux desktop finally succeeded even though nobody is running Linux on their desktops.
Hooray indirect wins!
Hooray indirect wins!
40 million Chromebooks will be shipped in 2021!
This comment saddens me.
When I see Chromebooks being mentioned, I always think about "One Tablet Per Child" charity from Person of Interest show.
(Slight spoiler for season 4)
Giving every child in the country a free tablet with Internet access, loaded with quality educational software sounds like a great good, but is it so good if it also comes loaded with surveillance equipment and is controlled by a malicious AI attempting to control human society?
(Chromebooks aren't free and Google isn't an evil general AI, but it is a multinational adtech corporation, which is as close as you can get to amoral GAI in the real world today.)
(Slight spoiler for season 4)
Giving every child in the country a free tablet with Internet access, loaded with quality educational software sounds like a great good, but is it so good if it also comes loaded with surveillance equipment and is controlled by a malicious AI attempting to control human society?
(Chromebooks aren't free and Google isn't an evil general AI, but it is a multinational adtech corporation, which is as close as you can get to amoral GAI in the real world today.)
Pretty much exactly my concern. This isn't some philanthropic group doing this. It's Google, and everything that comes with it.
Calling a Chromebook (or Android) "Linux" is disingenuous for the purpose of "The Linux Desktop" "winning". We all know that a proprietary user-land stapled on top of the Linux kernel and all the applications running in a web browser is not what was meant by "year of the Linux Desktop". Hell, Google will likely replace Linux with Fuchsia within the decade.
[deleted]
How so?
because those web apps run on linux webserver
Because now you can have the same (web)apps than everybody else. (And you have games, too)
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.
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.
How is it going for the Nylas Email Client? Does it still exist?
Also very importantly: Are users paying premium for the Nylas Electron Qwality, or is it cheaper to just use Office 365/AWS/Google?
Also very importantly: Are users paying premium for the Nylas Electron Qwality, or is it cheaper to just use Office 365/AWS/Google?
In the telecom business, low latency is viewed as a competitive advantage!
Bonus points if your competitor pays their employee's in US Dollars! Means we can make a BETTER product, for cheaper!
[1]: https://www2.deloitte.com/us/en/insights/industry/telecommun...
Bonus points if your competitor pays their employee's in US Dollars! Means we can make a BETTER product, for cheaper!
[1]: https://www2.deloitte.com/us/en/insights/industry/telecommun...
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.
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.
> Notice how the arguments pro Electron always include speed of development, speed of deployment, etc. (dev-focused)
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...
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...
Quite an awkward link that. Deep down the author feels bad from the cognitive dissonance experienced by offering an inferior solution and they are writing as a means of catharsis, more to convince themselves than others.
It's doubtful that most apps need to be cross-platform to such an extent. Any of those markets has such a large number of buyers that there should be no problem to build a company like the one mentioned in your link. At the same time all of those markets suffer from various pathologies which makes it difficult to build such a business. Market dynamics make it very hard to make a profit and deliver quality software that doesn't stab the user in the back through ads, subscriptions, tracking, etc.
Using Electron is a compromise done by the business for the business, not for the customers. They need money from more people, but don't have the resources or skills to deliver, so they resort to the only solution which helps them achieve their goals, however full of compromises it may be. Let's not pretend that they're going cross-platform only so that the poor macOS users have access to hair salon software.
It's doubtful that most apps need to be cross-platform to such an extent. Any of those markets has such a large number of buyers that there should be no problem to build a company like the one mentioned in your link. At the same time all of those markets suffer from various pathologies which makes it difficult to build such a business. Market dynamics make it very hard to make a profit and deliver quality software that doesn't stab the user in the back through ads, subscriptions, tracking, etc.
Using Electron is a compromise done by the business for the business, not for the customers. They need money from more people, but don't have the resources or skills to deliver, so they resort to the only solution which helps them achieve their goals, however full of compromises it may be. Let's not pretend that they're going cross-platform only so that the poor macOS users have access to hair salon software.
Honestly I can't fathom the same company that made vs code which is really snappy for an electron app made Teams. It's almost like the best electron app vs the worst electron app.
Probably different teams and a cast difference in developer experience. MS likely didn't care that much about teams.
That doesn't show from how they use Teams. It's literally integrated into Windows 11.
> MS likely didn't care that much about teams.
If you’ve ever had to work with MS recently it’s honestly all they talk about so I don’t think that’s the case.
Think it’s more a case the VS Code team are probably passionate VS Code users so care about what they’re building.
If you’ve ever had to work with MS recently it’s honestly all they talk about so I don’t think that’s the case.
Think it’s more a case the VS Code team are probably passionate VS Code users so care about what they’re building.
This also represents that Windows and Mac OS are no longer the only operating systems. Chrome and Firefox are closely equivalent. And Chrome is the leader with its dominance on Android and Desktop systems.
iOS is the only threat left and if any of the anti-trust measures against Apple are able to break Apple’s grip on the iOS enough to let Chrome or an equivalent browser act as an OS equivalent to what Chrome could do on Android, we could see a very different app ecosystem in the next decade.
iOS is the only threat left and if any of the anti-trust measures against Apple are able to break Apple’s grip on the iOS enough to let Chrome or an equivalent browser act as an OS equivalent to what Chrome could do on Android, we could see a very different app ecosystem in the next decade.
The crap dev environments for iOS and Android are the real reasons people gave up on native.
2017? Anything new since then on this you think?
Yes, WASM is happening and slowly creeping into the web. The web five years ago was basically dom trees and javascript. Flash had been marginalized by then. HTML 5 + javascript was basically the only way to do web applications. Now we have web applications like Figma that are part written in C++ that have elements in their UI that are rendered in a canvas. Another one is Miro.
The next big leap here is WASM progressing to the point where e.g. garbage collection work is finished, which will enable a whole range of languages to easily target WASM as well (without having to bring their own GC). For example, Jetbrains announced a few months ago that they are working on a WASM compiler for Kotlin that will rely on this. MS has been targeting WASM as well with blazor. This will likely take another few years to mature.
Other trends are reactive frameworks like jetpack compose and swift UI slowly creeping into the mobile space. Jetbrains is actually working on web and desktop variants of compose. So cross platform UI development might become a lot easier. I expect that there will be multiple reactive frameworks for different languages available for use with wasm in browsers in a few years. Right now, it's mostly C/C++ and frameworks like QT and GTK being used for that. More choice might change a few things.
The next big leap here is WASM progressing to the point where e.g. garbage collection work is finished, which will enable a whole range of languages to easily target WASM as well (without having to bring their own GC). For example, Jetbrains announced a few months ago that they are working on a WASM compiler for Kotlin that will rely on this. MS has been targeting WASM as well with blazor. This will likely take another few years to mature.
Other trends are reactive frameworks like jetpack compose and swift UI slowly creeping into the mobile space. Jetbrains is actually working on web and desktop variants of compose. So cross platform UI development might become a lot easier. I expect that there will be multiple reactive frameworks for different languages available for use with wasm in browsers in a few years. Right now, it's mostly C/C++ and frameworks like QT and GTK being used for that. More choice might change a few things.
This is really a win for Google, since most of these web apps are easily ported to ChromeOS. and it is going to continue as ChromeOS is gaining even more market share.
Mobile is also eating the desktop whole. As much as I love personal computers I can't deny the fact that my phone became my main computer due to how convenient it is.
I should probably look into Linux phones before the corporations turn my phone into an appliance.
I should probably look into Linux phones before the corporations turn my phone into an appliance.
Does it? Any form of productivity app seems to be nerfed on mobile...
Desktop is coming back.
I wish it were true, but I don't think it is. Personal computing as a mainstream concept is dead. The modern developer no longer seeks to enable users to leverage the power of computing, they seek to corral users and farm their eyeballs for ad revenue. The future is appliances that will only ever be used when and how the developer wants them to be used, because the modern developer has no respect for users. Nothing will interoperate, nothing will respect user choices, nothing will be free of ads, everything will suffer latencies due to the network, nobody will be able to store their data locally under their own control.
This is the future we've built for ourselves, and we don't even have the decency to be ashamed of it.
This is the future we've built for ourselves, and we don't even have the decency to be ashamed of it.
"The web is swallowing the desktop whole"
You mean computer applications which require internet connection.
You mean computer applications which require internet connection.
Electron apps are still desktop apps.
The web however did eat the desktop: everything other the browser and the text editor is now a web app.
I have literally 4 apps that I use on my machine: terminal and postman in addition to the above.
I am wondering why mobile apps too haven't entirely been replaced by Web apps
The web however did eat the desktop: everything other the browser and the text editor is now a web app.
I have literally 4 apps that I use on my machine: terminal and postman in addition to the above.
I am wondering why mobile apps too haven't entirely been replaced by Web apps
> everything other the browser and the text editor is now a web app.
The media creation community is looks at the web programming community and wondering what the hell you are talking about, and why your view is so narrow.
Blender, ZBrush, Unreal Engine, Visual Studio, ProTools, Reaper, Substance Suite etc. etc. the list goes on and on. These kind of applications often have extremely heavy system requirements and are often extremely sensitive to latency, and are just not going up and "migrate to the cloud" anytime soon.
Embedded programming is another example. A lot of developers work in this space.
> I have literally 4 apps that I use on my machine: terminal and postman in addition to the above.
Your personal requirements, as lightweight and easily offloadable as they are, do not represent the wider community. I am constantly astounded by how blinkered the web community appears to be about this.
The media creation community is looks at the web programming community and wondering what the hell you are talking about, and why your view is so narrow.
Blender, ZBrush, Unreal Engine, Visual Studio, ProTools, Reaper, Substance Suite etc. etc. the list goes on and on. These kind of applications often have extremely heavy system requirements and are often extremely sensitive to latency, and are just not going up and "migrate to the cloud" anytime soon.
Embedded programming is another example. A lot of developers work in this space.
> I have literally 4 apps that I use on my machine: terminal and postman in addition to the above.
Your personal requirements, as lightweight and easily offloadable as they are, do not represent the wider community. I am constantly astounded by how blinkered the web community appears to be about this.
Visual effects artists and embedded programmers are very niche communities (former embedded SW engineer here). Probably something like 90% of people just need a browser 90% of the time. It's kind of a no brainer from a business point of view. If your app can be browser based and still functional, it should be. Of course there are drawbacks but the economics are in the browser's favor.
> If your app can be browser based and still functional, it should be.
We can choose to disagree on this point, however...
>> everything other the browser and the text editor is now a web app
It is a long way from the parent's comment (above) to "if your app can be browser based and still functional, it should be".
Maybe it should, maybe it shouldn't, but that doesn't contradict my point that the parent is incorrect in that "everything other the browser and the text editor is now a web app". You're arguing a different thing.
There are plenty of apps, as I described above, that don't have functional web-based equivalents, and probably will not for a very long time to come. There are enough niche industries with such requirements that combined, they will act as a counterweight to the push for everything to run as a web app for quite some time.
We can choose to disagree on this point, however...
>> everything other the browser and the text editor is now a web app
It is a long way from the parent's comment (above) to "if your app can be browser based and still functional, it should be".
Maybe it should, maybe it shouldn't, but that doesn't contradict my point that the parent is incorrect in that "everything other the browser and the text editor is now a web app". You're arguing a different thing.
There are plenty of apps, as I described above, that don't have functional web-based equivalents, and probably will not for a very long time to come. There are enough niche industries with such requirements that combined, they will act as a counterweight to the push for everything to run as a web app for quite some time.
"If your app can be browser based and still functional, it should be. Of course there are drawbacks but the economics are in the browser's favor"
This right here is the reason there are many browser-based apps - it's really convenient for the company, damn the users. The company can do whatever they want, whenever they want and have full access to both telemetry and user data.
This right here is the reason there are many browser-based apps - it's really convenient for the company, damn the users. The company can do whatever they want, whenever they want and have full access to both telemetry and user data.
[deleted]
> everything other the browser and the text editor is now a
web app
video editing, DAWs, music notation, CAD/CAM, 3D modelling (think Blender), compilers, linkers, IDE's other than VSCode, local photo management, media players, messaging services (telegram etc), device management ... these and many more called and laughed at your claim.
video editing, DAWs, music notation, CAD/CAM, 3D modelling (think Blender), compilers, linkers, IDE's other than VSCode, local photo management, media players, messaging services (telegram etc), device management ... these and many more called and laughed at your claim.
IIRC you can use fusion 360 in the browser now?
WhatsApp is of course available on the web. I'm a regular user of play.spotify.com, works great. Figma is a great design tool available only on the web.
I do get your point, but there are more and more things moving to the web as more and more standards are being published (if you think this is a good idea is another discussion).
Modern html and CSS is by far the least complex GUI framework I've used. And it is (somewhat) cross platform.
WhatsApp is of course available on the web. I'm a regular user of play.spotify.com, works great. Figma is a great design tool available only on the web.
I do get your point, but there are more and more things moving to the web as more and more standards are being published (if you think this is a good idea is another discussion).
Modern html and CSS is by far the least complex GUI framework I've used. And it is (somewhat) cross platform.
Wow, if modern html and CSS is the least complex GUI framework you've used, you need some exposure. That combo is uber-complex, and the tool sets are college degrees all by themselves. It is a flat out joke how the developers of today have added complexity everywhere they could.
>I am wondering why mobile apps too haven't entirely been replaced by Web apps
Apple has made it so that every browser on their mobile devices is basically really Safari under the hood. And they have purposefully crippled Safari to push developers to the lucrative app store. Nothing is going to change until this changes, either through consumer behavior or through legislation.
Apple has made it so that every browser on their mobile devices is basically really Safari under the hood. And they have purposefully crippled Safari to push developers to the lucrative app store. Nothing is going to change until this changes, either through consumer behavior or through legislation.
Web apps purposefully cripple mobile performance, battery life and accessibility. Nothing is going to change until this changes.
Not to mention device level access like Bluetooth integration, making phone calls, using the camera etc. Mobile apps are hard to do as web apps if they are anything more complex than a front end for some web system.
Yes. We had to do native because there are no Push Notifications on Safari mobile. I understand people hating the permission pop-ups on marketing-saturated blogs and other places that don't need it, but that's the whole purpose of a web app is to be more app-like and less static-website-like.
>I am wondering why mobile apps too haven't entirely been replaced by Web apps
One reason is we don't have unlimited energy sources on mobile devices. I am yet to see a non-trivial "web app" that can run fast without drawing kilowatts from the outlet.
One reason is we don't have unlimited energy sources on mobile devices. I am yet to see a non-trivial "web app" that can run fast without drawing kilowatts from the outlet.
You don't have a lot web apps on mobile because the mobile web browsers provide a worse experience compared to native applications, unlike Electron or Chrome on Desktop that provides a much better experience in general (unless you have a 10 years old hardware with very little ram or are into old school GUI I know).
The companies making web browsers and mobile operating systems are the same companies making native applications stores and requesting 30% of the revenue, so they don't have any good reason to make web applications better. They are not non profit.
The companies making web browsers and mobile operating systems are the same companies making native applications stores and requesting 30% of the revenue, so they don't have any good reason to make web applications better. They are not non profit.
> mobile web browsers provide a worse experience compared to native applications, unlike Electron or Chrome on Desktop that provides a much better experience in general
Electron apps are perhaps faster and cheaper to make than native desktop GUI apps for most organizations because they already have Web developers, but I've never heard anyone claim they're "better" than native, if that's what you're saying. Do you mean they're somehow better for the end user? If so, how?
Electron apps are perhaps faster and cheaper to make than native desktop GUI apps for most organizations because they already have Web developers, but I've never heard anyone claim they're "better" than native, if that's what you're saying. Do you mean they're somehow better for the end user? If so, how?
Yes I was more thinking about development. Faster and cheaper development is the key. Development teams can focus more on the user experience and the features.
You also get a good application on all platforms, GNU/Linux, Windows, and Mac which is nice and used to not be the case.
You also get a good application on all platforms, GNU/Linux, Windows, and Mac which is nice and used to not be the case.
Electron’s user experience is atrocious even on recent hardware. It falls right into the uncanny valley of superficially appearing native and while not behaving natively.
VS Code is my fav piece of software of all time, it's an Electron app
Agreed it’s an excellent editor however it has a lot of engineering resources behind it and still suffers from sluggish performance, especially on startup.
It starts quickly on my laptops. What kind of hardware do you use ?
Both an Intel and an M1 mac, it's especially noticeable on the newer machine as native apps open instantly, even Xcode, which is a pig seems to open quicker. Like I said it's a great editor and I use it when I need to do some Python or JS work (remote/ssh development functionality is especially nice) but I don't think it's immune from the resource argument against electron.
VS Code is the most frustrating piece of software I use, because it is very good, but it's UX is terrible because they refuse to make any allowances for native platform standards.
I don't use it enough to have any of the hotkeys that aren't bog-standard memorized, and the refusal to add menu options or toolbar buttons makes discoverability really bad.
I don't use it enough to have any of the hotkeys that aren't bog-standard memorized, and the refusal to add menu options or toolbar buttons makes discoverability really bad.
VS Code is so sluggish that I’ve found myself spending more and more time in vim when Sublime Text isn’t an option.
Most web apps are an accessibility disaster compared to their native counterparts. I guess that is not the main blocking factor, but not being native has subtle disadvantages all over the place. I remember there was actually a time where web apps were a trend, but most vendors stopped doing that since they just couldn't provide a really smooth user experience.
>I am wondering why mobile apps too haven't entirely been replaced by Web apps
Harder to track people and feed them ads.
Harder to track people and feed them ads.
> Harder to track people and feed them ads.
This is it. And it's really the app stores that make them so.
On desktop, people are wary about installing programs, because they can pretty much do anything. So you can get people to visit your website who would never in a million years install your app on their PC.
With app stores, people assume that apps are safe, because that's what they were promised. But then the apps are hoovering up all their personal information, even more than they get from a web page on a desktop. And the app stores that claim to be constraining bad behavior don't kick them out for it because huge social networks are some of the few companies with enough market power to divert their users to another phone platform.
This is it. And it's really the app stores that make them so.
On desktop, people are wary about installing programs, because they can pretty much do anything. So you can get people to visit your website who would never in a million years install your app on their PC.
With app stores, people assume that apps are safe, because that's what they were promised. But then the apps are hoovering up all their personal information, even more than they get from a web page on a desktop. And the app stores that claim to be constraining bad behavior don't kick them out for it because huge social networks are some of the few companies with enough market power to divert their users to another phone platform.
I dont think parent was refering to web as in "web sites you can open in Safari", but apps built with web technologies, as in Ionic or similar.
Your comment can be interpreted in two opposite ways, but it seems you meant that native apps allow the better tracking and ad delivery.
While mobile apps are quite awful from this perspective, you must consider that the web is by far the most efficient platform for ad delivery and tracking.
It's the web which has cookie pop-ups with dozens and dozens of companies that want to track you.
It's the web which led to the development of ad blockers.
It's the web where an app developer has full access to your data on their servers.
It's the web where an app developer can at any time flip a switch and turn on telemetry, ads, etc.
While mobile apps are quite awful from this perspective, you must consider that the web is by far the most efficient platform for ad delivery and tracking.
It's the web which has cookie pop-ups with dozens and dozens of companies that want to track you.
It's the web which led to the development of ad blockers.
It's the web where an app developer has full access to your data on their servers.
It's the web where an app developer can at any time flip a switch and turn on telemetry, ads, etc.
No it isn't, even the govt apps in my country have ads in them. With firefox i can easily block them, for apps this becomes much harder, if dns blocking isn't sufficient.
Yep, that's exactly what I was saying!
What The Flying spaghetti monster?
> Harder to track people and feed them ads.
In native apps, you mean?
In native apps, you mean?
It's not about whether they're native code or using a cross-platform API, but the fact that they're not web pages running in a browser. This allows them to "phone home" even when they're just running in the background, push notifications and bypass certain types of Adblocking (such as uBlock in Firefox).
There is a good reason why so many websites push you to use the apps on mobile.
There is a good reason why so many websites push you to use the apps on mobile.
On Android you can block every app with relatively fine grained control via TrackerControl [0]. Sometimes a little fiddly but worth it IMHO. You can download directly from the site, use the official client or use the much snappier Foxy Droid [1] that lacks features but i still recommend it.
[0] https://f-droid.org/de/packages/net.kollnig.missioncontrol.f...
[1] https://f-droid.org/de/packages/nya.kitsunyan.foxydroid/
[0] https://f-droid.org/de/packages/net.kollnig.missioncontrol.f...
[1] https://f-droid.org/de/packages/nya.kitsunyan.foxydroid/
Music player, video player, password manager, messenger, IDEs, Nextcloud Sync, phrase replacer, search, file explorer, 7-zip, backups, REPL, budgeting, office suite, texteditor and terminal.
And those are just the non-electron, non-web-frontend apps I regularly use, and still excludes games.
And those are just the non-electron, non-web-frontend apps I regularly use, and still excludes games.
Two words: app stores.
While this is less of a concern for Google (the Android supports alternative app stores, and Google would love it if we all used Chrome), switching to mobile apps will deprive Apple of a significant source of revenue derived from the App Store. Thus, it is in Apple's best interest for developers to continue writing iPhone/iPad apps and Apple receiving a chunk for each sale than for developers to write Web apps and Apple not receiving a cut.
While this is less of a concern for Google (the Android supports alternative app stores, and Google would love it if we all used Chrome), switching to mobile apps will deprive Apple of a significant source of revenue derived from the App Store. Thus, it is in Apple's best interest for developers to continue writing iPhone/iPad apps and Apple receiving a chunk for each sale than for developers to write Web apps and Apple not receiving a cut.
Yup. This bears repeating. Desktop got conquered by web tech because OS vendors had no moat around third-party software. Smartphone OSes managed to create app stores before web technologies got to the point of competing with native, so mobile OS vendors have both leverage and strong business incentive to keep apps native to their platform.
> I am wondering why mobile apps too haven't entirely been replaced by Web apps
Simple equation. Efficiency of a mobile device is directly proportional to the efficiency of the runtime the apps are running on. For example Objective-C / swift has a GC-less memory model which just means we get to do more with less memory. This is how iPhone typically ship with lesser RAM than Android phones, yet do everything that Android phones are capable of surprisingly well.
Desktops/Laptops have no need to worry about extreme memory efficiency. They are always/usually connected to a power outlet. But mobile platforms on the other hand need extreme memory efficiency to get by with battery power.
If you do the math, the abstractions that the web provides comes with a huge cost. A virtual rendering engine, a programming runtime that is notorious for bad memory management and all this on top of a huge VM called the browser. It doesn't scale.
Simple equation. Efficiency of a mobile device is directly proportional to the efficiency of the runtime the apps are running on. For example Objective-C / swift has a GC-less memory model which just means we get to do more with less memory. This is how iPhone typically ship with lesser RAM than Android phones, yet do everything that Android phones are capable of surprisingly well.
Desktops/Laptops have no need to worry about extreme memory efficiency. They are always/usually connected to a power outlet. But mobile platforms on the other hand need extreme memory efficiency to get by with battery power.
If you do the math, the abstractions that the web provides comes with a huge cost. A virtual rendering engine, a programming runtime that is notorious for bad memory management and all this on top of a huge VM called the browser. It doesn't scale.
> For example Objective-C / swift has a GC-less memory model which just means we get to do more with less memory. This is how iPhone typically ship with lesser RAM than Android phones, yet do everything that Android phones are capable of surprisingly well.
You forgot CPU that's light-years ahead of anything that Qualcomm or Samsung have. But, please, keep thinking that it is about Swift/Objective-C, lol.
You forgot CPU that's light-years ahead of anything that Qualcomm or Samsung have. But, please, keep thinking that it is about Swift/Objective-C, lol.
> You forgot CPU that's light-years ahead of anything that Qualcomm or Samsung have
That's a relatively recent development.
iOS's lower memory usage compared to Android, however, has been forever.
That's a relatively recent development.
iOS's lower memory usage compared to Android, however, has been forever.
> I am wondering why mobile apps too haven't entirely been replaced by Web apps
Isn't this obvious - the web is deliberately crippled on mobile platforms like iOS.
Isn't this obvious - the web is deliberately crippled on mobile platforms like iOS.
An electron app is not necessary SaaS but it is still a hidden web browser running an application built on web technologies (Essentially HTML5 which is html+css+javascript).
> I am wondering why mobile apps too haven't entirely been replaced by Web apps
There are many Cordova/Capacitor-based web apps in a Webview shell with access to native APIs.
There are many Cordova/Capacitor-based web apps in a Webview shell with access to native APIs.
I use VScode for code and text editing (mostly Latex etc.) which is also Electron.
Also, I don't really use mobile apps for most social media which have working mobile web pages.
Also, I don't really use mobile apps for most social media which have working mobile web pages.
[deleted]
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).