The native side of this has long been addressed by cross-platform toolkits including but not limited to: Qt, GTK, FLTK, WxWidgets (note: all FLOSS, at least optionally).
Alas, web development "decided" to completely reinvent the wheel for all this stuff, leading to a new generation of heading-to-native toolkits derived from browser-based technologies, such as Electron, React Native and Flutter.
Unless you believe there is any mechanism to force a single cross-platform GUI toolkit on all developers - a belief that would make you basically insane - the reality is there will always be N different options for cross-platform development, depending on (a) which platforms you intend to cover (b) your own development history (c) subjective preferences (d) specific functionality that may be limited to specific toolkits.
Does it matter if N is 10 instead of (say) 5 ? I don't know.
Does it matter if the N is segmented into "derived from 90s widget models" versus "derived from 2010's web models" ? I don't know.
Is there any chance of a single toolkit that covers native desktop environments (which continue to be important for creative apps, high performance apps, browsers etc.), native mobile and browser based apps? I don't know, but it seems ... unlikely.
If quality mattered then maybe the other toolkits would have a chance, but no one is looking at the web for that, they are looking to the one advantage that the web has that the others cannot hope to beat: They work around bureaucrats. At least in the enterprise, with desktop applications you need to deal with IT security losers who freak out when you ask that computers actually have useful applications, and god help you if you need to get a port opened.
Forget that, just shove everything down port 443 and download the application over and over again until the end of time.
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 install this junk endpoint management software actually want to install it. And it's laughable that corporations can simultaneously claim to be implementing zero trust, while at the same time giving crowdstrike software more trust than anything ever had before everybody decided they wanted to chase buzzwords. It can take weeks for me to get a new hire set up with WSL right now. If I didn't like the people I work with I would have jumped ship a long time ago.
Security teams have managed to threaten and bully their way into having more power than anybody else in IT. All the big stories about hacking is certainly part of it, but honestly I don't think that fully explains it. If I was a CIO paying an enormous amount of money for endpoint management and then saw something like solar winds happen, I'd probably have fired everybody on the security team that advocated those sorts of security strategies.
In my mind, security is something that should happen deep in the backend and be handled mostly by programmers, DBAs, and the admins that handle application servers. Once the data has left those environments with somebody it shouldn't have you have already lost. No hacker has ever said "I breached the database, but then got stopped from exfiltrating data because somebody made it so the USB sticks don't work".
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 capital destruction as these companies get ossified and disrupted.
"You cannot be blamed for bad decisions if you make no decisions".
Far easier to say no to everything, that way either your manager takes the blame when they overturn your decision or your are blameless when Shadow IT takes over.
That, and it allows you skip the troublesome business of userstanding user needs.
> "I breached the database, but then got stopped from exfiltrating data because somebody made it so the USB sticks don't work".
It might be a generational thing, at some point I know people actually had Napster running on their work computer, or were torrenting porn movies. That's how the whole Metallica thing happened. That feels absurd to me in today's corporate env., for better or worse the work/private split has really come a long way.
Malware spread by physical media was also a thing for a while, it's not just about the getting stuff out, a lot of the restriction on USB is not getting things in.
PS: on the "why" of all that...I'd say Windows. Platforms all have their weaknesses, but Windows opened the doors wider than anyone else IMHO.
This is also one reason why users in corporate environments solve so many problems with Excel: it's a powerful, easy-to-use tool for making custom "applications" (within certain constraints) that is already installed on your work machine. No approval process, no procurement, no IT staff involvement; just users getting things done with what they have.
Even in terms of quality, the web beats most of those platforms. Especially now, and especially when compared to GTK or Wx. You'd actually have an easier time building a native-like app using web technology than GTK or Wx.
I guess that wasn't the case a decade back when the web for everything trend started, so your point about ease of use/bypassing stupid security policies is still right about how the shift started, I think. But that eventually led to a steady improvement.
I don’t necessarily disagree with any of this. But the toolkits first listed are all pretty poor if you care about aesthetics and UX.
It’s like making furniture with framing lumber and OSB. It’ll work fine and be durable. But it just always feels not great. They generally feel, to me, a semitone sharper than portability with 90s Java applications.
For some classes of applications, all the developers want is a 2D surface (call it a canvas if you like) to draw on and then they do everything else themselves.
This leaves several notable areas of UI/UX to address:
These are where "the native experience" (i.e behaving according to guidelines or rules laid down by the platform controller) is really felt.
Yet they have very little to do with the "interior" (in-window) behavior of the app at all, despite being critically important.
If we're going to continue with the construction metaphor, I'd say it's more like creating a lovely house that has unusual door handles, windows that open in strange ways, and a different LED lighting temperature than you're used to.
As you say, I think you’re right for many classes. But in other classes, apps are entirely widgets. I’m looking at the first Electron app in my quick bar: Spotify, and thinking about how to make it portable without being Web.
It’s all widgets, no canvas. If you made it in any of the above it won’t feel Spotify it’ll feel Qt or whatnot. For Linux and FOSS types this is usually fine. It’s sure fine for me. But for the vast majority of users it isn’t.
And I don’t think anyone wants to write the application natively thrice.
When it comes to “mostly canvas” applications I find myself thinking about using game engines. They’re portable and basically that: a canvas with some basic UI support.
The differences aren't always surface level aesthetics. Say in a toolkit the text input widgets don't support pasting content. An app using it will behave materially different than any other on the system. Not only that it might look ok but lack functionality necessary to the user.
This is not hard to imagine since various UI frameworks have long had issues with different paste board systems on Linux.
> Say in a toolkit the text input widgets don't support pasting content.
That's a bug.
> various UI frameworks have long had issues with different paste board systems on Linux
In my experience on *nix (37 years, going back to SunOS), the paste board systems for X Window are very well defined, and the only UI frameworks that have "long had issues" with them are buggy and not widely used. Are you thinking of something in particular?
Pasting between Xlib, GNOME, and Qt apps was a shit show for years. The situation has improved significantly since the advent of Freedesktop.org but there used to be lots of problems. It doesn't matter if a UX problem is a bug or design problem. A user doesn't control if some app decides to use some unpopular UI framework. It's a Linux-on-the-desktop problem no matter the ultimate cause of the issue.
There's still issues today on Linux with keyboard shortcuts. Some apps use Ctrl+Shift and others use only Ctrl, there's no way to know what an app uses a priori. You have to hope the shortcut is displayed in the menu and you remember it when you need to actually use it. Different frameworks have different default shortcuts for common behaviors. Accessibility for any individual app is still hit or miss, same with localization and theming. Mac and Windows users don't face anywhere near the same impedance mismatch between various first and third party applications. Those systems are far from perfect but they're usually much more consistent UX than a Linux desktop.
For the sort of "creative" apps I'm interested in, kbd short cuts other than Ctrl/Cmd-[cxv] are the domain of the app, and more or less every possible combination is used. My own app has more than 400 shortcuts just when installed with no additions by the user. What the OS or other apps do is of no relevance for creative apps (except for other similar apps).
There is still an opportunity for Qt to win in this area - they should make it really easy to create (well documented) bindings for new languages (that integrate with their runtimes)
> Unless you believe there is any mechanism to force a single cross-platform GUI toolkit on all developers - a belief that would make you basically insane - the reality is there will always be N different options for cross-platform development, depending on (a) which platforms you intend to cover (b) your own development history (c) subjective preferences (d) specific functionality that may be limited to specific toolkits.
The problem is not forcing people to do this or use that.
The problem is the quality and development experience is just _so bad_ that people are resorting to other options.
Don't get me wrong, the dev experience for web is terrible, but it's still light years ahead of legacy toolkits like qt/gtk/etc.
I think they're roughly the same in terms of dev experience. Major toolkits have good bindings for dynamic languages like JS and Python so C++ isn't a barrier. I think mostly what happened was Electron's pitch of "turn your web app into a desktop app almost for free" meant that web devs could stick with React rather than learning wx or Qt. There were a lot of web devs and web companies so this meant a lot of Electron apps where once there might have been native apps.
There are multiple explanations for why cross-platform toolkits are kind of awful. I'm treating "cross-platform toolkits are kind of awful" as an observation here, because I've used them, I've worked with them. And my measurement for awful is poor UX, relative to native apps.
Different platforms are just slightly too different from each other to make it work well. So you end up with a bunch of cross-platform apps which are built on things like Electron. You more or less reject platform expectations for how apps should work, how they should look, or how they interact with other apps / other parts of the system.
You end up with stuff like Spotify or Discord.
Thing is--if I'm getting work done with this app, if I get paid for working with it, I'm going to pay for a better experience. Instead of using GIMP, I'll use Procreate, Photoshop, Pixelmator, whatever. Maybe I'll use Notepad++ or BBEdit. Maybe I'll buy Pro Tools despite its cost, or maybe I'll buy a Mac just so I can use Logic.
It is costly to just reimplement your UI for multiple platforms, but that's where the "closed ecosystems" come in. React Native is kind of a compromise between the Qt-style approach (cross-platform UX) and the native approach. You're given a framework which works with multiple native toolkits, and you can have a mix of cross-platform UI code and platform-specific UI code.
Is Photoshop a native application? It sure doesn't act or feel like one on Windows. It seems to be just using an Adobe in-house cross-platform abstraction. Maybe you like that abstraction's output more than web platforms, but that's a different matter.
"Somewhere, deep down under the streets of Photoshop, down where the mole people live, is a little framework called "MacApp." It's a remnant from the very first versions, a fragment of foundation. MacApp originally let Photoshop communicate with the underlying operating system, which was then Mac OS 6.0.3."
> It is costly to just reimplement your UI for multiple platforms, but that's where the "closed ecosystems" come in. React Native is kind of a compromise between the Qt-style approach (cross-platform UX) and the native approach. You're given a framework which works with multiple native toolkits, and you can have a mix of cross-platform UI code and platform-specific UI code.
I don't understand this claim at all. Qt (or GTK) let's you "escape out" to the "native" toolkit on Windows or macOS as needed.
There are not multiple "native toolkits" on Windows or macOS.
> Different platforms are just slightly too different from each other to make it work well.
So basically, you're denying that it's possible to do excellent cross-platform apps at all. OK. I'm not sure I agree with that, but it's a position.
> There are not multiple "native toolkits" on Windows or macOS.
This is just not true on Windows. What is native Windows these days? Win32? WPF? WinUI? Even if your view is that Win32 is the one true native toolkit, MS alone produces multiple abstractions over Win32 like Windows Forms or MFC.
Even when I was programming on Windows in the mid 200x’s there were 9 or 10 ways to represent a “string” depending on which framework you were using and you had to convert between them depending on the API you needed to call.
Honestly, if someone produced a book that said how to write win32 applications in a way portable enough that current distributions of wine would not have to do any special work to make them work, I would very strongly consider that option.
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 doesn't call Win32, it implements its own widgets, something that would most often be exposed in differences in high-dpi support. These do generally try to align with the Win32 widgets from that Windows version visually, but there's plenty of discrepencies.
WinUI is the new framework which isn't even shipped with the OS as of the latest versions, but even if you're using the built in verison it's not calling Win32 widgets or WPF widgets, it's once again implemented a new set. The lower level APIs share some similarities with WPF as it basically started as a fork of WPF modified to implement Windows 8 UI patterns, but neither WinUI or WPF are implemented in terms of the other.
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" inside it. There's essentially no other way to create a GUI app for macOS, regardless of the toolkit you use. There's a separate question like "are the buttons drawn by Cocoa, or app-specific, or toolkit specific?" but I regard that as a separate question.
On the flip side, nearly all groups in the VFX industry author their apps with Qt and deliver across Linux, macOS, and Windows. The "native" side of things is where people usually end up having the most debate, typically around appearance. VFX and creative apps tend to choose to look and behave consistently across platforms within their own context, rather than trying to utilize the human interface guidelines (HIG) of each respective platform. The standard place where this differs is usually on the file picker component.
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.
So if it’s “themed” to look “native”, what happens when the vendor chooses to change the theme of the native widgets? Do the themed widgets automatically support the user’s localization and internationalization preferences? Does it support the accessibility affordances that you could get for free when you use the native toolkit?
> 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.
And could that be part of the reason that Microsoft and Adobe - both with a multi decade history of writing cross platform apps that use the native frameworks of the target platform are really the only two software companies that are really still successful making desktop consumer/prosumer software?
The biggest DAW of the last 20 years: Ableton Live (Windows/macOS)
The next biggest DAW of the last 20 years: Reaper (Windows/macOS/Linux)
The most rapidly expanding DAW right now: Bitwig (Windows/macOS/Linux)
The most deliriously loved DAW: FL Studio (Windows/macOS)
Most widely used DAW by paid professionals: Digidesign ProTools (Windows/macOS)
Other DAWs not made by Adobe or Microsoft (neither of whom make an actual DAW): every single other DAW, most of which run on Windows & macOS, except Logic, which was cross-platform until Apple bought it.
But I could make a guess at other worlds too:
Biggest splash in the video editing world: DaVinci Resolve (Windows/macOS/Linux)
Most widely used 3D/animation: Blender (Windows/macOS/Linux)
Not really sure what you're talking about claiming that Adobe & Microsoft are the only two software companies that are really still successfully making desktop consumer/prosumer software, unless you are deliberarely excluding actual "pro" software. In which case ... I just don't really care.
I’m considering massively successful as two companies that have literally been selling versions of the same software for Mac and PC software for over 35 years.
Another poster cited this as far as how much “native” code is in PhotoShop
> But Russell still has MacApp to contend with — it most recently flared up during the Mac Cocoa conversion. Millions of lines of code had to be changed, and for a time the entire team was engaged on the project.
And let’s talk about ProTools. It is even in a worse position than Adobe with respect to being able to use cross platform frameworks. The backend leverages Mac and Windows specific APIs
> same software for Mac and PC software for over 35 years
You couldn't even do what contemporary DAWs do in a native application until the late 1990s. Even in the early 2000s, ProTools relied in a "DSP Farm" installed on the PCI bus to provide enough compute power. So the timeline for this particular sort of software only extends back 25 years or so.
CoreAudio is not a "front-end" toolkit/framework/library.
You cannot do audio or MIDI I/O on any platform without ultimately talking to the platform APIs for that (not totally dissimilar to how all GUI toolkits ultimately having to talk to some low level drawing/event API).
The backend of every DAW, audio editor, audio player etc. uses platform-specific APIs, either directly via their own platform-specific code, or via a wrapper such as JUCE, or RtAudio (JUCE is extremely popular these days, though it is also a large cross-platform GUI toolkit that is increasingly dominated startup audio software development).
None of that has anything to do with GUI toolkits, or front ends, or native experience, or UI or UX or any of the things we've been talking about.
> None of that has anything to do with GUI toolkits, or front ends, or native experience, or UI or UX or any of the things we've been talking about.
This was the basis for my comment. It's not possible escape native APIs, but what differs will be how you consume them. You can either choose to use them directly (true native) or you can use a toolkit that abstracts the various backends. This provides you a single development layer across all platforms while the toolkit itself is what handles the access to the underlying platform native APIs. So it's not on you the vendor to keep up with what's changing at the OS layer, but the toolkit.
Obviously there are trade offs with all methods, and they can be mixed and matched as needed. For example, Qt is not a GUI toolkit like GTK, but a platform toolkit providing APIs for a whole host of functionality beyond visual representation. Does that mean you need to use Qt's multimedia package to handle video or such? Absolutely not, but for the features it provides that are shared across platforms it can make things easier to develop (this is purely for example purposes, I've never authored anything with Qt Multimedia).
Do web developers generally create their own audio subsystems or use platform native APIs directly? No, those aspects are handled by the browser which does the heavy lifting for them, allowing for a write-once-run-anywhere{-that's-supported} experience. The cross-platform toolkits (like Qt, JUCE, etc) do the same thing; they talk to the platform APIs on your behalf. What kind of expertise or team structure you require to build your application for various platforms really depends on what level of the stack you want to author against.
> I don't understand this claim at all. Qt (or GTK) let's you "escape out" to the "native" toolkit on Windows or macOS as needed.
You're kind of fighting against Qt or GTK when you do that. Qt and GTK have their own widgets. React Native is more of a framework that uses native toolkits to begin with, so it starts out with much better alignment with platform expectations, and has better interoperability with platform features.
> There are not multiple "native toolkits" on Windows or macOS.
I'm confused by this comment. I don't know what kind of point you are trying to make here, or what you are responding to.
> So basically, you're denying that it's possible to do excellent cross-platform apps at all. OK. I'm not sure I agree with that, but it's a position.
Yeah, let's dial the "it's a position" condescension back one or two notches.
When I said, "Different platforms are just slightly too different from each other to make it work well," the "it" refers to cross-platform toolkits like GTK and Qt, which provide their own widgets. This explains why so many people use Electron and just embed a web browser (let's say "fuck it" and make one UI inside a big window), or choose to use something like React Native. Maybe I'm drawing too fine a line here--I think of Qt and GTK as cross-platform toolkits, I think of React Native as a framework without the toolkit parts, and I think of Electron as some kind of cross-platform box that you can something inside. I'd rather not talk about the definition of "toolkit" or "framework" because the definitions are not material.
Qt is a big honking mess, and GTK is worse. Speaking as someone who has written apps using both, and fixed UI problems in people's open-source Qt and GTK projects.
> This explains why so many people use Electron and just embed a web browser
I would wager there are 100x the number of Qt/GTK apps than there are electron apps. That number could go up or down by an order of magnitude, and the older widget-based toolkits would still be ahead. So ... I don't think that citing numbers of developers doing X or Y is helpful here.
> React Native is more of a framework that uses native toolkits to begin with, so it starts out with much better alignment with platform expectations
More similar to WxWidgets then, which uses native widgets but wraps them in lowest common denominator API. For one reason or another WxWidgets hasn't been as successful as one might expect.
Anyway, as I've noted elsewhere in this thread, the majority of creative apps (including Logic) barely use any of the native toolkit within their main windows. Almost all DAWs, drawing programs and image editors just treat their windows as a big 2D drawing surface, and do their thing without regard for UI/UX widgets or rules designed around productivity/business/system utility apps. The "native" aspect kicks in only when they interact with the rest of the desktop environment, and they vary quite a bit in how native they go (they also keep changing this; Logic has gone back and forth with using the native file browser vs. an app-specific one several times over its life, and in different contexts within the app).
This also has implications for the extent to which Qt/GTK/etc. toolkits impact the UX. If someone writes a widget-heavy app, then the toolkit design & implementation will have a strong impact. If the widgets are limited to some toolbar at the top, it doesn't really make a lot of difference as long as the devs get system tray/notification right, and don't screw with window management.
> I would wager there are 100x the number of Qt/GTK apps than there are electron apps. That number could go up or down by an order of magnitude, and the older widget-based toolkits would still be ahead. So ... I don't think that citing numbers of developers doing X or Y is helpful here.
If making the comparison is not helpful, then why make the comparison in the first place? I was just observing that "many" developers made the choice to use Electron; I am not trying to compare numbers of developers here.
> More similar to WxWidgets then, which uses native widgets but wraps them in lowest common denominator API. For one reason or another WxWidgets hasn't been as successful as one might expect.
Yeah, although I think WxWidgets abstracts too much.
Maybe I can frame it this way--I'm not really against cross-platform toolkits in the first place, and I'm not complaining about cross-platform toolkits on a conceptual level. I do think that apps made with cross-platform toolkits often have UX problems and I think part of the reason is because the underlying platforms are too different. Those differences are both (edit: fix) technical differences and differences of conventions / expectations.
React Native seems to have less abstraction. Maybe that's just my subjective thoughts on it.
> Anyway, as I've noted elsewhere in this thread, the majority of creative apps (including Logic) barely use any of the native toolkit within their main windows.
Sure, if you focus narrowly on the main content of the main window, you'll see less of the native toolkit being used. But that's only one part of the app, and it's still built to match platform expectations, in a way that is not easily abstracted out by cross-platform toolkits.
Logic is a bit of a funny example because Apple has a separate set of "pro" widgets they use for their creative apps, like Logic and Final Cut. You can see that, for example, Logic has a decent number of .nib files, which means that it's making use of the native toolkit, even if it's not everywhere.
Finally took a look, and this appears to be mobile only. Certainly covers one definition of cross-platform, but a little different than the other toolkits we've discussed.
Nope, React Native does support targeting Windows and macOS (and, though with less love, Linux) and even Web, tvOS, Android TV, and more. It’s just that iOS and Android are the only official Meta-maintained ones.
The macOS and Windows implementations are solid, being maintained by Microsoft, and are even used in small corners of Microsoft Word and other flagship apps.
Some further digging does reveal the non-mobile stuff but sheesh, that is so easy to miss. Incredibly obvious to conclude that it would not be relevant. And indeed, even where they mention the macOS & Windows targets, no mention of Linux.
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).
That's a false dichotomy, someone can want a cross-platform app that has shared code but the outcome is "native-like" on each of the platforms. If a cross-platform toolkit can't do that and people consider that its result is a bad fit to some of the platforms, it doesn't mean that these people don't want a cross-platform app, all it means is that this toolkit is not good enough.
Why do I as a Mac user care about cross platform apps? Even as a long time Windows user, why would I care about cross platform apps?
I chose a platform because the platform and the apps meet my set of priorities.
As far as how that affects Linux users, even if I did prefer Linux as a developer platform, why make it my daily driver instead of running it in a VM or with something like WSL2?
Well, you're obviously welcome to do whatever you want, but I personally regard this as backwards. I believe in libre software, because I believe it is ultimately going to be better for users (over what timescale, I can't say for sure, but longer rather than shorter), and better for developers and better for technology. So I want to work on a libre platform, to some extent regardless of the applications I need/want to use, and thus I pick Linux first and apps second.
When the app is not there (e.g. a DAW), I merely choose to spend a few decades of my life developing it, thus destroying my ability to do what I originally wanted to :)
As for why would you prefer Linux as the daily driver, that would depend a lot on what you were doing/needed. It is a technically superior in almost every respect (not every, but close). It has better audio latency performance, should that matter, better bandwidth for most things, is generally more customizable to your own preferences (though obviously other platforms may be customizable enough). Upgrades and maintainance is generally simpler and smoother. I like being in control of my technology in a way that Microsoft and Apple increasingly do not allow me to be.
I'm not saying that you have to care about any of that. I do, that's all.
It sounds like you are largely in agreement with GP, who says:
"I chose a platform because the platform and the apps meet my set of priorities."
You listed a wonderful set of priorities which put the philosophy and a certain kind of usability at the top. GP seems to value day-to-day UI/UX within the desktop.
So question for you, with regards to cross-platform, insofar as you value it as a goal, is that to help spread the user base of libre software?
> So question for you, with regards to cross-platform, insofar as you value it as a goal, is that to help spread the user base of libre software?
Essentially, yes. As a developer, I'd like my work to be available to as many people as possible, and I'm not dogmatic enough to insist that they choose to use Linux or another libre OS as their platform. If I want users of other platforms to be able to use my work, I need to somehow do cross-platform development. That means either creating my own cross-platform toolkit, or using an existing one.
As a side note, I'd also say that cross-platform development turns out to be great for finding bugs and design flaws in your software. Exposing it to other compilers, linkers and UI/UX design models has always been a positive experiences, even if often frustrating.
So you regard it as backwards that Apple and Microsoft give users what they prefer including a better user experience? Do you seriously wonder why the “the year of the Linux desktop” never came?
And what good is this supposed “technical superiority” if it doesn’t have any end use benefit? Does it integrate with my other hardware seamlessly like my headphones that switch automatically between my phone, computer and watch? I can start an SMS message thread on my phone and finish on my computer or if I’m sitting at my computer and my phone rings, I answer it from my computer? Does it give me 16 hours of battery life?
And the Mac is kind of known to be great for audio editing if you’re not aware and has first rate software.
I haven’t heard anyone say that the ARM based Mac are poor performers
> I like being in control of my technology in a way that Microsoft and Apple increasingly do not allow me to be.
Would I rather be “in control” of hardware that sounds like a 747 when you do something even mildly intensive with piss poor battery life by modern standards or have a laptop that I can actually work with on my lap and have 16 hour battery life?
Laptops are a different category. I use one, but only for travelling. Most of the time, I work on a massively multicore self-built AMD-based system which is cheap, incredibly powerful and almost silent. My power comes from the sun, and I don't have to care about battery life.
My AMD system has better audio performance than any Apple system I could buy (and I can even run Mojave on it, with better $-per-cpu-cycle than anything Apple would sell me), despite Apple systems indeed having great audio subsystems.
I rarely use headphones, but when I do they are studio quality ones that do not use bluetooth, and are fed via my studio gear, not random consumer devices.
Look, I get that different users have different needs. I'm not trying to persuade you not to use Apple products. I just happen to think that the focus on "how good is this for my day to day needs" can obscure a more important long term truth. Farmers have been discovering this with John Deere for the last few years, another company that makes incredibly great hardware that is totally what their users need. It just turns out the Deere's model of buyer lock-in via repair control is now causing conflicts for those same users.
So when will that day come? Microsoft and Apple have been the dominant desktop OS since the mid 80s. Yes I realize that Apple has hovered between 10-20% since the mid 80a
What day? I never dreamed of the "day of the Linux desktop", if that's what you mean. Couldn't really care less (other than to note that it would be nice).
I meant the day that Windows or Mac users would regret the “lock in” like farmers do with John Deere? Especially since Linux is easy to run on top of either and many of the best tools are ported.
I suppose you don't, at least not as a user. But behind app availability, which is a concern for you, is this whole debate about cross-platform apps. It's likely that the only way you get to continue using your preferred platform and some new app/piece of hardware is if the developers use a cross-platform toolkit.
When releasing software, macOS is a small tertiary concern for me at best, behind Linux (for myself), Windows and mobile platforms. So if you care about app availability, you indirectly care about cross-platform toolkits.
This is going to sound a lot worse than I intend it to. But why would users care about a little indy app that’s a bad port with a non native UI when they have the choice of major, popular, commercial apps from the major players?
Well, maybe they shouldn't. Those popular apps are likely to be better just by virtue of being better funded. But if there were apps from the major players for every usecase, all programmers would be working for Adobe-sized corporations. Thankfully, that's not the world we live in.
Recently I've looked at apps for running a "flat owners' association" in the Czech Republic. The general feeling I got was that maybe one was at least approaching intuitive and good looking design. Using a cross-platform UI toolkit wouldn't hurt these apps one bit.
Besides, the only ones that supported macOS at all were web apps, the epitome of non-native. So if a non-programmer wants to manage such an association on a Mac, their only options are cross-platform apps or a spreadsheet, proving my point.
Look at WebGPU. Still a WIP, but it shows that you really CAN provide a performant cross-platform... platform if you're really thoughtful about performance
No I didn't mean to imply its utilization for GUI development. I meant for it as an example of cross-platform technology that maintains good performance while being extremely cross-platform
And will it look and act like a native app? Will it support all of Apple’s built in accessibility affordances that a developer can get for free by using Apple’s native toolkits (and Microsoft’s)?
a11y is definitely a critical and often overlooked issue. And this is one area where I find myself in 110% agreement with the title of TFA: Stop Building Closed Ecosystems.
If the Apple and MS a11y frameworks were not so distinct from one another, wrapping them in a cross-platform layer would be much easier. But they couldn't be bothered, largely because they both have enough users whose priorities match your own: are the apps on the platform good enough for them. The incentives to standardize a11y at the API level across OS platforms is a tiny fraction of the incentive to standardize e.g. WebGPU.
Then, on the other hand, you'll rarely see Linux ports. Lowest Common Denominator apps have been a blessing for Linux users - we would have never had Visual Studio Code, Slack, Postman, and who knows what else otherwise; and you can't tell me any of their developers would've done the work to port everything to GTK or Qt otherwise.
Isn’t that a problem that Linux only has crappy cross platform apps that are not as good as native apps?
Why would I run a Linux box as my daily driver instead of a my Mac that is real Unix, has a 16 hour battery life and I can get great polished native apps?
> Why would I run a Linux box as my daily driver instead of a my Mac that is real Unix, has a 16 hour battery life and I can get great polished native apps?
Depends on the apps you are using; what's the Mac equivalent of Emacs? How about Meld?
Yeah, this is a bit of a leading question; you can get great polished native non-xplatform apps for Macs but if you limit yourself to that category then the Mac is no longer as useful as a mid-range Windows/Linux laptop.
If you're going to insist on using only non-xplatform native apps when on Mac, you're in a niche (image/video/sound editing, maybe?)
BTW: What kind of Mac laptop do you have that you get 16 hours of battery life? My 5mo M1 barely gets 4 hours when using only video-calling, Goland, Chrome and some terminals.
In over a year of using a Mac as a daily driver, I've yet to use one non-xplatform native Mac application. so I am curious about what you non-xplatform native Mac app you are using.
> BTW: What kind of Mac laptop do you have that you get 16 hours of battery life? My 5mo M1 barely gets 4 hours when using only video-calling, Goland, Chrome and some terminals.
Hard to say without knowing what’s running in the terminals, but I’d say Chrome/Electron (and potentially, its use of non-HW-accelerated codecs in video chat) is the likely culprit here. Not the same machine, but my M1 Pro MBP 16” can pretty easily swing a full work day flipping between Xcode and Android Studio so long as I’m using Safari for browsing.
I have a (work issued) MacBook Pro 16 inch M2 Pro Mac. I charged it to 100% and it lasted two full work days on battery at a client site open most of the time running VS Code and Teams (some people were still remote) and occasionally building AWS Lambdas. The build tools let you build Lambdas within an Amazon Linux Docker container containing the appropriate runtimes when you are building on Windows or Macs.
I mean, it depends on how much time you're spending in great, polished native apps. For work, I spend all of my time in VS Code, Chrome, Slack, and the terminal. It's hard to justify any platform as being better if those are the apps you use, since they basically work the same on any platform.
And then there are the people who spend day in, day out in programs like Photoshop, InDesign, Pro Tools, etc.
At least two of the final three you mentioned run on Windows and macOS, meaning that somewhere there's a cross-platform layer for the GUI. And yet apparently, that works.
There's a lesson there, though I'm not sure what it is.
The lesson is that you can get great cross-platform UX if you have a massive budget. There’s some cross-platform UI code, sure, there’s also duplicated work.
Photoshop was originally written using MacApp, so it must have gone through some extensive, extensive changes to get its first Windows version.
Adobe and Microsoft both have spent 30 years optimizing their development around supporting both Macs and Windows.
But how much of the GUI is actually cross platform? Adobe famously used Apple’s Carbon API and was very upset that it wasn’t ported to 64 bit. There is a lot of Cocoa in both products.
Microsoft use to brag that they had more Mac developers than Apple did.
> 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 similar toolkits, but they are not writing twice the code every time they have do something in the GUI.
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).
> 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?
This is still backwards. The domain logic doesn’t open a dialog anymore than a back end API opens a dialog on a web app or mobile app. The front end gathers whatever information it needs to call the backend code along with an event saying when it’s done “call this”.
The back end logic is usually naive to the presentation layer. Even in GUI apps it’s usually event based where the backend just sends an event saying “I’m done” and the front end registers an asynchronous function for a call back and when the function is called a dialog box shows up saying “done”.
The user clicks on a button or menu item labelled "Do Foo". To "do foo" requires further interaction with the user, and the designers opted to do that in a dedicated dialog. So the program now needs to make a dialog visible to collect information from the user. Simple enough for you?
What is the code at the call site that opens the dialog? WinUI? Cocoa? I am extremely doubtful that it is either. Ergo .. cross-platform "toolkit", albeit in-house.
Serious question - are you a developer and what frameworks have you used?
The front end already knows the inputs that the backend needs (in this case tte engine). When you click on a menu, it usually brings up another view without ever talking to the backend. I’m sure some companies have a framework that can automatically generate a native view based on an API definition.
Even your standard CRUD app you usually have a set of API developers and they may publish their API using something like the OpenAPI specification and then your web developers, Android developers, iOS developers create interfaces to call the API.
> What is the code at the call site that opens the dialog? WinUI? Cocoa?
This is fundamentally opposite of how development is done in a GUI event driven architecture. The back end is never the “call site” that tells the front end to “bring up a dialog box” The front end calls the back end.
Even if it’s not a user generated action, the front end still defines the interfaces and subscribed to an event.
In your example:
1. The back end developer (the engine creator) writes code that is usually cross platform if that’s the aim and required certain inputs and raises events.
2. The front end developer creates menus and defines views that are shown when the menu item is selected. The view allows the user to enter the necessary information.
3. The front end then sends all of the information to the backend and probably some type of call back function that the back end should call when it’s done or in the case of error.
The back end is never the “call site” nor does it know anything about the front end.
I was the 2nd employee at Amazon. For the last 23 years, I've been the lead developer of Ardour, a cross-platform DAW. I also wrote JACK, the only cross-platform inter-application audio/MIDI routing system, but since that's a system that doesn't require a GUI, it's not really relevant. It did win me an award in the early 2000s though.
What you're describing sounds to me like a process out of 1980s "application development" blended with web stuff blended with contemporary "rapid application development" aka "define the GUI with a GUI tool, and it automatically generates code".
Ardour has a fully MVC architecture, with a backend that knows nothing about any of the multiple frontends that can exist for it (GUI, MIDI, OSC/UDP, OSC/WebSocket). We do not use RAD tools, there is no generated code.
I asked you a simple question about what the code looks like in an Adobe or Microsoft app that runs on two platforms, the code that opens a dialog to collect information from the user. Nothing in my question makes any reference to tbe backend. All I can guess is that you think that all GUIs are defined via RAD-ish tools. All I can do is to try to use your language: what is it that a front-end developer is doing when they "define views that are shown when the menu item is selected" ?
> Ardour has a fully MVC architecture, with a backend that knows nothing about any of the multiple frontends that can exist for it (GUI, MIDI, OSC/UDP, OSC/WebSocket). We do not use RAD tools, there is no generated code.
In that case, you know that the call site is never “telling the front end to bring up a dialog box”
> I was the 2nd employee at Amazon
Well I’m the millionth something employee at Amazon :). But as far as generating a view. I’m thinking of something like the home grown (publicly discussed) tools that AWS has so that when the service team introduced a new API, we have tools that can automatically generate SDKs in all of the supported languages and the CLI. Why couldn’t a custom tool create native views?
Hey
Again we know for a fact that Adobe has “millions of lines of native Cocoa”. Why is it so hard for you to believe that the front end is hand coded by native developers?
Even at one 200 person company I use to work for we had dedicated web, Android, IOS and desktop developers.
But even when you aren’t using RAD tools, you are still defining your views some kind of way with XML, config files or something.
BTW, I’ve been a continuous hands on ”programmer” (we didn’t call ourselves developers back then) since the mid 80s when I was a hobbyist 65C02.
But even then the reason I prefer my Mac is that it integrates with my personal hardware. I do log in to my personal account on my work Mac But I am careful about what gets synced.
> Why would I run a Linux box as my daily driver instead of a my Mac that is real Unix
Because your real Unix ships with certifiably ancient GNU tools that haven't been updated since they switched to GPLv3 licences, and are a massive security risk.
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 being body snatched by the closed-as-can-be native app world.
The post here is a more developer-centric view of open & I think that's so valuable. It feels like we really used to have a more share-early share-by-default spirit.
I think that's one thing that kind of agitated so many folks about webdev, is how share-centric it was.
We didn't have established experts, there were no well established patterns, everyone was collectively figuring it out. Finding libraries that might work for you or doodling around with an idea was lead by sensibilities fit & taste. Throw it against the wall & see what sticks.
The web today has really become a far far far more hyperindustrialized system, with far more popular (not enforced) norms & conventions. The random lead devs at a company are no longer necessarily intrepid explorers navigating an open sea of possibility. Everything is more set. And we no longer have that spirit of it just being us in the room, of sharing by default. The expectation is there's very very smart far off people building libraries, and we're just working on our app. The mindset has shifted, the culture has shifted, in a way where open is no longer the collective exciting happening place that we are all a part of.
> 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.
This is effectively what Flutter does on other deployment targets as well, building a framework and high-level primitives on top of the host's low-level primitives, and in the process abandoning everything good about native frameworks and primitives for the sake of a Google-controlled runtime.
It's why Flutter apps feel so janky and awkward, and the same will be true of the web runtime.
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.
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.
Ok, that's reasonable. Thank you for your upfront starting agreement. I obviously have some real emotional attachment to the issue of whether users have agency or not, and this has been a really hard time for me, and hearing some recognition of the jeopardy as relevant is really touching, thanks.
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).
I think there's potential in those ideas, if only they are not to the detriment of the Web (which is already working just fine).
As an alternative to iOS and Android development, I welcome ground-up solutions as long as they can get text editing right. However, I bring that up as I can't see anyone ever making a ground-up text view as reliable as a browser or native one (consider CJK, RTL, and vertical text, and IME input) without a dedicated team spending years of work and closely examining each platform's equivalent.
What would you say is state of the art for Rust-native text rendering on the web?
I'm aware of ab_glyph, used by e.g. https://www.egui.rs/ but it looks noticeably non-native to my eyes. For one there seems to be no hinting. So text ends up blurry at 96dpi, and since a glyph stroke is thinner than a pixel the text always appears slightly faded, never able to reach fully black or white.
I wish these libraries would just use native APIs on each platform to render text, then all these problems would already be solved by the OS/browser. Though I'm not sure if the web has good APIs for that.
Maybe there's something better in Rust these days that I missed?
My personal applications tend to use only monospaces fonts and stick to Latin characters so I can get away with glyph rendering and then a very simple layout algorithm so something like ab_glyph or freetype is enough and I don't need harfbuzz.
I'm aware of swash and the other libraries in that stack, but it was going through a rewrite. The Linux support was incomplete, for example, it was dependent on a piped call to fc-list and parsing the output to get the system fonts.
Also, if I were doing it via web, I'd be tempted to render to an offscreen canvas and call it a day.
The worst part of flutter's web stuff is that the quality is absolute janky garbage. They're trying to undermine an open ecosystem, and they don't even offer anything useful in return. It's like making a deal with the devil except instead of getting the thing you bargained for, you just get stuck with a pitchfork and also you lose your soul.
The 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 the web. I think ultimately, that's ok and it's "worth" having competing standards, because the alternative is - pardon the dramatics - authoritarian.
edits:
> #2) Check for prior art first. The problem may have been solved before...
I generally take issue with the statement "this is a solved problem". It ends up killing critical thought on the vine. I think everyone is better served thinking critically, and yes maybe something off the shelf is the right choice. But think critically, and freely, first.
> #3) "be opened-minded to other approaches"
contradicts the idea of building one-thing all-together no?
I think the point is that the decisions on direction shouldn't be made behind entirely closed doors by insiders. Outside input should be taken seriously, with invitation to dialogue, rather than chasing some narrowly-supported vision.
As a web developer myself, I too am baffled by the folks who don't like the Web stack, but fine.
And good points, I guess I wasn't too concrete on "unify on one approach" vs. "consider all options". So to solidify my thoughts, I do think diversity in approaches is a good thing. It would just be great if any parts could be shared so that others could iterate on the same idea.
For an example of a missed opportunity for diversity, if only React Native had originally architected itself as Reactless Native + React, we could've had equivalents for each different renderer by now (e.g. Vue Native, Angular Native) based on that Reactless Native base.
For an example of the merits of unifying on one approach, see Yoga Layout. Flexbox has proven to be an agreeable layout model, and because it's so solid (apart from where it varies from the spec, which I do grumble about) various different cross-platform projects have benefitted from unifying around it as a reliable building block.
I guess my grumbles with Yoga's spec deviations echo your distaste for the "it's a solved problem" sentiment, too. Even established solutions should be open to improvement and evolution, and I had that partially in mind when talking about being open-minded.
Not everybody who's coding is doing it in a tech company on a complex multiple-person team project. I'm a software mechanic: I do really small scale tweaks for small businesses (I mean SMALL - my current project is for a business with one owner and 2 employees), non-profits, libraries, etc.
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.
I count writing JSX as hand-written as the child comment mentions. Also HAML in rails. I realize this perhaps is a fuzzy definition as we move along the spectrum of automation and abstraction.
What I mean to say is I still have a more-or-less 1:1 relationship with both HTML and CSS APIs to affect user interfaces. Like how do make round corners I need to know `border-radius: 100%`, or `borderRadius: 1rem`, etc
(And you're right, in all projects where "I have my way" meaning it's personal or in a small-group, I have the freedom to choose low-level vanilla primitives. Less so at work in large teams where everything is a build pipeline.)
I think writing a React component using JSX counts as "hand-written" HTML and CSS. Definitely when you're writing the low-level components that other stuff is built on.
I 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?
Vendor lock-in on behalf of Apple, Google, and Microsoft, sure. But then:
> but all frameworks are guilty. Electron, Capacitor, Tauri, Xamarin, Qt, NativeScript, the lot.
Well, these all solve entirely different problems. Different problems, different solutions. Not sure what the "lock-in" is here. It's like arguing that there is "lock-in" because one project is written in C# and the other in Javascript. Seems like stretching the concept of "lock-in" too thin.
> What I’d really rather see more of is standalone platform-agnostic modules
This is a false proposition. A phone is very different from a desktop. "Platform-agnostic" would mean a denominator so common that it isn't useful for anything. Again, different problem/hardware, different solution.
> It's like arguing that there is "lock-in" because one project is written in C# and the other in Javascript. Seems like stretching the concept of "lock-in" too thin.
This is absolutely an instance of lock-in. An ecosystem grows faster when it can borrow from other ecosystems but doesn't allow doing the same. This is exactly the same problem: there is no good FFI, so we have to write M libraries times N languages.
I agree that M libraries x N languages is an absurd reality (and why I still write C), but "lock-in" to me suggests intent, and the situation you describe is more accidental, at least if you exclude corporate languages like .NET and such.
The sense I get is, things should be more open, but not too open, because then it would be harder to sell the app. They're hoping that a very unnatural state becomes the default because it would be more profitable for _them_.
I guess everyone goes through the stage of life thinking that Open System, or Cross Platform should be the norm. Java write once run everywhere in the 90s or earlier attempt like Smalltalk. But forgetting the lesson of Write Once, Debug Everywhere. Even if you had "open" Ecosystem completely built on top of Linux you will still have completing OS with different parts like UX, UI or windowing systems / rendering engine. So what you want is a single OS for everything and everyone. Then you run into the other sets of argument which I wont name here.
There is probably a reason why many working in Tech or specifically software is heavily leaning into certain political spectrum which relates to the above.
I think about these frameworks as products. They are meant to solve specific problem for specific audience. I also think we need to start differentiating between different classes of developers. I think a good analogy is car mechanic vs mechanical engineer. when a car is made there will be a lot of need for mechanical engineering. Once it's on the road and needs to be fixed is when car mechanic comes into play. You need to decide whether you want to be mechanical engineering or a mechanic - skillet is very different.
This is utopian thinking that disregards how software ecosystems actually work in practice. Take the opening sentence:
> 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.
Developers don’t like closed ecosystems for obvious reasons. But companies like them because they’re very profitable, if they can get enough users trapped in them.
Having an open ecosystem can often mean you have no moat around your business.
Ecosystems interest me ("how do I get my product/feature adopted in a larger landscape?"). The following are some observations everyone could make, yet I see some companies (Microsoft in particular) struggling with it, so maybe it's not that obvious.
> The lack of interest in Unimodules taught me that it’s not enough to come up with an opt-in common standard.
It's a tough sell if it offers no immediate value to the developer. If there's no immediate value for the user or a big push, they aren't going to be asking for it either. This can turn into a vicious cycle Apple keeps avoiding and Microsoft keeps falling into.
> Given it’s far too late to convince each framework to redesign their native module interfaces from the ground up for compatibility, it may be worth exploring a top-down approach instead. That is, producing tools to translate modules from one ecosystem to another “whether they like it or not”.
That's the gold standard, IMO. Once you need people to do anything for your feature to work, your work becomes a lot harder. "If everyone would adopt it you'd see the benefit!" doesn't convince many users OR developers. By removing the requirement for developer opt-in, you're suddenly avoiding a huge part of the viscous cycle (no users because no devs, no devs because no users), which is a huge part of Apple's ARM success and probably a good part of Microsoft's ARM failure.
What upsets me is the waste of effort building the same things again and again. I would like to reuse solutions to problems I solved and use them going forward.
Imagine if we were all building upon the state of the art at all times and upgrades were free and things don't break between upgrades.
Good luck with that. Developers love creating frameworks and new ways of doing the same things. You might as well complain about how movies keep using the same plots.
Content streaming is one case where I wish,wish,wish they were non-closed ecosystems.
Make your offerings available via an API. Make the actual content stream with whatever DRM standards you (the "platform") need to feel comfortable.
Let me wrap all my streaming services with a single platform, having decent search and ability for me to do automatic price arbitrage. Why rent on Netflix when it's free this week on Hulu?
People invoke corps when discussing this problem, but fail to realize that publicly traded stocks only care about monetary value; that's why they're there. Any notion of bettering humanity or doing something sensible in terms of software is purely secondary. They're a business.
Is it any surprise that tech is the way it is with this in mind? Is it frustrating? Absolutely. Is it as expected? Yup.
Huh? Apple and Android (google) are for profit companies and are literally competing against each other. One of the iPhone’s biggest selling points is iOS. Why does the author think Apple would want to share a single, unified interface with its competitor?
It sounds ideal in a developer POV, but this is not open source territory.
A lot of these responses make me wonder how closely the original article was read because his critique goes beyond that and he’s also upset about, like, code that only works with React.
This short essay is a lament about how close we are to creating really good cross-platform solutions, but how we always fall short because of closing off our ecosystems to each other. I hope to spark a bit of conversation with this about how we can do better moving forwards!
I see and understand the premiss. I disagree becuase the internet exists and any group can define or adopt a specification for inter-operation. The web is also part of the internet and has plenty of opportunity for development outside the norms. Let us move the conversation with out strawman arguments about what is holding us back. Let us move the conversation forward by demonstrating all the great things we can do right now. Almost any argument regarding constraints is more likely to boil down to some value dreamed up by a VC. Which is not a technical problem caused by proprietary tech.
Almost every single programming language ever invented has to reinvent more or less the same ecosystem of libraries from scratch. What is the best estimate of how many hours of work that is per language?
Author here. Very confusing licence, is my main complaint (I speak also as the author of Svelte NodeGUI, which is built on top of Qt). The fact that there are hour-long seminars explaining the licencing (https://www.youtube.com/watch?v=m7etOQfrMiM) show that it's a real issue. I recall Qt for mobile has an even muddier story, with a different licencing/pricing model again.
Besides that, I also personally find it horrible to program with, because different elements have differents way of managing their child nodes (unlike HTML Elements, which have one consistent API). And of course I'm a JS dev, though NodeGUI does solve that. But maybe these aren't valid gripes.
The long-term solution seems to be to ditch iOS and Android on mobile devices entirely and replace them with fully featured operating systems based on Linux, e.g.
I like the idea of Ubuntu Touch (having worked with Ubuntu a lot), but even more so Firefox OS. As a web developer, the idea that "native" could simply mean "the Web platform" is really attractive.
Who says every app has to run in a separate browser instance like with Electron? It could be as efficient as a browser tab, which would be perfectly fine as long as the UI is built in a reasonable way. On Android it's been possible for a while to install webapps via the browser that are then displayed like normal apps on the homescreen, and that is nothing more than running a website in the single browser app instance running on the device.
I have an Android and have done as you described but they're simply not as smooth as native apps, not even considering the lack of good native API integration.
Attractive-for-the-developer ideas are fine but attractive-for-the-user dominates. That's the sad lesson since the 80s and 90s OS wars and the early dominance of the market over the committee-standards that happened repeatedly with databases, with web browsers, with text editors, with spreadsheets, etc etc.
Personally I see the ossified bifurcation between users and developers as a major defeat that perhaps I won't live to see reversed.
It was not set in stone that people would be by design dumbed down progressively as computing caught on, rather than assimilated into the computing world as 1st class citizens.
In a parallel universe something like the Smalltalk, LISP or Forth machines were widely adopted and the dichotomy between user and developer was blurred to mean an incidental situation related to a specific set of code.
It's hard to even convey in words how damaging it is, and can still be much worse, that the user was corralled first as a consumer and then as the product. Wholesale across all the industry. And the sad thing is that it wasn't like this, at all, as late as the 1980s.
Yes and I’m sure that car mechanics are also tsk tsking about everyone that drives a car doesn’t know how to fix one. I’m sure they also thing that cars have been “dumbed down”.
I’ve been programming for a long time (since doing assembly in the 80s). My second job out of college was for a small company where I was a developer and also had to manage a SAN, a dozen computers that ran jobs, mail servers, ftp servers, MySQL and SQL Servers, messaging servers (MQSeries, MSMQ) etc.
Now I can just write some yaml or HCL and spin up an entire “server room”. I don’t wax poetically to juniors who never have to go through that and I even encourage them to use an even higher level of abstraction - the CDK that allows you to use code to create the yaml.
Ob Disclaimers: yes I work at AWS now (ProServe).
2nd disclaimer: while the CDK creates CloudFormation, Hashicorp ported it to work with Terraform and is cross platform.
I don't think the car mechanics analogy goes very far(tehe) but it could be done with some consumer electronics, as long as the integration and coupling of software and hardware has worked much more against the people than it has benefited them.
Granted, it's not for everything. But by losing computing we lost a lot more, too.
That isn't realistic. We already gave pure 'Linux-based' mobile devices and desktops a chance years ago and unfortunately, they haven't taken off commercially.
The only one that came out with a inkling of 'Linux' is ChromeOS and Android which both are not even fully open-source and will eventually be moving to Fuchsia-based OS and will ditch the Linux kernel.
Alas, web development "decided" to completely reinvent the wheel for all this stuff, leading to a new generation of heading-to-native toolkits derived from browser-based technologies, such as Electron, React Native and Flutter.
Unless you believe there is any mechanism to force a single cross-platform GUI toolkit on all developers - a belief that would make you basically insane - the reality is there will always be N different options for cross-platform development, depending on (a) which platforms you intend to cover (b) your own development history (c) subjective preferences (d) specific functionality that may be limited to specific toolkits.
Does it matter if N is 10 instead of (say) 5 ? I don't know.
Does it matter if the N is segmented into "derived from 90s widget models" versus "derived from 2010's web models" ? I don't know.
Is there any chance of a single toolkit that covers native desktop environments (which continue to be important for creative apps, high performance apps, browsers etc.), native mobile and browser based apps? I don't know, but it seems ... unlikely.