Hacker News Reader

Comment by gitgud | Hacker News Reader

This has been discussed many times here... of course running a Chrome instance is inefficient but in some cases that's acceptable. Especially for the gains in cross-platform compatibility and reliable user interfaces.

Almost no other platform can guarantee that a UI elements will look pretty much exactly the same on all different operating systems.

Most people don't mind the extra RAM consumption for some applications... as long as the app works!

View on HN

Who cares if an application's UI elements look the same across platforms? I want it to work on the platform I am using. I simply do not care what it looks like on someone else's platform, and I especially do not want to pay a performance penalty so some designer can have a virtual feather in their cap over it.

I prefer native widgets to whatever application-enforced fad of the year is current.

Apps are lauded for providing "dark mode" now; when ten years ago I simply switched GTK themes.

To say nothing of accessibility.

We've gone way backwards in UX.

Absolutely. Developers can pick from many native-widget frameworks in pretty much any language, heck I bet there are even Qt bindings for node. But there are just so many people doing web development, it's probably a hiring/design issue in that hiring web developers and designers is just so much easier than hiring whatever people know the GUI framework that's driving much of the code.

There's also the fact that the UI tools for web development are mostly way easier to use than Gtk or Qt.

Even "simple" stuff like Tcl/Tk is not trivial to get working easily or well.

HTML + CSS + something like React is miles simpler than writing something for Gtk. Qt has QML now but the C++ Qt bindings are _pretty hard_! And after all that work you don't (by default) get an app that resizes as nicely as the HTML/CSS box model does!

I think that WxWidgets has one of the better usability stories for cross-platform native, though.

If someone wrote a good feeling UI library that generated native UIs and had good JS and Python bindings, so many people would be happy to use it, I think. But right now, despite all the shortcomings, web tech is pretty easy to prototype in.

This is an important point. Being easier to create means faster to market, faster to create new features, easier cross platform, more value for users in less time. Not all apps can be web based but for those that can be, faster dev time has become a competitive requirement.

To be fair, dark GTK themes don't really work. I say this as someone who uses dark GTK themes. Far too many applications end up with dark text on a dark background, and Firefox applies your theme colors to websites so websites also end up with dark text on dark backgrounds. At least a dark mode created by the application's authors usually works.

Firefox is a special case of stupid as far as themeing. Fortunately it's possible to both make Firefox's ui dark with css and make Firefox use a light gtk theme for websites with an env variable which is the logical choice.

This has been a problem since forever. Even on Windows 95 it was like that. Probably before that. Windows does have special values for system colors, like text, window background, text background etc. But for some reason, a lot of programs ended up setting the text color explicitly to black and leaving everything else at the system colors. So you better left the color scheme at default. Which is probably fine for the average user, but there were these high contrast schemes which were white on black. People who actually had to rely on this must have had a bad time. Just how these schemes also increased the font size. Doing that, or increasing the system's dpi setting guaranteed that all text in every application would be truncated.

have you tried using OneNote in dark mode, it actually feels dark, like you can't see anything

The problem comes when you design a UI and then someone else goes to use it and the font in the selects is a different size and ends up cut off. Also windows users regularly complain at me that the ui looks ugly but its just the windows default ui elements they find ugly

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

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.

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.

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.

This sounds like Java Swing.

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.

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

> "Who cares if an application's UI elements look the same across platforms?"

Designers.

End users simply want a functional, working product. Polish on top is a nice added bonus, but these days it's been turned into the focal point of software development. A Teams/Slack-caliber project begins with product requirements, immediately followed by design and UI mocks - the software/tech always comes last.

Designers are given too much leeway. They care about a consistent UI across platforms; fantastic -- no one else really does.

A computer program is a tool to convert data from one form to another. FULL STOP. Unnecessary added complexity, on top of that data transformation, is wasted effort, wasted time, wasted energy.

Software development has caused so many problems for itself because of things like this. People forget so quickly that programming is not the job! Solving the data transformation problem is the job. Effort spent that does not solve the problem is wasted effort, and we've made a fucking industry that churns out far more waste than product.

The problem with regard to RAM consumption is the tragedy of the commons. One electron app is okay, but once you're running up to ten or more of them, the resource usage gets out of hand.

I remember back in the early 2000's when everybody was complaining about Java. That it was “slow”, and “used a lot of memory”, and that its UI “is not native”.

Now it's all JS and Electron and every single complaint people used against Java is an order of magnitude worse and everybody seems to be happy about it.

Progress have definitely been going backwards.

Reply on news.ycombinator.com