Hacker News new | ask | show | jobs
by gitgud 2504 days ago
My opinion is that the OS should not be responsible for providing native elements to the application. If this is true then the application is tightly coupled to the OS implementing these components.

In a perfect world, every application would have minimal dependencies required by the OS, and completely encapsulate their runtime and UI components, making them very portable... which is basically web apps, hence Electron's popularity...

4 comments

I like the application to be tightly coupled to the OS, because then my applications have a consistent UI. All of my GTK apps look great, because I can change the theme for all of them with a single command. With one script, I can switch my entire system from dark mode to light mode, and have all applications have the exact same color scheme - can't do that if every application has their own implementation of the UI components.

And different systems have different UI requirements, so I don't think it makes sense in many cases to have the same UI between them. iOS and Android, for example, have very different standards surrounding what buttons mean, and how the navigation should work. The back button on Android, for example, completely removes the need to a back button in the application, while in iOS it is still required. And of course if you are making an application that runs on both touch screen devices, and devices with keyboards, the UI should definitely not be the same.

And then we end up in GTK hell: https://stopthemingmy.app/

At least the web platform is open enough to do this and still function.

>The problem we’re facing is the expectation that apps can be arbitrarily restyled without manual work, which is and has always been an illusion.

Except for working pretty well on most apps

>However, if you change things like stylesheets and icons, you should be aware that you’re in unsupported territory. Any issues you encounter should be reported to the theme developer, not the app developer.

Themes are rarely problematic and it would take 10 seconds to check if one supposed it to be problematic.

They could perhaps work on solving actual problems.

That's really not a hard problem to solve though, as an application developer you can just have a default theme for your app, and have some checkbox somewhere letting the user use their OS theme instead of the app default.

Or you can just accept that whenever you let someone configure the UI in an advanced way, it is possible for them to make the UI more confusing. Just because it is possible for someone to mess up your app with a bad config, doesn't mean it is best to remove any kind of configuration at all.

Yes, there are benefits to having the OS supply the components; switching themes, familiar design and probably performance gains.

But, the trade off is simply unpredictability. The app is assuming that the OS has all the components it needs, at the correct version etc. Not all OS's have all components you think, which leads to unreliable user interfaces, which may work for small applications with only a few OS dependencies, but as the app grows the reliability decreases...

You're correct in saying the UI should not be the same on every platform (iOS, Android, Windows). But in my opinion the app should encapsulate it's UI and share as little as possible with the host OS.

All major OSes have better, faster, more flexible UI components. These were invented for native apps.

If a component is not available, it means it's not appropriate for that platform or not part of the UX guidelines.

That's why you build on top of a layer which ensures the OS has the required components. If you build on top of GTK, you know your application will run on any OS with that GTK version installed. Or if you build on top of Android, you know they will make sure that the button component still works on different versions of the OS.
That's the point of the OS, offering a standard runtime environment.

Your "perfect" world isn't. It leads to a fragmented landscape of competing runtimes and UIs, is inefficient and results in extra implementation effort.

The JS community can't even be trusted to be stewards of a left pad library, never mind UI environments.

This sounds like Java Swing.
Coupling is not bad in itself. Depends on what you want to achieve. There's likely always a trade-off.