7 ms·
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 productivi
by iamcalledrob 11mo ago
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.
- g-mork 11mo agoYou'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
- throw32435678 11mo ago[dead]
- sirwhinesalot 11mo agoYou'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.
- thw_9a83c 11mo ago> 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.
- TiredOfLife 11mo agoVS Code is Electron not WebView2
- RossBencina 11mo ago> The Microsoft provided APIs are a disaster that keeps getting rewritten every half decade, and even Microsoft barely uses them. What are you talking about? The Windows APIs have been stable for at least 20 years.
- TiredOfLife 11mo agoThey 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
- 11mo ago
- almostgotcaught 11mo ago> nonlinearly 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.....)
- lazide 11mo agoPractically 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.
- myaccountonhn 11mo agoIt'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.
- baq 11mo agoyou 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.
- fhennig 11mo agoWhy 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?
- andsoitis 11mo agoBuying 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.
- cudgy 11mo ago“Buying shares primarily benefits you as an investor.” Maybe during a never-ending bull market … but all bull markets end … look at the “lost decade”
- andsoitis 11mo agoThat's a different discussion. Argument here is that buying shares (other than during specific events like an IPO) affects the shareholder, not the company's products. So whether or not you buy shares has no relation to supporting the company's products. The latter happens when you buy or not buy their product.
- 72deluxe 11mo agoI 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.
- baq 11mo agonobody they hire knows how to do anything that isn't react anymore.
- bossyTeacher 11mo agoThey said software will eat the world. They were sort of right. React will eat the world.
- jagged-chisel 11mo agoIf 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.”
- 72deluxe 11mo agoI too did not know anything about Horde3D when I found it and incorporated it.
- 11mo ago
- vintagedave 11mo ago> 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.
- agos 11mo ago"only" is doing a lot of work here
- SJC_Hacker 11mo agoSeparating 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++ …
- iamcalledrob 11mo agoPersonally 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.
- variadix 11mo agoThis is ridiculous. The real explanation is a level of uncaring incompetence that can only be sustained in large organizations.
- snarfy 11mo agoYes, 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.
- pona-a 11mo agoAs 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.
- ASalazarMX 11mo agoAnecdata: 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.
- xzjis 11mo agoIs 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.
- tcfhgj 11mo agofewer features and lower resource usage on phones? understandable on the desktop client? nah
- mghackerlady 11mo agoI truly believe in 10 years webapps will be the next COBOL
- mostlyk 11mo agoWhy kill people who are trying to reverse engineer and write native apps for this? WhatsApp just bans you :(
- qcnguy 11mo agoThey can't easily tell the difference between "good" custom clients and spambots.
- EasyMark 11mo agoOh 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.
- wackget 11mo agoWhy 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.
- deleted 11mo ago[deleted]
- kridsdale1 11mo agoI 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.
- ynx 11mo agoTo 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.
- mwcampbell 11mo agoIf 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.