Live data from Hacker News

Stop Building Closed Ecosystems

buttondown.email

141–150 of 174 posts

Re: Stop Building Closed Ecosystems

#141

Earlier quoted context omitted.

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

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.

It doesn't even have a real package manager, which leads to things like this : https://news.ycombinator.com/item?id=35581375

Re: Stop Building Closed Ecosystems

#142
post #34

Earlier quoted context omitted.

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

WebGPU doesn't offer any facilities relevant to GUI development except a method of putting pixels on the screen. If you're suggesting WebGPU, you're really suggesting a drawing technology, not a GUI toolkit.

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

Re: Stop Building Closed Ecosystems

#143
post #112

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?

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), Wi…

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?

Re: Stop Building Closed Ecosystems

#144

Earlier quoted context omitted.

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 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. It doesn't even have a real package manager, which leads to things like this : https://news.ycombinator.com/item?id=35581375

Yes, because it’s impossible to download new versions are packages on the Mac…

Re: Stop Building Closed Ecosystems

#145

Earlier quoted context omitted.

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

I never said anything about the backend. 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…

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

Re: Stop Building Closed Ecosystems

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

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.

https://learn.microsoft.com/en-us/cpp/text/how-to-convert-be...

Re: Stop Building Closed Ecosystems

#147

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…

> or choose to use something like React Native 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.

Re: Stop Building Closed Ecosystems

#148

Earlier quoted context omitted.

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

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

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

Re: Stop Building Closed Ecosystems

#149
post #123

Earlier quoted context omitted.

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

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

I can only speak to the land of DAWs:

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.

Re: Stop Building Closed Ecosystems

#150

Earlier quoted context omitted.

> or choose to use something like React Native 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.

Then their website needs some serious revision.

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.

Post reply on HN