Live data from Hacker News

Stop Building Closed Ecosystems

buttondown.email

121–130 of 174 posts

Re: Stop Building Closed Ecosystems

#121
post #100

Earlier quoted context omitted.

My definition works like this: is there an API layer on which (a) everything else is based and (b) people sometimes use directly for app development? macOS: Cocoa/Quartz - yes and yes windows: win32 - yes and yes linux: X Window - yes, no (though of course Wayland is changing the "yes" a bit) GTK, Qt, WxWidgets, FLTK etc - no, yes

But that's my point, WPF (the Vista-7 era primary toolkit), is not based on Win32. Neither is WinUI (the 8-11 era primary toolkit) calling Win32 or WPF. Win32 is mostly used for legacy apps, you'll find some random usages still like pre-Win11 notepad or the services configuration menu. WPF is the primary UI framework of Windows Vista/7 and still the framework which the majority of the OS is in for Windows 8/8.1. It d…

Thank you for a brief update on the situation on Windows. I didn't know all that, and now I know a bit of it.

Re: Stop Building Closed Ecosystems

#122

Earlier quoted context omitted.

> But how much of the GUI is actually cross platform I find the idea that when Photoshop or Protools wants to open a dialog with a button, the developer creates two functions, one for Windows and one for macOS, completely unbelievable. There is almost without doubt some level of in-house cross-platform toolkit in place. It may not go as far as, say, Qt tries to, and it may differ in design philosophy from other simil…

That’s kind of backwards isn’t it? If I am writing a banking app for both the web and mobile. My GUI development is going to be different. But I’m calling the same set of APIs. The backend isn’t “opening a dialog box” to the front end. The developers would be designing a native dialog and calling backend shared codex

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 that they do not. Adobe has wrapped "dialog creation" (along with hundreds of other GUI abstractions) in their own cross-platform layer, and their GUI code calls that. This is the same thing done by pretty much any company developing for more than one platform.

The approaches can differ a lot. For example, consider Reaper (another DAW). Its lead developer picked a tiny subset of the win32 API that he wanted to be able to use, and implemented that for macOS and Linux/X Window. Then he uses the (partial) win32 API for the entire GUI (with higher level stuff built on top of it).

Re: Stop Building Closed Ecosystems

#123

Earlier quoted context omitted.

I wasn't trying to name "great" cross-platform apps. The question was "what is a cross platform app". Is Chrome or Firefox a cross-platform app or not, regardless of how they shitty they may or may not be? > Photoshop has a shit ton of Cocoa and before that Carbon on the Mac. While the processing engine may be cross platform. The UI is mostly “native”. Every GUI application that runs on macOS has a "shit ton of Cocoa…

The discussion is about cross platform “frameworks” versus writing apps using the native frameworks. Adobe and Microsoft basically use native frameworks for most of their apps. It’s the difference between most of Office and Teams and VSCode.

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.

Re: Stop Building Closed Ecosystems

#124

Earlier quoted context omitted.

How did things end up this way? I'm massively frustrated by the stupidity of our security team and it gets worse each year. And I've tried to explain this stuff about web apps exactly like you just did but it never quite gets through, and when it does it gets a response like "well, we should probably find a way to restrict web apps as well". I know for a fact that none of the people doing systems administration that…

Security teams don't bear the costs of reduced productivity from saying no, but bear all the blame if they make a wrong decision to approve something. So they're heavily incentivized to say no. Like many principal-agent problems, it requires someone appropriately situated to weigh the costs and benefits. If that doesn't happen, it gets borne by someone, usually shareholders who pay in reduced profits and eventually c…

This was very insightful, I hadn't thought of it this way before. Thank you for your comment.

Re: Stop Building Closed Ecosystems

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

Re: Stop Building Closed Ecosystems

#126
post #36
post #4

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

> I hand-write HTML and CSS to this day! Yeah but... for your job? I'm sure we all do those side projects, but hard to imagine being able to do that on a complex multiple-member team project

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.

Re: Stop Building Closed Ecosystems

#127

Earlier quoted context omitted.

I want native apps on my platform of choice that leverage the native capabilities of that platform. That’s the entire reason I chose one platform over the other. Mac users complained about Word 6 forever ago when MS tried to use a cross platform toolkit and Apple’s Windows app were just as bad.

So you don't actually want cross-platform apps at all, but either single-platform apps, or apps developed independently for both platforms (because otherwise you're just talking about some in-house cross-platform toolkit).

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.

Re: Stop Building Closed Ecosystems

#128
post #6

This is my main fear with Flutter CanvasKit & "Towards a Modern Web Stack". https://hn.algolia.com/?query=%22Towards%20a%20modern%20web%... They are using canvas & webgpu, & making their own rendering engine (borrowing Skia) to take web apps from part of a participatory open ecosystem where extensions & user-agency work, & turning the page into a giant animated screen. The best open ecosystem we have on the planet is…

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.

Re: Stop Building Closed Ecosystems

#129
post #55

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

It's a selfish take.

Re: Stop Building Closed Ecosystems

#130
post #40

Earlier quoted context omitted.

It's going to run fine everywhere. It's going to work. As a native app strategy I think it's fine. It's immaterial, if it works. But on the web, it is damage. It breaks all user agency, wrecks all extensions, breaks accessibility extensions, prevents scraping. It's a closed world, and the web doesn't deserve this native app mistreatment.

> But on the web, it is damage. I couldn't agree more. > As a native app strategy I think it's fine. It's fine in the sense that it doesn't damage open ecosystems in the same way that circumventing the web experience does. It matters if you care about the customer experience. Companies like McDonald's would likely see a significant bump in use and user satisfaction if they replaced their Flutter app with native apps.

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

Post reply on HN