As the person who designed and fought for this app, I am a bit sad about the change.
The native app was by no means perfect, but it felt like a real productivity tool that was trying to be respectful of it's environment.
I've come to the conclusion that native desktop apps are just not viable from large companies, even if there is headcount. The problem is coordination cost.
If you want to launch new features and experiments here, there and everywhere, then the coordination complexity increases nonlinearly with the number of platforms.
If you can sustain a more deliberate, low churn pace of development then it's workable. Features can be well defined and then implemented by the platform team as they see fit. But if you want a more fast-paced, "just in time" style of development, you need to coordinate with every team for every change... wouldn't it be nice to just write web code and be done?
Even Microsoft are building this way these days.
This is why ironically small companies seem more able to support native apps than large ones. The more "stuff" that's being worked on concurrently, the harder it is to support multiple platforms.
I am baffled by this. I wrote a cross-platform GUI for an audio signal processor in wxWidgets that rendered all of its own widgets (own Draw calls, for faders, graphic EQ, compressors, drag/drop linking of nodes for a layout, knobs, meters/scopes) and incorporated Horde3D as a 3D rendering of the arena. It ran on macOS and Windows. Another chap handled the network control code that included joining multicast groups to discover the devices, and the device itself had a series of DSPs on it with an ARM processor for drawing on the LCD and handling the network stack and interfacing between the DSP and inputs from the network. That's 2 people.
So you're saying that it is impossible for a large company to somehow use native toolkits to draw text bubbles and emojis?? Video and audio is another matter, but MSN Messenger managed 75% of this decades ago, natively.
> So you're saying that it is impossible for a large company to somehow use native toolkits to draw text bubbles and emojis??
One weird thing about software development is that there are plenty of things which motivated individual developers can achieve which large companies can't even write the requirements for, let alone achieve.
> It's not a skill issue, it's an organizational issue.
We can say that for the majority of companies with large teams that already have this. Everyone knows Meta is no different.
In this case, it's a skill issue to ship low quality software which is what whoever that team at Meta just did and knowingly approved.
> The engineers at Meta are world class but they're nerfed by organizational constraints.
That doesn't mean anything given that shipping regressions to billions of users is not of "world class" calibre.
If fact, that is of amateurs behaviour and way below the expectation of a multi-trillion dollar company hiring the "best" engineers which they can certainly afford.
It is a management failure 100%. It doesn’t matter how good you engineers are when they are punished for doing good work and rewarded for shipping garbage.
Part of being good means pushing back too and managing upwards. Seems like they hire only those that won’t. Thus the management failure causes culture causing mediocrity.
Hacker News just recreated startups from first principles! /s
But seriously folks, this is why there will always be room for startups.
Megacorps are slow lumbering beats that suffer from entropy and signal loss at every edge on the graph.
The example here is that some marketing function gets the signal from Zuck to put Lego duplo characters everywhere because metaverse. Of course 90% of the company knows its dead on arrival so they are going to drag feet and try to work on their actual problems (or their local feifdom mandate) and wait for the latest fad to blow over.
Super wasteful, super inefficient but hey ads make an insane amount of money so Zuck can do whatever for a loooong time.
This is why Warren Buffet advocated dividends. Companies and people have few good ideas. Management however uses this money from the good ideas to fund boondoghles (see metaverse). The thinking here is that the money would be better utilized returned to investors to fund other good ideas.
Warren Buffett would rather have dividends than autonomous driving. Investors like him are the enemy of long term moonshot R&D like deepmind and Waymo. I’m glad Google shareholders don’t think like him
> Investors like him are the enemy on long term moonshot R&D
That's because he comes from a generation who has "the government and universities take care of R&D" as a mindset. A lot of the stuff we take for granted today - *nix, TCP, IP, the Internet itself, lasers, microwave, radar - came out of universities, government grants or the military.
The idea that the government is incapable of R&D is relatively new and originates in small-state / lean-state / starve-the-beast ideology.
And personally, I rather believe the wisdom of an old man who made a metric shitload of money by being a good honest citizen than others who got rich on advertising and stonk market shenanigans.
Imagine having to tell voters that the government is going to spend 11b (Waymo funding since 2020) on automating an entire profession away, good luck winning your next election. It is inherently infeasible to have popular support for the most revolutionary technologies that will cause societal upheaval. Voters have voted to preserve their lifestyles in amber over positive revolutionary change every time, see: public transit, building dense housing, corn subsidies, etc.
> Imagine having to tell voters that the government is going to spend 11b (Waymo funding since 2020) on automating an entire profession away, good luck winning your next election.
So what, NASA spent billions on the new space race, with everyone knowing the true aim was to kick Boeing's ass and Boeing being widely known as a pork distributor first and foremost and rocket/plane manufacturer second.
The job of politicians isn't to cater to the whims of reactionaries, the job of politicians is to do the right thing and sell it to the voter base.
> Management however uses this money from the good ideas to fund boondoghles (see metaverse).
I'm not sure we should be critical of risk taking in large companies because there was some notable failures. But maybe it is the sort of thing that doesn't scale well in a large org, they want big immediately.
> Megacorps are slow lumbering beats that suffer from entropy and signal loss at every edge on the graph.
True. I work for one and its terrible. My work is 95% jumping through hoops imposed by other teams, restrictions put in for political reasons by substandard business 'leaders', and often even keeping vendors happy (really why should we care, we are their customers not the other way around :( )
5% is doing actual improvement. And meanwhile HR want me to show I'm making a difference to the company. Well yeah 5%.
I hate it a lot but the pay is good and a permanent contract with 20 years service is valuable (if I'd get made redundant I'd get more than a year's severance so I'm definitely not leaving on my own for something that may not work out)
You're proving exactly why this is the case. With 2 people, it's easy to coordinate, agree upon a lot of things, accept compromise, meet face to face. Try 20 people. Infinite meetings, pushback from managers, resource allocation clashes, politics top to bottom.
I'm not defending any large company, they could if they wanted to, they just don't care. If this is "cheaper" and they can cut costs, this is what they'll do.
If they want fungible engineers, yes. They don’t want to pay extra for an expert in wxWidgets and Horde3D. They don’t want to wait while that expert’s replacement comes up to speed on Horde3D. They don’t even want to wait for any existing engineers to learn these two technologies.
They know web, they can manage web - web is “less risky.”
> They don’t want to pay extra for an expert in wxWidgets and Horde3D.
In my experience, in a large software company [0] it's very common for new folks on a "team" to have to spend one or (often) more months learning both the software they're now working on and the various libraries used in its construction.
It's very nice if you can find an expert in everything you've used on a software project, but that's not going to happen often. [1] And -IMO- if whoever you've hired can't generally come up to speed on WxWidgets in a couple of weeks while also becoming familiar with the rest of the project they're now responsible for, they're not someone you want working on your project.
[0] Which is the sort of company we're talking about right now.
[1] In part because companies generally don't want to pay enough to hire such people.
A lot of native toolkits are much more amenable to learning than the web. Web developers tends to create abstraction towers just to say they’re expert in a very small niche. I’ll take autotools and gtk over next.js everytime.
yes, precisely that. Or if you want to generalize further: Companies have staff and processes to "improve" the product, process and productivity. After a few years, when they've done a marvelous job (worth every penny) the job doesn't exist anymore but they continue to tinker and ruin their creation.
In my manual labor occupation the office folk often try to get away with a horribly inefficient schedule designed to make their job easy. I often have to remind them that they work for me. I do the actual work, your job is to optimize it.
This to me is the same thing as replacing a rather decent desktop client with a web wrapper. This is their update, its obviously bad for the customer. The excuse is to make further updates easier. There is reason to think these will also be bad for the customer.
Someone once explained to me that the process of everything we build and create is very similar. If some young sector has a wildly different approach one should be very skeptical. It happens that an architect still has work to do after delivering the drawings. Sometimes it is necessary to recall thousands of cars.
Ideal would be to have a perfect construction drawing then build the machine. The architect moves on and designs the next garden. A plumber puts the pipes in, tests if everything works then goes to the next construction site. The difference with software is that, when done, it can last forever. The opposite of what the industry pretends to be true.
I think what he is saying that native platform apps get delegated to different teams and coordinating among those teams becomes an additional cost. You don't want each team going off and doing their own thing.
Your 'answer' is "use a cross-platform GUI toolkit" but that has its own challenges. Not least that you typically build a native app because it delivers a native experience that users expect.
In general (and I accept there may be counter-examples) cross-platform tools fail to do this.
Is that worse than the usual mobile/web frontend/web backend split? The thing is that there should be more whiteboarding done to design the features. Instead you mostly have product designer trying to impose whatever regardless of the technical challenge/practicality.
Yes. Arguably because of the organisational cost of maintaining both a web version (which they arguably need) and a native windows version (which they arguably don’t need).
Most of WhatsApp is UI veneer on a set of webservices. Unless they’ve architected their app badly, I’m not seeing the cost of maintaining a native software being substantial.
That's not really native either. Whether it's a web wrapper or Electron or wxWidgets, just because something runs "natively" doesn't mean it feels native.
You're absolutely right that the issue is the coordination cost. It's not about the number of resources but just the fact that you need those resources to coordinate, slowing everything down.
Not a problem in waterfall, since you can set the targets beforehand and just have the teams work in parallel. In an "Agile" setting though (not the manifesto version, the current practice version)? It's a huge mess.
So then the question becomes, is this coordination cost worth it and how much are we willing to "spend". It seems the cost is worth it for Android and iOS since the native app experience on those platforms is so much better.
The macOS app is just a tweaked iOS app so it's also easy to justify.
But what about Windows? The Microsoft provided APIs are a disaster that keeps getting rewritten every half decade, and even Microsoft barely uses them. Windows users don't have a "feel" for a native app the way macOS and mobile users do, since there hasn't been a "native app experience" on Windows for a very long time.
Just look at the 2 context menus on Windows Explorer, they can't even get the sizes and colors between them right.
Meta would have been better off doing like Telegram and just using Qt.
> Microsoft provided APIs are a disaster that keeps getting rewritten every half decade
What a wrong and misleading statement.
Not they aren't. Otherwise Winamp 2.95 from 2003 wouldn't flawlessly work on my Windows 11 install 23 years later. Same with my Unreal Tournament 99 installation that I just copied over via a CD left from my Windows 98 PC.
As long as you haven't used any undocumented APIs or made your app hack its way into the OS via hooks like some games did back then for performance optimizations or some anti-piracy SW did, then most Windows apps from over 20+ years ago will still work today and it's also why WINE works so well to get Windows app working on Linux, is precisely because Microsoft HASN'T changed the APIs.
They're half-right. Microsoft do keep supporting the OS APIs, but it's the UI frameworks that get half-assed and abandoned. Which is why so many people recommend Avalonia these days. Microsoft don't even reliably use their own frameworks - go through Win11 and see how many Windows Forms dialogs are still present in things like settings and Explorer.
(WinUI is also a hybrid: since it uses the DirectX APIs rather than the old GDI model, most of it is in a userspace package that's delivered as an .appx)
Of course it does, those APIs don't work well together. It's a pain in the ass to use the features only available in the new APIs on old applications. Microsoft has put some effort into making it work but it's still hugely hit and miss. You can mix WPF and WinUI2, but not WinUI3.
Amazing. I thought they fixed that years ago with "XAML islands", but apparently [1] they un-fixed it again with WinUI 3 and still haven't re-fixed it?
Yup, though I wouldn't even say they "fixed it" with XAML islands since they lock you into .NET core 3...
They also keep doing boneheaded decisions like the new DWriteCore, which is a reimplementation of DirectWrite, and some features are only available in DWriteCore, but DWriteCore is not a strict superset and doesn't even interoperate directly with Direct2D like DirectWrite did.
So once again, either stay on the "stable" as people like to call it version, which is effectively frozen, or use the new one and rewrite half you app!
And then people wonder why nobody uses Microsoft APIs if they can avoid it.
It doesn't directly, but the fact that these old APIs are abandoned still matters. It's not like you'll get bug fixes for Win32 (non-CVE) issues, it's just that it will keep working as is.
You can't get a competitive UX by using Win32, even basics like resizable windows and proper hidpi support is missing. And the number of people who know this API is probably sub-1% these days. There are dozens of us left, dozens!
It's not wrong nor misleading at all. Win32 doesn't even support dark mode properly because it's effectively "deprecated" like all the others in the graveyard.
Who cares if they keep working if the only way to get dark mode is to custom render the whole UI yourself? Might as well do something non-native at that point.
Microsoft does not provide a serious UI library for applications to use. It provides 10 half broken and deprecated ones.
>if the only way to get dark mode is to custom render the whole UI yourself
Most the apps I use support dark mode: Chrome, FF, Notepad++, Jellyfin, Qbittorrent, SumatraPDF, Signal, Wiztree, WinSCP, and others I'm forgetting. Seems like it's not an impossible task for the developers.
And on Github you can find FOSS apps[1] that have implemented light/dark mode switching for their UI, so you can just copy what they're doing if you don't know where to start.
Are you speaking as a user? I'm speaking as a dev. Of the applications you mentioned only a couple actually use the Win32 controls (like Notepad++) and they custom render them to get dark mode. That's a lot of extra work they had to do, essentially draw the whole look themselves.
Chrome is not native. FF is not native. Qbitorrent is not native (it uses Qt, right there in the name). Signal is not native, it's a web page bundled with Chromium (aka, an Electron app). WinSCP only this year actually started using the right font! But at least that one is native I'll give you that.
The GitHub you sent doesn't really have anything to do with the discussion.
> Win32 doesn't even support dark mode properly because it's effectively "deprecated" like all the others in the graveyard.
Remember when you used to be able to make custom Windows color schemes? Where you could color each widget type independently? I miss that.
Assuming that your report is true, if Microsoft gave a shit, they'd come up with four color schemes (high-contrast light/dark mode and regular-contrast light/dark mode) for Win32 programs and sync them with the relevant "modern" settings. Alas.
What do you do if you're a Win32 program who refuses to use the system color scheme? Well, I guess you'll stand out no less than you would have been in the Windows 95/98/ME days... stubbornly refusing to conform to the user's commanded colors and all that.
I like to joke that we already had dark mode on Window 95. It didn't work super well with black colored icons but you could always just tone down how dark you made it.
We also had pseudo-dark mode themes for Windows XP. But the new dark mode stuff in explorer doesn't use uxtheme anymore.
> I like to joke that we already had dark mode on Window 95.
When I say it, it's not a joke! :D
> But the new dark mode stuff in explorer doesn't use uxtheme anymore.
I'm only familiar with Windows 10, and in that version Windows Explorer seemed to conform to the system color scheme just fine. Did Microsoft break that at some point in the past three, four months, [0] or did they royally fuck the dog in Windows 11?
For me, the *maddening* color-scheme-nonconformance was Task Manager. No matter what I did, it was *white*. It made it substantially unpleasant when you wanted to check a performance something-or-other in a dark room.
[0] Ever since I learned just how well video games work on Linux (via Steam), I've not booted into Windows. It's so nice. Folks report that there are launchers to run games in the Epic Game Store, but I've not yet bothered, so I can't provide first-hand info.
Windows Explorer still respects the color-scheme preference but the problem is the way it does it.
When you as a dev use a Windows provided control (be it a button, a toolbar, a context menu, etc.) the system grabs the theme information from something called uxtheme. This is how it worked in Windows XP and why you had like 3 different themes you could pick from and switch between at any time, and most apps would respect the selection.
But dark mode doesn't work like that, there's no uxtheme for dark mode. Windows Explorer is given special treatment by Windows with undocumented APIs. Other apps are not so lucky. If they want dark mode, they need to effectively draw the whole UI themselves. Even apps like Notepad++ have to do that these days.
> Windows Explorer is given special treatment by Windows with undocumented APIs.
Microsoft: "We offer GREAT backwards compatibility! The best in the business!"
Also Microsoft: "Man, doing things the old way is so hard. What if we had a clean break with the past?!?!"
Microsoft, some time later: "Man, making a clean break from the past is so hard. Let's just ship what we've done so far and think about finishing up the rest later. What? Windows Explorer is broken, and you refuse to let us ship!? *Fine*, we'll hack something in and not tell anyone."
I think few people are using the Win32 APIs directly and Microsoft has been shifting their stuff a bunch.
WPF (Windows Presentation Foundation ) had been the recommendation a while back, but then Microsoft started pushing UWP (Universal Windows Platform). Both of those have been succeeded by WinUI 3. UWP has been deprecated. WPF is alive, but more in a maintenance mode while WinUI 3 takes over the future. Oh, and WinForms were popular, but now not.
There's definitely been a lot of shifting and I think that's caused a lot of annoyance in the developer community - especially as Microsoft ships JS/WebView2 based apps instead of dogfooding their own stuff. If you hang out in the dotnet subreddit enough, you'll definitely see Windows devs annoyed at Microsoft's mercurial attitude toward their desktop frameworks and seeming lack of direction/interest - as their big new things are JS/WebView2.
They are talking about UI. Winforms (abandoned), WPF (abandoned), UWP (abandoned), MAUI.
Windows itself was always using their own custom stuff and not any of those. The closest thing to an established framework in Windows is react native that is sprinkled here and there. And QT that OneDrive uses
> Meta would have been better off doing like Telegram and just using Qt.
Qt would certainly be the better choice. However, since Meta already has a web version of the WhatsApp client, the WebView2 path was an easy and inexpensive option. After all, MS itself paved the way with Teams, Visual Studio Code, and Outlook.
You're in a very unique position to render a great public service just now - could you point in the direction of the secret storage used for the database key on Windows? I tried to locate it before but could not. Since that DB is about to be bricked it'd be real nice to export from it imminently
Yes, they are optimized for the developer, not the end user. It's a terrible situation that repeats all too often.
The developer makes a highly optimized native app that is a hit with the user. Now that it's a hit, the developer is now big company. And big company needs telemetry, A/B experiments, fast iteration. They can't just sit around waiting for the original developer to spend more years crafting another masterpiece. Due to tech, sign-ins, or what have you the app is also a kind of monopoly. Since it's a monopoly, quality doesn't matter. It can be a bloated electron thing and nobody can do anything about it other than suck it.
I made Facebook and FB Messenger for Windows. It was considered a complete failure by management as it never got above 1% of the usage by windows users vs the website.
If you're allowed to say, are you referring to the Windows 10 ports of the iOS apps that were done via Osmeta in 2016, or the earlier WinRT-native version? If the former, that was a non-starter for me and my blind friends due to deep accessibility issues, probably having to do with the Osmeta port/reimplementation of UIKit. Edit to add: And we wanted something that was easier to use with a Windows screen reader than the desktop website, particularly for Facebook proper.
To be honest, the Microsoft store was the biggest single impediment to success the project ever had. All of the ridiculous UWP requirements or exceptions and friction to install doomed it, start menu tile be damned.
And the start menu tile BS wasn't impactful except for the narrowly avoided multibillion dollar GDPR fine Facebook almost fell headfirst into when they declared "mission accomplished" and I realized they forgot the apps existed and escalated, just before the deadline.
I deserved a bonus for finding that, yet it didn't even register on my PSC.
It's worth wondering why we need so many changes done to a chat app. Everything they introduce to this app just makes it worse. I just want to have something where I can chat and call my friends with no frills.
you kinda answered yourself and perhaps suggested the answer, but it's worth saying out loud: they don't want whatsapp to be a chat app. they want it to be the next facebook and they want to smuggle it in a chat app container. if it seems like if it starts working out, I'll be buying Meta stock with disgust.
Why buy stock of something you don't like? Surely you can find other profitable investment options that also then don't support the thing you don't like?
Buying shares in a company supports the company financially only in very limited contexts (e.g. IPO). Buying shares primarily benefits you as an investor.
Buying shares in a company doesn’t benefit its operations, like making a product, directly. Hence, buying shares != support company’s products, however counterintuitive that feels.
Why is the UX around photos and videos in WhatsApp Web so incredibly poor?
I have clients who regularly send me photos/videos to publish on websites. There are many usability issues around this:
1. There is no option to "download all", which means you need to click through every photo manually and hit the download icon.
2. When navigating through photos, the download icon is often hidden behind a submenu which means it takes two clicks to download a photo instead of one.
3. It's impossible to download videos without first having fully buffered them. This means you need to click through the full video to ensure it's streamed to your device before the download icon appears. This is super annoying especially with longer videos.
4. Bonus non-web annoyance: if a user sends you multiple photos, your phone goes insane with notifications and sounds like a rapid-fire pinball machine. DINGDINGDINGDINGDINGDINGDINGDINGDINGDINGDINGDINGDINGDINGDINGDINGDINGDINGDINGDINGDING
As a web developer I find it incredibly difficult to even think of releasing software with these kinds of basic inadequacies.
> The problem is coordination cost. If you want to launch new features and experiments here, there and everywhere, then the coordination complexity increases nonlinearly with the number of platforms.
Why not use a common library, where platform teams can update what features they use from it at their own pace?
Or why not use some other tech that allows multi-platform native shipping? The company I just started at, RemObjects, builds software for Mac and Windows (and iOS etc) from a common codebase. They just keep the UI separate, and all that is done when there's a new feature is _only_ UI layer coordination.
So an app has a C# (say) or Go codebase, and a UI layer in WPF and Cocoa.
I feel like coordination cost goes way down with both of these:
a) Library approach: central functionality, platform teams not tied to specifics
b) Shared codebase where all logic lives: platform teams do only UI
Edit: forgot to add, all this is can be across languages, ie maybe you have a Go shared library and write your Cocoa UI layer in C#, that's fine, their tech makes it all interop.
Personally I think the challenges with this approach (having literally used a Go shared library + native UI myself):
1. The web still exists. You can't practically use a Go shared library on the web. And you probably don't want your shared library written in JS.
2. In my experience, most of the coordination is about the UI, not the underlying implementation. So the human cost isn't reduced much with shared libraries.
3. At a big company, "feature teams" can't easily ship native desktop UI because feature team eng only knows web...
I do think this approach is super viable with a product development approach that is more waterfall, however. Where a team owns the platform and it's design.
>feature teams" can't easily ship native desktop UI because feature team eng only knows web...
This is the bane of a lot of the native developer's existence. Add to that the designers that only know how to use Sigma plugins and it just makes it worse.
Separating the UI from the functionality is not as easy as it sounds. Often the first iteration of a program has the business logic tightly coupled to the UI, and is designed for a single platform. You need engineers with foresight to refactor before it becomes a mess
Also even the non UI is not trivial. I once worked on a very la4ge code base that was console only. We en we eventually gave up on our Windows and Mac ports. Granted it was C++ …
As much as I hate the cowboy cryptography of it, Telegram could do it. They are a 30 person team and maintain a web version, a first-class Qt desktop app, and native iOS and Android clients.
I would wager that if they wanted to simplify coordination, Flutter would easily kill iOS and Android with one stone, and optionally desktop and web if they so wish, all without a 1GB web wrapper.
Anecdata: I use WhatsApp web daily, and the tab always consumes a bit more than half a gibabyute of RAM. The problem might not be the wrapper, but the sheer waste of resources of the web version.
Oh it's viable, they're just too cheap to do it. The bean counters will always win in the end, and they are relentless; it trumps quality, aesthetics, and everything else given enough time.
Calling it nonlinear paints some horrible exponential picture. It's just squared (all to all communication). We deal with squared problems all the time (that's literally what distributed consensus is all about.....)
Practically it’s not squared because people randomly just ignore you (or even worse, maliciously comply), and tracking down all the people doing those things makes it more like exponential.
Eventually, the effort required to actually manage doing the thing is at least as large/larger than just doing it - ex: every large organization.
Is it really that useful to have feature parity across all platforms? In Telegram, for some features, it just says "please open this message on your smartphone", and that's fine. If I had the choice, I'd prefer fewer features and lower resource usage over having access to the very latest functionalities, and you can offer the web version as a supplement for whatever is missing.
The native app was by no means perfect, but it felt like a real productivity tool that was trying to be respectful of it's environment.
I've come to the conclusion that native desktop apps are just not viable from large companies, even if there is headcount. The problem is coordination cost.
If you want to launch new features and experiments here, there and everywhere, then the coordination complexity increases nonlinearly with the number of platforms.
If you can sustain a more deliberate, low churn pace of development then it's workable. Features can be well defined and then implemented by the platform team as they see fit. But if you want a more fast-paced, "just in time" style of development, you need to coordinate with every team for every change... wouldn't it be nice to just write web code and be done?
Even Microsoft are building this way these days.
This is why ironically small companies seem more able to support native apps than large ones. The more "stuff" that's being worked on concurrently, the harder it is to support multiple platforms.