Earlier quoted context omitted.
My definition works like this: is there an API layer on which (a) everything else is based and (b) people sometimes use directly for app development? macOS: Cocoa/Quartz - yes and yes windows: win32 - yes and yes linux: X Window - yes, no (though of course Wayland is changing the "yes" a bit) GTK, Qt, WxWidgets, FLTK etc - no, yes
But that's my point, WPF (the Vista-7 era primary toolkit), is not based on Win32. Neither is WinUI (the 8-11 era primary toolkit) calling Win32 or WPF. Win32 is mostly used for legacy apps, you'll find some random usages still like pre-Win11 notepad or the services configuration menu. WPF is the primary UI framework of Windows Vista/7 and still the framework which the majority of the OS is in for Windows 8/8.1. It d…
Stop Building Closed Ecosystems
121–130 of 174 posts
Re: Stop Building Closed Ecosystems
#122Earlier quoted context omitted.
> But how much of the GUI is actually cross platform I find the idea that when Photoshop or Protools wants to open a dialog with a button, the developer creates two functions, one for Windows and one for macOS, completely unbelievable. There is almost without doubt some level of in-house cross-platform toolkit in place. It may not go as far as, say, Qt tries to, and it may differ in design philosophy from other simil…
That’s kind of backwards isn’t it? If I am writing a banking app for both the web and mobile. My GUI development is going to be different. But I’m calling the same set of APIs. The backend isn’t “opening a dialog box” to the front end. The developers would be designing a native dialog and calling backend shared codex
The GUI code wants to open a dialog. The way to do that differs dramatically depending on whether you're opening a dialog on one of the (many) Windows native GUI APIs, or Cocoa (or even Linux). Are you proposing that when the, ahem, domain logic in Photoshop requires opening a dialog, that the developers write 2 or 3 or 4 different implementations at the call site?
I would bet that they do not. Adobe has wrapped "dialog creation" (along with hundreds of other GUI abstractions) in their own cross-platform layer, and their GUI code calls that. This is the same thing done by pretty much any company developing for more than one platform.
The approaches can differ a lot. For example, consider Reaper (another DAW). Its lead developer picked a tiny subset of the win32 API that he wanted to be able to use, and implemented that for macOS and Linux/X Window. Then he uses the (partial) win32 API for the entire GUI (with higher level stuff built on top of it).
Re: Stop Building Closed Ecosystems
#123Earlier quoted context omitted.
I wasn't trying to name "great" cross-platform apps. The question was "what is a cross platform app". Is Chrome or Firefox a cross-platform app or not, regardless of how they shitty they may or may not be? > Photoshop has a shit ton of Cocoa and before that Carbon on the Mac. While the processing engine may be cross platform. The UI is mostly “native”. Every GUI application that runs on macOS has a "shit ton of Cocoa…
The discussion is about cross platform “frameworks” versus writing apps using the native frameworks. Adobe and Microsoft basically use native frameworks for most of their apps. It’s the difference between most of Office and Teams and VSCode.
That being said, even with these toolkits you can make applications that are themed and behave similar enough to the native runtimes that most users wouldn't notice. But that's a developer's choice to do so, or to completely customize the app for themselves and the UX they're looking to deliver.
To me the concept of cross-platform desktop applications is pretty interesting, as when you include the Linux ecosystem into the fray it's not macOS, Windows, and Linux (Qt/GTK), but rather macOS, Windows, GNOME (libadwaita), KDE (KDE Frameworks), etc etc. And that is significantly more difficult to support "native" for, even if the latter are using GTK and Qt under the hood of their respective platforms. Apple can make first party applications that abide exclusively by their HIG, and the same with Microsoft, but asking vendors targetting multiple platforms to do so and essentially support multiple versions of their apps to achieve "true native" when "seemingly" or "close-to" native via the toolkits widgets, built in theming capabilities, and backend abstractions are available can be a bit of a tall ask.
Re: Stop Building Closed Ecosystems
#124Earlier quoted context omitted.
How did things end up this way? I'm massively frustrated by the stupidity of our security team and it gets worse each year. And I've tried to explain this stuff about web apps exactly like you just did but it never quite gets through, and when it does it gets a response like "well, we should probably find a way to restrict web apps as well". I know for a fact that none of the people doing systems administration that…
Security teams don't bear the costs of reduced productivity from saying no, but bear all the blame if they make a wrong decision to approve something. So they're heavily incentivized to say no. Like many principal-agent problems, it requires someone appropriately situated to weigh the costs and benefits. If that doesn't happen, it gets borne by someone, usually shareholders who pay in reduced profits and eventually c…
Re: Stop Building Closed Ecosystems
#125> In the world of mobile development (though likely also elsewhere), we sink so much engineering talent into making tools that are great within-ecosystem, but as we don’t bother making them available to other ecosystems, everyone ends up reinventing the wheel.
I get the frustration with software churn and substandard tooling when you have to code for multiple platforms, but this is a very hand-wavy admonishment. Leaving aside who "we" are and what our cross-platform responsibilities are for the moment, how would this even work? Different platforms have different capabilities. Cross-platform tooling will therefore always be more complex and less capable than platform-specific tooling.
One could then argue that we should consolidate platforms, which generally will be more efficient, but who will be responsible for this platform? Whether closed or open, you are now in a situation where one platform has to be all things to all people, and that means there will be tradeoffs that hurt someone. I'm a happy iOS user, but I'm sure glad Android exists because diversity is healthy.
Technology will always trend towards consolidation because bits are cheap and easy to move, and there's always an incentive to harness economies of scale. The problem is mono-cultures are brittle. Some amount of "reinventing the wheel" is just the cost of a healthy and diverse software ecosystem. The OA should be careful what he wishes for.
Re: Stop Building Closed Ecosystems
#126The main problem is who gets to decide on the one anointed approach. Diversity ends up being a good thing, and also makes everything more messy and more complex. Take your example of the Open Web. I wouldn't be in software without the Open Web. I hand-write HTML and CSS to this day! But many people hate the web stack. They hate the ergonomics and enjoy better ecosystem for nearly every possible thing implemented in t…
> I hand-write HTML and CSS to this day! Yeah but... for your job? I'm sure we all do those side projects, but hard to imagine being able to do that on a complex multiple-member team project
In those use cases, there can be good business reasons to do things this way: Part of my current project is building something where odds are there won't be another tech person around regularly and it needs to last for several years (the information is evergreen). For something I want to run for 8+ years with minimum fuss that doesn't require storing user data and that may need to be ported from LMS to LMS or eCommerce platform to eCommerce platform/won't be broken by updates (because again, no regular dev to maintain it and check compatibility), using basic HTML, CSS, and even vanilla JS can make sense. I can write something in HTML/CSS/vanilla JS and it will probably run in browsers until the heat death of the universe.
Re: Stop Building Closed Ecosystems
#127Earlier quoted context omitted.
I want native apps on my platform of choice that leverage the native capabilities of that platform. That’s the entire reason I chose one platform over the other. Mac users complained about Word 6 forever ago when MS tried to use a cross platform toolkit and Apple’s Windows app were just as bad.
So you don't actually want cross-platform apps at all, but either single-platform apps, or apps developed independently for both platforms (because otherwise you're just talking about some in-house cross-platform toolkit).
Re: Stop Building Closed Ecosystems
#128This is my main fear with Flutter CanvasKit & "Towards a Modern Web Stack". https://hn.algolia.com/?query=%22Towards%20a%20modern%20web%... They are using canvas & webgpu, & making their own rendering engine (borrowing Skia) to take web apps from part of a participatory open ecosystem where extensions & user-agency work, & turning the page into a giant animated screen. The best open ecosystem we have on the planet is…
Re: Stop Building Closed Ecosystems
#129I strongly disagree with most of the points in this article. Why does he blame small app developers for vendor lock-in? Why is everyone casually avoiding the fact that vendor lock-in comes from.. vendors? You think I want to rewrite the same app 3 times for it to work on Apple, Google and Microsoft systems? When is the last time these 3 major platform owners have done anything but locking you in their ecosystem? Such…
It's a selfish take.
Re: Stop Building Closed Ecosystems
#130Earlier quoted context omitted.
It's going to run fine everywhere. It's going to work. As a native app strategy I think it's fine. It's immaterial, if it works. But on the web, it is damage. It breaks all user agency, wrecks all extensions, breaks accessibility extensions, prevents scraping. It's a closed world, and the web doesn't deserve this native app mistreatment.
> But on the web, it is damage. I couldn't agree more. > As a native app strategy I think it's fine. It's fine in the sense that it doesn't damage open ecosystems in the same way that circumventing the web experience does. It matters if you care about the customer experience. Companies like McDonald's would likely see a significant bump in use and user satisfaction if they replaced their Flutter app with native apps.
I had kind of assumed Flutter was performing fine/native-ish, it just didn't look native native. Different people will feel differently about the importance of native purity. I personally (with apologies) have seen native as a bit of a negative in general (with concerning privacy, dark patterns, & no observability/extensibility), and that's made me care a lot less about React-Native & Flutter & the like there. But if Flutter's really running bad too: that's embarrassing and not good, straight up!!
However, two things. The first is a repeat: it won't always be bad. This team is going to make this fast. There aren't real encumbrances to that happening & it will, is what my reading of the tea leaves says. Mostly gut feel, yes, but the plan seems solid. On the web, they're only just getting WebGPU booting, and still using older Dart VMs rather than actually compiling to wasm, so the web in particular is just barely getting started, but I'd expect the mobile situation has gobs of tuning potential too, and the team seems capable & smart & like they have the mandate to bring it. Their new Impeller optimizations to underlying Skia are just landing & already should help a lot, for ex.
The other point I'd just raise is the Electron/Slack problem. People all assume Electron is unbelievably awful & slow & terrible, because they used Slack a couple of times & saw it responds slowly. When an app is bad, people tend to blame the framework. Electron is not without sin, but there are examples like vscode where it is quite snappy & fast & universes more featureful & expansive-in-purpose than Slack. No matter what your development target, it's possible to make slow & bad apps.
I have no real insider knowledge of the Flutter app situation today, the lay of the land, but I'd caution too much against using current bad apps as an indicator of what to expect, caution against letting current experience too deeply/permenantly shape our belief/disposition (lest these form convictions which lead us astray from the truth everyone else experiences). More than UI, issues like Client-server data models & algorithmic complexity are woefully under-considered everywhere. Few businesses have a chain of command that speaks the tech language well enough to keep the ship from bottoming out or from not just rubbing along the seabed as it travels. It would be unshocking in the least to me to find a bunch of the big name Flutter apps are at Slack levels of quality internally.
Then again, maybe it is partially or all Flutter's fault! Maybe I'm wrong and it stays terrible forever! But the Highest Form of Disagreement is to assume these problems are surmountable, and I don't see anything really strongly technically impeding success (if having native widgets isn't somehow a requirement).