Live data from Hacker News

Stop Building Closed Ecosystems

buttondown.email

91–100 of 174 posts

Re: Stop Building Closed Ecosystems

#91
post #70

Earlier quoted context omitted.

> 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 (o…

> 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.

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

Re: Stop Building Closed Ecosystems

#92

Earlier quoted context omitted.

I don't even know that this question means. Is Photoshop a cross-platform application? Protools? Chrome?

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”. And do you really want to bring up the battery killing Chrome as a great cross platform app? Safari is much more efficient and ironically from reports, so is Microsoft’s Chromium based browser.

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.

Re: Stop Building Closed Ecosystems

#93

Earlier quoted context omitted.

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 t…

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?

Re: Stop Building Closed Ecosystems

#94

Earlier quoted context omitted.

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 t…

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…

> 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.

Re: Stop Building Closed Ecosystems

#95

Earlier quoted context omitted.

> 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…

> 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 to…

> 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.

Re: Stop Building Closed Ecosystems

#96

Earlier quoted context omitted.

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”. And do you really want to bring up the battery killing Chrome as a great cross platform app? Safari is much more efficient and ironically from reports, so is Microsoft’s Chromium based browser.

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.

Re: Stop Building Closed Ecosystems

#97
post #47

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 the…

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…

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.

Re: Stop Building Closed Ecosystems

#98
post #70

Earlier quoted context omitted.

> 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 (o…

> 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.

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.

Re: Stop Building Closed Ecosystems

#99
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?

Re: Stop Building Closed Ecosystems

#100
post #70

Earlier quoted context omitted.

> 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.

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 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.

Post reply on HN