The web is swallowing the desktop whole (2017)
char.gd
char.gd
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).
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.
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.
Windows 8 was a catastrophic failure, 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.
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...
On Windows 10, you just need to install your own X server. I'm using VcXsrv with great success to use GUI software running on WSL1.
[0] https://devblogs.microsoft.com/commandline/the-initial-previ...
It does actually although you are correct in your general point.
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.
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.
Sadly, the solution seems very business-driven. The ROI threshold to making a desktop-native app is quite high.
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...
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.
> 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.
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.
You can see how on mobile platforms, where app distribution is not a big problem, native applications are still doing well.
I still remember how awesome it was I could stream music sitting at a train station while browsing the internet.
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.
What was less obvious was that electron would grow this big and still be this bad. How is the memory usage still so inefficient?
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?
(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)
Nah, it's Kubernetes
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.
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...
In this example of one match they don't, but there's a lot of aggregates that are functions of live data.
tldr; just pay tech debt ASAP.
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.
https://static.seekingalpha.com/uploads/2019/7/31/49654246-1...
Everything will be either a Chromebook or EdgeBook, basically.
Mozilla.
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?
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.
I may be wrong, but as things are now, Electron, more or less packages an unmodified, headless Chromium.
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.
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.
Would you really do that though? Or would you run a random exe from a random zip hosted from a random website?
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.
Don't get me wrong, I'd much prefer if Windows had implemented proper application sandboxing.
> 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.
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).
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
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."
Unless of course you're taking about pro apps like AutoCad or Photoshop; but they have never been electron and unlikely to ever be.
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.
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.)
.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.
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.
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.
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.
On Windows, 90% of UI toolkits are deprecated with no support, no bug fixes, nor migration guides.
Every native app I have ever used has been many times snappier than its Electron/Web equivalent. Think on why customers demand native apps.
$5 -> this looks cheap, probably poor quality
$49 -> this is quite too much
$99 -> are you kidding meIf Electron is what it takes then I’ll use an Electron app and not care.
Most non-tech people I know detest auto-updates.
Isn't customer demands are the main incentive for any developer?
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.
So even though basic command-line C-apps are great in terms of maintainability they also typically do less than modern web-apps.
There are benefits to using the same language for both the front-end and back-end.
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?
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++).
The jobs here are JavaScript, Java, Python, etc.
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.
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.
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.
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.
Who are these users? Under what circumstances do they “want” such things?
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)
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 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 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.
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.
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.
Ooh, this is such a good point! I am one such developer.
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.
How many people would know that Slack and Spotify are basically just web apps too?
For everyone else, all doubt is removed when the app presents you a 501 or 404 error.
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.
Still, it could be marvelous.
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.
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).
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).
I think economics is the real reason they won. And Google pumped a lot of money in this space, too.
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
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...
Hooray indirect wins!
(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.)
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.
Also very importantly: Are users paying premium for the Nylas Electron Qwality, or is it cheaper to just use Office 365/AWS/Google?
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...
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.
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...
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.
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.
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 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.
I should probably look into Linux phones before the corporations turn my phone into an appliance.
This is the future we've built for ourselves, and we don't even have the decency to be ashamed of it.
You mean computer applications which require internet connection.
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
Harder to track people and feed them ads.
In native apps, you mean?
There is a good reason why so many websites push you to use the apps on mobile.
[0] https://f-droid.org/de/packages/net.kollnig.missioncontrol.f...
[1] https://f-droid.org/de/packages/nya.kitsunyan.foxydroid/
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.
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 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.
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.
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.
Also, I don't really use mobile apps for most social media which have working mobile web pages.
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.
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.
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?
You also get a good application on all platforms, GNU/Linux, Windows, and Mac which is nice and used to not be the case.
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.
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.
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.
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.
That's a relatively recent development.
iOS's lower memory usage compared to Android, however, has been forever.
No, it's not. Apple been dominating mobile since a5.
Relative to inception of iOS and Android, which is since when iPhones has got away with shipping less RAM compared to Android flagships.
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.
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.
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.
And those are just the non-electron, non-web-frontend apps I regularly use, and still excludes games.
There are many Cordova/Capacitor-based web apps in a Webview shell with access to native APIs.
Isn't this obvious - the web is deliberately crippled on mobile platforms like iOS.