Hacker News Reader

Comment by hamstergene | Hacker News Reader

I have never seen cross-platform UI that would work and/or look close enough to native. It has always been classic "choose any two": cross-platform, UI, great.

There were many people who claimed they have achieved all three, but at the close examination all of them, 100% without exception, were missing many little things like standard shortcuts, respecting color preference in user settings, or just couldn't see the difference between 11pt and 13pt fonts while looking directly at them.

10 years ago I worked on rewriting Qt interface of a desktop app back to native for a similar reason, and now I am reading all the same story except it's about React Native in mobile apps.

View on HN

> I have never seen cross-platform UI that would work and/or look close enough to native.

But wouldn't knowing that require that you investigated the tech choices of all the apps you are using? If not, there's a slight fallacy in that you only _know_ that the app is cross platform when you can see that it is. So then obviously all the apps you know is cross platform will look out of place, because that's how you know they are cross platform. Not sure I'm making the argument very well.

For instance, I'm don't think that the Discord app for iOS and Android looks out of place [0].

> Switching to React Native for the Android app means an experience that is ever-improving at a more rapid pace across every platform Discord is available on, while still retaining Android and iOS specific patterns in the UI.

[0]: https://discord.com/blog/android-react-native-framework-upda...

The discord user complaints rose exponentially after the switch to RN, and almost all users felt a perceivable difference in the quality of the new apps.

Hehe, I guess I was too late to party to experience the good ol' days.

It has a good rating in app store today. Better than Slack, even. And although there are probably many reasons for that, atleast RN hasn't killed the ratings.

this is quite normal when you do a full codebase refactor, even if you didn't switch technologies it is like comparing a 5 year old codebase with 1000s of man-months ironing bugs out with a 1 year old codebase with 500 man-months of work

Seems like the bigger problem is their QA department than their engineering decisions

> But wouldn't knowing that require that you investigated the tech choices of all the apps you are using?

I did investigate every app I ran, because I was programming UIs and was interested in all tech that was there. To the point of being able to tell whether the app was written with Delphi or Qt or MFC/ATL by just playing with it.

Qt apps on Mac always stand out, being "OK" is the top they achieve.

Windows is less offended because it has never had a stable style, but still, there are always tiny details like context menus or not responding to Ctrl+Arrows that give non-native away.

I shipped consumer software with Qt in the 2000's. It was nicer to work in than MFC. It looked and worked great on Windows 98/2000/XP. Qt's Windows XP renderer called Windows' own uxtheme.dll to draw everything.

Mac OS X looked a little off, especially the spacing.

Is the point of React Native to use native GUI elements and not to emulate the platform look and feel?

A few years ago I worked on Java application using SWT. It looked very OK on Linux/Mac/Windows. Even original AWT in Java was cross-platform an native. The problem with Java was GC pauses, but this is a solved problem now.

20 years ago I worked on some Java applications as a college student curious to compare AWT/Swing to other options, and I found that the cross-platform rendering worked decently well, but that the underlying architecture and algorithms were hot garbage. For instance, if you had a full-screen panel nested in a full screen panel, and you put the CPU under heavy load, you could watch it fill both background colors despite the front panel completely obscuring the back panel. Using Windows native API "windows" the paint events would only happen for the un-obscured components and only for the regions exposed. Java advocates advertised how "lightweight" their components were because they "didn't depend on a heavy-weight operating system window object" when in fact those "heavyweight" window objects were part of an algorithm that performed much better. Another big annoyance was that every UI event was delivered in its own thread, so you had to deal with all the complexities of multithreading just trying to write simple user interfaces. I had a whole blog-sized article I wrote once about all the design deficiencies; I've forgotten most of the rest of those details.

Java actually succeeded quite well at being cross-platform, it just wasn't a design worth being cross-platform in the first place.

Hopefully they fixed some of this in 20 years.

React Native literally uses native widgets.

The JavaScript bridge is still quite slow, though.

Reply on news.ycombinator.com