Should You Use Angular 2 in Your NativeScript App?

One common question new NativeScript users often ask is whether they should use Angular 2 or not to build their app. In today’s Slack chat, we’ve invited a few of our Telerik Developer Experts to help you decide. The questions for today’s chat are:

  • What are the advantages of using NativeScript with Angular 2?
  • What are the advantages of using NativeScript without Angular 2, which for the purposes of this article we’ll refer to as “vanilla” NativeScript?
  • How do you choose when implementing new apps?

Let’s start by listing out what we feel are the advantages of each approach, starting with Angular 2. Why is it a good idea to build NativeScript apps with Angular?

Nathan Walker, Sr. Software Engineer with Infowrap:
1. Syntax clarity:

tap="{{login}}" visibility="{{loggedIn ? 'collapsed' : 'visible'}}"

vs.

(tap)="login($event)" [visibility]="loggedIn ? 'collapsed' : 'visible'"

It’s clear what is an event binding vs. property right away, not to mention you can pass arguments to angular2 event bindings.

Josh Sommer, Web Application Developer at Renovo Solutions LLC:
I figured this would be the first one but, code reuse with your existing web apps.

Steve McNiven-Scott, Sr. Software Engineer McMaster University:
I would have to say clearly code reuse…to port your script over to web.

Josh Sommer: jinx!

I agree with Nathan, I find the syntax friendlier.

Alex Ziskind, Technical Director at Nuvious: +1 on code reuse AND skills reuse

If you're an Angular developer and want to use your knowledge, this is a great way to do it

Nathan Walker: 2. Service architecture via dependency injection.
I haven’t built a large vanilla NativeScript project but not sure I’d want to honestly. Going at a large project without dependency injection would leave me to my own devices and that’s never a good idea. 😉 I like DI…a lot.

angular2

TJ VanToll, Developer Advocate at Progress:
To me the skill reuse thing is big on things you wouldn’t necessarily think about right away. For instance, with NativeScript + Angular we don’t have a style guide, because we just use the Angular style guide for that. We don’t tell you how to structure your code because that’s what Angular does.

Steve McNiven-Scott: To me I don’t see that as “better” syntax… I mean I can see why you would prefer it, but from a non NG2 side I prefer #1 minus binding the login method.

Josh Sommer: I find it easier to build reusable components in Angular as well.

Nathan Walker: Steve, definitely was a big argument/debate when Angular2 was first released, the uproar with just the binding syntax changeup was big. So I can understand this is a very debatable topic.

Josh, agreed. Reusable components are key to a large application that needs to scale.

TJ VanToll: Josh, good example. Another case where you’re coding to Angular’s APIs instead of NativeScript’s.

Alexander Ziskind: Another one is application architecture style. Angular guides you into an MVC style app

As opposed to vanilla, which in NativeScript leans towards MVVM.

TJ VanToll: I’ll also toss out support and community. The Angular community is epic-normous, and if I’m quite honest it dwarfs NativeScript’s. So if you run into a problem building your app, you’re more likely to get help on places like Stack Overflow and Google searches when you’re using Angular.

Nathan Walker: Alex, I think that’s the biggest thing you get with Angular+NativeScript; organization and a solid best practice to frame your app.

Alexander Ziskind: Yep. While certainly nothing wrong with MVVM, Angular does guide you a little more with opinion – an opinion of very smart engineers.

Nathan Walker: A con would be that you have to work with and understand Zones, definitely not something that is intuitive really.

TJ VanToll: Ok, so that’s a good overview of the advantages of using Angular. Now to switch over to our next question, what’s the advantage of using NativeScript without Angular, or vanilla NativeScript?

Nathan Walker: Filesize of app.

TJ VanToll: Yep, you can’t get around the fact that Angular takes up space, and even after Webpack you’ll have a couple of extra megs in your app.

Steve McNiven-Scott:

  1. Less Layers = Less bugs. Is the problem I’m having in NativeScript or Angular 2?
  2. App Size
  3. Less complexity

Nathan Walker: Angular will add some to the ending filesize of the app, however this will become a moot point once the full tree shaking support is complete, which is already working at this point.

Alexander Ziskind: Given that NativeScript is so new, there are a lot of people interested in jumping in and doing mobile development. NativeScript does offer web developers an easier way in, but still there is a slight learning curve. Learning a whole other framework (and especially one where there aren't many tutorials yet) is a bit daunting.

Josh Sommer: Slightly slower boot up with Angular 2 in NativeScript

Nathan Walker: Steve, agreed. There are things that can happen sometimes that seem several layers deep and you can sometimes be left scratching your head.

Steve McNiven-Scott: Now I’m not opposed to Angular at all, just I don't feel I want to use it just to use it unless it’ll give me an edge, like when I need to do dual mobile/web.

TJ VanToll: We get that sort of feedback when people are starting up all the time. People don’t want to learn iOS and Android and NativeScript AND Angular. It’s hard for sure.

Josh Sommer: I also think plugin compatibility and ease of use is better in vanilla NativeScript as well.

Nathan Walker: I think if you are wanting to do a native mobile app with a web app, NativeScript+Angular is the best way to go, no doubt, too many wins to mention in a chat log.

Steve McNiven-Scott: TJ, Don’t forget AND Typescript.

TJ VanToll: Yep, good point.

To me the question is whether you get enough value to justify the learning curve.

Alexander Ziskind: To expand on Steve's point #1, you don't have to rely on a third party framework bug to get fixed before moving on with your NativeScript only development

Steve McNiven-Scott: TJ, if you’re coming from the web using Angular 2 to Nativescript there’s the instant value, not necessarily code reuse, but SKILL reuse.

Josh Sommer: I tell people if they know some Angular 2 already, then give it a shot. However if they do not know any Angular, I'd say they are better off just going vanilla only instead of Angular and NativeScript at once.

TJ VanToll: And I think that’s a good point. You can always start with vanilla NativeScript, and move on to Angular later when you have a good use case. If the learning curve is a problem.

Steve McNiven-Scott: Yeah, I wouldn't want to scare someone away from NativeScript showing them the Angular 2s way to do it if they don’t know what it is.

Nathan Walker: Vanilla is more approachable at the start I think if you're not familiar with either. However, if you know or had worked with rxjs, you will be confused by NativeScript’s own Observable, it’s not the same.

Josh Sommer: Observables is great point. That still can trip me up.

Nathan Walker: They trip me up often too actually. There has been talk between Nathanael Anderson and I to submit a pull request to swap NativeScript observable with complete rxjs throughout – if that happened, it would be a win+win for both sides of this discussion. Not to mention more standard observable implementation.

Alexander Ziskind: Agreed about observables. They've always been a bit different in NativeScript, even for folks that are coming from a Knockout background.

Alexander Ziskind: Let's say there wasn't a vanilla option (as in another hybrid framework), then people would be forced to learn Angular and while you might lose some folks at first, in the end everyone will be on the same page at least. (This is more of an argument for the first question)

Steve McNiven-Scott: What I love about NativeScript is how much I can do with little to no code at all.  Keep it simple…

I am however glad the Angular 2 option is there.

Nathan Walker: Alex, great point. It’s excellent there even is a ‘vanilla’ option at all.

TJ VanToll: Ok, let’s move on to the most important question, since we’re heading in that direction anyways. Put yourselves in the shoes of someone who is ready to build their first NativeScript app. What sort of things do you consider when picking between the two approaches?

Nathan Walker: Most important question to me: Do you plan to do web as well?

Josh Sommer: You beat me to it.

Steve McNiven-Scott: Agreed

TJ VanToll: And to be clear, I think we’re not really recommending that you build the same app for native and the web.

Nathan Walker: If the answer is no, then ‘vanilla’ is what you want if you are not familiar with Angular, no doubt.

Josh Sommer: If you have a web component I feel like it's a no brainer, go Angular.

Nathan Walker: If you're familiar with Angular, then Angular 2 + NativeScript without question.

TJ VanToll: Yeah I’ll agree there. If you feel you already know Angular 2, then Angular 2 + NativeScript is a slam dunk.

Steve McNiven-Scott: Or I guess like Nathan mentioned above, if have a large complex app, NG2 has a lot of tools to help keep you sane.

TJ VanToll: I think it’s worth mentioning that you absolutely can share code between NativeScript and the web without using ng2.

Alexander Ziskind: Perhaps we need a decision tree diagram.

Nathan Walker: I always knew you worked with Microsoft Word open all the time 😉

TJ VanToll: Angular 2 gives you more of a defined structure for architecting that sort of code sharing solution, but NativeScript runs vanilla JavaScript code just fine.

Nathan Walker : Good point. Very true. I feel like there would be more questions on how to do that without Angular than with Angular though.

Josh Sommer: Honestly, I'm starting a project and I've struggled with this question as well, for the simple fact I think vanilla is a little more stable than Angular 2. (I'm looking at you Router)

TJ VanToll: Yep, once you take on Angular, you have to deal with Angular updates as well as NativeScript updates.

TJ VanToll: And those can be… um, fun!

Steve McNiven-Scott: Back to the “Who’s causing my pain” problem

Josh Sommer: LOL exactly.

Nathan Walker: Router has been source of most of the pain with Angular 2 this summer. It’s unfortunate, but I do see the light.

Steve McNiven-Scott: I only want to dive in there if there’s gonna be some payoff that offsets the potential headaches.

TJ VanToll: Alex, I feel like that next branch in your decision tree should be, “Do you plan on sharing a non-trivial amount of your code between a web app and your native app?”.

Alexander Ziskind: If you abstract your code enough into components, couldn't you go either way and still be able to have a lot of reuse?

TJ VanToll: I think something else to consider is the composition of the development teams at the company/organization you work for.

If you have a bunch of people that use Angular, then even if you don’t plan to share code necessarily, that skill reuse you get with Angular is still going to pay off.

Steve McNiven-Scott: Question for the Angular 2 gurus though, if you know Angular 2 web, are you instantly at home in NativeScript or is there another learning curve? (NativeScript cli\etc plumbing aside)

Alexander Ziskind: Good question. I'm wondering what is the delta between web Angular 2 and NativeScript Angular 2.

Josh Sommer: Slight learning curve, but it will feel very familiar, right of the bat IMO.

TJ VanToll: Alex, that’s certainly an option. We’ve seen some plugins built that way, including UI for NativeScript. Write the plugins in vanilla JavaScript or TypeScript, and then throw an Angular API around it. I think that works best only for code you know is going to be used in different environments, like plugins though.

I wouldn’t want to write my whole app in a way that works with either approach, but maybe some utility functionality.

Steve McNiven-Scott: Are we at all dealing with a performance hit though from like NG2->NS XML Template Parsing vs just vanilla XML parsing?

Nathan Walker: learning NativeScript XML definitely has a learning curve…coming from strictly web angular component building.

Most web gurus love (or hate to love) the twisting and turning of div’s into whatever they want. NativeScript XML is more concise and is not really like div twist and shout.

TJ VanToll: From a performance perspective, once you opt into Angular, that framework really controls a good amount of the perf, for better or worse. It’s one of the reasons we’re trying to get Webpack really integrated into the NativeScript workflow, so that we can do things like pre-render templates and such.

Alexander Ziskind: In my opinion, the rigidity of NativeScript's XML is a win. I've been a XAML developer in my past life and being able to look at an XML file and actually know what component does what is a big plus

TJ VanToll: In a way, it’s a good thing, because you get performance improvements Google makes, and aren’t just reliant on NativeScript engineers.

Nathan Walker : TJ, definitely the pre-rendering of templates will be the answer to the perf question from the passer by.

Alex, after working with it awhile now, I couldn’t agree more. I like NativeScript XML more than HTML now. Simpler, more predictable, consistent.

Josh Sommer: I love NativeScript's layouts they "just work"

TJ VanToll: At least currently, the developer refresh cycle is faster without Angular, because the NativeScript CLI can really quickly swap out XML and CSS files, and that gets harder once Angular gets involved. But that will change. We’re working on incorporating Webpack deeper to make the Angular refresh cycle significantly faster.

Steve McNiven-Scott: I would like to just note if I haven’t already, I will shortly be deep diving into Angular2 on NativeScript, but I’m glad I started out with vanilla NativeScript as a primer.

Nathan Walker: TJ, that’s big point we didn’t touch on.

NativeScript cli is better oriented for vanilla at the moment it seems.

TJ VanToll: At the moment 🙂

Ok let’s hope this chat was able to clear some things up. Any parting advice for people still trying to decide between vanilla NativeScript and NativeScript with Angular 2?

Josh Sommer: If you're just getting started out, go with what you know, I think is the general consensus here.

Nathan Walker: I think I’d just like to conclude that there is no 1 way with this debate. It’s purely based on these core questions:

  1. Do you plan to do web with your native mobile app? If so, Angular 2 + NativeScript
  2. Do you know Angular2? If so, Angular 2 + NativeScript
  3. If none of the above, do you like general best practices with app building? If so, Angular 2 + NativeScript will be advantageous as there are several good solid best practices you will find in the Angular community.
  4. Do you have web devs on your native mobile team? If so, Angular 2 + NativeScript may help them.

Alexander Ziskind: My final thoughts – get to know NativeScript in both forms so that you can pick which tool suits the job at hand. If you're on a team that uses Angular2, you'll be ready. If you're on a team that hasn't picked up Angular, then you're ready as well.

Nathan Walker: All of the above may be arguments for Angular 2 + NativeScript but I’d like to say that I am as much for vanilla as I am for Angular 2 + NativeScript, so it just depends on your case, what your objectives are, and what your boss says. If you’re the boss, then you’ll love Angular2, I guarantee it (at least when it’s final very soon!)

Steve McNiven-Scott: Vanilla is a great place to start with NativeScript to learn the framework IMO

TJ VanToll: I’ll just add from the Progress side of things, the nice thing about Angular 2 is that it isn’t an enormously large extra engineering effort. Angular 2 is a plugin that builds on top of vanilla NativeScript, and it’s developed and maintained by a small group of people, not half the team. I’m happy that we can offer two slightly different approaches that build upon the same base, just because it gives developers some options on how they choose to build their apps.

Hopefully this chat has helped you decide, but if not, feel free to jump on the NativeScript Community Slack channel to continue the conversation.

Comments