Hacker News Reader

Comment by flukus | Hacker News Reader

> If you’re making a native app, your tech stack choices are pretty limited. On the macOS side, you’ll use Xcode, Swift, and AppKit. On Windows, you’ll use Visual Studio, C#, and WPF or UWP.

I'm not sure they know what native means because c# is not native code and WPF is not a native UI.

> To maintain parity across the codebases, we had to implement and design the same features twice. If we ever wanted to add Linux support, we’d have to do it all a third time. All this meant we had twice the work, twice the bugs, and far less time to build new features.

Nothing forced them not to share logic from the start, they could have done that and still had a native UI on each platform. It only doubles the work if 100% of the work is in the UI.

View on HN

> c# is not native code and WPF is not a native UI

"Native" confusingly has two different commonly used meanings. The one you seem to think is the only meaning distinguishes VM from non-VM runtime code (where C# is non-native). This meaning is the N in Android NDK.

The other common usage is "the preferred local platform specific language and dev stack", eg "A native Android app" which usually means "written in Java compiled to dalvik/art" distinguishing from a webapp or an app that is just a packaged webview.

I always interpret "native" to mean "without the use of an intermediary virtual machine." I assume my definition is overly simplistic, but am I incorrect?

Android is a bit weird because the platform is the VM that you're targeting. The same goes for Chromebooks, html and JavaScript are native there.

The terminology for "native" used in the blog post is inexact (actually, incorrect), but consistent with how the casual usage of the term has drifted due to the competition from the 'web technologies' stack. In this usage, "native" means non-webview; and/or non-HTML5/JS/CSS-bundled-with-the-entire-browser-runtime.

Often it's also a byword for the platform-preferred first-party stack, making the argument somewhat tautological: of course there's a limited selection of first-party preferred stacks on every platform.

I'm guessing this usage is a contraction of the term "platform-native".

> In this usage, "native" means non-webview

I wonder what the authours would think of C++, Qt and webviews?

C# compiles to native code since Windows 8, when targeting store applications.

Yeah, I'm genuinely surprised that "four native developers" didn't realize that there is one native language which works great on all three platforms, and has direct bindings to all of the platform UI toolkits...

There isn't one that I know of. A language like c++ though would compile to a native library on each platform and allow them to share logic between 3 front ends in the same or a very similar language.

That's mostly what I meant. I don't particularly think it's a good idea to share UI code between platforms as different as macOS and Windows. I'm sure there will be serious integration regressions with the new version.

You mean several native languages with multiple multi-platform ways to create native UI.

The only env. i know is Lazarus-ide and Freepascal

> c# is not native code

Correct. C# does not ahead-of-time compile to hardware machine code (e.g. x86).

> WPF is not a native UI

How do you classify "native" vs "non-native" UI?

A native UI is one that uses that platforms (or desktop environment) native toolkit, that's win32 on windows, qt on KDE, gtk on gnome and cocoa (or whatever it is today) on Mac.

WPF is it's own toolkit built in directx, it's as native as swing. WPF sits at the same abstraction level as most games, would you consider the main menu in GTA to be a native one?

would you consider the main menu in GTA to be a native one?

Does a WPF menu (and WPF-based apps in general) integrate with the systemwide conventions and settings for things like keyboard shortcuts, default font, etc? Is it a first-class UI toolkit for the system? My impression was it is supposed to be, in a way GTA's UI (or Swing) is not.

> Does a WPF menu (and WPF-based apps in general) integrate with the systemwide conventions and settings for things like keyboard shortcuts, default font, etc?

About as well as swing ever did, no where near as good as Qt does, I think we'd all agree qt is not the native UI of windows.

Then again, it is hard to judge. Not a lot of win32 apps seem to follow system wide settings either, even the MS ones.

About as well as swing ever did

Really? It's just not the impression I get, granted it's been a while since I've used Windows for anything other than to, well, play a bit of GTA. I remember paint.net being a thing (seems it's still around) and it looked and behaved like a Windows app. Qt apps look instantly recognizable and fugly to me on any platform. It's hard to believe that WPF apps had or still have, say, the font-rendering problems Swing apps had or were missing access to affordances like control over the tray icon, etc.

The reason I'm skeptical is that WPF was very much intended to be a first-class Windows-specific ui toolkit. You're telling me it's worse than cross-platform toolkits with all of their necessary design and implementation compromises.

Edit: Oh! I figured out where I was confused. WPF and Winforms. Not the same thing.

Win32 is essentially deprecated and the native toolkit from Windows 8 on is the WinRT components/engines in "Windows.UI.*" which natively speak XAML (and natively here means these are C++ components baked into the OS). WPF has much more in common with the modern Windows.UI toolkit than Win32 does.

DirectX is at the same level of abstraction as Win32's Graphic Device Interface (GDI) and Hardware Abstraction Layer (HAL) that the rest of Win32's "native toolkit" was built on top of; Windows.UI is just as "native" as Win32 ever was. It should not be a surprise that the hardware abstraction toolkit beat into performance submission by performance demanding games is the new native layer for Windows. The surprise should be how long it has taken to make the transition across. (Avalon promised it back in Vista and WPF was the closest to delivering it. Windows 8 finally delivered on the Avalon promise.)

The problem is they didn't provide backward compatibility for Windows.UI. Until windows 7 is dead win32 is the only native option.

I think to some extent they felt WPF was a strong enough backward compatibility story. Windows 7 supports WPF well. There is a cross-over between WPF XAML and UWP XAML and it is possible to support both with a lot of code shared and even some XAML shared.

Of course, there have been bumps in the road in the compatibility story between the two XAML environments. .NET Standard 2.0 will help a ton (in the very near future), deeply increasing the amount of .NET code that can be shared between the environments. XAML Standard 1.0 (in the slightly further future) will help a lot, in particular the fact that Xamarin.Forms is planning to implement a WPF renderer for sharing a much larger portion of XAML across every platform.

On another note, the classic opening Window of Unity games (when you select resolution and quality) looks remarkably native!

Examples: My Summer Car, Sol 0, Software Inc.

> How do you classify "native" vs "non-native" UI?

Not OP, but presumably WPF can be considered non-native because it relies upon the .Net stack.

Not just .net (I think it's all c underneath), I'd consider winforms with c# to be a native UI (but not native code) because it's just a .net wrapper around win32.

Is UWP UI "native"?

Yes, although the windows desktop situation is such a clusterfuck that I could make a case that it's not ;) It all depends on if you consider the full desktop or the metro interface to be the native one.

Sure it does.

Ever heard of NGEN, Mono-aot, .NET MDIL, .NET Native?

To what degree are they native? I wouldn't consider something native just because it bundles the VM into the exe.

To the same degree as C is native, there isn't any VM doing JIT compilation.

All straight sugar free Assembly instructions.

Now if you mixing the notions of VM and runtime, even C has a runtime called crt0 on most UNIX systems.

> Now if you mixing the notions of VM and runtime, even C has a runtime called crt0 on most UNIX systems.

I was mixing them up. The line seems be kind of blurry though once you start embedding garbage collectors though, then again the GC could just as easily be in an external library.

Reply on news.ycombinator.com