Going Native (Premium)

A recent Microsoft developer blog post makes an interesting assertion about native code that conjures a decades-old argument. What is native code, exactly, and why does anyone feel strongly about this topic, regardless of which side they support?

"React Native for Windows is a great option that allows developers to use JS/React skills and tools to develop native cross-platform applications that target desktop, mobile, web, and more," Microsoft software engineer Chiara Mooney writes. "React Native uses WinUI under the covers to support many native Windows controls."

There's a lot of "native" in there, and that's confusing. Is it even possible to build "native cross-platform applications" across different platforms, some desktop-based, some mobile, and some web? And what, exactly, is a "native Windows control?"

Sticking mostly to Windows here, most have a vague (mis)understanding that the Win32 API, sometimes just called the Windows API, is the "native" programming environment for Windows apps. And that there are other frameworks and environments--Visual Basic or MFC from 35 years ago, perhaps, or the Windows App SDK today--that "sit" on top of Win32, providing a layer of abstraction to the native APIs with the aim of simplifying or otherwise improving the app development process. This "thing on a thing" approach will remind old-timers like myself of the relationship between Windows and MS-DOS in the pre-NT years. But it also conjures up the notion of trade-offs, where a developer loses some control or performance in return for whatever improvements they get for not going native.

But Win32 is not native code. If you want to be pedantic here--and developers always want to be pedantic, so we must allow for this--Win32 is/was written to abstract even lower-level system code, which is itself an abstraction of the processor architecture-specific code below that.

In fact, it should be obvious to any developer that Win32 essentially being a C++ API today means that it's not native. C++ is an object-oriented programming (OOP) abstraction built on top of the C language, which was itself built on top of assembly language. Which is built on top of machine code. Which is processor architecture specific. Which explains why these higher level abstractions exist in the first place: With a language like C, for example, the same code can run on different processor architectures. We've been abstracting computer hardware since there have been computers. In many ways, native code is a myth. No human beings write native code today, regardless of the platform.

Pedantry aside, perhaps the best way to describe Win32 today is that it is the lowest-level code that any developer, save those that create device drivers, would ever work in today. But no developer would create a meaningful Windows app using C++ and Win32 now. Instead, they would choose between the available frameworks and APIs, typically delivered--as is Win32--via a Software Development...