074 AiA NativeScript with Burke Holland and TJ VanToll

Get your JS Remote Conf tickets!

02:20 - Burke Holland Introduction

02:40 - TJ VanToll Introduction

03:04 - NativeScript + Angular; The DOM

07:04 - Getting Started/Setting Up a New Application

NativeScript Getting Started Guide
- Plugins and npm modules
- plugins.telerik.com
Power Features: Skill Reuse

10:34 - Code Reuse

Data Models
Components

17:00 - Platform Specific Customization

22:12 - Plugins (Cont’d)

27:36 - Doing Things with Angular + NativeScript

Animation
- ngAnimate
TypeScript
IDEs

34:14 - Testing

37:08 - What’s coming down the pipeline?

Documentation, Samples

39:19 - Comparing Angular + NativeScript to React Native

The iPhreaks Show Episode #128: JavaScriptCore with Cesare Rocchi 42:31 - UI for NativeScriptPicks

Pebble Time Steel (Chuck)Fathead (Chuck)Apple Photos (TJ)Michigan State (TJ) Buy albums you love to support music artists (Burke)

Transcript

[This episode is sponsored by Hired.com. Every week on Hired, they run an auction where over a thousand tech companies in San Francisco and New York and LA get on JavaScript developers providing to put the salary and equity upfront. The average JavaScript developer gets an average of 5-15 introductory offers and an average salary of over $130,000 a year. You just can either accept an offer and go right into interviewing with the company and neither with that any continuing obligations. It's totally free for users, and when you're hired, they'll also give you a $2,000 signing bonus as a "Thank You" for using them. But if you use the Adventures in Angular link, you'll get a $4,000 bonus instead. Finally, if you're not looking for a job but know someone who is, you can refer them to Hired to get a $1,337 bonus if they accept the job. Go sign up at Hired.com/AdventuresinAngular.]**[Ready to master AngularJS? Oasis Digital offers Angular Boot Camp, a three-day, in-person workshop class for individuals or teams. Bring us to your site or send developers to ours classes in St. Louis or San Francisco – AngularBootCamp.com.]**[This episode is sponsored by Digital Ocean. Digital Ocean is the provider I use to host all of my creations. All the shows are hosted there, along with any other projects I come up with. Their user interface is simple and easy to use. Their support is excellent. And their VPSes are backed on solid-state drives and are fast and responsive. Check them out at DigitalOcean.com. If you use the code “Angularadventures” you'll get a $10 credit!]**[This episode is sponsored by Telerik, the makers of Kendo UI. Kendo UI integrates seamlessly with both AngularJS 1.x and 2.0. It provides everything you need to integrate with AngularJS out-of-the-box bindings, component configuration and directives, template directives, form validation, event handlers and much more and yet Kendo UI tooling does not depend on AngularJS. So if you want to use it with Angular or not, that’s totally up to you. You could check it out at KendoUI.com] **CHUCK: Hey everybody and welcome to episode 74 of the Adventures in Angular Show. This week on our panel – I guess I’m the only regular here. I’m Charles Max Wood from Devchat.tv. Quick reminder – go check out JS Remote Conf that’s in a couple of weeks. We also have two special guests this week. We have Burke Holland. BURKE: Hey, how’s it going? CHUCK: And TJ Van Toll. TJ: Hey everyone. CHUCK: Do you want to introduce yourselves really quickly? BURKE: My name is Burke Holland and I am the director of Developer Relations at Telerik. I live in Nashville where it’s 80 degrees this December I guess that’s thanks to El Niño but that’s me. Lately doing a lot of mobile stuff with TJ here, specifically around NativeScript. CHUCK: Awesome. TJ, how about you? TJ: I’m TJ. I am from Lansing, Michigan where it is currently not 80 degrees. I work as a developer advocate for Telerik 2. Burke is actually my boss. I have focused mostly on web development in my career and slowly moving into mobile with projects like NativeScript. CHUCK: If you complain about your boss, TJ, we won’t tell him. TJ: Alright. We can edit that one out, right? CHUCK: That’s right. He’ll never know. BURKE: He’ll never hear it. CHUCK: So NativeScript. It’s funny because we talked a lot, and by a lot I mean a lot about web development, the dom and how Angular deals with that. And at Angular Connect, there was an entire talk and part of the big set of announcements, they were talking about NativeScript with Angular. I was like, “Well, I thought NativeScript was native?” Then I was like, “Okay, the dom.” Your talk really explained how that’s possible with Angular 2 where it’s not with Angular 1, and it’s specifically because it doesn’t tie to the dom. Did you want to talk about some of the other changes to Angular 2 that make it something that you can actually use with NativeScript? TJ: As you said, when you look at Angular 1, the code that actually tied it to the dom was actually baked into Angular directly. It would have things like – it’s part of its data binding or its binding approach. You would know how to propagate that specifically to the dom and explicitly to the dom. If you look at some of the changes in Angular 2, what’s been done is it’s interaction with the dom is now an abstracted level where there’s a part of Angular 2 that says abstractly, “Here’s what you do if you want to append a child.” The dom – there’s a specific implementation that will say, “Okay, well that’s document at append child and here’s how you actually append a dom node.” But because that’s now in an abstracted layer, it makes it possible for Angular 2 to be used in things that aren’t the dom. Basically, all you have to do is implement this interface that tells Angular how to make these changes in a world that does not have a dom. In the case of NativeScript, what we come in and do is we implement that interface and do the things we need to do so that we can basically render Angular 2 apps in completely native worlds, so native iOS and native Android apps with native user interfaces. CHUCK: Yeah. And if you look at NativeScript – we did an episode on JavaScript Jabber on NativeScript so if you really want the details of what NativeScript is and how it works, I would recommend you go check that out. I don’t think we’re going to – we’ll talk about some of the basics but I don’t think we’re going to dive as deep into that as much as the Angular tie-ins with NativeScript. But essentially, what you're doing is you have your XML markup that constitutes your template or your view and Angular manipulates that in the same way that it manipulates the dom on a webpage. TJ: Yeah. More or less, to get into the very specific level, in an Angular 2 app, you have basically a series of components, the most common thing. So as part of that, you usually have a template or you point it – ate URL, you point it at some external template file. So normally, if you're writing a web app, you would write dom things in there; you’d have some divs in there, you’d have an input button. So when you're writing a NativeScript app instead of using dom components, you would use actual NativeScript UI elements. So you would have an R-button component which we then delegate that down to a UI button in iOS, or in Android, that widget.button on Android. Basically, you're typing R UI components instead of typing out dom components. Other than that, it’s basically the same Angular 2 that you would use as part of your web app. CHUCK: That’s really interesting. So there really weren’t that many changes you had to – or you just had to implement that view layer, that template layer that tie in and the rest of it just works as you would normally expect a regular Angular 2 app to work. TJ: Yeah. There’s more to it than just that. I’m oversimplifying things or just for simplicity because there’s other changes, too. When you think about how routing works and the difference between that, and when you're writing it in a browser, there’s specific html if I push date APIs in different things that Angular do. In a native world, those aren’t quite there. So it’s more complex than just that but I think that’s the way I think about it at a high level for what needs to be done. CHUCK: So I guess the thing that I’m wondering then is – because I get – okay, so I can mostly write an app in NativeScript with Angular 2 the way I would write apps for the web with a few minor differences. So if I wanted to get started with NativeScript and use Angular 2 in there, what’s a process for setting up a new application? TJ: The first thing you want to do is just go through basically the NativeScript Getting Started stuff, figure out how to get NativeScript app up and bootstrap and up and running. The actual Angular integration is done through a plugin, so the NativeScript we have is a concept of plugins. If you're curious, you can go to our docs – docs.nativescript.org. There’s a plugin section. We also have a little collection of plugins and plugins.telerik.com, so you could head over there and look for more details on what plugins are. Basically, there are different ways that you can extend or augment what NativeScript provides natively and Angular’s implemented that way. So after you have your NativeScript app set up – you could just set up a simple Hello World NativeScript app – you would go through and actually add the plugin to your app. That makes the necessary changes to the core NativeScript framework to allow you to write the different NativeScripts or the different Angular syntaxes, I should say. The NativeScript Angular plugin has dependency on Angular 2 itself, so just by installing that, you’ll get Angular in there as well. BURKE: It’s important to clarify that NativeScript itself is really just a runtime and it’s more than something that was created for Angular 2. So everything that we added, sort of gets added in as a plugin, something that’s just like a Lego piece that you snap in so Angular 2 is just a big Lego piece that snaps on to the top of NativeScript and it works. Theoretically speaking, you could do the same thing for React or any of these ViewJS or Backbone. If you want to go old school if you wanted to, you could create these different plugins for the runtime. The runtime just knows how to deal with Angular 2 and then how to render that out to Native components. It’s the renderer, so if Angular 2 stops at the proto views and then hands that out to NativeScript which then takes that and knows what to do with it. CHUCK: That makes sense. So if somebody were to decide, “Okay, I’m going to write with just a vanilla NativeScript app,” what does Angular actually give them as far as power features or anything like that? TJ: The big thing that it buys you is skill reuse, I would say. So when you build a NativeScript app today, we try to let you reuse skills that you already have like a web or Node developer. So there would be things like we use the same CommonJS syntax Node uses; we let you use NPM modules, so you use CSS for styling those sorts of things. But one thing that you have to learn new if you're building a NativeScript app today is sort of our conventions for how to build up views, how to do data binding. So these are the things that you come in to NativeScript and you won’t already have known those things; you have to learn our APIs for doing it. What he Angular 2 integration really lets you do is use those same conventions that if you're learning Angular 2 to build a web app, then you should be able to take the skills, those APIs, and use those for building components in your NativeScript app so you can reuse some of that knowledge. Another thing, too, that people might be able to do with it – and we’re toying with it right now – is the ability to actually [inaudible] code directly. So have an Angular component that you’ve built for your web app and just directly taking that component and utilizing it in your NativeScript app. CHUCK: I was actually going to ask about that because we hear all these people talking about code reuse, say, with node on the backend and something else on the frontend. I just haven’t seen that work quite the way you would expect. It seems to me that even though you're using Angular and Angular in this case instead of Angular and Express or Angular and something else – Sails – you still got concerns that are going to be different. So unless your NativeScript app mirrors your web app pretty closely, I don’t know how much code-sharing you’ll be able to get. BURKE: Well, I think that one of the lies that we’ve learned to tell people for some reason is that you can build one application and it will run everywhere. That just doesn’t work especially when it comes to native apps. It’s hard to do that on the web; virtually impossible to do it. So when somebody comes and says to you that you can build one app and it’ll run on iOS and Android that’ll be your one, single code base. That is generally a lie; that may be 80% true but there’s 20% platform-specific things. CHUCK: It’s true until it’s not true. BURKE: Right, it’s true until it’s not true. I think when it comes to Angular, because of Angular’s component model, it allows you to take things like your – historically, if we just say, theoretically or generally, services and your models and things like that and have those be very broad, general JavaScript objects that you can then use across applications, then it becomes possible to reuse a good bit of code. Right now – let’s say you're a big Java shot, you do Java – and all of your business object is contained in Java jars, then you have to be able to plug those jars in and if you can’t plug them in, then your business logic is encapsulated in something that you can’t get at. I think the idea here is that if you create something and you put your business logic in JavaScript objects, you can then share that between the web and now also on mobile devices and on the desktop as well with Electron. So we’re just now getting to a point where we actually have code reuse and a language that’s supported on all those platforms. CHUCK: So one example that I can see with this is data models. Most data models in Angular are encapsulated in one way or another in services. So as you build out these services, they’re all generally built around XMLHttpRequests or AJAX. What you're saying is because NativeScript has an XMLHttpRequest implementation in the RLL of our browsers do, and Chromium does which is what Electron is built upon, you can share those services across all of those different systems and then feed the JSON or the JavaScript objects out to the rest of your application. TJ: Yup, I’d say that’s pretty much spot on. I like think of it in terms of – the code sharing is most practical for the mundane things, so you hit it data models, services – [crosstalk]. CHUCK: Business logic. TJ: Yeah, exactly. I like to think of it, in my head is – if you're writing an iOS and Android app, no one in the world wants to know how to make an HTTP call in Objective-C or Java code. It’s ridiculous; nobody wants to do that sort of thing. So I think that’s where the power – this approach really plays in. That’s just one of those things that you just want to assume. I don’t want to care about how to do that because it’s just a very simple, straight-forward thing. Now where it gets way more complex is when you talk about the actual interface or the view. Although there’s the potential to share code for that sort of thing like directly outputting the views, I think for most situations, it’s probably unrealistic to assume that you directly be able to share your view code between your web and your native apps. I think it’s more realistic to think that you’ll have a completely separate interface that you’ll use for the web and your native apps, but that you’ll be able to share a lot of your backend service code. CHUCK: Yup. I also need to tell John, because we were talking about this with components and directives a couple of weeks ago. He mentioned, “Why in the world would you need a component that can have two different templates?” And I can see that if people think that they can use the same component with different templates – one for NativeScript and one for the web – then they may be looking at it and going, “Okay, that would be really convenient. BURKE: Yeah, I think that’s exactly right. That’s part of the power of Angular 2 is that it allows you to do that, to switch very quickly between those two because you're really going to have to write the view layer most likely more than once. That’s just reality. So being able to quickly plugin view layers without having to switch out the rest of your code is something that we’ve never – that’s nirvana. We haven’t actually gone there yet [crosstalk]. CHUCK: Yeah, neither do [inaudible] doesn’t do that. You have to specify what the template is. TJ: Yeah. One thing you can do that we’ve been playing with internally is – the component have this template URL property, so what you can do is you can have some build system that says, “Okay, well for the web, point the URL at this template and for your native app, point it at this template.” But again, this is something that – because Angular 2 is so new, because all of this is so new, I think that it just needs some time for the community and all of us to play with this and come up with best practices and come up with what is actually realistic for building practical apps. CHUCK: I was going to say Burke put up very well earlier when he said not all of these systems are going to be the same. So you may be able to have a component that does all of the right things or all the things you needed to do for both a NativeScript view and for a WebView, but I don’t know if you can count on that and I don’t know how much of that is really going to happen. I think we are going to see it shake down a little bit and really get a feel for how realistic that is. TJ: The other thing, too, is that there’s a ton of different use cases out there. You have businesses that want to just turn out a generated app as quickly as possible. They don’t care; productivity to them is way more important than the user experience or how high quality or polished or design-y the actual app is. On the flip side of things, you have companies where the final product – the view – how well it performs, how good the user experience is absolutely paramount. They’ll want to customize every last bit of that. The approach we really did with NativeScript is we want to try and enable both ends of that so that if you want that simple [inaudible] something out there, you can get that sort of thing but if you want to customize and fork your code, really polish your app, you’re able to do that as well. CHUCK: One thing that I’m wondering about also with regards to this – this goes back to the point that Burke was making where 80% of your code is probably going to be fine to reuse across iOS and Android. If I remember right, Windows phone is coming with NativeScript. That might’ve been a different system; I don’t remember. BURKE: At one point in time, that was the case but I don’t know where that stands today. TJ [inaudible], do you know if that’s still on the road map? TJ: It is on the road map but it is not something that is probably coming in the short term in the future. It’s more like middle to end of 2016, so something that’s certainly being considered, but it’s not something that we’re actively saying is going to be soon. BURKE: I will say, the fact that Microsoft open-sourced their Chakra JavaScript engine makes it much easier. Prior to that, we have no idea how we’re going to do that because we couldn’t get out the VM, but we can now so it makes it a lot easier. CHUCK: That’s awesome. The question I was going to ask though is that with these platform-specific customizations you have to make, maybe some in the logic, most of it’s going to happen in the template or view. How do you manage that in Angular? Do you put it into an Android component or an iOS component or do you work it in some other way? TJ: NativeScript itself; we have a couple of different ways you can fork your code for Android and iOS. At one – probably the ultimate way of forking your code is we have a naming convention that you can name any file .android.js.ios.js, the same thing for your XML files. So you could do that for an Angular component. If you wanted to say, “This is the Angular component I’m going to use for Android; this is the one I wanted to use for iOS,” you call it mycomponent.android.js and mycomponent.ios.js. What our build system will do is that it’ll actually just – for the Android app, it’ll only package the one with the .android name and vice versa for iOS. That’s one way that you could say if I wanted to provide entirely different implementations, I could do that. But I think that’s fairly uncommon, at least with what I’ve been doing because usually, there’s at least something that you want to share between the two platforms. It’s common that you want to just have completely different implementations. What I find to be more common is in our actual XML implementation. For those that don’t know, NativeScript UIs are built through these XML tags. So you have things much like the web’s HTML buttons, text fields – things like that. We have tags for Android and iOS that basically is like a way – we run a rejects on it, just exclude things from other platforms. Let’s say you want to have a [inaudible] show up on iOS and a label show up on Android, you can throw in iOS XML tag – I’m making hand gestures here that you can’t see – [chuckles] but with iOS and then within the iOS tag, you would put things that you only want to show up on iOS and then the same exact thing for Android. You put those things within the Android tag. Basically, it’s a way of saying ‘only show this chunk of the UI on iOS and only show this chunk of the UI on Android. I find that to be far more common. That’s the trick that I use the most in my NativeScript app because I’ll do things like I’ll have a little Android fab buttons, so the little button that floats on the bottom, right corner of the screen; I only want that thing to show up on Android. So I’ll toss a little Android XML tag around it. That way NativeScript will automatically take care of just showing that thing on Android. Usually, I’ll have some sort of corresponding y to do that same action on iOS; maybe I’ll have a button towards the top of the screen or in the action bar on the top of the screen, so then I’ll just throw an iOS tag around that. I personally find that to be the far more common way of customizing the experience for each of the different platforms. CHUCK: And then if there’s any deviation in the JavaScript, then you just have a function for the Android bit and the function for the iOS bit and they just call whatever is appropriate. TJ: Exactly. So we have ways of just simply of [inaudible], just good old-fashion ifs. CHUCK: Right. BURKE: If you go watch the Angular Connect video from Angular Connect, at the very end of that, [inaudible] was one of the engineers on the team that’s showing a to-do MVC example and there’s checkboxes in that example. He points out that that’s tough on mobile because iOS has no concept of a checkbox at all. It has switches but it doesn’t have a checkbox, so what do you do? One of the things that he points out is that you can write an Angular component that will render out a simple checkbox for iOS, then for Android, it just renders out a checkbox. Then you encapsulate that and then when you need it, you just pull it into your XML and you use it. So anytime that you're using controls like that, that have conditional logic, you’d segment that off so I’m going to make a checkbox component, stick it over here; require it in and use it when necessary, then all that logic is over there inside of the component where it should be and not in my XML where my app lives. TJ: And to take that one step further, too. So we have NativeScript plugins as well so you could totally publish that thing as a plugin so that other people could just directly bring it in and then just type out a checkbox in their app and then have all that hard work taken care of. CHUCK: Yeah. Somebody fix my problems for me. I like that. BURKE: Yes, exactly, right? [Chuckles] That’s the best way to do it. CHUCK: So that’s another thing that I’m wondering about is people write plugins, do they just import them through the module system the same way that you do with plugins for Angular on the web? BURKE: With NativeScript, we have – there’s a command line utility and you would say – TNS is the command we use so that’s TNS, plugin add and then the name or location of your plugin. We also have a verified plugins marketplace. You can get them from NPM but you can also get them from our verified plugins marketplace. They're all free but there’s a lot of people out there that are already writing NativeScript components. I saw one just this morning that somebody launched. It actually obscures your code. One of the problems that NativeScript, React Native and Accelerator have is that because the code is not native code specifically speaking, it’s possible to get those app packages, unpack them and then look inside and see what your private keys are which is uncool. We don’t like that at all. Somebody’s already created a plugin to obscure that and make that secure. They publish that plugin, you're able to get that plugin and add it into your project. Once you add it in, NativeScript then writes all of the boiler plate code to get that into your application and drop the files in the right place. CHUCK: Okay. TJ: The one thing I’ll add to that, too is that one thing that separates something like plugins or modules you use in a web app and a NativeScript app is our plugins can actually do native-y things. That includes things like including CocoaPods for iOS – [crosstalk]. CHUCK: Oh wow, you can get CocoaPods? TJ: You can. Yes, so you can use CocoaPods [crosstalk]. BURKE: Any CocoaPods. CHUCK: I guess you have the JavaScript bridge. This is something we haven’t really discussed on this episode, but yeah, you have that JavaScript bridge over to native stuff, so you can make calls into those native libraries and just include them in your app, right? TJ: Correct. BURKE: Yes, and NativeScript will actually go through it and generate the TypeScript bindings for those files as well without actually having to do anything. So you import the pod, NativeScript peers inside the code, looks at it, generates the TypeScript bindings so that when you go with your TypeScript and you try to use it, you get the intellisense that tells you what method you can call on that library the way that you would expect it to work inside of a strongly typed environment. CHUCK: I know some of our listeners listen in the car. I think we caused about four accidents while they swooned over that. [Chuckles] BURKE: It is a really cool feature. CHUCK: That is super nice. Because the thing is that you have the JavaScript runtime which runs on – at least on iOS. It runs through the WebView or it runs through the JavaScript core. Then you have all the native stuff and it’s not always clear how that’s all placed together. The fact that NativeScript just takes care of that for you and you don’t have to go hunt it down and figure out how to call into it, that’s really nice. BURKE: Yeah, that’s the idea is that the developer experience should be very pleasant. And anytime you're peering inside of header files and Objective-C code, trying to figure out what initialization method you need to call, that’s not right. If you're doing that, then the whole purpose of using NativeScript has been defeated because you’re now looking at Objective-C, the goal being to keep you out of that environment all together. CHUCK: So could somebody conceivably write a plugin then that includes a component or directive that connects in – or a service for that matter that connects into some of those native libraries, so that it all just hooks nicely into Angular the way that we expect through a dependency injection? TJ: Yes. So you could write an Angular component that says – grabs in, let’s just say, the Google Maps SDK for iOS and Android and renders your Angular component for a Google Map that used native implementation of Google Maps. Not the dom, web-embedded version but actual native Android and iOS code. CHUCK: Sounds so nice. I have a Chromecast and I’m excited about the idea of being able to put a little button on the screen so that I can push whatever I’m coding in to my native app up on to my screen with a Chromecast. I know there are CocoaPods and other libraries that you can pull in for that. It seems like that all would work, too; you just put the button in there. TJ: Yeah. BURKE: You can actually create plugins that pull in pods – CocoaPods as well. So you could create a plugin that people install, then when you install that plugin, it will go in and automatically pull down the CocoaPod if you’ve included one. I actually just did this for iOS and all I did was all the pod was a material design switch. That’s all it was. I was looking at the code for that switch, just what the guy had to do to get a material design type switch in iOS and it’s ridiculous. You would never want to do that. It’s so much easier to do on the wen than it is on mobile. Unfortunately, a lot of these people have gone out and already created these components to go in and worry about animation and draw rect, make rect – all these other stuff. You just pull in the pod and then let NativeScript generate that bindings. CHUCK: So you don’t need a pod file? It just goes [crosstalk]? BURKE: You have a pod – there is a pod file. If you dig in to the project structure, you’ll see a pod file. The way NativeScript organizes your project is just an app full [inaudible] underneath that, there’s a resource, and underneath that, there’s an iOS. If you keep drilling down, you’ll actually get to where the Xcode project lives and you’ll see the pod file right there. CHUCK: Okay. For those who don’t know what a pod file is, it’s essentially your list of CocoaPods you’re pulling into your application. Very similar to NPM or bundler if you're familiar with those project. TJ: CocoaPods is almost thought of as an NPM for iOS libraries, too. It’s basically just a collection of iOS things that you can add to your iOS app. CHUCK: Yeah, and if you have any Ruby foo, it is based directly on bundler. This is also exciting. [Chuckles] So what are the kinds of things that people aren’t thinking about that you can actually do with a setup like this with Angular and NativeScript? BURKE: That’s a good question. I think that one of the things you can do with Angular in NativeScript is – that people may not be thinking of – is animations. I remember back in the early days in Angular 1, there was really no way to animate between views and things like that, the Mattias had the ngAnimate library which was eventually merged in. so NativeScript actually provides this out of the box. You can do this with Angular 2. Also in the video, Sebastian demonstrates this where he’s trying to login his login form. When the login is incorrect, the whole screen [crosstalk]. Yeah. CHUCK: Yeah. BURKE: That’s all done with – it looks like CSS 3 transitions and transformations; the syntax is the same but the actual animation gets done by the native device which is really nice. TJ: Another thing I’ll add on is – I think one thing we haven’t talked about yet is TypeScript and how that plays into the equation. Because NativeScript itself basically – it runs JavaScript, so you can use anything that compiles down to JavaScript. But the NativeScript modules and a lot of the NativeScript source code is actually written in TypeScript. What that makes possible or what makes it really nice is that the incorporation between Angular 2 because it is also written in TypeScript. It’s actually fairly seamless. For those people that are TypeScript fans that are used to it, the same autocomplete and compiler hints that you’ll get from working with TypeScript in Angular 2, you’ll also get those form working in NativeScript as well. Some of these UI modules that we’ve talked about, how they work in such if you're unfamiliar with them, working in TypeScript is actually really nice for that because it provides little hints for you here and there to help guide you on your pay or keep you from making silly mistakes. BURKE: That’s a really good point. People that are going to do Angular 2 are – there’s a good chance they're going to do TypeScript. It was just [inaudible] that we built our project on TypeScript as well. So the actual modules themselves in NativeScript. When you get them, they're JavaScript but they're actually written in TypeScript on the development side. Then in Angular 2, adopt the TypeScript is the first class [inaudible] as well. So your knowledge of these two things, if you adopt TypeScript, it’s going to be very comfortable inside of NativeScript. And would say to people that are skeptical about TypeScript – because even on the dev world team, we have this big chasm where we have TypeScript [inaudible] on one side and ES 6 people that are like ‘I would never use that on the other side’. [Chuckles] TJ: It’s a holy war. Yeah. BURKE: Yeah, it’s a crusade but I would say that I was being strictly a JavaScript person before. When you're dealing with huge API surfaces the way that you do on Native applications, on the browser, you’re really only dealing with the dom and whatever libraries you import in, but on native devices, you're dealing with these huge frameworks. When you have that, you really want a language that allows you to peer into those APIs without having to constantly go back to the docs and that’s what TypeScript gives you. It gives you nothing else; it gives you that – documentation and line really nice. TJ: Yeah, because for native developers, when you're building iOS apps, the Xcode experience for development is actually quite nice. The hinting it can provide all of those sorts of things to make your life a lot easier than if you have to forgo it entirely. Android developers have the same thing in Android Studio. Just simple things like being able to, in an Android app, type Java dots and then have the IDE tell you what your options that can come next and what comes wrong. It’s incredibly valuable in a native space compared to a web app. I say this too as a TypeScript skeptic. I’m also – come from a JavaScript world and I’m slowly coming around TypeScript especially in the context of these types of apps. CHUCK: So speaking of TypeScript and specifically IDEs, do IDEs like WebStorm and visual studio code play nicely with NativeScript? I can see that if it plays nicely with Angular, it would play nicely with a lot of this. But since the views or templates are different and some of the other ways that you build and emulate things are different, do they do that nicely or do you have to go through some manual steps to get everything to look the way that you want to? BURKE: Personally, I myself have made the switch from Sublime to Visual Studio Code when it comes to NativeScript for the sole reason that the TypeScript support in Visual Studio Code is just really, really nice. I heard it’s the same way with WebStorm. NativeScript itself is pretty agnostic because it is just a CLI, so whether or not you use Sublime text or if you use Visual Studio Code, you’re going to write some sort of build system that basically just shells out a command in the background that says to relaunch the emulator, a built relaunch. Or now we have what we call live sync where you just save and it automatically compiles because it’s watching your files. So you kick off an initial command to launch the emulator and it just stays there, and whatever you say, that picks up those changes and shows it to you automatically. So really, you can go either way; it’s totally fine. I think that’s because the API for NativeScript in actually building is really, really simple; it’s not that complex at all. TJ: Yeah. I think that no matter what editor you're going to use, you're not going to have a bad experience. It’s not like NativeScript doesn’t work in any editor; it’s more – what you’re going to be able to have. If you wanted to build an enhanced experience, like directly integrate NativeScript things into the editor, like NativeScript plugins and such. We’ve seen some of this from the community having some short, little NativeScript plugins that just enhance the experience like make certain TypeScript thing available by default. Or a little build system that integrates with our command lines so that you have keyboard shortcuts you can use from your editor that launch commands directly in your terminal. We’re looking for – this other thing, too, that we like to have feedback from the community to see what kind of editors people are looking for. [Inaudible] looking into directly integrating with. CHUCK: Yup. BURKE: I will say since you logged up this softball, Charles, if you – shameless plug here – if you are using the Telerik platform, the whole idea behind that is tooling in Visual Studio to make it really easy to write NativeScript apps. You don’t have to worry about the build system; you don’t have to worry about TypeScript transpolation – all that just happens. Even the app templates found in projects in an app template, all you do is go to the menu and hit the build button and it takes care of everything else including building your application for you in the cloud and sending it back to you. So there are those kinds of things; because the CLI is open, you can create the tooling around it as necessary. CHUCK: Gotcha. One more thing before wee wrap up the show [inaudible] testing. Now when you test JavaScript, you're either doing stuff in Node and you just run it in Node or you're doing it more along the lines of a web application. So effectively, you load up a browser, be it headless or not, that actually runs through several steps on the browser to make sure that everything works properly there. How do you test NativeScript apps? Do you throw open an emulator and then say ‘okay, do this, click this, run this, do this’ like you do in the dom on the webpage or is there another approach to that? TJ: There’s two parts to this – unit testing and functional testing. Unit testing is baked directly into the NativeScript CLI. We have a command, NativeScript test and there’s some options and such. What that does is it actually launches your emulator; you can run them on physical devices even. So it runs – launches up an iOS or Android emulator device to actually code your test in the actual NativeScript environment, so it’s actually launching up an app to write on your test. What we do is – there’s a couple of different options for test runners that we support. We use – I have to look at a list but we support Mocha, Qunits, couple of other different test systems that you can use to write your unit tests. As long as you abstracted your actual interface code from your service code, then it works pretty well for you to be able to unit test the code in your NativeScript app. The harder part is the actual functional testing. If you wanted to simulate – launch up my app and click a button on it and do something there. For there, you have a lot of options in terms of – there are a lot of services. Since you actually have a truly native iOS and Android app, there are a lot of services that provide that sort of thing. We have Telerik offer one called Telerik Test Studio; you have a [inaudible] little sound in there [chuckles], but there are other services as well. It’s just – you actually have a truly native app with a truly native UI. One of the cool things about that is that it opens the door to other services that are out there for those types of applications already. That includes things like functional testing, different analytics – a lot of other things as well. CHUCK: Yeah, you’re not going to hear me complain about you gentlemen promoting any products up by Telerik just because we’re designed to work with this and it may be much more cost effective or much less headache to actually go by them. Not a problem there but that’s really interesting that there are tools out there to get it done and to get it done properly. BURKE: We have an internal framework that we use for unit testing. I sent you a link to that and if you want to put it in the show notes, people are more than welcome to go and take a look at. We use – we have the Studio but we also use Appium as well. Appium’s a great tool that if you're doing functional testing, you should check that out as well. A shameless plug for Appium there which we do not own. [Chuckles] CHUCK: Awesome. I guess the last question is just kind of wrap up question. I have two of them. One of them is what can we expect coming down the pike as Angular to ghost to beta and then comes out to actual production release or release candidates? TJ: Yeah. Right now in NativeScript, we’ve recently upgraded to actually support the beta. I think the big thing that we’re working on adding is documentation and samples, and all those sorts of things you would expect to really show how you build things the Angular way and not just the simple syntax that you need to build with. I think you’ll see a lot of things like that out of us. Also, like with Angular, just to push towards stability so that when we are ready to flip the switch and say this is something that you can actually go use and build apps that people feel comfortable actually using. CHUCK: So is this something I can play with now? BURKE: Yes, absolutely. If you – there’s a GitHub page for the plugin obviously but if you just google NativeScript Angular 2, you’ll get right to it. There’s a Read Me that goes through there. I know TJ was sending a message the other day; we have a Getting Started guide on NativeScript.org, watching through vanilla NativeScript which is I’m not [inaudible] to Angular 2, I just want to do JavaScript. We also want to create one for Angular 2 that does the same thing but from an Angular 2 point of view. So we’re working on that at the moment. It’s important to know that just because we were working with the Google team very closely does not mean that they told us any more than they told everybody else in terms of when the framework was going to be ready. So it’s difficult to develop something when you're not really sure when V1’s actually going to be out. But now that we’re in beta, it’s a whole lot more stable and it’s a whole lot better so I know that the NativeScript team is really ramped up. We also need to get that tooling into our Visual Studio offering. We’ve got to get that in there because right now, it’s only available on the CLIs. We will be getting all that stuff in there as well. Just like we survey our own customers at Telerik – at least half of them are .net developers – most of them are using Angular right now; Angular has a huge presence in the .net community so those folks in Visual Studio are going to want that Angular integration. We got to provide that in Visual Studio, so that will be a goal for us in the first part of 2016 as well. CHUCK: So I’m sure this next one’s your favorite question – how do you compare Angular plus NativeScript to React Native? BURKE: That is our favorite question. I’m so glad you asked that. TJ, what’s your answer? TJ: One thing that’s cool about NativeScript is that it doesn’t prescribe a specific framework, which is one of the things that makes Angular even possible. But we also – let’s see. How do I want to phrase this? From a high level, if you compare the two things, you’d actually – you’d put them in a similar bucket; there’s a lot of parallels between using React with React Native and using Angular 2 with NativeScript. At the end of the day, we can go into comparing each individual pros and cons. We could have an entire show about that. At the end of the day, it’s different programming paradigms and just what suits your needs better. Some people are going to like building using React, using React in the web, using React to build native apps and that’s fine, that’s great. But some people, that doesn’t fit their programming style, and what we’re trying to do is provide an alternative for those people who like Angular, that like our ways; especially people that have backgrounds in .net [inaudible], people that have background on the web, those sorts of background experience that way prefer our approach to building native apps. CHUCK: You sound like me when I’m talking to people about ‘I’m doing Angular – should I switch to React? Because Angular 2’s been coming out forever’. It’s like which one do you like? TJ: Yup. My advice to people that ask me that question – ‘should I use React Native? Should I use NativeScript?’ – my answer’s always just try them both out and see for yourself especially if you're embarking on some big task that is going to cost you or your company. You're putting a large investment in it. It doesn’t hurt to take two hours, three hours to evaluate each, try them out, give them a go, try to build something small and then see which one you prefer and then make your decision based on that. BURKE: We had one time – a couple of months ago, we said, “Well, maybe we should allow React – allow you to write React inside of NativeScript.” We’re like, “Well, React Native is already doing that.” That solution’s already available. Right about that same time as when Brad has reached out and said, “Hey, do you guys want to record together and see if we can make Angular work inside of NativeScript?” Nobody really knew at that time that NativeScript is really just a runtime. We weren’t providing an application framework so we were really waiting for people to figure out which application or framework they wanted to use, which is how they got there. I would say also that the React Native team is really kind and really smart, and doing really cool stuff. We worked with them as well, just sharing back and forth because the two things work similarly, the way that they actually function on the device. CHUCK: Yup. Yeah, in fact, if you wanted to [inaudible] a discussion about some of those similarities, there’s an episode of iPhreaks where I talk Cesare Rocchi about JavaScript Core. You can go check that out as well and get a little bit of handle on how that works and how all the calls bridge over and stuff like that. One last question – here’s the last question I have. We’ve talked somewhat about some of the things that are coming up with NativeScript, but are there any other things that we haven’t talked about that are coming up? New features, new anything like that new tooling that we didn’t come up when we were talking about some of these other topics? TJ: One of the things that we’re concentrating on is providing some really high quality UI components. We have this thing called UI for NativeScript which is just a sweet user interface comments for NativeScript apps. We already have a list view in there so think list view – it’s one of the more common components in mobile apps. We have features in there like allow you to reorder items in a list, allow you to do the pull to refresh things, so just a simple API for letting you do that. We also just recently added a calendar widget, so if you're building a native app and you want to tie in to a calendar, we have a widget for that now. We’re working on a few more of these; I think that ones that we have in our road map – I’m just checking here. We have an autocomplete coming. CHUCK: A lot of these sound like things that come out of Kendo UI. BURKE: Yeah it’s – the concept is similar historically speaking, Telerik’s a UI company. That’s what we’ve always done; we create grids and pivot grids and previews and things like that for the web and for native. So this was – NativeScript is really the first thing that Telerik’s created in terms of where there’s a runtime and ecosystem that lives on top of it. Now that we have the runtime, we want to provide all of the components, not just commercial components but the free components as well which is what the NativeScript plugin’s marketplace is all about. TJ: Yeah, and the thing I was searching for was charts. We have some charts but we’re working on adding more different kinds of charts. So pie charts, line charts, grid – there’s fifty of those things. CHUCK: Alright. Good deal. If people want to know more about the NativeScript world and about the Angular plus NativeScript world, where do they go? TJ: Anybody starting, I would recommend you first learn the basics of NativeScript. If you go to NativeScript.org, there’s a big Getting Started or Get Started button. It’s a tutorial that’ll take you about an hour to go through and it’s really the best way to get up to speed with what Angular is and how it works. From there, if you want to learn specifically about the Angular component – Burke mentioned this earlier – you can really just do a google search for NativeScript to Angular, but specifically if you go to NPM’s website and the search, just type NativeScript-Angular; that’s how you’ll find our plugin for NativeScript in Angular and that’ll have the docs you need to tell you how to actually import the plugin, how to get up and running. There’s a link to a few different samples that we have out there that shows you how to get going. BURKE: And we got a Getting Started guide coming soon from TJ, unless he decides to take off and actually enjoy his Christmas. [Chuckles] It’s a working holiday for TJ. CHUCK: If you can’t find it, blame TJ. BURKE: Exactly. It’s TJ’s fault. And let me know so that I can [crosstalk]. TJ: Yeah, directly. CHUCK: Yeah, tell him to his boss. TJ: Add Burke Holland on Twitter. [Chuckles] CHUCK: Alright, well let’s go ahead and get to some picks. I usually take a minute when the other hosts are here to figure out what I want to pick on the show but they're not here. So I’m going to go ahead and just make a couple of picks off the cuff. The first one is – and I don’t know if I talked about this last time or not but I have a Pebble Time Steel watch that I am really, really loving. They just added health-tracking features to it and that was something that I had missed since I gave up my FitBit because it was causing me issues that was irritating the skin on my wrist when I wear it or else I’ll figure it out; because my watch started doing it, I figured out that if you clean the inside of the band periodically, it won’t irritate your skin so that might be the issue there. Anyway, I’m really liking it so I’m going to pick the Pebble Time Steel watch. You can get them on Amazon. Great deal. One other thing that I’m going to pick – and I’m not going to say this too loudly because I got my wife’s Christmas present off of it, but if you go to Fathead.com. You can get full-walled decals and they have them for Star Wars so you can get Darth Vader and the millennium falcon. We’re talking six foot by four foot decals that you put on your wall. She’s a nut for maleficent from Disney’s sleeping beauty. She got a six foot six maleficent that will stick to the wall. It’s cool stuff. They have sports teams, they’ve got a whole bunch of different TV and movie franchises. They’ve got a ton of Disney stuff. They’ve got Star Ward. They’ve got all kinds of stuff. If you're a nut about any kind of TV or movie franchise, or sports team, go check them out because they probably have something. TJ, what are your picks? TJ: I’ll pick two things. Since we’re around the holidays and Christmas, one thing I did every year, I make a calendar for my parents. It’s just one of these weird traditions that we have. This year, I actually went and tried through the photos app on OSX on Macs. There’s actually, in that app, directly a way that you can print out different photos. One of the things they have now, and I don’t know how long this has been a thing, but they have a way that you can make calendars. CHUCK: No way! TJ: Indeed, and it’s actually done by Apple. It comes in an Apple container. It’s 20 bucks to make a calendar that’s relatively cheap and the quality is actually really good, like surprisingly good. If you store – if you already have your pictures in photos, I use it; I don’t know if other people do as well, but it’s nice because the integration is right there. Your pictures are already there for you to drag and drop in. It was really quite good and I was very impressed with the quality of the calendar they shipped out to. So if anybody is into making calendars, it’s kind of fun. CHUCK: Yeah, my wife uses Shutterfly for that and it does more scrapbook-y stuff and they print and ship it. I didn’t know that. That’s really nice. TJ: The other thing I’ll pick – and this is a selfish pick – I’m coming from Lansing, Michigan, home of Michigan State. We’re in the college football playoff this New Year’s Eve. New Year’s Eve, eight o’clock, Eastern Time as Burke knows is the real time. All of the times are based on Eastern Time. Michigan State will be playing Alabama. I will predict we will win that game so if this airs after that, you can tell me whether I am an idiot r not but I will pick that for my last pick. CHUCK: Oh man. Yeah, I’m not picking football. My college team is BYU and they played in the Las Vegas ball against the University of Utah who is actually our in-state rival. Yeah, the first five possessions that BYU had, they turned it over and Utah scored touchdowns on every single one. Two of them were interceptions. It was bad. They did rally back but we couldn’t pull it out. That’s hard to come back, from 35 to nothing in the first ten minutes of the game. TJ: Yes. CHUCK: Anyway. Burke, what are your picks? BURKE: I have an odd pick her; I don’t know if it’s a pick as much as it is. I have a couple but I just say whatever I want. [Laughter] CHUCK: Oh yes! BURKE: I live in Nashville and you run into a lot of artists just in random places. I’m a huge Mat Kearney fan. Do you guys know who Mat Kearney is? He’s a pop singer. Anyway, I ran into him at the candy store and I was telling him how much I like his new album. He’s like, “Hey, did you buy the album?” I was like, “No, I just listen to it on Spotify.” And I could see the excitement melt off his face. A couple of days later, I saw an article where somebody was talking about Spotify and how this works. Essentially, his album is $10.98 on iTunes. If you listen to it on Spotify, you have to listen to the album 1,500 times or the whole album roughly five times a day for an entire year in order for him to make $10.98. So my pick is for people to buy an album if you like an artist. I’m not saying you have to buy every album. If you're listening to one Taylor Swift song like TJ does, you don’t need to buy the whole album. [Chuckles] But if you're like me and you’re really listening to the whole album, buy the album. I live in Nashville; these folks are not rolling in cash. They're just – they're hardworking folks so that’s my pick. CHUCK: TJ, do you play that Taylor Swift song over and over again? TJ: I do. It’s good stuff. It’s a good album. CHUCK: I’ve got some bad news because we are never ever ever getting back together. [Chuckles] TJ: I own the album. It’s good. [Chuckles] CHUCK: That’s awesome. BURKE: I remember last time on JavaScript Jabber, TJ had recommended the Insurgent series of books so he probably does, in fact, own the Taylor Swift album. I would not [inaudible] him. TJ: Yeah. I’m secretly a 15 year old teenager. [Laughter] CHUCK: I’ll admit to owning a couple of Taylor Swift albums myself. TJ: Oh wow. This is kind of cathartic. [Laughter] C; It was before she went full on pop. TJ: Sure, you liked Taylor Swift before Taylor Swift was cool. I hear you. CHUCK: Right. Country music. Alright. Anyway, if people want to follow up with you guys on Twitter or whatever, are there good places to do that? BURKE: Yes please. I’m @burkeholland on Twitter and TJ’s @tjvantoll. We would love to hear from you. If you have questions about NativeScript, comments, you can go to GitHub.com/NativeScript and it’s all open source s you can jump in the issues there and let your voice be heard. We’d love to hear from you there, too. TJ: And @nativescript on Twitter, too. It’s also a good one to follow. CHUCK: Alright, well thanks again for coming and everybody go check it out. It’s really cool-looking. TJ: Awesome. BURKE: Thanks for having us.[Hosting and bandwidth provided by The Blue Box Group. Check them out at bluebox.net]**[Bandwidth for this segment is provided by Cache Fly, the world’s fastest CDN. Deliver your content fast with Cache Fly. Visit cachefly.com to learn more.]**[Do you wanna have conversations with the Adventures in Angular crew and their guests? Do you want to support the show? Now you can. Go to adventuresinangular.com/forum and sign up today!]