NativeScript or Hybrid? How to Choose.

Two of the more popular options for building mobile apps today are hybrid apps built with Cordova, and frameworks for building apps with native user interfaces such as NativeScript. In today’s Slack chat we’ve invited in a few of our Telerik Developer Experts that have experience in both worlds to help you decide which framework you should use for your next app. The questions for today’s chat are:

  • What do you think are the best use cases served by each technology—Cordova and NativeScript?
  • Along the same lines, what are the pain points you’d associate with each?
  • What specific features or criterion do you consider a deal breaker for building with Cordova?

Let’s start by having everyone provide a brief intro, including the expertise you have with each of these technologies.

Nick Branstein: Telerik Developer Expert and Senior Consultant with KiZAN Technologies. I’m currently writing NativeScript in Action with Mike Branstein.

Josh Sommer: I’m a Web Application Developer for Renovo Solutions LLC and Telerik Developer Expert. I’ve done contracting work and built apps wrote with Cordova/PhoneGap in the past as well.

Nic Raboy: I have been developing Apache Cordova applications with Ionic Framework since 2013. I have a course titled Ionic Framework 101. Recently I’ve been focusing on NativeScript and its Angular 2 support. I also have released a NativeScript 101 course. In all scenarios I have tutorials on my blog.

Brad Martin: Telerik Developer Expert, Director of Development at Nastek National. I’ve worked with Cordova for 2 years, published an app for NASTC that has over 4k downloads between Android and iOS. I’ve also been working with NativeScript for a little over a year now. My main focus the past year has been learning the framework and creating community plugins – there are over 7k+ installs across the various plugins I’ve worked on. I also blog here.

Osei Fortune: I’m also a Telerik Developer Expert and a full stack developer working at TOSL Engineering. I’ve been using Ionic since it was in beta and built a couple of internal apps using it. I recently started working with NativeScript for about a year now and have created a couple of NativeScript plugins that have about 5k+ downloads – a socket.io plugin being my first.

Nathanael Anderson: I am also a Telerik Developer Expert and have been developing software for 20+ years and currently own Master Technology. I work actively in the NativeScript community and was the author of Getting Started With NativeScript

Jen Looper: I’m a Developer Advocate at Progress, working closely with our TDEs, many of whom are joining us today. I’m doing a lot of work with NativeScript these days. I have a gigantic and unmanageable app portfolio described on my blog. I have a mix of Corona SDK apps, hybrid and NativeScript apps.

TJ VanToll: And I’m also from the Developer Relations team. I’ve been building with both Cordova and NativeScript for a few years, and I have apps in the iOS App Store and Google Play built with each.

Ok, let’s dive right in. What do you think are the best use cases served by each technology—Cordova and NativeScript?

Nic Raboy: I’ve seen a lot of good things with NativeScript that are graphics and animation heavy. Being able to use the native platform features is great for performance.

Apache Cordova applications are great for web developers looking to quickly spin up a mobile application because you can use standard HTML and JavaScript without having to worry about learning new XML markup.

Nick Branstein: I think both frameworks are great for developing business to consumer apps. As Nic mentioned NativeScript excels in performance because it isn’t rendered in a webview.

Josh Sommer: Personally I think Cordova is great for rapidly prototyping an app.

Brad Martin: Cordova serves a great audience for developers and businesses. Simple data consumption – CRUD apps are the best use case that I think of Cordova apps. Anything that needs graphics, 60 fps animation and native API access to get better performance you have to get away from the webview in my opinion.

Nick Branstein: My personal opinion is that NativeScript takes Cordova and kind of does it better because it’s also a great way to rapidly prototype apps across platforms with the added bonus of using native libraries and controls.

TJ VanToll: We have a large group of people here that have used both of these frameworks successfully. Anyone want to talk about a thing they built?

Nic Raboy: I don’t have any applications in production anymore as I focus more on developer tools and plugins. I have a very popular Oauth plugin that I built for Apache Cordova and a very popular Couchbase plugin that I built for NativeScript.

Nathanael Anderson: The thing I like about Cordova is it is using web technologies; it is fairly simple to get up and running and rapidly prototype. However, since working with NativeScript and using my LiveEdit plugin, I only prototype with NativeScript now.

Josh Sommer: I built a streaming “talk” application a couple years ago for a client. It used PhoneGap for Android and iOS then BlackBerry WebWorks (I think that was their implementation of Cordova, can’t remember then name for sure. ) for a BlackBerry 7 app.

Osei Fortune: Well I liked Cordova since it allows quick prototyping but when I’ve needed something with a little more complexity, Cordova has kinda failed me, so it always had me thinking about going back to native dev. 😕

Jen Looper: Positives for me include the ease of getting started. I was able to spin up an Ionic app so quickly it made my head spin. And I built and released my app, Giftler, in a little over a week.

Brad Martin: The company I work for, Nastek National, partnered with NASTC and we rapidly published an Ionic app in about a week and half. This was before NativeScript came along and introduced me into the world of native access I was missing out on. For NativeScript, I was involved with creating, along with Josh Sommer and Nathan Walker an app at ng-conf that uses native Android libraries for smooth animations and audio effects.

Jen Looper: The Cordova plugin ecosystem is really mature as well. You can find a plugin for everything…though that can be a good and a bad thing, which is why I like Telerik’s plugin marketplace where the plugins are vetted.

TJ VanToll: Brad, a week and a half is awesome. And I think that’s also telling of what hybrid is really good at—getting up and running FAST.

Brad Martin: Agree, the rapid development with taking web developers and cranking out a mobile app for Android and iOS is very appealing. Which is also possible with NativeScript now.

Josh Sommer: Hybrid really has a low learning curve if you’ve never done any native development before. I think that’s the best thing about it – with a little HTML and JavaScript knowledge, you can have a functional application.

Osei Fortune: I’ve worked on several Cordova apps, mainly Ionic. My first was a phone book and I was able to create it in about a week or so, but it still felt like it was lacking something.

Nic Raboy: I think both plugin ecosystems are very solid. As a plugin developer, I find it easy to develop plugins for both frameworks, which really benefits developers.

Jen Looper: Playing devil’s advocate, for the plugin authors out there, is writing a Cordova or a NativeScript plugin easier?

Nathanael Anderson: Depends on the plugin.

Nick Branstein: That’s the perfect consulting answer right there hah!

Nic Raboy: The plugins I’ve written for Apache Cordova are very different than the plugins I’ve written for NativeScript. I agree with Nathanael that it depends on the plugin.

NativeScript does make it very easy to access platform APIs.

TJ VanToll: As a JavaScript developer I would say NativeScript. The ability to write native plugins in JavaScript/TypeScript instead of Objective-C, Java, etc is a huge time saver for me personally.

Brad Martin: Never done Cordova plugins. When I worked with Cordova a lot more, it just looked challenging. However, that was also very early on in my career, so it’s probably also an ignorance factor for Cordova plugins. NativeScript just seemed straightforward to me when I looked at how the core modules work.

Josh Sommer: I’ve never wrote a Cordova plugin myself, but I’ve found writing NativeScript plugins to be surprisingly easy. Cordova plugins always looked a little more involved.

Nic Raboy: While I agree partially with TJ, I don’t think NativeScript is totally in the clear when it comes to Java or Objective-C in NativeScript plugin development.

Nathanael Anderson: I have to say in my experience NativeScript is easier for the reasons that TJ points out. Using raw JavaScript to access the underlying native platform makes it a lot simpler.

Osei Fortune: I’ve never tried creating Cordova plugins – looked too complex for me.

Nic Raboy: Accessing platform APIs still requires a basic understanding of how things were done in Objective-C and Java.

Nick Branstein:
Do you feel there are any plugins missing from either platform right now?

Nic Raboy: I’d like to see an In-App-Purchasing plugin for NativeScript.

Jen Looper: +1 for IAP!!

Nic Raboy: Freemium apps are the future.

Josh Sommer: NativeScript and TypeScript definition files are so immensely helpful in this process as well.

Jen Looper: I’d like to see a Parse plugin, but that’s a huge endeavor.

Nic Raboy: Jen Looper must be kidding.

Jen Looper: No, just nostalgic 🙂

TJ VanToll: I think Cordova has a more mature plugin ecosystem for the high value plugins, but that NativeScript is rapidly catching up because of the low learning curve. Just look to npm for the rate of plugin creation to see for yourself.

Osei Fortune: One thing that I’m thankful to NativeScript for is that, after I started developing plugins for NativeScript, I was able to fully understand android native dev 🙂

Jen Looper: That’s true, it’s a great tool for learning. And our Plugin Seeds are very helpful.

Brad Martin: Osei, brings up a good point. Working with NativeScript plugins has taught me a tremendous amount about Android native development.

Josh Sommer: If a Cordova plugin only did 80% of what you needed it to do that last 20% was a huge pain and usually involved editing Java or Objective C code. I haven’t had that problem in NativeScript.

TJ VanToll: Ok, speaking of complexity that some of these plugins have, let’s switch to talking about pain points. Where has either framework burned you or limited you when building an app?

Nic Raboy: Performance is a big one.

Nic Raboy: While my Cordova apps were well crafted, they did suffer from performance problems on certain devices. Specifically Android devices.

Jen Looper: I have found the learning curve for building the UI a bit steep in NativeScript, which is why I wrote my article on layouts. Perhaps for Xamarin people it seems more intuitive to use XML on the front end.

Josh Sommer: Agreed, you really can’t fall back to much on past HTML layout experience.

Jen Looper: I would also just say that after leaping into Angular 2, keeping up with this fast-evolving world can be heart-attack-inducing.

Nic Raboy: I agree with Jen and Josh that NativeScript has a much steeper learning curve on the UI.

Nathanael Anderson: My pain points: Cordova – normal performance, majorly; NativeScript – threads (but will show up in 2.2).

Brad Martin: The webview performance limited my apps in regard to animations. That’s where I struggled with a few days trying to get the most I could out of CSS and JS to make an animation smooth and it just wasn’t possible on lower Android devices. With NativeScript, I sometimes struggle with syncing app changes whether it’s using LiveSync or manually running a new build. There are a lot of factors that play into an app updating as opposed to refreshing the browser – that’s another huge advantage of Cordova apps: developing in the browser.

Jen Looper: Oh, for sure, developing in the browser is a dream compared to constantly waiting for my emulator…

Nic Raboy: To be the bad guy here, I think for both Apache Cordova and NativeScript, the documentation is lacking. I’m talking from the perspective that things are changing faster than the documentation can keep up. This makes it difficult to find correct answers.

Osei Fortune: Learning to build the UI in NativeScript was a bit troubling at first and in Cordova the performance had me losing some hair.

Nick Branstein: My biggest pain point with NativeScript is that, although it is stable, it is being iterated on rapidly and I’m trying to keep up with everything 🙂 (but maybe that’s a good thing!)

Josh Sommer: I wish I could “inspect” NativeScript layouts like I can Cordova ones.

Jen Looper: Honestly, Nic, I would say the same for Angular 2 about documentation…actually for most of these engineering-driven tools.

Nathanael Anderson: Josh, you can inspect layouts with different tools.

Nic Raboy: I wouldn’t say it is just an Angular 2 problem, but yes a lot of it is

TJ VanToll: I’ll agree with Nic and say that with Cordova it’s all about performance. The issue is, if you have an app with certain UIs, which we’ll get into more detail about momentarily, there’s just no way to improve your performance because you’re stuck in that architecture.

With NativeScript, coming from a web developer’s perspective, I find the learning curve to be noticeably higher. As Jen said, the UI syntax does take some time to learn and get good at. Learning to use iOS and Android syntax in JavaScript/TypeScript takes time as well. For most apps I find this learning curve to be worthwhile — and once you know the stuff you know it — but that curve is still there for web developers that want to learn the framework.

Jen Looper: Are there tools that can help us inspect layouts in a native emulator?

Nathanael Anderson: Android has a layout inspection tool that is really simple and allows you to actually dig into the entire layout as Android sees it. It runs on emulators and real devices.

TJ VanToll: Even though tools exist it’s still far easier to inspect your UI in Cordova than it is in NativeScript — especially for web developers.

Josh Sommer: Yeah, I think that’s the biggest thing. I use Chrome’s inspector daily so the familiarity and ease of use is there.

Nathan, nice! What about anything like that for iOS?

Nathanael Anderson: Now that would be cool if Chrome’s dev inspector could be used… Big +1 from me if that was accomplished…

Jen Looper: The alternative is to roll your own simulator, like we used to have with Corona SDK.

One pain point that people do talk about is the size of NativeScript apps.

Nick Branstein:
Is that really a pain point? Storage is cheap right?

Nic Raboy: Yeah, as someone who writes a lot of NativeScript tutorials, the size of NativeScript apps does draw a lot of attention

Nathanael Anderson: Nick, no, downloads in a lot of countries is not cheap, so size is a big issue.

Nick Branstein: Ah that is a good point

Jen Looper: I always try to consider that I’m asking people to download my software onto their device, it’s like a favor people do to me so I don’t want to chew up their phone or their data.

The Miss Manners Guide to Effective Mobile Development.

Nathanael Anderson: The size of an average NativeScript app is 13mb, and Angular 2 is 20mb.

Nic Raboy: What is the average size for Cordova? Is it still ~6MB?

Jen Looper: This is something we need to address with things like Webpack, documentation and experience moving apps to prod will help.

Nathanael Anderson: iOS is very similar in size. It is smaller by a couple megs if i recall correctly.

Nathanael Anderson: Tooling in NativeScript sometimes is a pain, so many install issues. And tns doctor needs a re-education it seems frequently…

Jen Looper: That’s very true.

Nathanael Anderson: And no windows (target) support in NS; is also a pain point.

Brad Martin: To be fair to NativeScript, it’s still an infant compared to Cordova.

Jen Looper: I feel like all these things will eventually smooth themselves out.

Josh Sommer: Yeah 3-4 years ago Cordova’s tooling was not any better.

Nic Raboy: 4 years ago when I was developing native Android applications I laughed at people using Cordova. It has come a long way since then.

Jen Looper: I believe that Ionic had a lot to do with its maturation. So kudos to them.

Josh Sommer: Ionic really brought Cordova along. I don’t think we’d be having this conversation without them.

Nic Raboy: One big problem I have with Cordova apps, specifically in Android, is that when Google finds something wrong with Cordova, they will threaten to remove your application from the Play Store until you correct it.

Jen Looper: Nic, they only do that for Cordova apps?

Nic Raboy: I am talking when Google finds something wrong with Cordova, not your app itself.

Josh Sommer: That seems highly unlikely though.

Nic Raboy: I have native Android apps on Google play that I haven’t updated in 4 years. No threats from Google.

Jen Looper: Oh I see, that may be a good thing though, right? It protects everyone.

Nic Raboy: A good thing sure, but it is a pain in the butt to have to update all your apps every time Cordova changes versions.

TJ VanToll: Ok, so this leads me into the main thing I want to run by this group, because this is probably the single biggest question I get from people choosing between Cordova and NativeScript: what are specific features or criterion that you consider a deal breaker for building with Cordova from a performance perspective?

Jen Looper: If you need a long list of data and you want it to scroll well…go for NativeScript

Nick Branstein: Animations!

Josh Sommer: Lack of native animations. WebView doesn’t cut it.

Nic Raboy: Yea what Jen said. Cordova apps render all HTML to the screen. The more HTML, the slower your app.

Brad Martin: Animations and DOM limitations

Josh Sommer: Jen, Ionic build a component to handle that. It works really well.

Jen Looper: You can’t just use animate.css?

Nathanael Anderson: Lag from anything that makes a lot of JavaScript changes in the background can affect the view.

Nick Branstein: I feel like I could write a game in NativeScript – but I wouldn’t want to do that in Cordova.

Brad Martin: Yea the virtualization scroll techniques do work well on the web, so long lists are decent but it’s nothing like a smooth native list 🙂

Nic Raboy: I don’t think I’d want to write a game in NativeScript or Cordova. There are better tools out there for that.

Jen Looper: If you want to write a game and need to use Cordova, I think there are some engines like cocoon.js that help. I have written a game in NativeScript but it’s not a FPS or anything fancy!

Nick Branstein: Neither are probably a great choice for a game, but I could! muahahaha!

Brad Martin: animate.css works great on iOS but hand someone an Android 4.2 device and watch their eyes bleed.

Jen Looper: Good point, Brad.

Josh Sommer: Nick, in my oversized list of things I’d like to do there is a balloon popping game my son likes on Android that I want to try recreating in NativeScript.

TJ VanToll: Lists are the big one for me. Even on small lists with the most advanced web virtualization techniques I struggle to build performant lists on the web, and I can do that trivially with native or NativeScript.

Osei Fortune: Well after trying to build a message and creating some complex list – the lag killed it

Nic Raboy: Yea, I think Android has the biggest issues with performance in Cordova, but I still see them in iOS as well.

Jen Looper: Are there inherent security concerns in Cordova apps that are solved in NativeScript? Dredging memory here…

Nic Raboy: Well, when you decompile a Cordova app, you can access both the HTML and JavaScript. When you decompile a NativeScript app you can only access the JavaScript, unless you use the plugin Nathanael wrote.

That can be considered a security flaw.

TJ VanToll: So, we have lists mentioned by a few people, and also animations, what else?

Jen Looper: Security issues

Nathanael Anderson: Nick, actually you have access to everything in Cordova and NativeScript, but XML, HTML, CSS, and JavaScript if you decompile it…

Neither have any security in that regard…

TJ VanToll: I will say that I find native user interface controls faster and a lot easier to use than trying to recreate the same thing from the web. I don’t consider that a showstopper per se, but I do think it’s worth mentioning.

Jen Looper: That’s true, NativeScript modules really help there

Nick Branstein: TJ, I spend a lot less time styling my NS apps because the controls render as native controls.

Nathanael Anderson: Agree with Nick, building the app and styling it awesome in NS because they are native controls. And it helps greatly that NS css keeps getting better and better!

Jen Looper: Yes, CSS animations in NativeScript are amazing

Nick Branstein: The CSS support is awesome because 1) I can reuse existing CSS skills and 2) they work as I expect to style the native controls the way I’d expect. I don’t have to fumble around trying to make my webview look right on Android and then do it again on iOS.

Josh Sommer: The amount of work to get a NativeScript app looking great and performing great is a lot lower IMO than Cordova. Plus if you run into any particular problems, the fact that you’re able to access the native APIs means that if it’s fixable in native code, you can fix it in NativeScript.

TJ VanToll: Ok, so we have a lot here, and clearly we could talk all day, so I want to wrap this up. Since we have a large group of people that has experience building with both I wanted to end this by everyone the chance to give some parting advice. Put yourselves in the shoes of a developer that’s tasked with building a mobile app and has to choose between NativeScript and Cordova. What would you tell them based on this conversation?

Nick Branstein: If said developer has never written a mobile app before then I’d definitely go NativeScript. It will be easy to pick up and learn and I think long term it will only continue to get better.

Josh Sommer: Go with NativeScript, the initial learning curve will be higher, no getting around that. Once you get over that the sky’s the limit. Also make sure to join the NativeScript Community Slack channel.

Jen Looper:
I always say, “use the right tools for the right job”. You may need a simple internal app built and your team is more comfortable with web technologies. If this is your case, maybe Cordova is right for you. If you are not averse to learning a newer technology and your team is possibly interested in building a more natively-performant app, consider NativeScript. Most interestingly, consider whether you need a web+mobile app integration, in which case using {N}+Angular 2 might be right for you!

Nic Raboy:
Both Cordova and NativeScript are solid solutions for building an application. You really need to figure out what your business need is to decide between the two. If you plan on creating a data heavy or visual heavy application, maybe consider NativeScript. If you want to get something up and running quick and have the HTML skills, maybe choose Cordova. Keep an open mind between the two. Don’t freak out if you can’t get either working in 3 minutes. I use both and am very happy.

Nathanael Anderson:
Your learning curve and installation for a basic application in Cordova will be a lot smaller; but you will hit the limits of Cordova quickly and you might not be able to easily fix the issues in Cordova. NativeScript will take more time to learn (and maybe setup), but the limits of your application are the device; not the platform.

Osei Fortune:
If your are going to develop a simple app go with Cordova but if you need something a bit more complex and need extra performance it won’t hurt to start learning NativeScript you won’t regret it :heart: :heart: :heart:

Brad Martin:
I have to agree with everyone else, both technologies offer great solutions and it really depends on what you want at the end of the day. Personally, I can never go back to Cordova. I can rapidly create apps with NativeScript now just as fast as Cordova. I also can’t go back after wasting weeks of my life trying to make animations as smooth as possible on older Android devices. With NativeScript you get the FPS that your users expect without having to kill yourself optimizing JavaScript/CSS all day (and you might still end up disappointed).

TJ VanToll:
Thanks all! And I’ll just echo what a few people have said already. The right technology choice depends on what you’re building, and it always makes sense to evaluate your options before committing to a framework for a long-term endeavor. At Telerik/Progress we believe in choosing the right tool for the job, and we provide tools regardless of what path you choose. We provide both a Cordova and NativeScript development environment in the Telerik Platform, and we maintain a large series of both Cordova and NativeScript plugins at plugins.telerik.com. If you do want to get started with NativeScript, start with either our JavaScript tutorial or our TypeScript & Angular 2 tutorial.

And also, if you have thoughts on this discussion feel free to drop in the comments below and let us know what you think.

Header image courtesy of Fabrizio Sciami

Comments