The efficiency difference between native and "modern" web stuff is easily several orders of magnitude; you can write very useful applications that are only a few KB in size, a single binary, and that same binary will work across 25 years of OS versions.
Yes, computers have gotten faster and memory and disks much larger. That doesn't mean we should be wasting it to do the same or even less functionality we had with the machines of 10 or 20 years ago.
For example, IM, video/audio calls, and working with email shouldn't take hundreds of MB of RAM, a GHz-level many-core processor, and GBs of disk space. All of that was comfortably possible --- simultaneously --- with 256MB of RAM and a single-core 400MHz Pentium II. Even the web stuff at the time was nowhere near as disgusting as it is today --- AJAX was around, websites did use JS, but simple things like webchats still didn't require as much bloat. I lived through that era, so I knew it was possible, but the younger generation hasn't, so perhaps it skews their idea of efficiency.
In terms of improvement, some things are understandable and rational, such as newer video codecs requiring more processing power because they are intrinsically more complex and that complexity is essential to their increase in quality. But other things, like sending a text message or email, most certainly do not. In many ways, software has regressed significantly.
Another program I use a lot is Blender (3D software). Compared to Spotify and Slack it is a crazy complicated program with loads of complicated functionalities. But it starts in a blink and only uses resources when it needs to (calculations and your 3D model).
So I absolutely agree with you.
I also think it has to do with the fact that older programmers now more about the cost of resources than younger programmers do. We used computers without harddisk and KBs of RAM. I always have this in my mind while programming.
The younger programmers may be right that resources don't matter much because they are cheap and available. But now I had to upgrade my RAM.
Web apps masquerading as desktop apps are terribly slow and it's a surprise we've got so used to it. My slack client takes a few seconds to launch, then it has a loading screen, and quite often it will refresh itself (blanking out the screen and doing a full-blown re-render) without warning. This is before it starts spinning the fans when trying to scroll up a thread, and all of the other awkward and inconsistent pieces of UI thrown in there. Never mind having to download a 500MB package just to use a glorified IRC client.
I'm really enjoying writing code outside of the browser realm where I can care a lot more about resource usage, using languages and tools that help achieve that.
I'm not convinced it's the programmers driving these decisions. Assuming that it takes less developer effort - even just a little - to implement an inefficient desktop application, it comes down to a business decision (assuming these are programs created by businesses, which Spotify and Slack are). The decision hinges on whether the extra cost results in extra income or reduced cost elsewhere. In practice people still use these programs so it seems the reduced income is minimal. What's more, the "extra cost" of a more efficient program is not just extra expense spent on developers - it's hard to hire developers so you probably wouldn't just hire an extra developer or two and get the same feature set with greater efficiency. Instead, that "extra cost" is an oppotunity cost: a reduced rate of implementing functionality.
In other words, so long as consumers prioritise functionality over the efficiency of the program, it makes good business sense for you to prioritise that too. I'm not saying that I agree with it, but it's how the market works.
I do webdev mostly and there it's also a matter of management. I want to optimize applications to be less hungry, those are interesting challenges to me. But I've been told by management to just upgrade the server. Either I'd spend a day optimizing, and maybe fixing the issue. Or we just spend 50 euros a month more on a server.
Sometimes the optimization is not worth the effort. For applications like Blender? Optimization means a lot.
... articles with titles like:
“Slack in one Ruby statement” a la https://news.ycombinator.com/item?id=23208431
More seriously though, Spotify and Slack are optimised to intentionally be huge time wasters, so it makes sense the organisations that produce them don’t care about performance / efficiency.
But I can't. My ram is soldered on. How many tons of carbon dioxide should I emit so that you can use React? There are ways to do declarative ui/state management without dom...
I recently got a new PC myself and decided to go for 16GB, my previous one (about a decade old) had 8GB and I didn't feel I really hit the limit, but wanted to be future proof. Because as you said, a lot of 'modern' applications are taking up a lot of memory.
Just had to upgrade to 32 myself
What I remember from the time was how you couldn’t run that many things simultaneously. Back when the Pentium II was first released, I even had to close applications, not because the computer ran out of RAM, but because the TCP/IP stack that came with Windows 95 didn’t allow very many simultaneous connections. My web browser and my chat were causing each other to error out.
AJAX was not around until late in the Pentium II lifecycle. Web pages were slow, with their need for full refreshes every time (fast static pages an anomaly then as now), and browsers’ network interaction was annoyingly limited. Google Maps was the application that showed us what AJAX really could do, years after the Pentium II was discontinued.
Also, video really sucked back in the day. A Pentium II could barely process DVD-resolution MPEG-2 in realtime. Internet connections generally were not the several Mbit/s necessary to get DVD quality with an MPEG-2 codec. Increasing resolution increases the processing power geometrically. Being able to Zoom call and see up to 16 live video feeds simultaneously is an amazing advance in technology.
I am also annoyed at the resource consumption, but not surprised. Even something “native” like Qt doesn’t seem to be using the actual OS-provided widgets, only imitating them. I figure it’s just the burden we have to pay for other conveniences. Like how efficient supply lines means consumer toilet paper shortages while the suppliers of office toilet sit on unsold inventory.
Internet was slow but that was largely because for the most part of the 90s i was stuck with a very slow 2400 baud modem - i got to appreciate the option that browsers had to not download images by default :-P.
But in general i do not remember being unable to run multiple programs at the same time, even when i was using Windows 3.1 (though with Win3.1 things were a bit more unstable mainly due to the cooperative multitasking).
According to http://www.vogons.org/viewtopic.php?p=423016#p423016 a 350MHz PII would've been enough for DVD, and that's 720x480@30fps; videoconferencing would more commonly use 320x240 or 352x288 which has 1/4 the pixels, and H261 or H263 instead as the codec.
Being able to Zoom call and see up to 16 live video feeds simultaneously is an amazing advance in technology.
I'm not familiar with Zoom as I don't use it, but it's very likely you're not actually receiving and decoding 16 separate video streams; instead a MCU or "mux box" is used to combine the streams from all the other participants into one stream, and they do it with dedicated hardware.
That said, video is one of the cases where increased computing power has actually yielded proportional returns.
While on the topic, let's remember the speech recognition software available for Windows (and some for Android 2.x) that was completely offline and could be voice activated with, gasp, any command!
Google with its massive data centers can only do "OK/Hey Google". Riiight. I can't believe there are actually apologists for this bs.
With Moore's law being dead, efficiency is going to get a lot more popular than it has been historically. I think we're going to start seeing an uptick in the popularity of more efficient GUI programs like the ones you describe.
We see new languages like Nim and Crystal with their only value proposition over Python being that they're more efficient.
Similarly, I predict we will see an uptick in popularity of actually native frameworks such as Qt over Electron for the same reason. We may even start seeing wrapper libraries that make these excellent but complicated frameworks more palatable to the Electron crowd, similar to how compiled languages that look like Python or Ruby are getting bigger.
Very few companies are rewritting their electron apps in win32 (although they should be). Instead it continues moving in that direction, or worse. Crashplan rewrote their java GUI a while back in electron. Java UI's are mostly garbage, but compared with the electron UI it was lightweight and functional. The electron UI (besides shipping busted libraries) has literally stripped everything out, and uses a completely nonsensical paradigm/icon set for the tree expand/file selection. Things like slack are a huge joke, as they struggle to keep it from dying under a load my 486 running mIRC could handle. So blame it on the graphics and animated gif's people are posting in the chat windows, but the results speak for themselves.
Windows 95 never had a proper, operating-system supported package manager, and I think that's a big part of why web applications took off in the late 90s/early 2000s. There simply wasn't any guarantee that once you installed a native app, you could ever fully remove it. Not to mention all the baggage with DLL hell, and the propensity of software to write random junk all over the filesytem.
Mobile has forced a big reset of this, largely driven by the need to run on a battery. You can't get away with as much inefficiency when the device isn't plugged into the wall.
I would predict that if only Qt didn't cost a mind-boggling price for non-GPL apps. They should really switch to pay-as-you-earn e.g. like the Unreal engine so people would only have to start paying as they start earning serious money selling the actual app. If they don't Qt popularity is hardly going to grow.
I wonder how much memory management affects this. My journey has been a bit different: traditional engineering degree, lots of large Ruby/JS/Python web applications, then a large C# WPF app, until finally at my last job, I bit the bullet and started doing C++14 (robotics).
Coming from more "designed" languages like C#, my experience of C++ was that it felt like an insane, emergent hodgepodge, but what impressed me was how far the language has come since the 90s. No more passing raw pointers around and forgetting to deallocate them, you can get surprisingly far these days with std::unique_ptr and std::shared_ptr, and they're finally even making their way into a lot of libraries.
I sense there's a bit of a movement away from JVM/CLR-style stop-the-world, mark-and-sweep generational GC, toward more sophisticated compile-time techniques like Rust's borrow checker, Swift's reference counting, or C++ smart pointers.
I mention memory management in particular both because it seems to be perceived as one of the major reasons why languages like C/C++ are "hard" in a way that C#/Java/JS aren't, and I also think it has a big effect on performance, or at least, latency. I completely agree we've backslid, and far, but the reality is, today, it's expensive and complicated to develop high-performance software in a lower-level, higher-performance language (as is common with native), so we're stuck with the Electron / web shitshow, in large part because it's just faster, and easier for non-specialists to develop. It's all driven by economic factors.
The language Go has sub millisecond GC with multi-GB heaps since 2018. See https://blog.golang.org/ismmkeynote
Java is also making good progress on low latency GC.
Reference counting can be slower than GC if you are using thread safe refcounts which have to be updated atomically.
I don't want to have to think about breaking cycles in my data structures (required when using ref counting) any more than I want to think about allocating registers.
I worked for a robotics company for a bit, writing C++14. I don't remember ever having to use raw pointers. That combined with the functionality in Eigen made doing work very easy --- until you hit a template error. In that case, you got 8 screens full of garbage.
Work expands so as to fill the time available for its completion.[1]
Corollary: software expands to fill the available resources.
from A Plea for Lean Software (1995) https://cr.yp.to/bib/1995/wirth.pdf
A few years ago I read about a developer that worked on a piece-o-shit 11 year old laptop, he made his software run fast there. By doing that, his software was screaming fast on modern hardware.
It's our responsibility to minimize our carbon footprint.
> It's our responsibility to minimize our carbon footprint.
This, a hundred times.
As a long-time Linux user, that's what I say as well.
And as a privacy activist, that's what I routinely use.
https://tsone.kapsi.fi/em-fceux/ - This is an NES emulator. The Memory tap in Developer tools says this takes up 2.8MB. Runs in 60fps on my modern laptop.
It seems possible to build really efficient applications in JS/WebASM.
Multiple layers of Javascript frameworks is the cause of the bloat, and is the real problem I think.
If we save developer-cycles, it's not wasted, just saved somewhere else. In the first place we should not go by numbers, because there always will be someone who can complain for a faster solution.
> For example, IM, video/audio calls, and working with email shouldn't take hundreds of MB of RAM, a GHz-level many-core processor, and GBs of disk space. All of that was comfortably possible --- simultaneously --- with 256MB of RAM and a single-core 400MHz Pentium II.
Yes, no. The level of ability and comfort at that time was significant lower. Sure, the base-functionalitify was the same, but the experience was quite different. Today there are a gazillion more little details which make life more comfortable, which you just don't realize there are there. Some of them working in the background, some being so naturally that you can't imagine them not being there since the beginning of everything.
In other words, pass the buck to the user (the noble word is "externality").
Except for the 25 years support, you can get the same features if an electron runtime was introduced and you avoid using too many libraries from npm. In most electron apps, most bloat is caused by the bundled runtime instead of the app itself. See my breakdown from a year ago of an electron based color picker: https://news.ycombinator.com/item?id=19652749
The win32 code doesn't run anywhere, except on Windows, but most of the compute devices are mobile (non-laptop) systems and those don't come with Windows.
Running your native apps now takes both less work and more work: you can write (Somewhat) universal code but the frameworks and layers required to get it to build and run on Windows, macOS, Linux, iOS, Android, and any other system the market you target relies on now comes in as a dependency.
It used to be that the context you worked in was all you needed to know, and delivery and access was highly top-down oriented meaning you'd have to get the system (OS, hardware) to run the product (desktop app). That is no longer the case as people already have a system and will select the product (app) based on availability. If you're not there, that market segment will simply ignore you.
That is not to say that desktop apps have no place, or that CEF is the solution to all the cross-platform native woes (it's not, it's the reason things have gotten worse), but the very optimised and optimistic way to writing software from the 90's is not really broadly applicable anymore.
This is just the nature of “induced demand”. We might expand the power of our computers by several orders of magnitude, but our imaginations don’t keep up, so we find other ways of using all that capacity.
You might have used these words as a way to say "way faster", but factually you are incorrect. several orders of magnitude = thousands of times faster. No way.
A few kb for the binary + 20-40 gb for the OS with 25 years of backwards compatibility
Unless your domain requires high performance(with wasm and WebGL this will also be reduced) or something niche a browser cannot not currently provide it no longer make sense to develop desktop applications. The native application is too much hassle and security risk for the end user compared to a browser app and is worth the trade-off in performance for vast majority of usescases.
While the browser security sandboxes have its issues, I don't want go back to the days of an native applications constantly screwing my registry, launch processes , add unrelated malware and billion toolbars to your browser ( java installers anyone ?) .
Till late 2000's Every few months I would expect to do reinstall the entire OS (esp Windows and occasionally OS X) because of this kind of shareware / malware nonsense native apps used to pull. While tech savy users avoid most of this pitfalls maintaining the extended family's systems was constant pain. Today setting a chromebook or surface( Default S mode enabled) and installing an ad blocker is all i need to do , those systems are clean for years.
I do not think giving effectively root access and hoping that that installing application will not abuse is not a better model than a browser app. It is not just small players who pull this kind abuse either, Adobe CC suite runs like 5 launch processes and messes up the registry even today. The browser performance hit is more than worth not having to deal with that
Also just on performance from a different point of view, desktop apps made my actually system slower, you would notice this on fresh install of the OS, your system will be super fast , then over few weeks it will slow down, From antivirus to every application you added , they all hogging more of my system resources than browser apps do today.
Arguably many users don't know how to use a Windows desktop. But that's not a failure of desktop; that's failure of Windows. They could have provided an easy way to install applications to a sandbox. On Android you can install from apk files and they are installed to a sandbox. If Windows had such a feature easily available, I think most of genuine desktop app makers would have migrated to it. This would have the advantages of the browser and no battery drain, no fan noise, no sluggishness.
The reason that people don't write them is because users aren't on "the desktop". "The desktop" is split between OS X and Windows, and your Windows-app-compiled-for-Mac is going to annoy Mac users and your Mac-app-compiled-for-Windows is going to annoy Windows users. Then you realize that most users of computing devices actually just use their phone for everything, and your desktop app can't run on those. Then you realize that phones are split between Android and iOS, and there is the same problem there -- Android users won't like your iOS UI, and iOS users won't like your Android UI. Then there are tablets.
Meanwhile, your web app may not be as good as native apps, but at least you don't have to write it 6 times.
I must be living in a parallel world because I use a ton of desktop apps that aren't "written 6 times" - and write a few, including a music & other things sequencer (https://ossia.io).
Just amongst the ones running on my desktop right now, Strawberry (Qt), Firefox (their own toolkit), QtCreator (Qt), Telegram Desktop (Qt), Bitwig Studio (Java), Kate (Qt), Ripcord (Qt), all work on all desktop platforms with a single codebase. I also often use Zim (GTK), which is also available on all platforms, occasionnally Krita (Qt) and GIMP (GTK), and somewhat rarely Blender. Not an HTML DOM in sight (except FF :-)).
Linux of course doesn't have any standard toolkit, just two dominant ones. There's no real expectation of "looking native" here, either.
Which leaves macOS. And even there, the amount of users really caring about native UIs are a (loud and very present online) minority.
So really, on the Desktop, the only ones holding up true cross-platform UIs are a subset of Mac users.
Also I think you can deploy to all those things with Qt.
Anything that you need to run on a desktop can't be used effectively on a touch screen anyway, so phones and tablets don't really count for serious software. (Writing this comment is stretching the bounds of what I can reasonably do on an IPhone).
You can do it today with C# and https://www.mvvmcross.com/
And they'll let you know it, too. Unfortunately this has been an issue since the first Macs left the assembly line in 1984. If you point out that based on their share of the software market they're lucky they get anything at all, the conversation usually goes south from there.
Electron apps invariably make such kit feel slower than it actually is. You can get good performance out of even older hardware if you treat it well and load it with good software that respects the hardware.
At the same time a native win32 program can pack significant functionality into a 20KB exe. Put these together and you have a program where everything is instant, all the time on any computer. The original uTorrent was just over 100KB and installed then ran in an instant.
These two refinements together are such a massive difference from any electron program that it melts my brain when people say that it isn't a problem to have a chat program feel like using windows 95 on a 386.
People say talk about needing cross platform programs, but something like fltk has everything most people will need and also runs instantly, while adding only a few hundred kilobytes to an executable.
The trouble with Electron apps though (and most Node apps) is the sheer number of dependencies. It's just infeasible to package them for a distro if you care about their dependencies being packaged as well - at least, not without the entire process being automated.
On a whim I just checked how big the copy of Adium still lingering in my Mac is: 60 megs.
And Ripcord (a native discord/slack client) is a mere 40.
I am on the other side, building electron apps, I appreciate the flexibility and ease because I would rather iterate on ideas then learn three different OS-hooks.
I do agree that memory usage is too high on these types of apps and we as developers can be lax about performance.
And currently taking < 300 MB RAM
I don't see any `web first` or Electron solution replacing Reaper or Blender in a foreseeable future. One exception I'm intrigued with is VS Code, which seems to be widely popular. May be I need to try it to form my own opinion.
I despise electron and html-wrapper apps. But I gotta give credit where it's due. VS Code is pretty good.
With the advent of the new WinUI, React+Native on Windows, and Blazer. I'm betting the future of windows is more web based technologies mingled with low-level native libraries.
Web apps come from a tradition of engaging the user. This means (first order) to keep people using the app, often with user-hostile strategies: distraction, introducing friction, etc.
Native desktop apps come from a tradition of empowering the user. This means enabling the user to accomplish something faster, or with much higher quality. If your app distracts you or slows you down, it sucks. "Bicycle for the mind:" the bicycle is a pure tool of the rider.
The big idea of desktop apps - heck, of user operating systems at all - is that users can bring their knowledge from one app to another. But web apps don't participate in this ecosystem: they erode it. I try a basic task (say, Undo), and it doesn't work, because web apps are bad at Undo, and so I am less likely to try Undo again in any app.
A missing piece is a force establishing and evolving UI conventions. It is absurd that my desktop feels mostly like it did in 1984. Apple is trying new stuff, but focusing on iPad (e.g. cursors); we'll have to see if they're right about it.
Gmail empowers me. Wikipedia empowers me. Github empowers me.
Of course native application are important. You don't need to rely on those moralistic justifications.
* Email clients (I use Thunderbird)
* Office suites
* Music and media players
* Maps
* Information managers (e.g., password managers)
* Development tools
* Personal productivity tools (e.g., to-do lists)
* Games
As Windows starts on-boarding their unified Electron model (I can't recall what they have named this), I suspect we'll see more lightweight Electron desktop apps. But for the record, I like purpose built, old-fashioned desktop applications. I prefer traditional desktop applications because:
* Traditional applications economize on display real-estate in ways that modern web apps rarely do. The traditional desktop application uses compact controls, very modest spacing, and high information density. While I have multiple monitors, I don't like the idea of wasting an entire monitor for one application at a time.
* Standard user interface elements. Although sadly falling out of favor, many desktop applications retain traditional proven high-productivity user interface elements such as drop-down menus, context menus, hotkeys, and other shortcuts.
* Depth of configuration. Traditional desktop apps tended to avoid the whittling of functionality and customization found in mobile and web apps. Many can be customized extensively to adapt to the tastes and needs of the user.
Bottom-line: Yes, for some users and use-cases, it still makes sense to make desktop apps. It may be a "long-tail" target at this point, but there's still a market.
The search is not very good on Thunderbird...
You may also want to consider pricing implications of both. Desktop software can usually be sold for a higher up front cost, but it's tough sell to make it subscription based. SaaS would make your life a lot easier if you have a webapp. People are starting to get used to paying monthly for a service anyway.
Pro tip: If you decide to make a native app, don't use Electron. Instead, use the built-in WebBrowser/WKWebView components included in .NET and macOS. Create the UI once using whatever web framework you want, and code the main app logic in C#/Swift. Although the WebBrowser control kind of sucks right now, Microsoft is planning on releasing WebBrowser2 which will use Blink. I think they might also have it where the libraries are shared between all apps using it, to further reduce bloat. The old WebBrowser component can be configured to use the latest Edge rendering though by adding in some registry keys or adding this meta tag:
<meta http-equiv="x-ua-compatible" content="ie=edge">
The key is to make it only available as a subscription (no permanent licenses) and it does not have any cloud component.
We managed not to fall in the trap of making two types of licenses (suscription or permanent) to maximize early revenue (we could affort to wait).
We seek a marriage relationship with our users not a hook up.
This increases the value our users extract knowing it will not go away in the long term and the lifetime value of customers is a lot higher.
We know that some customers will not accept a subscription-only desktop application but in B2B world they are fewer than it might seem.
Great to know, thank you.
Or maybe there needs to be a consensus on terms. Do people consider electron apps to be native? I would put them in some weird middle ground, but definitely closer to web technologies than native development.
We did look at doing exactly as you said, i.e. using a web view within Windows and Mac, however I couldn't really get things working well enough at the time (as TBH I am bit of a noob WRT web development, and just pick things up as necessary as we go along).
For our market, there is strong demand for the desktop versions, and this is even with a subscription model; people get access to the most recent major and minor versions of the software as well as phone and email support while under subscription. When their sub runs out they are entitled to minor version updates, but nothing else. My biz partner is very good with people and very knowledgeable in the domain we operate, so this kind of arrangement suits everybody. Oh, and I get to work remote, and have done with him for ~15 years. The current situation really makes one appreciate fortunate arrangements such as this.
I wrote just enough PyObjC to get myself a trayicon in the Mac menu bar, which shows a popover containing a wkwebview to localhost. Then I have all the app logic in Python, exposed to the webview through a bottle server, and Svelte for the UI. Highly recommended.
But aside from my particular specialty, I also prefer any other software I use to be fully native. I'm surprised that's such a controversial thing to ask for these days. All I ask is so precious little:
* I want the software I use to be designed to run on the CPU that I own!
* I want software that doesn't require me to upgrade my laptop every two years because of how inefficient it gets with every iteration.
* I want software that isn't laughably bloated. I think we have a real problem when we don't bat an eye upon seeing the most rudimentary apps requiring 200+ MB of space.
The dev who posted it seemed perplexed when people told him the game was 100x bigger than it should be.
It's clear you've never worked with Electron; nothing about its system-level access has anything to do with HTML5 or related standards.
All of that lives in NodeJS, which offers reasonably low-level APIs for accessing system resources. For cases where that's not enough Node can easily call out to logic written in other languages, either directly through FFI (foreign function interfaces) or by spinning up an independent binary via the shell.
This is the problem with this discourse: the vast majority of the Electron haters are people who have no idea what they're talking about when it comes to the actual thing they're criticizing. It's particularly hypocritical when they go so far as to frame "JavaScript hipsters" as some combination of ignorant, inexperienced, and/or lazy.
[1] https://developer.mozilla.org/en-US/docs/Web/API/FileSystem
VR is another area where native desktop is still superior.
Then there is anything that is dealing with a lot of local data and device drivers. Video editing for example.
Development tools that work in a browser are getting better but native (or even just Java-based like IntelliJ stuff) still seems superior for now.
Stuff that doesn't use TCP, like network analysis tools, either need to be done as a desktop app or need to run a local server to point the webapp used to control them to.
I guess what I'm getting at is that if you need low-level access to the local device or if you care a lot about things like rendering performance then native is still the way to go.
The client you use to interact with the stream is a web page, yes, but the actual game running in their servers is a native Linux application.
• Familiar UI primitives: - Controls and chrome are in the same place - Font sizes are the same across apps - Consistent icons and button shapes
• Support standard keyboard shortcuts (including obscure ones that developers re-implementing these UIs might not know about) - All the Emacs-style keybindings that work in native macOS text fields but are hit-or-miss in custom web text fields - Full keyboard access (letting me tab and use the space bar and arrow keys to interact with controls)
• And consistent, predictable responsiveness cadences - Somewhat contrived example: In Slack (browser or Electron app), switching between channels/DMs (via ⌘K) has a lag of about 0.5–1 second. If I start typing my message for that recipient during this lag, it actually gets saved as a draft in the channel that I just left and my content in the new channel gets truncated. I don’t think that kind of behavior would happen in a native macOS app, which renders UIs completely synchronously by default/in-order (so it might block the UI, but at least interactions will be in a consistent state)
I purposefully make my FF unlike the other apps on my system. I use a couple of workarounds to prevent OS level keybinds from working in some apps. Sometimes a completely purpose made UI is better, sometimes.
In general, consistency [in desktop UI] is good, but there are good reasons to break it.
I frequently do light computing on a Surface Go. It's a delightful little device and I love it, but it is not powerful enough that I can leave gmail, Slack, and Discord open all the time.
I don't have enough RAM to run another web application but I could very easily afford a native app or two.
E-mails using claws-mail are not a problem. It generally runs fast enough until I open firefox and web stuff in general.
I'm not sure that's enough of a reason to develop a commercial app, because tightwads like me also like our stuff to be free.
But there are trade-offs: -the user has to install/upgrade it -less insight into what the user is doing -harder to sell as a subscription
I wrote this in 2013 and I think it is still mostly true: 'Is desktop software dead?' https://successfulsoftware.net/2013/10/28/is-desktop-softwar...
Why do you say that?
I use only one browser-based application: Gmail.
I've never used another browser-based application and I can't imagine that I ever will unless there's truly no alternative and it's forced on me by an employer.
I've happily paid for dozens of desktop applications, and I'm even semi-happily paying for around ten of them that have switched to a subscription model, but I never have and likely never will use browser-based applications even if they're free.
I use gmail but i get it through Thunderbird...
One area which is really tough to nail is cross-platform support though. Getting a good app on one system is hard enough, getting it in all three - rarely done. This is one of the things where web shines.
From business standpoint, I think web-first with an eye on native works for majority of cases. That is, as long as the majority of users don’t care about the above. In some future, if we start valuing efficiency and especially privacy more, this could turn around. But it feels like, even then, web will probably find a way to make more sense for most people.
I'd say that that when you're writing an application which is fundamentally just a pretty wrapper (e.g. it exists to take user input and pipe it over HTTP to some web service or use it to generate a command for some other binary) and your users don't care about performance, resource usage or reliability, it makes sense to use a browser. Your application is very UI-focused and if you're already familiar with HTML, CSS and JS, use what you know.
However if you're working on an application that has strict resource usage, reliability and/or performance requirements like say a control system for industrial equipment, a 3D game, a video encoder, photo editing software, or software that's going to be run on an embedded system, you're going to find it difficult to do what needs to be done with a browser/wrapper. It can be done for sure but it'll be something you work around rather than with.
Your web app, which requires several extra levels of indirection between the code and the bare metal, an online connection, quite possibly is built on a framework that tends to suck down a significant percentage of my CPU even when it’s idle in the background with all windows closed, and its own weird file management that’s probably a giant hassle when I need to get my work into another program, has no place in my world.
All of this is much easier to do with native applications, running them in a browser just adds the need for crazy kludges and workarounds to simulate or enforce something you get for free if running native. Also you end up with managing hardware boxes with periphery attached and software running on them anyway, so whether managing a native application that is a browser which then runs the POS application or whether directly managing the POS application does not save you any work; if anything it even gives you an additional thing to manage, which increases maintenance effort and potential for failure (which quickly is catastrophic in this business, POS down today effectively means the store can close its doors).
Back-office applications in the same space are actually pretty well-suited for a web application, and frequently implemented as such today.
But those things are getting fewer and fewer. And it annoys me to no end that I can't, say, run my favorite screencast/video editor (screenflow) on my Windows or Chromebook machine, since it seems pretty deeply tied to the OS. I don't want to have to learn another one, and I don't want to replace my Mac which is on borrowed time.
That said, I use a lot of apps like Gimp and Inkscape on my Mac, and they may be technically native, they can be really awful about "feeling native." I don't mind inconsistent user interfaces so much, as long as it is mostly cosmetic. But I've spent SO much time in both of those searching for lost windows, etc. (OMG Inkscape devs, has anyone even tried it on multiple monitors???) Things you never run into with "true" native apps (those two use GTK toolkit).
So, I certainly recommend web apps if you app can run sufficiently fast or otherwise can get away with being a web app.
Those will always be native.
These are your Cad programs, your video editors, your AAA games.
You can make a cad program in a browser too. But you trade a chunk of perf for convenience, and thats only rarely acceptable.
Anything that could ever be done in a mobile app (chat, media consumption, ..) those might be possible to do in a browser. But you didn’t even really need a computer for them to begin with.
But there are still many areas where native is king.
- Games
- Audio / Video work
- Adobe type of work (photo editing, motion graphics, vectors, etc)
- 3d
- Office. For me Google docs is enough, but not for heavy users.
- Desktop utilities (eg: Alfred, iStatMenus, etc). You could certainly use a web UI for those, and it would probably be fine , but you'd still need some native integration.
A 3d modeling package? Although Clara.io exists most of the time I'm dealing with 100s of megs of data so native wins. Creating a game? Mostly same though I can imagine some limited online game creation tool even the small sample 3D platformer for unity is 3gigs of assets so a game editor native seems to win. Photo editing, when I get home from vacation there's 100gig of photos so native wins for me. Video editing same thing.
On the other hand there are apps I have zero interesting in being native. WhatsApp, Line, Slack, Facebook, Office, Email, Discord, etc. I'm 100% happy with them in a browser tab. Native apps can spy on way more than browser apps (maybe less on Mac). They can install keyloggers, root kits, scan my network, read all or most of my files, use my camera, mic, etc.
I also use 7 machines regularly. Being able to go to any one and access my stuff is way more convenient than whatever minor features a native app would provide.
The experiences are fantastic. The applications look native to the platform, with coloured title bars and OS specific window decorations.
The performance is not noticeably different than the equivalent native experience. I am taking advantage of multi-threading through web workers, web push notifications (sorry iOS), and the (single) code base is maintainable and easy to work with.
I don't see how a GUI framework like QT or several native applications would make a more effective alternative either aesthetically or financially.
I'd consider it uncontested once installable web applications have deeper system access (filesystem, etc).
The addition of web assembly bindings for direct DOM manipulation and directly importing wasm binaries via a script tag would complete the browser as the most sensible customer facing front-end environment.
RE performance, look at Figma.
I suppose I am increasingly frustrated with the inability to use my computer if it has no internet....
I've seen lots of tools that spin up a local webserver and then use that to serve the webapp even offline. But then the question becomes is this really a webapp if I have to install a native server?
As a trivial example, https://jakearchibald.github.io/svgomg/ (which has no data storage requirements) works just fine offline.
Offline support is a banner feature of the PWA (progressive web apps) movement.
Msft is pushing on react-native-windows and macOS has project catalyst. React-native is making cross-platforms native apps viable.
Apps are way more immersive than the browser and it allows the developer to give a gamification experience.
A good example of a recent app that chose to leverage native platforms is Table Plus. They are developing native apps on Mac, Windows, and Linux. I respect the effort/skill and dedication required to pull this off! https://tableplus.com/
For example, I've made a Mac app that lets you customize your Spaces (virtual desktops), assign names to them, jump to specific ones, track your time spent across them, and trigger custom events when you move to specific ones. None of this would be possible via a web app or electron app. Project homepage https://www.currentkey.com, app link: https://apps.apple.com/app/apple-store/id1456226992?pt=11998...
And as long as there is differentiated hardware between platforms, there will be opportunities for innovative native apps. For example, though I personally don't love the Touch Bar, there are interesting native app projects around that like Pock: https://github.com/pigigaldi/Pock
It's a very web-dev-centric view to imagine that this model is right for everything and will eat all software. There are clear performance and efficiency tradeoffs.
If you KNOW the constituent bits of the software stack of an electron style app, you will be horrified at what you are doing in the name of being 'normal cool and popular'.
It would be considered extremely bad engineering if you whiteboarded the actual layers and proposed it sans the singular justification of "there are lots of JS devs and this is considered easier than QT which requires a bunch of picky expensive C++ devs'
More's the pity that the eventual use case is not first priority in such a decision making process.
"Background communication channel that should be kept open while the users main productivity software is afforded the computers resources for actual work" that would suggest that Slack would be better written as a native or near-native app. Hello, McFly...
So the questions are:
- do your customers care about performance? (gaming, 3D animation, music editing)
- are resource limits relevant? (embedded systems, mixing desks, broadcast, dvr)
- are people concerned about battery life? (pagers, medical equipment)
If none of these reasons for native apply, you can probably make your users suffer through a web app, which will be much cheaper for you to produce and maintain.
That said, people definitely notice the sluggishness that all web apps have. I mean those 100ms from click to screen update. So your customers will most likely be able to intuitively feel if your app is native or not, with native feeling better.
For some groups of customers, this premium feel might be a decision factor. For example, Apple TV (super responsive) versus Netflix (objectively slow website).
My father was right about so many things. The one I have in mind right now is when he said "age is another form of strength against the nitwit, because those with experience see straight through those with misplaced confidence."
He was right. I'm not calling anyone here a nitwit or anything, please be clear on that.
It's just amazing how wrong some of you are, while sounding so absolutely sure of yourselves. A few don't even get easily researched technical details correct, while trying to sound authoritative.
My point is that maybe this is related to why software development is in the sorry state it is in today: the ignorant are confident they know it all, and the knowledged are confident that they know very little.
- Marked (Markdown previewer/converter): native.
- Transmit (file transfer): native.
- PDF Expert: native.
- ImageOptim (image optimizer): native.
- Fantastical: native.
- MailMate: native.
- Terminal: native.
- iA Writer: native.
- Safari: native.
- CodeKit: native.
- Dash: native.
- GitUp (GUI Git client): native.
- 1Password: native.
- Telegram: Electron.
And a few that aren't running now but I run very often:
- Slack: Electron.
- Visual Studio Code: Electron.
- BBEdit: native.
- Nova[1]: native.
- MacVim: reply hazy, ask again later[2].
So, I mean, I can't speak for everyone, but it doesn't seem to me like native apps are going away in the near future, at least.
[1]: Nova is a still-in-beta code editor I'm trying out as a possible replacement for VS Code. Code still "wins" on features for me, but Nova is pretty cool, and still in beta, so...?
[2] I mean, MacVim is a native "GUI," but it's, you know, Vim.
1. Heavy lifting - As others have mentioned, running some code in a browser is quite a few times slower than locally. As Moore's Law comes to a screaming halt we're going to be need to get better at creating efficient software rather than relying on the underlying hardware to get faster.
2. Capability - Some things are inherently difficult to do in the browser, such as custom networking, calling kernel functions, accessing various hardware, etc, etc. You can always have your native app launch a web-based front-end, but going back the other way is not possible by design.
3. Hardware Access - Sometimes you need to access a camera, USB device, GPIO, I2C, SPI, run architecture specific instructions on the CPU, access the GPU, etc, etc. Again, the browser typically won't let you access these by default.
4. Security - This comes in a few parts: (a) You're able to bypass "most" security and do what you want within reason. As long as the user ran your application you usually have the same privileges. (b) Now that you're dug-in you can enforce a level of security that may not easily be available otherwise. (c) Features such as app signing mean that the user can more easily guarantee the app came from you, rather than relying on their ability to read the exact URL in some email at 2am. If I run `apt-get install <X>` or equivalent in other OSes there is a chain of accountability.
5. Memory - Put simply the browser adds massive overhead to any application and typically has inefficient data structures. Compare something like Atom [1] to any equivalent native editor for example. (There is some existing efforts in comparing editors [2].)
[1] https://en.wikipedia.org/wiki/Atom_Editor
[2] https://github.com/jhallen/joes-sandbox/tree/master/editor-p...
On the one hand, you can say “look, an Electron app that’s actually fast!”
On the other hand, you can say “wow web apps are slow; it takes ~50x longer to render a basic list than to regex search across tens of thousands of strings”.
From a performance perspective, the JS part of the stack certainly isn’t helping.
0: https://keminglabs.com/blog/building-a-fast-electron-app-wit...
In fact, the whole project started out as writing a replacement for Wordpress from scratch. At least 6 of my clients' websites got hacked and one of them had a million visits a month. Simply because of stale plugins (it's easier to accumulate them than you think). So, long story short, I absolutely believe there is a place for desktop apps even in 2020.
BTW, I plan to open source my CMS soon :)
(and I do write about my journey here - https://medium.com/build-ideas)
Dealing with "state" is much better/easier/clear in desktop than in web.
An app on desktop, if well made, will be insanely more responsive than a web app. That's one thing - the other thing is there are cases where speed/resources will dictate that the app should be desktop. A simple example is a video editor (such as, the one I'm developing, but that's besides the point). Sure, you can have a video editor as a JS app, but that will be incredibly trivial compared to a desktop app.
I'm not saying that you can't match any desktop feature on to web. I'm saying that some will take 10x+ time and resources (and thus, an insanely higher complexity) than desktop. And some features, they are simply not feasible to do on the web. Let me give you an example: time-remapping for a video editor (one thing that I'm gonna implement soon). This is such a complex issue, requiring advanced caching + lots of RAM + fast rendering, that implementing it in a browser is simply unfeasible TODAY.
As things become feasible on the web, lots of them begin by being 10x+ more complex than desktop (this gets lower in complexity in time), for one thing. And for another thing, that basically means more things that were unfeasible for desktop will now become feasible there (but still not feasible on web). And this cycle continues.
In conclusion - there will always be a place for native desktop apps IMHO.
I'm also going to burn some karma and re-iterate that there are only two languages worth using: JavaSE on the server (build everything yourself) and C(++) on the client. We need this to be understood so that fragmentation can be reduced!
Here are some desktop applications I enjoy and have gladly paid for:
Acorn (image editor) / 1Password / Evernote+Skitch / Pingplotter / djay
But wrt to electron apps and using web technology instead of native frameworks, I think it depends a lot as well how well the web code is designed. I've been prototyping a Matrix chat app [1] in a very minimalist way:
- no framework or library used for UI, "state", ... to have complete control on how and when things are updated and rendered.
- use indexeddb optimally to keep as little things in memory as possible.
My 2 main conclusions from this are:
- Web technology can perform very well. The chat client uses only 3.5mb of Javascript VM memory on a 200 room account. It visually outperforms some native apps as an installed PWA on Android on a low-end device. I attribute this to the fact that web browsers are very optimized.
- It takes more time to engineer an app properly like this, even in a language like javascript. I can imagine it's hard to justify the expense, when most people don't know who to blame when their computer is slow.
Economically, it's basically 'web first' or at least web by default. Not only it's cheaper, but also faster to iterate, since major clients' logic could be unified.
Development wise, most non-desktop developers hate native desktop development. There are too many quirks in different platforms.
PS: There are so many Electron hates in this thread. Sure, there are a lot of crappy Electron apps, but they're more likely assembled in like one afternoon either because it's a personal hobby project tool or their company wanted only a working software and demanding their developer to release it within one week. Given the same amount of investment, I believe Electron wouldn't be too much short than native apps.
VSCode like everybody mentioned is pretty slick. And personally I feel Discord's Electron app and the React Native app are pretty nice as well.
i generally hate using web-apps. the usability and performance just isn't there, and the web was not built for this use case. even now, it's a terrible experience.
for industrial engineering, scientific, creative jobs and more, almost everything you use aside from confluence is a desktop application. visual studio, visual studio code (line is blurred, but it's still a desktop app), solidworks, opera, other modeling software, xilinx vivado, matlab, visio, simulink, houdini, touchdesigner, unreal engine, logic, pro tools, studio one, VSTs, office suite, control applications, perforce visual tools, git gui clients, custom internal tools, etc.
all the real work gets done in desktop apps and yet people keep saying desktop apps are a thing of the past.
i truly don't understand what people's end game with web browsers and applications are.
The exception to this is something either so simple that it only has one button (e.g. some file format converter) or so large (e.g. Photoshop, Bloomberg, AutoCAD, Mathematica, Visual Studio) that it surpasses the capabilities of the web platform.
Most things like chat, music, or word processing absolutely can and should be done with Electron or (imo) a WebView.
The reason Slack etc. is slow is not because of Electron but because the JavaScript is probably very poor, bloated, and not optimized. I used to hate Electron for being slow but after using it have changed my mind. The bottleneck is never on the Electron side; it slow because of your code. VS Code is an Electron app and is snappier than many "native" editors.
There are many people who have older hardware. For example I write this on a 2009 Macbook. My parents use older hardware still. And we're relatively well-off in a rich western country. These machines are perfectly fine to use for almost all tasks, but they're not powerful enough to run ten copies of Chrome. We might easily be able to afford that newer 500€ laptop, but for many people that multiple months of income. Not to mention the unnecessary waste the churn produces.
http://ajit.dhiwal.com/2020/02/world-wide-web-is-worst-possi...
I would rather reverse the question: In which situations is it acceptable to use Electron, for example? Something like Balena Etcher makes sense, but Logic Audio not so much.
Don't let hype and popularity on HN (not to mention market share of JS as pertains to the amount of web front-end work vs desktop work) serve as a surrogate for noting actual performance given a specific application.
Wrap-a-browser approaches and bloaty non-native frameworks are good for configuration ware, and things that don't need to engage in high amounts of real time processing saturating the CPU and RAM.
Many applications continue to squeeze required performance out of each platform. Cross platform approaches can serve just fine if there are zero-cost abstractions.
Audio/Video/3D/Image production software, for example. CAD, not to mention developers tools and compilers, just for the tip of the iceberg.
(I wrote a fully native iMessage client for Windows 10 [0] and enjoyed it enough to consider building a product around the code, minus the iMessage component.)
It's super fast and featureful
1) Rich key combo support. When running your app inside a browser, many key combos are reserved by the OS (and they differ by OS), and many are reserved by the Browser (and they differ by browser). As a result, your app has to avoid a huge number of key combos, because some OS or browser uses those.
2) Latency. It's not impossible to make a fast web app, but you're already at a disadvantage, due to the inherent overhead of the browser and JS runtime. Put it this way: making a user experience that feels slow and sluggish in a native app requires a lot more mistakes than doing the same thing in a webapp.
3) Filesystem support. It's just better with native. Especially on Windows where you can fully customize the file-open dialog box with app-specific business rules and warnings.
4) Hardware. You'll always be at the mercy of the underlying browser's support for hardware. Need to allow the user to switch between sound devices? This is easy with a native app, but it may require going to the browser control panel if you're a webapp.
5) Leaky abstractions. As a user, I want to open an app and do everything inside of that app. When using a webapp, I may have to fiddle with browser settings, key combos may break me out of the immersion as I accidentally open some browser toolbar or help feature, and the browser toolbars and window is always there to distract me.
6) Updates. With a desktop app, it can show me an alert when it's time to update, and I can choose to update now, or do so later. With a webapp, the updates are normally locked to a browser refresh (I need to refresh the page to get the update, and the update will happen whether I want it or not once I reload). Sometimes, the app decides it's time to update and just force-reloads itself (in the case of an app window I've left open for too long - days or so, while working on something important).
Native desktop apps targeted at the average user are better done on macOS, since that platform has a higher percentage of users who will pay (compared to the percentage of users who’d just pirate it).
Applications targeted at professional users, corporate users and developers can get an audience that’s willing to pay on any platform.
If your application is better done as a service, and you’d like better control on managing versions, a web based SaaS might make sense.
That was always the standard wisdom. However I have released the same software on Windows and Mac and seen significantly worse piracy for the Mac version.
You have to give users a reason to prefer native desktop apps. But today, thanks to Flat UI, most end users can't even tell a native Windows app from an Electron app. If users don't demand native apps then developers have no reason to limit their customer base to Windows users (or Mac users).
For users to demand native apps, native apps must have a distinctive look and feel that is loved by end users. Before Apple switched to Flat UI, Mac OS X apps did have such a look & feel, and developers were making OS X native apps even when users could use a Web version.
If Apple or Microsoft dropped the Flat UI stupidity — which is both ugly and has usability issues — then one day demand for native apps may return.
This means either apps with general mass appeal, or niche apps in specialized markets, but not small markets either.
Taking a quick look at my computer right now, I have a bunch of specialized apps that are considered "expensive" by many, and there is NO WAY I would want to use them as web apps: Ulysses, Camtasia, 2Do, Bear, Fantastical.
The other side of that coin, however, is that people do not appreciate how expensive desktop development is. For my SaaS, I would love to offer desktop apps (as in, not Electron apps), but the cost is prohibitive and this will likely never happen.
Native Applications in the platform's toolkit (not some cross-platform abstraction on top) will always squeeze a little bit more performance and usability out of the corners.
What I would really like is to completely separate application logic and UI so I'm free to choose whatever language fits best and potentially add several UIs on top of the same core without being forced to write it in C.
I recently started playing around with the idea of implementing application logic as a separate server that reads/writes a simple line based protocol from/to stdin/out. Simple enough to be tested from a shell, and easy to map to JSON for a web server or drive from a GUI.
Outside of niche use cases you get two much with electron. Computers are so dam fast most users just don't care and those of us that do care use Linux anyway. If your app also runs nearly identically in a browser not just electron, on boring users is so much easier. I won't install an app just to try it, but I will use a website and reluctantly upgrade to electron.
A sand-boxed stripped down electron replacement as a system library, ala Deno for UI will replace electron in the next few years. Web-Native frameworks targeting WASM, WebGPU for responsive components and Dom for everything else will replace JavaScript, but the web will win.
Many comments here explain the advantages of full desktop applications. (And there are many.)
The thing to always keep in mind is, does your application justify an installer? There's so many tiny utilities that run in a browser that I can find with Google. These are utilities that I probably use once a year and don't care to install.
But if I use the application heavily, I want a desktop application even if it's just an application specific browser.
I'm sure there's a good web implementation out there for the Dropbox-style sync thing, I just haven't seen it yet.
With all the computer resources in the world (tons of RAM, NVME drives, etc) it's still easy to tell the difference between native and anything else. It's amazing with these resources that apps can just be ridiculously slow-feeling. It's just painfully obvious.
Just another hell we have to accept living in. Overly dramatic? Sure, but I wanted to express how much disgust I feel for non-native apps.
I created a small macOS native app, it is a menu bar app for monitoring CI pipelines https://tempomat.dev, something like this is not possible on the web because everything is running on the same browser but native features are so much better
I use this because I don’t like the idea of financial account info being stored by a third party has has no liability for breach. And also because I have over 10 years of transactions in the ledger and running this remote can take a long time. I’m not even sure if there are any services that store for 10 years and let you do text searches.
The app code is delivered by a web server and runs entirely in the user's browser and with service workers configured it runs offline too.
Personally, I think it would be cool to have a sort of secure "runtime engine" on the client side that could manage permissions to system functions for client side web apps.
I'd pay good money for a native Evernote alternative.
I think no cross-platform solution will ever compare to native, and in the long run, native will prevail.
Electron might be good for quick development and deployment, but that's for the developer's benefit, not the consumer's.
As will applications like Final Cut Pro and Logic Pro. As I see it, the web platform is neither adequately performant, nor are its timing mechanisms accurate enough.
So no, native is sliding. I argue that >95% of users are happy with browsers and/or electron apps.
Either that, or those peeps move over to iPads. Which by design forces native or psuedo-native apps.
Web apps have an incredibly flat learning curve with an equivalent entry barrier. If the same were made for native apps, they'd be more popular.
Web apps aren't displacing things, they're filling a void.
As a developer I understand why the native app road can become a more expensive solution, especially for startups.
But, I have to express that I am really tired of glitchy super heavy javascript apps, online, mobile and desktop. I would choose old clanky but lightweight UIs everyday.
Anything that communicates with devices using serial, UDP, or custom layer 2 protocols.
Also anything which needs to be used in a lab environments with networks that can't access the web or corporate network.
Also anything that needs to run in a manufacturing environment, where precise configuration management, predictability, and reliability are crucial.
Motif appears to have an old and stable API. Its visual style looks grey and blocky, but has a rich widget toolkit.
Where brute-force performance is a #1 concern I think it diverges. For things like Photoshop filters or rendering, WebAssembly may still be fine (it depends). But for real-time processing that needs timing guarantees or more direct access to hardware (games, DSP, etc.) the code has to be native running in dedicated threads. Still, it would be nice if those operated essentially as native browser plug-ins that still interfaced with a browser environment, rather than a totally separate executable.
I'm seriously ready to let my web browser just be the GUI to my operating system. I want my file manager and terminal and system preferences just to be tabs next to my Gmail and Docs.
I would assume the same for desktop versus web apps but as time goes on I think web apps will prevail.
The original iPhone didn't even have a call log.
Jailbreak App Store came out and lots of third party apps, then Apple opened up.
It's really about time for the pendulum to start swinging back, as processors aren't getting much faster anymore.
We’re a very unique niche software that could be design online only, some have, but they slowly fail.
Think to Photographers (Photoshop?), Designers (3DS Max, Blender), Gamers (Steam & co), Administrators (VirtualBox)
But for mobile, there is an almost religious insistence that even text-based CRUD apps need to be compiled binaries.
Yes.
https://www.youtube.com/watch?v=kZRE7HIO3vk
(For those who never saw it)
What I'm hoping for is a pendulum reaction to the recent trends of UX design, where we see a renaissance in really solid interfaces that focus on discovery and speed. But I'm not seeing signs of that yet.
Have you tried compressing videos professionally or producing 3D content without a native app?
There's tonnes of random enterprise applications that look like they're straight out of 2005 out there still.
In theory it is great, you write the app once and then it runs on Windows, Linux, Mac, using a wrapper around each native GUI.
Unfortunately it is written in Pascal, so the community is tiny
As someone who has used Autocad since Ver 9 (1993) this is important.
Also - heavy 3D design. Blender/Alias/whatever these days.
Solidworks as well.
Edit: I presumed that the context of the discussion was apps in a general sense. Obviously not every application is going to be on the web and there are a lot of niche software that will never make the switch. I was thinking more qucad or sketch 3d for woodworkers to plan their desks, not solidworks and all its plugins to handle complex fluid simulation in mission critical areas.
What if your program needs to directly access some kind of hardware, say EDC machine?
But most people are probably not saying "ugh, Slack is made with Electron, I should completely avoid it."
If legacy apps like AutoCAD ported to WASM can give similar performances and experience as web app this is just inevitable now.
In the 90s and early 00s, there were many easy language products like Delphi, VB, and others who were much easier to use than C++ and friends. Cross-platform could be done with REBOL, REALBasic (aka Xojo), Runtime Revolution (aka LiveCode) and many other languages. Users didn't expected fancy flat animated user interfaces made of 100% custom controls, people were fine with normal native standard stuff as long as the app worked.
Now, there is no easy way to build cross-platform apps that is easier than electron. Languages like modern C++ and Rust are extremely powerful but they require more experienced developer to be used effectively. GUI toolkits like Qt and wx, are good but a ton of UX professionals now are trained to ship UIs in tools like figma, skewing all the native controls and creating beautiful masterpieces that are easier to do with HTML/CSS than implement with a native toolkit.
Native apps got harder to do not because we don't have access to the tech we had, but because of added friction. It is like death by a thousand paper cuts. You make the professionals designing the UX/UI create interfaces that are harder to reproduce with native technology, then you select a GUI toolkit such as Qt/wx and try to reimplement that using whatever language is best. It takes longer than developing an electron app, requires more expensive developers. Don't get me wrong, it will be a better product, but it will take longer, be more expensive, and will need to be done with more care. And after the app is done, there is the need to deal with all the sandboxes and crazy stuff that Apple requires these days if you're shipping a native mac app. Many electron apps sidestep a lot of this by simply being thin clients for some SaaS company and doing the hard stuff on a server (which also opens an opportunity for mining the data for our capitalists overlords).
The barrier for entry for developing an electron app is so low. JS is an easy language to start. There are so many ready made UI kits. You can have a small app running before a new developer can understand how the new pointer stuff work on modern C++.
All that text is to say that I think we need easier languages and toolkits that target native experiences. Something like Lazarus, LiveCode, are all steps in the right direction for me.
Memory Usage
A few years ago while trying to figure out why I was running out of RAM, I stumbled upon chrome’s task manager. Gmail was using up 700MB of RAM and all I had open was the Inbox. No fancy search box or Compose, the Inbox was taking up 700MB of RAM to display lines of text in a Tabular format. I’ve been a heavy user of Email clients and if you pick any of the native clients (Thunderbird, Outlook, Apple Mail) and open a bunch of searches and compose windows the memory usage will still stay below 100MB.
I used mIRC a few decades ago to connect to multiple chat servers, run my own bots, serve files over DCC and run scripts all while staying under 20MB of Ram. These days to send a text message over Slack I need over 1GB of RAM. Even basic apps with all of their trackers, external javascript scripts and doms take up 100s of MBs in memory. And the most common solution to running out of memory is to close chrome windows.
Battery/CPU Usage
DOM is slow. Updating layout and repainting is even slow. Javascript being a dynamic language is slow. Web apps are anything but simple these days and since they have to work under the limitations of all the slow components, the CPU ends up making up for it. Chrome is almost always present in my Macbook’s ‘Using significant energy’ tab. On the other hand, I rarely if ever see native apps in the battery bar unless I’m doing something which should actually consume a lot of CPU cycles like running multiple synths in Ableton or Compiling. When apps are built for mobile, battery usage is a major area to optimize on. But nobody even gives it a thought for web apps
60 FPS
Mobile apps run on 60fps, Native desktop apps run at 60fps, Games run ( or at least are designed to) run at 60fps. Instagram on chrome starts at 2-3 fps and usually hovers around 30fps. My laptop which is supposed to be more powerful than my mobile phone is only able to churn out half the frame rate even though they are both running at the same resolution! Web apps are not buttery smooth and can be jerky at times. Sure somebody can work really hard and optimize a website to run at 60fps at all times, but it needs a lot of effort. Mobile apps run at 60fps out of the box without much effort. Mobile and native apps use the GPU a lot more efficiently. Since they have a lot more information about which controls are being used, they can recycle items a lot better and do a much better job at hardware acceleration via the GPU. Not to mention that you have access to raw graphics APIs in case you want to push UI performance even further.
Development Environment You can build desktop apps in a plethora of languages and even for mobile apps you have many cross-platform frameworks. But building for the web(and electron) forces you to HTML/Javascript(and derivates). Javascript is a dynamic prototypical language that was not designed for the scale of apps that are being built in it today. It has no type safety, memory leaks are common and it’s slow due to its dynamic nature. While there have been many efforts to improve performance like V8s JIT, it still lags behind a lot of major languages. WASM seems promising, but it’s still has a long way to go. And it’s laughable how weak the browser platform itself is. SQLite is available on raspberry pi, embeddable systems, mobile platforms and just about every other platform on the planet. You can store data, run complex relational queries and do more with so less. But it is not available on the most widely used platform on the planet, the browser.
With the rise of electron apps, big and bulky web apps have started making their way onto the Desktop. There are some who are even trying to get the same apps on mobile via PWAs. While the web has the advantage of easy accessibility, IMO we have sacrificed too much in terms of user experience for that one convenience. If you built an app with the same UI and functionality in a native language and as a web app, the native app will run circles around it.
Sort of. There are browsers written in things like Java (HotJava was an old one that was basically a demo app) and so I guess anything written in a VM-language could technically be considered non-native.
XD
The only non-native app I dont detest that much is VS Code but it still feels painfully slow compared to something like Sublime Text.
Lets look at the chat apps that provide a similar functionality.
* Teams
Takes between 600-800MB on my PC. It's sluggish as hell and will often choke to re-render if I click on something.
* A native chat app Takes 15MB...Is just as eye candy as Teams and yet i dont care if it's running or not.
They got data lock in with Photoshop and Lightroom. Admittedly, the free alternative just doesn’t work as well as Photoshop or Lightroom.
The SaaS is on a monthly or annual subscription. So spending $20/month, if you only use it for 1 month, is far cheaper than spending $800 outright for a Photoshop license. And now, Adobe has the potential to reach a global audience of 7 billion people.
Of course, there is some risk that your code will be pirated, decompiled, and reassembled, to remove the ET-phone-home feature, but this is only a minor annoyance. It’s better to get your product pirated, than another competitors product. That way, the people using the pirated copies, who are likely poorer, or kids, will learn your program, and eventually pay for a full commercial license eventually, when they get a job professionally using the product.
I think you'll also find that the typical non-technical users simply don't care whether or not Electron is powering a piece of software. They just want something that looks modern and works "well enough".
If you’re not building something like this, don’t build for desktop.
Electron(or whatever web-based nonsense somebody comes up with six months from now):we've optimized your insane garbage collectors. We've optimized your GPU insane modules. We've optimized data structures to get a 10X performance increase. We've cut down memory usage by half, which still rounds down to AT LEAST 100MB in most cases. Look at me now...
Desktop/Native:Good for you! But did you know my code runs on bare metal? The only thing stopping it is cache misses and dirty TLB entries. Sometimes I can use registers, but there's just a few of them. And, well, stupid RAM sometimes takes over 100 nanoseconds.
Web:What in the world is cache? TLB? Are you on something right now? What is a nanosecond?????
Web cannot perceive what a nanosecond is
Native:There, there. You'll figure it out one day.
I don't want to come off as snarky, but this feels like a dumb question. And yes, I know, from a "business" perspective writing the code "once" and have run everywhere makes more sense. But let's be real, one of the main reasons a lot of these tech companies like Discord/Slack is jumping on the Electron wagon is money. It's cheaper to have one team of developers, than 3 for each platform. But even that argument feels a little weird to me when stuff like Qt that is 100X more mature than Electron will ever be exists. And before anyone asks, as long as you open source your app, Qt is completely free.
I do think that in SOME cases an Electron app MIGHT make sense. But cluttering native platforms with all this bloat is like riding a horse to work on your 40 mile commute instead of your Honda. Even that's a horrible analogy because your Honda is terrible for the Earth. But hopefully you get my point.
This lack of concern for computational resources by us programmers is utterly discouraging. As has been mentioned before in this thread, people that do ACTUAL work on computers will not take the bloated nonsense. Go ask the struggling artist if they prefer to use Krita or the new "modern" app that takes 600MB of RAM and the entire system gets bugged down to the point where they can't do research on their browser while drawing because Windows10/macOS plus the "modern" app takes 90% of their RAM because they have a 4GB/6GB computer.
Well shit, I guess I need a 1500 dollar computer to just draw a few sketches. I already have crippling debt, what's some more debt under my belt gonna do?
The issue is that developing for a particular OS is, generally, more difficult than developing for the web. The app delivery mechanism is also more convoluted (for native apps) than simply entering a web address in the browser. The web also seems to have more ubiquitous standards that abstract away the differences between OSs - you can, with a high degree of certainty, ensure that your app is usable by 99% of computer users, given the current software they have on their device - with native apps, there is no such guarantee, especially if you're relying on shared libraries.
Browsers are also becoming more feature rich. This has had a negative impact on their memory consumption, but given it's 2020, some may retort "memory is cheap". And while some browsers (Chrome, looking especially at you) do a very poor job of memory management, I believe the competitive nature of the browser market will force a reawakening soon, where a lot of the inefficiencies in memory management will have to be eradicated (or vendors risk losing market share). Think back to 2014/15 when Node.js was really becoming established - the PHP team suddenly felt a need to re-optimise their engine for PHP7 (and with dramatic results)... Point is, only after ~20 years at the top did something spur PHP's team on enough to do something about their inefficiencies.
Finally, I can see a future where the line between web and native apps is even more blurred. WebAssembly is the first step, however things could get even more elaborate. Perhaps we could end up with the ability to start docker-like containers from within web apps (given the right permissions, of course) to spin up servers for audio/video/image processing on the client itself, and interact with them via a web page. If we get to this point, native apps would feel even more obsolete.
I know your question was only about the current state, but I felt the need to talk about the future to highlight the marked difference in the rate of innovation in the web ecosystem (fast) vs the native ecosystem (slower). It would not surprise me if the web ecosystem ends up winning in the end. If I was building an app today, and it only requires features I can deliver via the browser, I would almost certainly go the web app route.
Now, if I was building a video processing app today, I'd almost certainly go native, but in a couple of years, my answer may be very different.
Since native apps take much longer to develop and the UI toolkits are stuck in the 90s, it's pretty much given nowadays that new ones are shitty compared to the equivalent web one.
The only other argument you mention is that native apps take much longer to develop, and that from that somehow follow that they are "shitty". I'm not even convinced the premise is correct, but I certainly don't see why longer development times would imply worse outcomes...
Intuitively, I would assume the opposite: something that is put together all too quickly should have a higher potential for being half-baked.
I'm not criticizing your preference, I just don't buy the arguments.
Personally, I hope that web browsers die off and we go back to gopher for displaying information. I hate the web.
While there are high performance and graphics heavy tools and niche products that still require native apps , with tech like WebGL , WASM , WebAssembly this limitation is also going away. Unless your application falls into this category where the gap between Browsers and native is still very big, do your users a favour and build a non native application.