Native Code Is Bad For You

At the risk of creating yet-another harmful "Considered Harmful" blog post, it's recently become more and more apparent to me that writing native code, on any platform, is a bad idea in the long run.

That's quite the inflamatory assertion, and I'm sure that if you are currently writing native code (Obj-C, C#, Swift, Java, C++), you may not like me right now. That's legit, and I don't even want to take that away from you. It's not my goal to convince you to turn your back on the technology that pays your bills and that you probably love deeply, but consider giving me just a few minutes to explain why on earth I would say such a thing.

In this article, I’m going to propose that developing for specific platforms is a bad idea because time has taught us that these technology silos simply don’t scale in the long run. I think that today we have an option for developing across every platform – and that option is, wait for it, JavaScript.

But you already knew that.

Before you blow this off as another one of those articles, allow me to explain why I believe we should forsake our runtime roots for JavaScript virtual machines. First though, let me set the stage with a little background and history.

Platform Development vs Development For Platforms

Before I get started, let me clarify my statement: native code is bad in the long run iff you are not working on or building a platform. In other words, if you work on the UIKit team at Apple, this article is not for you. If you work on the kernel for Windows, this article is also not for you.

If you are a developer that is developing for a platform (which is most of us), listen up.

Platforms Have Ruined Everything

Contrary to the popular belief that OAuth has ruined everything, it's actually platforms that have ruined everything. Let's do a little time traveling.

time-travel

In the late 90's and early 2000's, there were basically only two platforms that mattered to the majority of developers: Windows and the Web. Most developers were tasked with doing both. But they didn't want to have to learn two platforms. This is how we ended up with solutions like ASP.NET WebForms and JSP/JSF. Developers writing native code had no interest in learning yet another platform language (ES3). Besides that, at that time JavaScript was really seen as only useful for disabling the back button. So we turned to our racks servers who out of necessity became the great "platform equalizers".

But these server-side web apps were passive to a fault. Servers are great at rendering static pages, but completely inept when it comes to rich client experiences (Meteor and Universal JavaScript not withstanding – that's a new thing).

In 2006, jQuery bounced onto the scene. JavaScript was, at the time, a language in need of validation, and jQuery did exactly that. Developers everywhere began to peek out from behind their servers and embarked on a treacherous journey in search of a better opportunities for client-side applications.

At this point, we were already seeing a fracture of skills based on platforms. For the first time, we had people identifying as "JavaScript Developers". We even began to see prominent developers announce their departure from native code in favor of JavaScript. Developers were forced to make a massive paradigm shift from their one native code base into a JavaScript one. It was a big change, and it was very painful for a lot of people. Don't miss that fact. The human condition is that change hurts. But the real pain, had only begun.

Thanks A Lot, Steve

In 2010 I was working at a startup that was building a web based music distribution platform. We had .WMA "Plays For Sure" music that you could buy and then side load to your Creative Nomad mp3 player. The iPod was already out, but we thought we had a good chance to take on iTunes since the mp3 market was stiff, and honestly, we had the relationships and thusly a more complete catalog.

plays-for-sure

Then one day, Steve Jobs walked on stage at WWDC and released the first iPhone. I remember watching that release and thinking, "It's all over." The iPhone wasn’t a phone nearly as much as it was a platform. I knew that everyone was going to get an iPhone, and that platform would dictate that their music store of choice would be iTunes.

That startup failed a mere 10 months later, and within 24 months, mobile devices were deeply embedded into culture. It was truly a revolution.

Bring Your Own Device

It wasn't 2 years before the landscape of Blackberry phones began to erode in traditional enterprises. It was incredible to watch. These companies were bastions of Windows, group policies, and antiquated browser versions that were guaranteed to work with their 10 year old JD Edwards systems – user experience be damned. Yet, here they were, allowing employees to bring their own devices to work and connect to email systems.

By this time, there was already a growing fragmentation in the mobile space. Not only did we get a smaller browser, which meant we had to re-think our websites yet again, but we also got new native platforms (Android) that came with native SDKs and corresponding languages. It was, in a phrase, an utter free-for-all.

And that pretty much brings us to today.

Where We Are Now

In 2016, most developers are still trying to grapple with desktop apps, web apps and if they are on top of their game, mobile web apps. Native mobile applications are like a unicorn that is mostly found only in San Francisco.

Hybrid (i.e. Cordova/Phonegap) applications are incredibly attractive since web developers can use their web knowledge and almost build a native mobile application. They key word there is "almost". Hybrid applications are good enough for a lot of scenarios, but are also inadequate for a sizable share of them. Hybrid application performance suffers as applications grow in size. Trust me, I know this all to well. We spent a lot of time trying to debunk the myths that HTML5 on mobile is too slow to be good. The honest truth is that “good enough ” just doesn’t cut it for most.

This is why many developers went back to native code in the face of mobile applications.

Back To Native Code

The very premise of this article is that native code is bad. It's bad, dear developer, because it doesn't scale across platforms. Java runs on the desktop and Android, but not iOS. C# doesn't run on iOS or Android.

"BUT WHAT ABOUT XAMARIN!?!"

Xamarin has done a great job of creating a runtime that can work on almost any platform, but there is one place where it still doesn't work, and that's the browser. Beyond that, Xamarin does a great job of normalizing the primary language and the .NET SDKs, but developers are still exposed to patterns they aren't necessarily familiar with, such as the true MVC pattern on iOS (delegates and such). Xamarin Forms is trying to fix this, but so far, it simply hasn’t been able to turn the corner. And that’s no surprise. Creating a normalized API across platforms is not for the faint of heart.

Since none of the native languages will run everywhere, developers are staring down the barrel of building their business logic in multiple languages for multiple platforms.

One solution to this problem is to try and stuff all of the business logic behind an API. This actually works moderately well up until a point, and then you began to sacrifice interactivity and responsiveness at the feet of your API which may or may not be able to scale to handle your user base, if in fact you have that glorious problem. Even if you don’t have the problem, the intermittent connected state of mobile devices means that an API may or may not be available, and it’s impossible to every know when that situation may occur.

There is a solution here. It's called JavaScript, and that shouldn't surprise you one bit.

JavaScript Native

The term, coined by Brian Rinaldi and TJ VanToll, categorizes the newest group of mobile application frameworks. These are frameworks that utilize the JavaScript engine on the device to evaluate JavaScript and in turn execute native code. The most well known of these are NativeScript and React Native. Note that neither of these frameworks actually run JavaScript on the device. Both include an embedded JavaScript engine (V8 for Android and JavaScript Core for iOS). This means that strictly speaking, both of these frameworks could be extended to the desktop without a huge technical divide to cross.

The fact that these frameworks even exist proves that developers will not stop until they can create truly native applications with JavaScript. The Principal Of Least Power is as true today as it was when it was first written.

And the creators of frameworks already know this. Facebook created React and then React Native. They did this because they know that, when developers learn React, if they can then extend that knowledge to the mobile device, it becomes a no-brainer. Facebook referred to this as, “learn once, write everywhere”.

NativeScript works along the same premise using Angular 2. NativeScript is arguably more of a runtime than React Native is since it actually does expose all of the native APIs through JavaScript. The idea is that developers who use Angular 2 for their web apps should be able to turn around and build native mobile apps with Angular 2 as their application framework, and NativeScript as the runtime.

There Is No "Write Once Run Anywhere"

"Write Once Run Anywhere" is, unfortunately, a pipe dream. The layout engines and strategies between mobile, desktop and the web are simply too disparate. Developers will have to build multiple UIs. That's just a fact.

The lie of a pipe dream is what gives life to the whole misbegotten mad lot of us, drunk or sober.

Eugene O'Neill

What developers should not have to rebuild is their business logic. JavaScript is the only language that runs on every single platform. It is the only true "write once run everywhere" language. Whether that's directly on a JavaScript engine, or as an abstraction to native languages, the important part is that the language that the actual logic is coded in stays the same.

Native Code Is Bad For You

If you are building your business logic in C#, you can bet you are going to have to build it again in JavaScript at some point. There is a good chance that you already have. The same goes for Java and any other proprietary runtime. This is the very definition of technical debt.

Developers don't have to encapsulate their business logic behind proprietary platforms anymore. We also don't have to sacrifice performance to get that benefit. JavaScript makes it possible to have all business logic in modules that is the single source of truth. Those modules can then be used on the web, on the desktop (see Electron) and now on iOS and Android thanks to NativeScript.

Don't Be Bullied

Don't let yourself be bullied by your platform. And don't be fooled – those platforms have every intent of locking you in. It's imperative to their business model. They could care less about whether or not your code extends to other platforms, because they are hell bent on ensuring that never happens. JavaScript is here to set you free. Combine that with the improvements of ES6 (specifically a proper module system), and the design time tooling that is unlocked by TypeScript, and you have a world class application language. There’s simply no denying that fact anymore.

Native code, no matter how much you love it, is pinning your wings down. It's only a matter of time before a new platform comes out, and history has taught us that it's only a matter of time before that new platform supports JavaScript. Don’t be left holding your native code in one hand, and your broken cross-platform dreams in the other.

Header image courtesy of Eugene Zemlyanskiy

[cm_ad_changer campaign_id=121]

Comments