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.


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.


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.


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



  • Dalvik

    I generally agree that Xamarin forms has failed and that their basic concept is wrong. However, you didn’t fix anything.
    There are 3 possible solutions and two those are derivatives of the “smalltalk wars” of the 90’s (remember the guys that invented MVC). Lightweight and heavyweight widgets. We later added HTML which is sort of a combination of both and has its own set of issues (which we’ll put aside).

    Xamarin forms fails because its heavyweight, it uses native platform widgets which by definition are not portable. This failed for Java both with AWT & SWT and negates the idea of portability. Swing was pretty portable but at a price, it was over designed and very hard to update/fix. It did demonstrate the only way to reach native code and portability to everything.

    There are several native solutions that provide things like that including Corona, Codename One, Ionic etc.
    Solutions that call into native widgets will by definition have portability issues.

    • Jen Looper

      I’ve been a fan of Corona SDK from early on, and have used and enjoyed Ionic as well…the problem is that the widgets they display like date pickers, drop downs, etc, look the same cross-platform and immediately identify your app as something hybridish. Sometimes that’s ok. Sometimes it’s not. I like NativeScript for its truly native look and feel, diversified cross platform. I admit to being biased 🙂 At the end of the day, though, we want one codebase that is maintainable cross platform that looks appropriate to its platform and performs well.

      • I second this. It’s imperative that the compiled app use the platform’s UI elements. Users know when the toggle button is not “their” toggle button, even if they aren’t techies.

        I like using javascript, but the strongly typed nature of C# keeps me coming back to it. TypeScript + NativeScript (and it’s XAML-like xml markup) is a win-win.

        (disclosure: I’m a Senior Tech Support Engineer at Telerik and Microsoft MVP, who works mostly on native platforms)

      • Chris Pawlukiewicz

        They’re changing this in Ionic 2 as they’re adopting Material Design. Either way, IMHO something like nativescript or react native are superior because they’re rendering actual UI elements rather than HTML elements that look like the UI elements.

        • Yeah, I guess React Native and NativeScript is kind of the next generation

    • burkeholland

      Solutions that mimic native APIs have portability issues. NativeScript simply proxies whatever command you enter down to the native runtime. I think this is the core difference that we haven’t seen yet outside of projects like Appcelerator.

      • Dalvik

        You have it reversed. Solutions that mimic native are more portable but feel less native.

        Solutions that proxy to native rely on either being the lowest common denominator or on platform oddities that fail in weird ways on every platform. Since we spend over 90% of the time debugging our apps just a few of those mistakes will make all the time you saved in development null and void.

        I agree with what @jenlooper:disqus said although I disagree with the conclusion. E.g. React Native specifically claims that it isn’t very portable since that isn’t an achievable goal once you start using native widgets.

        • burkeholland

          Let’s clarify though – UI code will almost never be portable, regardless of how you choose to build that UI. If a developer could share a UI between iOS and Android, that would be a huge accomplishment in and of itself. To share a single UI between desktop, web and mobile is simply not feasible. The closest we’ll ever get to that is RWD.

          • Dalvik

            Lightweight UI as Swing/Codename One implement in Java, ionic does in JavaScript and Adobe did with Flash is totally portable and very feasible as there are quite a few samples beyond the ones I mentioned.

            Whether it gives a “good enough” experience is debatable. Some are better than other and it depends on your requirements but its pretty much the only way to be properly portable. The alternative means that any time saving you get thru coding you later spend in debugging minor and odd issues that “only happen on the device”.

        • To clarify even further, solutions that mimic native will be more portable but feel less native because of the performance implications of having to use high level and primitive languages such as javascript. Lets be real here, 75% of the TOP 10 most downloaded mobile apps are written in C++ OR make heavy use of C++ in one way or another. Sure you can abstract details to a higher DSL but there is performance implications when you are not capable of writing optimized code. You want your app to run on a cheap Android phone? Goodluck… try squeezing performance using React Native or any other javascript implementation – it will not happen and never will happen.

          • Dalvik

            In Android Java applications beat the performance of C applications as the UI is written in Java (with the exception of games where C goes directly to the underlying OGL layer).

            Objective-C which is the basis for most iOS apps is actually a pretty slow language due to reference counting and message passing overhead. Modern AOT VM’s from Xamarin, RoboVM & Codename One all claim to beat Objective-C for some use cases and are really performant.

          • You are correct in stating that Java is still required for the “UI” but computationally expensive tasks can be written in C++ – Dropbox did this for their “Model” layer (

            Either way interop between Objective-C and C++ is actually very easy but a bit harder on the Android / Java side. The problem is JavaScript aims to be a be-all and do-all language in the write-once run-anywhere paradigm, and as such your Apps will suffer in performance. I just want the JavaScript community to stop promoting it for something it isn’t meant to be.

          • Dalvik

            As far as I know all the solutions I mentioned support calling native C code. However, realistically 99.99% of app developers (not game/system tools developers) won’t do that whether they write Android code or use cross platform tools. Notice that dropbox did this before ART… ART is pretty darn fast and writing native code to get that extra kick in performance is no longer required.

          • burkeholland

            Is that true though? Often C++ is used for things like Box2D and other engines. If proxies to those engines were made available, what would be the difference in perf? It would be hard to know without having the comparison.

            There is always going to be some amount of performance difference because of the JavaScript proxy – we have this now with NativeScript and React Native suffers from the same issue. The main difference is that the perf hit is so slight, it’s not observable and there is no difference in frame rate.

          • Sure, you think it applies to “engines” but it is used for many other purposes. I can speak on this because I’ve worked with NativeScript and Ionic. Have you tried building an Ionic application? Try animating one div with box shadow on it, boom you just crippled your phone and frame rates will be under 10fps. Most modern applications make use of heavy CSS effects and some animations or transitions.

            Animating something on the truely native platform, e.g using Java you wont run into such performance limitations.

    • quazecoatl

      “I generally agree that Xamarin forms has failed and that their basic concept is wrong. ”
      “Xamarin forms fails because its heavyweight, it uses native platform widgets which by definition are not portable”

      Xamarin forms concept is not wrong. Their implementation however might not be the best.
      I spent time looking with a .NET dissembler at the Xamarin.Forms assemblies.

      Unfortunately Xamarin itself did not believe in Xamarin.Forms. The Xamarin.Forms was very very small, like under 3 people or something like that.
      Their progress was slow both in implementation and fixing bugs. Which made people mad and probably make it not so popular.

      The implementation wasn’t the best or optimal at least for Android. For example, in Xamarin.Forms app running on Android, there’s just one Activity, all the Xamarin.Forms Pages are basically Android child widgets. This is different than on iOS where a Xamarin.Forms Page is actually a ViewController.

      What’s great in Xamarin Forms is that if you need something which is not any of the Xamarin Forms controls, you can build it natively and expose it in Xamarin.Forms.

      I think Xamarin.Forms is a great tool maybe just not the best implementation.

      • Dalvik

        That’s inherent into the “native widget” problem. You can’t have multiple Activities as UI elements and still be portable as that is an such an in-grained Android concept that can’t be converted to other OS’s sensibly. Even basic image DPI’s are painful e..g if your designer was “helpful” and gave you @2, @3 images etc. and you didn’t know iOS development well enough you can so easily shoot yourself in the foot here.

        React native also took such an approach despite all their “native” claims. The top level of the UI is a lightweight container to manage the top level behaviour that is too different between iOS & Android.

        I think Xamarin Forms can’t be implemented better because of the inherent conceptual problems in its design.

        • quazecoatl

          “You can’t have multiple Activities as UI elements and still be portable as that is an such an in-grained Android concept that can’t be converted to other OS’s sensibly.”

          Why would you need to convert from Android to iOS? That’s not how Xamarin.Forms works.
          In my example, I was just questioning why Xamarin.Forms chose to map a Xamarin.Forms Page to a ViewController in iOS, but not to an Activity in Android. I’m sure they had their reasons, I wish I knew it.

          “Even basic image DPI’s are painful e..g if your designer was “helpful” and gave you @2, @3 images etc. and you didn’t know iOS development well enough you can so easily shoot yourself in the foot here.”

          You are missing the point I think.
          Xamarin.Forms is not that kind of framework where you are completely oblivious about the native. If that would be the case it wouldn’t be a good framework.
          The idea is you try write using a common API but you have to understand that it translates at runtime to native controls.

          I don’t understand what’s the problem with image DPI and “shoot yourself in the foot”. The image DPI works fine in Xamarin.Forms and it’s handled nicely.
          Did you work with Xamarin.Forms or you just read about it?

          “I think Xamarin Forms can’t be implemented better because of the inherent conceptual problems in its design.”

          No, the problem with Xamarin Forms are not related to its conceptual design.
          The problem is Xamarin decided in a weird way that Xamarin Forms it’s not a priority. I am not sure how it is now, but some time ago it was a very small team dedicated to Xamarin.Forms.

  • ɹǝʇunɥ ʎǝןʇɐ

    Sounds like bullying to wedge Javascript back into my life after running screaming from it after more than 15 years of pushing square pegs into round holes. 😉

    I prefer the security, manageability, and power that native coding provides.

    From my experiences, JavaScript doesn’t really offer the the stability and portability that the theory suggests simply due the fact that there are always one or more layers of engine to make things actually happen.

    Pure business logic tends to make up a fairly small part of the interactive UX of most successful apps, so I don’t seem to find this to be as much of an issue for me or my business cases.

  • ɹǝʇunɥ ʎǝןʇɐ

    Sounds like bullying to wedge Javascript back into my life after running screaming from it after more than 15 years of pushing square pegs into round holes. 😉

    I prefer the security, manageability, and power that native coding provides.

    From my experiences, JavaScript doesn’t really offer the the stability and portability that the theory suggests simply due the fact that there are always one or more layers of engine to make things actually happen.

    Pure business logic tends to make up a fairly small part of the interactive UX of most successful apps, so I don’t seem to find this to be as much of an issue for me or my business cases.

    • burkeholland

      Good points here. I would say that security and power are the two areas where JavaScript is still lagging slightly behind. Power is almost there given how fast the VMs are, but security is still an issue.

      Java has always run in a VM and while we love to laugh at it’s constructs and architecture, nobody has ever questioned it’s security or power (bunked updates from Oracle not withstanding).

      I would also say that for large enterprises, the business logic is really where the technical debt gets accrued and it’s also what locks departments into a stack that eventually greatly restricts their ability to move as the business moves. I’ve seen this firsthand on more than one occasion – healthcare and retail.

      • ɹǝʇunɥ ʎǝןʇɐ

        I would say that for the enterprise, where the generalities of most enterprise solutions being basic CRUD and advertising, JavaScript is a good way to minimize the duplication of a small portion of that work, but in order to do real, serious computing, native is still, and will be for the foreseeable future, the way to go.

        In my experiences, most enterprises are not putting much, if any, core business logic on devices at all, instead, (and rightly so in my opinion), keeping the bulk of the business logic on central servers that cna be tweaked, maintained and upgraded out of band to ensure maximum capabilities, scalability and accessibility.

        I am finding that, at many levels, as I am pushing the bounds of what devices can do to create memorable user experiences, I find that even the third level scripting languages (C#, etc) can, in some cases, be lacking, so fourth tier scripting makes no sense for me.

    • Chris Pawlukiewicz

      Curious, when you say security do you mean security API’s through the platform/framework or something to be achieved through the language? Javascript has changed a ton in the last 15 years. With classes and the new ‘let’ statement you have to expose a lot less of your code. Either way, using something like nativescript will provide the same security.

  • As a dev whose coded real world projects in jQuery Mobile, Sencha, Kendo, native iOS/Swift, and Java/Android, I can say it comes down to this: save money with JavaScript; or get the best UX with native.

    Cross-platform is a win for the devs and the business, not for consumers. The real win for consumers is with native. The true raw control over the machine’s functionality, sensors, graphics, and processing cannot be debated and depending on the priorities of the project, compromising the user’s experience for budget might be a way to go – but consumers are less forgiving these days.

    • quazecoatl

      I’ve been working with both .NET/C# and JS/web stuff for a while now.
      Xamarin is stil the best choice between JS and native for a number of different reasons.

  • feellikeastranger

    undubitably …