Live data from Hacker News

Stop Building Closed Ecosystems

buttondown.email

81–90 of 174 posts

Re: Stop Building Closed Ecosystems

#81

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…

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?

Re: Stop Building Closed Ecosystems

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

I don't even know what the argument is either.

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.

The rest of the post just devolves from there.

Re: Stop Building Closed Ecosystems

#83
post #78

Earlier quoted context omitted.

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

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.

How so, I think the modern iPhone works a lot better for most people than my old Apple //e or the first PCs I used ever did.

Re: Stop Building Closed Ecosystems

#84

Earlier quoted context omitted.

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.

Re: Stop Building Closed Ecosystems

#85

Earlier quoted context omitted.

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: 1. menus 2. file browsers 3. text entry 4. notification/tray integration 5. window management These are where "the native experience" (i.e behaving according to guidelines or rules laid down by the platfo…

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.

Re: Stop Building Closed Ecosystems

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

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

Re: Stop Building Closed Ecosystems

#87

Earlier quoted context omitted.

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: 1. menus 2. file browsers 3. text entry 4. notification/tray integration 5. window management These are where "the native experience" (i.e behaving according to guidelines or rules laid down by the platfo…

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.

Re: Stop Building Closed Ecosystems

#88

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…

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

Re: Stop Building Closed Ecosystems

#89

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.

There are only two plots:

(1) a developer creates a framework

(2) web is more convenient than apps

Re: Stop Building Closed Ecosystems

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

It could be so much better, but it's not.

Post reply on HN