Hacker News Reader

Comment by foxhill | Hacker News Reader

that's a real shame. i understand that even with modern cross-platform UI toolkits, like qt and wx, multi-platform development is more labor intensive than an electron app.

sublime text has been managing it for a long time though, and is one of the reasons i don't see it ever going away as _the_ text editor.

View on HN

> i understand that even with modern cross-platform UI toolkits, like qt and wx, multi-platform development is more labor intensive than an electron app.

I don’t think this is a given, it only really becomes true if you have a need to control the UI down to the pixel, and if we’re being honest, very few developers actually need that. Your life as a cross platform dev becomes a lot easier when you accept that the UI will have minor platform-influenced deviations that ultimately have zero negative impact on usability.

That’s one of the reasons Sublime is been able to keep their boat floating — it doesn’t look and feel 100% the same between platforms and even adopts various platform-isms, like the text navigation key shortcuts under macOS.

The only reason “native-ish” cross platform UI frameworks are challenging to use is brand-driven UI design. Do as Google is suggesting they’re going to do and let brand take a back seat and things become a lot more simple.

Sublime doesn't use native platform UI toolkits. They ship their own version of Skia (same as what's used in Chromium) and have their own UI toolkit for the editor rendering.

The point remains that its UI isn’t the same across platforms, like for example it uses whatever the local system font is instead of whatever the designer decides.

The point is that they're using an off-the-shelf icon kit with some native dialogue forwarding. By this definition, VS Code is also a 'native' app, which we know to be untrue.

Frankly, I think the MacOS HID has been dead since Mojave. At some point, developers realized that Cocoa wasn't enough for most apps, and it was an awful lot of work to put into an app that would only be used by a fraction of their customers. Currently, the definition of "native" on MacOS is that it uses loosely the same keyboard shortcuts as your other programs, and if you're lucky then it integrates with your global menu. In the age of webapps and cross-platform development, there's simply not a way that MacOS' approach works. Even niche toolkits like GTK solved this problem better than Apple, which makes it even more mind-blowing when I see Mac developers defend their build system.

Walled-gardens lead to sticky situations like this, where volunteer-driven efforts are more developer friendly than first-party offerings. I weep for the Xcode users who don't know what it's like living on the outside.

I respectfully disagree that GTK is more friendly than AppKit. It may be truly strictly from a cross platform perspective, but AppKit is still unbeaten in variety and capability of UI widgets, especially if front end web is the point of comparison. Just to get an interactive table view that’s comparable in features to NSTableView on the web you’re looking at duct taping together several libraries or reinventing the wheel yet again and writing the whole widget yourself. GTK and Qt better than the web in this aspect but still not as good (custom widgets are still frequently necessary with both toolkits).

AppKit only comes up short in that it’s not built to have its appearance changed dramatically and of course that it’s tied to macOS. If you need cross platform that’s a legitimate limitation, but as noted before brand driven UI design is far from a need.

Reply on news.ycombinator.com