It's fascinating to see so many folks out there supporting web apps, because I personally don't like using them. They're fine for tasks I don't care about being pleasant, like, say, quickly buying something online.
But for anything I consider work, that takes toil, like writing, editing media, or programming. I'll avoid using web apps, these tasks are hard enough on their own, I don't want to make them harder by using software that, to me, lacks joy (due to it not hitting my bottom line in performance, reliability, or even beauty). I just hope enough folks out there continue to appreciate native apps, because I think my continued joy at being in tech depends on it.
Native apps don't offer deep liking and bookmarking. You can't easily open multiple instances of the app in multiple tabs. Your data is usually tied to the specific devices you are using. Unless carefully designed, desktop apps might not be responsive or adaptive to various viewport sizes.
I know native apps are likely faster and use the full capabilities of he device, but the advantages of web apps are too many. Also, web app failing to inspire joy is a indictment of developers who don't care, not of the medium itself.
Native mac apps for example get a whole tabbing system for free so long as they support multiple windows (and most apps that one might want tabs in do). Deep linking is not difficult to implement in native apps and in fact some do.
As far as tying data to devices goes, with the exception of apps built around databases this is usually trivially changed by placing the data in question in a folder synced with SyncThing/iCloud/OneDrive/etc and most importantly gives you the choice, whereas many web apps will happily keep you pent up in their cloud with little or no capability to export full-fidelity data.
> Native apps don't offer deep liking and bookmarking. You can't easily open multiple instances of the app in multiple tabs.
Sure they do, and sure you can. It's up to developers to support, but it's certainly doable.
I think you hit the nail on the head in the subsequent sentence: native apps need to be carefully designed to compete with web apps. No one cares enough to do that.
> Native apps don't offer deep linking and bookmarking.
Sharing files is trivial, and just putting files in a folder is the file-native to find something again (i.e., bookmark). Personal preference whether one of these systems is better or worse than the other, personally I'd just call them different.
But I would specifically callout collaboration on a single document as a strong suit of web apps. E.g., two people editing the same document (like a Google Doc) is pretty much the only task that I'd prefer a web app for. Also referencing a single specific line in a document. Again I use web apps for doing that (e.g., find the exact line number of some code on GitHub to share), but I can't say I enjoy the process.
> You can't easily open multiple instances of the app in multiple tabs.
I'm mainly talking about desktop apps, which today almost always support multiple windows and/or tabs.
Might be missing what you're getting at here, are you talking about mobile apps? I'm pretty sure iOS also supports multiple instances of apps, but I don't need this functionality often enough myself to care. Again, maybe I'm missing what you mean here?
> Your data is usually tied to the specific devices you are using.
I don't think this has been problem since the first release of Dropbox in 2007? Again I might be missing something, but native apps are either file-based in which you can easily sync the file, or are a front-end for a database, in which most apps have a way to sync across devices? Syncing is kind of table-stakes for apps these days.
> Unless carefully designed, desktop apps might not be responsive or adaptive to various viewport sizes.
I'd argue this is more of a problem on the web than desktop, a well-designed desktop app will enforce a sensical minimum window size, whereas in my experience most web apps absolutely fall apart when you shrink them too small.
> Also, web app failing to inspire joy is a indictment of developers who don't care, not of the medium itself.
I don't agree with this type of reasoning, i.e., I don't look at a technology and say "there's nothing stopping it from making great software!" Instead I look at how great software is being made, and then prefer that technology. At the end of the day the only real proof that great software can be made using a technology is the great software itself.
Visual Studio Code is an interesting case study. I don't know how I'd categorize it.
In the past I've noted how absolutely glacial it is with some tasks, and it's baffling to me how this stuff doesn't drive folks insane (much like the enjoyment of web apps is baffling to me), I guess people just care about different things:
(Note those time trials are years old, this may be different now.)
But even though VS Code is objectively slow for some tasks, I would still categorize it as extremely high-quality software. So at the end of the day, I don't know. VS Code isn't for me, but I'm not confounded by it having fans the same way I'm confounded by web apps in general having fans.
I don't. I hate installing, and I hate both apps and data that are tied to a single device.
I like the security model of browsers, and I like using browser tabs to organize my apps like Gmail, Docs, etc.
And webapps can use your CPU and GPU just fine. We have such powerful machines, but checking your email isn't going to use that power regardless of whether it's a desktop app or a webapp.
> Relying on a third party cloud provider for your secrets is the opposite of a security model.
Why? If you encrypt your data, it doesn't matter where it sits. And if you don't, then there's not much difference between the government getting the data from AWS or them seizing your laptop. And a non-state actor will probably find it much easier to steal your laptop than to get access to your cloud account.
> If you are talking about the browser sandbox, then it helps nothing with keeping your data secure from actors you dont realize are bad.
Of course it does. My tabs from different domains can't steal data from each other or from the rest of my machine. The desktop applications I install can.
1. Easier to keep one program update. i.e browser. use firefox (or its nerfed clones) if you hate Google or Apple
2. For any decent software it needs update. Even most opensource tools are hundreds of MB. For example, a school teacher in Zambia does not need to download digikam or okular or notepad++ or ffmpeg every week to get security updates.
> it helps nothing with keeping your data secure from actors you dont realize are bad
Not saying updates aren't necessary, especially security related but I loved we slowed down with the pace of updates, many times forceful updates that brake things that used to work. Many times users no longer have the latitude to make the choice when to update. They also brick devices that can't take up their updates rendering them obsolete. Updates aren't something inherently bad but they're being used in evil ways with no resort from users other than leave.
Even if it is every 6 months one program is easier to update and control than different ones. Usually even if Ubuntu or Windows is never updated - download and updating firefox is stable. Nothing fails.
But if one thinks something like KDE or digikam or other complex tools - it updates 200 libraries that eventually lead to some f'kup - either unusable or driver conflicts in case of Windows.
This brick/EOL is a different issue but common man benefits from simplicity. Yes, environment is trashed or software obsolescence - but yet - most of them buy a new phone or device every at least 5 years (of course, I am talking within my circles - there may be people at different ends).
I used to buy expensive nexus phones. Then I realised I use only WhatsApp and Banking. Now I buy cheapest Motoroola for $100. Works fine. Become EOL in 2 years as they are bad in updates. Get another one for $100. Latest OS.
Instead if one spends latest pixel flagship for $800 - no benefits.
> Updates aren't something inherently bad but they're being used in evil ways with no resort from users other than leave.
Yes there is no resort but people live in real life. They need banking, recent cool apps etc. Some could live like RMS and not use anything modern or use Terminal but most people don't.
You must be relying on inferior update mechanism. This is a solved problem since long with a central package repository as you will find in most linux distros. On windows you have scoop, chocolathy and winget (from microsoft btw) attempting something similar, on macos there is macports and homebrew.
> Even most opensource tools are hundreds of MB
Even if this was true, and it isnt, I dont think you realize how heavy most web pages are today. Those hundreds of MB is used up fast, while the offline app is still there.
> For example, a school teacher in Zambia does not need to download digikam or okular or notepad++ or ffmpeg every week to get security updates.
Agreed. Noone needs to do that. If you are concerned with security, then you should also learn to understand your attack surface. Otherwise it is just FUD.
Example dont feed ffmpeg with unknown files in a uncontrolled fashion. You should understand that the videos you recorded yourself are safe and wouldnt need the very latest update to be processed.
I understand why scrappy startups like Electron, but it's astounding that companies as large Spotify and Slack won't shell out for a couple of Windows/MacOS native developers.
God how I hate Electron apps (nothing against Electron itself though)... People don't appreciate how much it means for example, for Mac users not seeing the rubber band effect on scrollers, let alone everything else feeling just unnatural and sloppy. You are immediately transferred back to the 1990s. Why should I care that some big fat corporation wants to save pennies on native app developers?
I can forgive a free and open app running on Electron (hello, Signal), but never a commercial one, full stop.
That's only after a tremendous amount of effort, with high CPU and mem utilization to add to it. The potential with native (at least on Mac) would be much higher.
Please define "fine"? There is always a very detectable lag when switching between channels and/or DMs. Always. Not a single exception.
There's zero technical and human reason for allowing that to continue. The visible-on-the-screen messages are cached and you can, you know, just get on with it by painting the whole thing on the screen right away.
It's "fine", he says. "Fine"...
[grumbles under his nose, annoyed, and ventures into the far distance]
Electron can be done well when treated as any other Desktop UI framework. VSCode is probably one of the only examples of that. I think the bad reputation comes from lazy wrappers pushed out to tick the "Desktop app" box, which are the unfortunate majority in my experience.
Well you kind of debunked your own first point: while we theoretically can have very fast and responsive Electron apps, the fact of life is that we don't; they are a vanishing minority.
What "can" be done is kind of irrelevant. What's much more important is what metrics would the default (or lazy as you called it) way of doing things with framework X or Y net. If the defaults are a slow and laggy app then that's what 95% or more of the using apps will be.
I made no point about the state of most Electron apps. What I mean to say is that rather than pivot to a native toolkit, businesses could prioritize improving their use of Electron. These days most of the UI world is focused on web. Using well-established and widely understood tech brings a lot of benefits.
Not to mention that desktop UI development is just unpleasant. I say this as someone who would really prefer that not to be true, it's just that in my search I've been disappointed. You choose between a number of imperfect "cross-platform" frameworks (and deal with their licensing), or maintain native code for several platforms. Creating custom "widgets" often requires you to start at the drawing API level and have a deep understanding of the framework.
I am keeping an eye on Avalonia, though. The tooling wasn't quite there yet when I tried it.
The part where I get frustrated in a similar manners as yours is that while yes businesses could prioritize improving their use of Electron, they never do.
I'd say they would need at least 30 people each to support windows & mac native apps. Especially considering all the extra overhead having multiple codebases introduces. Maybe more than that.
Edit: Just to clarify "need" is in the context of working in a big company on a complex product. These products are a lot bigger than they appear.
Tangent but the original spotify gui was about 1mb download and blazing fast. In no small part because of the original author of µTorrent (and ScummVM) had a central role. [1]
Spotify the company only moved to a electron remake later, I can only guess because it was hard to find more quality devs.
People might not remember this, but µTorrent used to be amazingly snappy too before it got bought and shovelwared.
I’d argue that desktop native is also the most likely to introduce system breaking bugs, viruses, and malware. A web app is much safer from these types of issues.
The result is people can use more efficient terminals to do most of what they need. And the powerful native machine is available when that extra power is justified.
These clearly aren't comparable to the support of browsers. I know this metric isn't really an important signal, but they both have under 500 stars. If I'm a business evaluating whether to build my cross platform experience either on the web using the sandboxing of browsers vs smaller frameworks like this, it's basically not even a choice.
At work I've introduced various in-house tooling based on Dear Imgui and people are just blown away by how fast everything is. "I didn't know computers could be this fast and responsive". I say, well just think about the fact that the machine at your fingertips can do billions of calculations per second and it shouldn't be that much of a surprise really.
If I had a dime for every web framework... We need better desktop api's. It's hard enough having to abstract nuances of linux/unix vs osx and the like. A better, more robust, desktop framework is needed (and no, not just another web framework on top of it because UI is hard).
Less Electron's, more OpenGL's - Less XML and more Swing (just not swing, plz).
Sure, but learn from why the Electrons of the world are winning. It’s because browsers are already what you would get after reinventing the wheel all the way to its logical conclusion— a highly customizable, generic application runner. Let’s not throw that away and make an Nth new thing. HTML/CSS/JS are good enough abstractions with great implementations, and it’s easy to build applications against this. Portability is already solved too. Yes, we can do better than shipping each application with an embedded web browser executable, there are huge jumps being made all the time with native web view frameworks. Personally, I think the ship has sailed on making the “perfect” framework, let’s pick the one that’s already winning and make it the best we can.
Electron/web still has the glaring issue of its primitives being, well, too primitive. They’re great for documents and lighter “web 2.0” apps but have a long way to go for the purposes of replacing full fat desktop UI frameworks.
This is actually a big factor in why web apps have the perception of being bloated. Basic widgets being missing means that everybody and their dog has their own custom implementations, nearly all of which are somewhat slapdash in nature due to speed of implementation being prioritized over quality. They never meaningfully improve either since there’s little sharing of efforts, with everybody instead preferring to reinvent wheels for themselves.
If the platform provided a more robust set of widgets, much of these problems would go away since devs would be using those instead either as-is or with light cosmetic customizations. Over time the browser implementations would get better and all users would benefit with more performant, less buggy apps.
This is what I've been saying for a long time. HTML remains too primitive in its support for rich UI apps.
The main problem I think is what you have identified: we need sophisticated composable widgets with practical and sensible defaults, that are also really customizable with scoped CSS, built right into the browser. This alone would be the biggest QOL improvement as far as web development goes, in several generations. I really don't know why this is not the highest priority for the W3C
> […] pick the one that’s already winning and make it the best we can.
I agree, it can be much better. Tons of incremental improvements have been made, and should continue being made.
I too would like to see browser close the gap completely, supporting everything needed to build real applications, not hacked together applications that accidentally work. We seem so close…
Browser based apps are better than ever. As a developer who has delivered applications on CD-ROM and downloadable installers, I do not have a strong desire to return to these times.
Browser-based word-processing and spreadsheets pretty great. I love VS Code. The multimedia capabilities of browsers are pretty good and up to the tasks I need them for.
OK, I still want instant switch between separate chats in Slack though, not this 1970s-like 1.5s laggy slow transition on a machine that can scan ~300K files in the same 1.5 seconds.
Couldn't agree more. If anyone is thinking about writing fast, safe, cross-platform GUI apps, I'd encourage you to try iced. It's a breath of fresh air
You know, I go back and forth on this a lot these days. I have a a couple of high power machines across operating systems and I find that, lately, I barely trust installing a downloadable application on them anymore. Installation instructions have sudo commands everywhere, on windows everything wants to escalate to admin rights for the installer, etc.
At some point applications completely broke my trust, and the OS manufacturers failed to protect us, and now we're all paying for it with inefficient garbage everywhere.
I have similar suspicions towards unknown web apps, because even with how good browser sandboxing has gotten it just takes a single click or less to set off a nasty chain of 0days.
For native apps, I treat non-obvious need for sudo or admin priveleges as a smell. The way everything on Windows needs admin is actually one of the reasons why I don’t use it for anything but games.
I wish operating system developers would make developing using their native UI systems not a pain in the ass and actually be competitive with the web as a platform.
I, a php/js web developer, have over the past few years launched and maintained a C# .NET app and can testify that the experience has been overall pretty positive as somebody that had never even launched visual studio before except for playing around unity and doing some tutorials.
And I say this even after the adventure of trying to decipher whatever Microsoft is doing/going with their 4 or 5 competing frameworks and SDKs.
But I still find huge value and love a good web app whenever what you need doesn't really need to be native which was not my case.
There will still be uses for native apps for a long time IMHO.
Issue with desktop app is doing updates, pushing updates/hotfixes to all of them and then works for some and not for others, instead of webapps you only update the host and test on different browsers. thats all.
If you say so. Telegram for example updates in half a second on my Windows gaming machine, and having a daily update script on my Mac and Linux machines is easy as hell.
Sure many people don't update like ever, but Apple's and Microsoft's app stores do updates without asking people anyway (they learned, finally).
Not such a big problem as you make it out to be IMO, even for very casual non-technical users.
the lack of proper tabs / multi instance support for many desktop apps makes me hate them. the possible quality range of a desktop app is much bigger than that of a web app, and given normal distribution of developer skill levels, i'd take a web app over a native app.
And yet we all want to be multi platform, and that with native comes costs.
I get it, I work with some multi platform apps and I just don't want 20 layers between me and the damn device and some crazy build process ... I hate it.
But I can't argue that going native everywhere isn't it's own hassle.
