01:56 - TJ VanToll Introduction

03:08 - Code Sharing

06:35 - Components and Directives

13:09 - NativeScript and Electron

15:02 - Business Model

16:07 - Compatability; Multi/Cross-Platform Capability

17:31 - Why Use NativeScript?

26:41 - Performance and Usability; Hybrid and Native

30:21 - iOS Concerns; Xamarin

37:23 - Where is NativeScript heading? (Future Visions and Plans)

38:21 - Getting Started with NativeScript

Picks

Things Organized Neatly (Jules)
House of Cards: A Tale of Hubris and Wretched Excess on Wall Street by William D. Cohan (Ward)
AngularFire - Firebase (Joe)
Zootopia (Joe)
Rogue One Star Wars Trailer (John)
HoloLens (Chuck)
.NET Rocks! (Chuck)
MicroConf (Chuck)
Build a Raspberry Pi-Powered DIY Amazon Echo (Chuck)
The 5th Wave Book Series (TJ)
Red Rising Series (TJ)

Special Guest: TJ VanToll.

 

Can you tell what kind of car John drives by the air vent?

Hey everybody and welcome to episode 90 of the Adventures in Angular show. This week on our panel we have Ward Bell.

Hello, hello.

Jules Kremer.

Hey.

Joe Eames.

Hey, everybody.

John Papa.

Hi.

I'm Charles Max Wood from DevChat.tv. And this week we have a special guest and that is TJ VanToll.

Hey.

Now, you've been on the show before but do you want to do a quick intro for those who aren't as familiar with what you do?

Yeah, sure. So, TJ. I'm coming to you from the lovely state of Michigan. Lancing, Michigan. I work as a Developer Advocate for Telerik. I've been doing that for almost three years now. And before that just doing general web development stuff for over a decade now.

Awesome.

What do you do for Telerik?

So, I work as a Developer Advocate. So basically, I spend most of my time either blogging about Telerik stuff, trying out a bunch of our products. I spend most of my time on NativeScript nowadays. We also make Kendo UI. It's one of our web tooling frameworks. So, I spend a lot of time with that as well. So basically, trying out our stuff. I'm usually the first beta tester. The first person to try out a lot of the software that we write to give feedback to engineering and such and write about it, speak about it, come on podcasts and talk about it as well.

I don't see any dents in the wall behind you, from beating your head on that beta [blockware].

Oh yeah, yeah, yeah.

[Chuckles] Yeah, we're talking about beta software on beta software when we're talking about Angular on NativeScript, right?

Right. Beta meets beta.

Yeah. Fun times.

Yeah. In fact, we had you on the show a while back to talk about NativeScript and Angular 2. I think we brought you on today to talk a little bit more in depth about some of the concepts there. One of the things that I think Joe brought up when we were discussing this episode was just code sharing. And that's something that I think is, I keep calling it a pipe dream in JavaScript. I mean, people want to share code between backend and frontend or they want to share code between their mobile app and their web app. So, I wonder. Can you share code between the two? Does that make any sense? Or are we just making stuff up that complicate our lives?

So, this is always the pipe dream. And I think it's getting more and more true as we as developers are increasingly asked to build for multiple different platforms, right? There's always been the concept of many years ago you usually would just have your web app and maybe you have a Windows app available. But nowadays with desktop apps, with phone apps, with web apps, with responsive web apps, we're being asked to basically build more and more things. And with the same amount of resources in many cases. And I think that's what's driving this desire to find if not a single approach, just as many techniques as we can to be more efficient with our time and build code that can be used the leverages these different platforms.

So, how does NativeScript fit into that story?

Yeah, so just to take a step back. What NativeScript is, is basically it is a runtime that lets you build iOS or Android apps with JavaScript. And the key difference with NativeScript if you compare it to something like Ionic, Cordova, PhoneGap, that sort of thing, is with NativeScript we're actually building native UI components, so native iOS and Android applications. And so, from a codesharing perspective what's interesting about it is that you're able to build something that you traditionally would have to go into Xcode or Android Studio and use native tool chains to build. But instead, you can build those same applications, these native applications with JavaScript and then especially for an Angular audience with TypeScript and with Angular. And so, because of that, because you're sharing the same language and the same framework it opens up a lot of doors that were previously not available.

If you think of for instance if I am writing an iOS app and I need to format dates and time, something that any software anywhere tends to need to do, well then before I might look up, I might do a Google search for what's a Swift library that formats date and time. But with using something like NativeScript I could instead say, “Hey, I know that Moment.js does date and time formatting and I could use that library that I already know how to install and use.” And maybe I

already have some existing code of myself that wraps moment or uses moment in a specific way. And I could say, “Hey, let me just pull that into my app and use that thing that I'm already familiar with.” And it just shortens my development time, just lowers the number of things I have to keep track of in my head in order to solve problems across these different ecosystems.

So, I see this as services, right? So, services in Angular are like these utility libraries that format dates or whatever. So, those can be shared because yeah, it's common logic. I'm a little curious though as far as components and directives. How much sharing can you get away with there? It seems like your view and the way people use the app are going to be different. So, I wonder how much of that can you share and how much of it can't you share?

Yeah, so with NativeScript for instance because we're building native UIs the one really obvious big difference between building for native and building for the web is that there is no DOM in NativeScript. There is no HTML. That's just not there because we're not running in a browser. And so, because of that the key difference is that your templates, you're not going to have HTML code that you're going to throw in there. You're not going to throw in an HTML label and an input and expect it to work, because there is no direct equivalent of that in the native space. So, at the very least when you're writing code for native and web, you do at least have to fork your code in terms of the templates that you want to output. They're just, by necessity, there are different things that you need to output in a web and a native world.

And then beyond that, generally speaking what we found in our initial prototyping with this stuff is that usually your view layer is going to be different, in many cases completely different implementations for your native and your web apps. And I think to get at more of the pipe dream pie in the sky type thing that I think a lot of developers are looking for a solution where they can just get a hundred percent code reuse, like I write this code once and it's just going to work in multiple environments… but I think it's also important that when we build these applications that, I mean the reason that you're building a native mobile app for instance and not a web app is in theory you should have something, some reason that you're building this app. Some unique characteristic of the device that you're building for that's causing you to build a native mobile app. And you really should be able to leverage that ability in your app to differentiate it from your web app. There are certain things that native apps can do that web apps can't do. And you'd be silly not to tie into that and fork your code to accommodate that when you have the opportunity to do so.

So, where's the boundary? Like I'm imagining. I don't know that this is actually how it works. But then you can disabuse me of my pipe dream. Which is that I could at least write the component class which is kind of view-agnostic and expect some kind of binding system to talk to a thing that represented the native view something or other. So, I guess let me retreat and say, if I have a vision of how the component class would work independent of its view can I reuse that part? Or do I just treat components as completely different animals and just use services in JavaScript?

Yeah. And that's what we're trying to figure out as well. This is new territory for us. So, in terms of specific syntaxes you could reuse the exact, just the same component class. And for instance we have boolean check so you could know whether you're running in a native, an Android environment, an iOS environment. So, you could do things as simple as just if iOS, this is the template I want to use. This is the template URL that I want to use. If Android, if web, those checks are available. And you can do that. And the nice thing is because everything is based off of Angular 2, that same binding system is available. So, you could bind to those properties in your component class. And I think where that line is, it's hard to give generic advice for that because I really do think it depends on what you're building.

If you're building something where your native app has to… the native view and the web view are going to be somewhat similar just because that makes sense for your use case, then that might actually make sense. That might something that you want to do. But I think lots of times in native apps too, what you're building for native is going to look and feel a little bit different. And just the number of if checks and workarounds, times that you're forking your code, is going to make it more maintenance friendly if you just split that up into two completely separate components that just imports the things that need to be shared. So, services being the obvious example, utilities for things like Moment, Lodash, that sort of thing, and bring those in. But that you build two separate component views. But I think that's the thing that we're trying to figure out here. This is new territory for I think people that are doing Angular development. So, I think coming up with these conventions and where this makes sense is going to take some time to work out.

I could see that. But my instinct is, because we all use different devices, right? And if I fire up Skype on my desktop or on my phone, whichever phone system I've got, pretty much got a bunch of panels and a slide. You know what I mean? And the logic behind it, some things, there's a lot of logic that's essentially the same across whatever device I put it on. Well, I'm thinking [inaudible] opportunity there.

Yeah, so I think it's easier to talk in terms of specific examples. So, if you look at Slack for instance, Slack, I think an app that a lot of people are familiar with, it's a service that they have native iOS and Android apps. And natively written ones, native code that runs. They have a desktop app that's based off, I don't know if it's based off Electron but it's web-based but it's a truly native desktop app that's got some sort of web wrapper. And then they also have apps that run in the browser as well. So, if you take that as a specific example though, the prime functionality in all those places, even though the UI works somewhat differently is pretty much the same. You have channels. You have direct messaging. You can share files. There are things that you can do across those interfaces.

So, if you were, say you were building the next great Slack app, you're building a Slack clone today, it's pretty cool to think about. You could build all of those things with Angular 2 as a base. You could build your web app with Angular 2. You could have your services. So, if you're Slack I'm going to have services for sending messages, for starting new channels, for these various things. And those service backend wrapping calls are things that you could then bring into an app that uses Electron. There are plenty of people that are messing around with Angular 2 and Electron and just directly use those there. Then you could also bring them into NativeScript in the same way. Use those services in your iOS and Android views. And maybe you'd want to get down to the specific level where your individual components are shared. Maybe you don't. But even if you're just sharing those services and sharing the same conventions for building these things, I think it's still a massive productivity and time-saving gain.

So, you compared it to Cordova and PhoneGap. Can you compare it also to some other strategies like Electron for example?

Yeah. NativeScript really is, it's really an arbitrary runtime that could potentially be used to target multiple different things. We have the potential with NativeScript to potentially target native OS X, OS X and Windows potentially as well. Really, the core, the nitty-gritty of NativeScript is taking a JavaScript virtual machine and having a translation or a bridge layer between that and the native world. So, the real in-depth part of NativeScript is the code that actually drives your app, that lets you write your code in a JavaScript VM and hit the iOS or Android APIs. And in NativeScript we have code that specifically does that for iOS and Android. And the reason we only have those two platforms is it's quite a bit of work to build and maintain those things. But it's a solution that at least in theory could be used to target other platforms as well.

Nice. I can run it on my mainframe eventually.

[Laughs] Well, you know, I can't wait to run this on an IBM 360. I want to go old school.

Dude, I have been resisting making a comment about that Windows Phone [inaudible].

[Laughs] That's true.

I have one of the world's last Windows Phone, yeah.

Well, you'll be happy to know that we have some beta implementation if Windows Universal. And we're just sort of playing with it. Right now we're looking for basically how much interest there is before we go down the route of making it an officially supported thing.

It'll be massive. There have to be hundreds of people who…

[Chuckles] Well, Windows Universal, now Windows Phone. So…

Yeah, [laughs].

I kid because I love, right? [Laughter]

Okay. So, how do you guys expect to go to market with this? What's the business? If I'm interested in this, how much do I have to pay?

Yeah, so NativeScript itself is free and open source. It's all up on GitHub. Now, I work for Telerik and we are the company behind NativeScript and we offer premium tools and services. It's essentially that business model. So, if you were to look up Telerik's business model in general, we tend to create UI components for just about everything. And we have premium UI components for NativeScript if you were to look up UI for NativeScript. We have charts and various other things that you can purchase from us. We also have what's known as the Telerik platform which adds a couple of additional services that you can add for NativeScript apps. So, think things like a backend as a service, analytics, push notifications, user management, deployment tools. If you say you're a company and you have an app and you want to deploy it to beta testers or QA testers we have tooling to help you out with that. So, we have premium tools and services that we add onto the open source software.

Now, one thing that I'm wondering about here a little bit is with those tools and offerings, are those things that you can use with say your regular web app?

Yeah. And so, this is something that we're trying to explore a little bit more because for some of those things yes, and for some of those things no. One of the things that initially drove NativeScript and especially all our Angular integration is because we got a lot of demand for these things that can work across those environments. So, we also have Kendo UI which is our web widget UI library. And we've already had people asking us for components that essentially render with NativeScript in the native world but that also render with Kendo UI on the web world. And so that you have the ability to use these in both places. But as of today that sort of thing doesn't exist. So, for instance our premium charts and such, those are specifically built to run in a NativeScript and native environment. And so, they're not things that immediately render on the web. But it's the sort of thing that's theoretically possible and that we're looking into, sort of prototyping at the moment.

Yeah, that would be really nice. If we're talking about this multi-platform stuff something like Kendo UI would be nice to be able to just pull in those components on both ends and just have it work seamlessly.

So, I have a question. Could you explain to me, and this is just for the developers I've been talking to in the field lately, why I would want to choose to write native apps using NativeScript versus just a web app?

Oh, yeah. This is a great question. So, we could probably have a whole podcast about this question, too. So, in my mind there are many different reasons you'd want to build for one or the other. I think the most succinct way I can put it or that I believe is that what the web is really good at is reaching a lot of people. The web runs everywhere. It runs on every single device. There's no question that with the web you can reach more people. It's easier to reach people as well. But data also shows that what native is for and native's unique place is for building rich experiences in things that people actually use. So, there have been studies that show for instance that people use native apps on their devices about 10 to 15 times more often than they use the web. And that's certainly something that I see in my own personal usage as well, that the apps that I use on a dayto-day basis tend to be native apps and not web apps.

And so, every business and every service is going to be different in how they attack this. But the business models that I see making the most sense is that you have your web app for your way of reaching a bunch of people with your service and reaching the broadest possible audience. But then you have a native app for really catering to those power users or those people that use your service a lot so that you can provide essentially the best possible interface into what you do as is humanly possible, if that makes sense.

Well, there are two components to this, right? One is yeah, I'd rather have the app experience, rapid fire, all that stuff. But that's the Cordova and Electron sell, right? I can take my web thing, write across all platforms, put it in one of those things, get a nice wrapper, throw it in the store, babing. I'm ready to go. You're saying, because I see the pressure there between that which is the next step from just hit a browser, that's the next step. I've got a package. It feels like an app. But you're saying, “No, no, no. It's better still, more important still if it actually talks native.” And that's an additional cost, right, because you just finished telling us that I'm going to tune it to each target platform. How do I make that trade? When am I going to make that trade-off?

Yeah, and I think it's a decision that really every individual company service is going to have to make. Because there's no question about it. Building with NativeScript and this also applies to similar frameworks like React Native as well, once you take that step and say that you're going to be native it is going to be harder. And I think it'd be silly to act like it isn't because you're giving up the HTML layer, the DOM layer. That's now gone. So, if you have that understanding as a web developer for how that works, in some ways you're throwing that out the window. What you're getting in return though is a natively written app, something that feels like a first-class citizen on that platform.

So, to give you an example of some small little things, like on iOS with NativeScript and even with Angular 2 when you navigate with the Angular router to another view in iOS you get the slide in behavior. If you're an iOS user you're probably familiar with how that works, from one view to another. The back button in the upper corner. The swipe to go back between views. On Android when you're using the router you get things like the hardware back button works as expected. You can use native menu items, things that are going to look familiar to the user. You're going to get the very best performance because you're using something, a layout that's native code and is not something that's a web app that's being wrapped as part of a native app. So, it just depends on what you need.

The other thing with NativeScript as well is that you have closer access to native device features. So, if you choose to go down the Cordova and PhoneGap route any time you need to tie into the native layer you essentially have to go through a Cordova plugin to do that. And these are things that I can give you a few instances of this. If you're building a native app what you might want to do is offer touch ID authentication for your iOS apps to make it easier for them to login. On Cordova that's a plugin. In NativeScript that's just something you get because you're running in a native platform. There are things like social sharing. If you want the ability to share things in your app. Basically anything you can think of that's available on your device, as you move towards you app needing more of those things, then something like a NativeScript, a React Native type approach where you're building truly native makes more sense because you're running closer to that metal.

You're not running on some abstraction away from that.

But let me play the devil's advocate. So, let's say I'm an Ionic 2 developer with Angular 2, et cetera. And I'm building an application and I feel like I can build those things, integrate with social aspects like you're talking [about], the share icons and all that stuff [today]. I can do that with those. How is my experience better with the NativeScript versus what I get out of Ionic in a [hybrid] role and how much better is it? Like, so I can quantify the justification to do it.

Yeah, that's a good question. And it's hard to give a specific answer to just how much better it is because it depends on the use case. It really depends how much your app is going to push the device and what's needed to be built. I think the biggest place that I recognize this in my own personal development is any time my app has to do something with lists. So, think of any feedbased app, the Facebook/Twitter type examples out there. Once you choose to go native you get access to the native controls for building these things, so UI table view in iOS, android.widget.ListView on Android. And once you go those approaches, you can rely on the native OS to handle the heavy lifting of that for you. So, think things like if you need to implement a pull to refresh. Those are things that are just to me a lot more fluid in a native app than something that's hybrid written. You're not restricted by the limitations of the DOM whereas in the DOM you have to go to these somewhat hacky virtual DOM based solutions.

Right.

To handle large datasets. In the native land you can introduce massive datasets and just lean on the bytecode and some of these native controls to handle the heavy lifting of memory management for you. And so…

You know, I think that is the canonical example, right? What you're pointing at is the canonical example I think that I've hit a lot and others have hit. If you have a large list, especially in older Cordova apps, not so much in newer ones as much but it used to have a real problem with lists being fast, both rendering, scrolling, virtualizing, the pull-down. It's gotten better with Cordova, with Ionic 2 and stuff, but I still think there is a noticeable difference. I'm just not sure if there are other areas that are a big difference.

Well, and the nice thing too is that especially if you've decided to use Angular 2 for your app development the nice thing is that it's a lot easier to switch between these things. So, let's say your service layer, your utilities are all in some layer that's not tied to some specific interface, all of a sudden it becomes a lot easier for you to prototype these things out, to start with a Cordova-based approach, and see if you run into any restrictions. And the nice thing is if your app is one of those apps that say, “Okay, I'm starting with Cordova with this Angular 2 app but I've hit some situation that I have no way out of,” like the performance just isn't good enough here, then you can flip a switch and I guess I shouldn't make it seem as easy as you're just turning something on. But you're still able to share a lot of the same concepts, a lot of the same tools that you've used to build your app and switch over to it. So, I think…

If you've designed it well, right? If you've pushed everything out of the components mostly. Because if I understand you correctly, most of what I'd have to redo besides the minutia files that go around it is I'd have to take the templates, my HTML, and convert them over to the XAML like structure for you guys. Now, you mentioned switch so I'm going to lay it out there for you. Are you guys working on some kind of a button that gives a starting point to take an Angular 2 web app and convert it over to a starting point for a NativeScript app?

It's something that we're working on right now. The thing is you can't really necessarily convert things. Because for instance with HTML there's not really direct native equivalents of a lot of the things that you're doing. There is no native equivalent of a div for instance. So, there's no way to directly take and convert those types of concepts. I think the best thing that we can do, at least at the moment, is try to push people towards a coding mechanism that takes that approaches that you spoke of, make your code modular, keep your UI code separate from the rest of your codebase. Just because not only does that have the traditional benefits of better modularity, decoupled testing, that sort of thing, but once you add something like NativeScript in the picture, having that ability to switch between interfaces and platforms really adds an added layer of benefit to taking that sort of approach.

So, follow John's style guide.

Yeah, exactly.

Now, I want to go back and talk a little bit more about this whole you started off in one direction maybe doing Cordova and you got yourself into a bind you were talking about. I find that to be an interesting aspect of something. We used to live in a world where we had three options. You could do a mobile website or you could take the halfway step and do a hybrid web app or then you could go full native. And I saw a very interesting tweet recently where somebody tweeted predictions for 2016 and they said 2016 like every other year is going to be a year where it's best to build your mobile apps using native technologies. And then of course somebody quickly replied and said three times using three different teams and three different tool chains. [Chuckles] Right?

So, NativeScript adds this new other option. And the two things you talked about are great. Benefits of a native application are performance and I guess we'd call it usability, right? So, are that the only benefits that there are? Is development time still going to be weighted towards it's quicker to build a hybrid app and publish it through say Ionic than it is through using NativeScript? Or is it because of the way that NativeScript is positioned or the technology works, is it becoming easier and quicker now to build? Because certainly nobody wants to spend three times the effort building their native application three times.

I do. If I'm a consultant, I absolutely do. I get paid three times for it. [Laughter]

Right.

Yeah, no. I like this point a lot. And I think that there's no question that taking a hybrid approach is going to be faster. You're going to have the ability to use fewer resources. I think what NativeScript offers is that it's like a halfway step in a sense. So, you don't have to go down the route of having three full teams. Instead you might have, say your existing JavaScript team, your web team, being able to build a large chunk of your app.

And then maybe you have one specialist on your team that really knows iOS or Android really well that can help you out with the nuances of developing for those environments. Because there are certain things that, for iOS and Android that even with hybrid or with native that you can't get around learning. You're going to have to learn how to provision iOS apps to deploy to the store. You cannot get around that. It's Apple-enforced. You're going to have to learn things about how Android permissions works and how to integrate that into your app. So, I think having some of that specialized knowledge even regardless of whether you're building hybrid or something like NativeScript is still valuable to have. I think what NativeScript offers though is for you to get that native polish that you may need for your application with say one of those specialists versus a full iOS or Android team that you'd have to hire.

Right. Is there also still a benefit in hybrid where you can make easier updates and deployments to your app?

Yeah. The cool thing about NativeScript, and this is true of React Native, is that all of the code that runs in these ecosystems is actually interpreted. So, your JavaScript code, there is no crosscompilation that happens with your app. So, it is possible to remotely update your entire application. The same benefit of hybrid is also true with NativeScript as well. You can deploy or hot-patch your app on the fly.

Awesome. And that's a huge, huge benefit over a fully-native application, right? Because deployments and updates can take weeks.

Yes. The iOS App Store iTunes Connect process especially is a giant pain. [Chuckles]

How do you get away with that? Because Apple is like, they so didn't want us to be able to have any dynamic stuff going on [inaudible] dynamic code. So, how do you beat that?

Yeah, so I'm not a lawyer so I'm not going to give specific legal advice. But if you look at the incredibly long and complex terms that Apple has out there, there is specific wording out there that apps that are using JavaScript Core for their JavaScript VM, they have a specific exception in there. And there have been lots of debates that you can find online that again goes over my legal head because it's basically a bunch of lawyers over-interpreting a couple of sentences that Apple wrote [chuckles] as expected. But from a technical standpoint there is no restriction whatsoever. It is easily done.

Well, it's critical for anybody who has a business application, you just can't sit around there, and I can be [inaudible], you've got a bug, you can't wait for some schmo in the back room to decide that you violated a policy when the house is burning down. You've got to ship. You've got to ship the fix. And that has always seemed to be an obstacle to doing any of the app store stuff. As a business I'd be very reluctant to put an important application in the store.

Yeah, this is almost entirely an iOS concern, too. Because Google Play updates take a matter of hours to push out whereas iOS updates take anywhere between five and say at the high end 10 to 12 days depending on how lucky you're feeling.

Yeah. Let's say you're building these apps and you're a big business. Maybe you're a small business, either way. There are a lot of options these days. And something I'm curious about from you is recently we heard Microsoft purchasing Xamarin which in a lot of ways I feel like Xamarin and NativeScript are very similar because they target similar types of audiences. Not the same audience but a similar type. Meaning I've already got a certain skill set and I want to use that skill set but develop mobile applications that work natively.

So, Xamarin takes from the angle of theirs however many numbers of C# out there and I can write C# and I can use a custom view layer. It's not using HTML. It's a custom view layer using XAML and I can produce a mobile app that's native. And Microsoft just bought them like a month ago. You guys with NativeScript took a similar tact which is I can write my JavaScript and I can use Angular 2 if I want to, and I don't have to, but I could also use this custom view layer to create a native app. I'm curious about the similarities and how much Xamarin influenced you and also what you guys think about the Xamarin purchase from Microsoft and how that might affect what you're doing.

Oh yeah. It's certainly interesting. I'd agree with you that the high-level approach is actually very similar. I think the fundamental difference is in the language. Xamarin is obviously very targeted towards C# developers whereas NativeScript is more towards JavaScript and TypeScript developers. And even though there is some overlap there, I think for the most part you'll find that people tend to be fairly dogmatic about their language preferences in those terms. So, I don't find… certainly some people from a business, people that are above the developer rung tend to compare NativeScript and Xamarin quite often. What I've found is that at the actual rank and file developer rungs people have their preferences based off language that they tend to want to choose and support.

So from Telerik as a company, we also make UI controls for Xamarin that you can purchase and buy. So in a way, we've sort of hedged our bets here and we're cool if you want to build in either ecosystem.

So, do you guys embed bugs into those?

Are there intentional bugs in those that are like seeding viruses into Xamarin?

No. It's also…

I'm kidding. [Laughs]

It's also worth mentioning. We build things. We have services out there for PhoneGap builds as Telerik platform is a PhoneGap tool chain as well. So, I think we also build native. We have UI for iOS, UI for Android, native controls we build too. So, as a company we can't make up our mind really what we want to do. But what's nice about that is that we don't necessarily have to be dogmatic when we talk to developers as well. We can encourage them to pick the best tool for the job.

Now I think for us the reason that we use JavaScript is just the nature of the language. It's a more lose language, permissible language, that is more interpretable. That's a word. So, it fits better for the type of approach that NativeScript takes that your code is basically interpreted at runtime. The one unique advantage that gives us over Xamarin is that because of this ability to live-update apps that are out in the app store, but also during the development process as well. Because your app is interpreted at runtime, during development we can have a simple watcher that just hot-reloads your app on the fly which makes your development cycle a lot faster when you're using JavaScript versus when you're using a compiled language.

I don't think that's a debate one can win. I think there are advantages on the other side. I don't think there has to be a winner. I think it's great that there are two approaches to try and get native without making you write everything all over again no matter which platform you're on. Because I talk to people who, they just say I'm never going to write in JavaScript. That's it. I'll quit my job before I write in JavaScript. And I say, “Hey, have fun.” And they do. And they do wonderful things with XAML and C# and they should be free to do that. So, they're just different markets trying to attack the same problem and it seems great to me.

Yeah. I see this, the best way I think of this visually is almost like a spectrum. Where on one end you have an approach that's really easy to use but that isn't quite as polished but on the other end you have something that's highly polished. So, what I mean by that is if you are a business and you need to build a native app, your easiest route in is something like Cordova or PhoneGap especially if you have existing web expertise. It's going to be the fastest for you to build, the easiest for you to maintain. If you continue down that spectrum you have something like NativeScript where you've moved on. You've decided you need the added performance. You need the native user interface. But you still get to use web technologies to build it. And Xamarin is almost on the same point except with a language shift and you're using C# instead.

And at the end of the spectrum is you could still absolutely, a lot of companies still use the completely native tool chains. They have an Android team that builds completely native Android apps. They have an iOS team. And if you're a big company, oftentimes that makes sense. You really want those apps. It's incredibly important to your business model they have the most polished experience possible. So, I don't think that you're going to see Facebook for instance or some of these massive tech companies switching away from building truly native apps any time soon. It's just where upon the spectrum makes sense for you based off your development team, your resources. And I think having more options is a good thing.

So tell me, where are you guys heading? We know what NativeScript is. We know you guys are going to be having some cool stuff at ng-conf and other places this year. But what's the future? What's the next thing for NativeScript beyond where you are? Do you see any kind of future visions or plans you guys are thinking about?

The big thing to me is this idea of code sharing and where that could lead. We're starting to see the basics of it with things that we've talked about today with just the ability to share services and modules. But imagine if you could say for instance take some more complex user interface components and you could code to an Angular component one time and spit out charts both in a native iOS app but also in a desktop web app. And integrations between NativeScript and our other web products with Kendo UI. I think that's one of the things that excite me the most is that ability to just go further down the code reuse strategy and see what makes sense and what's possible.

So, one last question I would like to ask would be about learning and getting started. That's something I always want to make sure that our viewers get a good handle on. I want to check this out. I want to play around with it. Where do I go?

Yeah. Actually, I can get you a shorter URL to use. The best place if you're looking to learn NativeScript today, if you go to NativeScript.org there's a big green get started button and it will take you to a little tutorial that takes several hours to go through but it should walk you through learning all of what you need to learn to use NativeScript. Now, one caveat to that right now is that that guide is showing a workflow that does not use Angular. So NativeScript, Angular 2 is not a hard dependency of it. So, the guide in about a month so maybe by the time this ends up airing, that guide will show Angular. But for now, if you want to go through a tutorial that teaches you how to use NativeScript in Angular. The URL is tjvantoll.github.io/nativescript-angular-guide.

And we'll have a link to that in the show notes, of course.

Yeah. And if you just search, probably google NativeScript Angular guide you can find it as well. And that will be live up on the docs within a couple of weeks actually. If you have any feedback on it we'd love to hear what you think.

Cool. I got one more question. What's your favorite talk at ng-conf going to be?

Ah. That's a good one. I don't know. I have to look over the…

It's not going to be the NativeScript talk?

Ah, but no. I'm not any good. It won't be very exciting. [Laughter]

Will it be the talk where they get up and say, “Alright guys. Let's break for lunch.” [Laughs]

I always love that one.

I hear John Papa's talking. I've heard he's pretty good. So, I'll be excited for that one.

His talk title is awesome. Have you seen his talk title?

What was it again? I remember thinking it was… now, I'm embarrassed. I don't know it.

Lay it out, John.

He doesn't remember either. [Laughter]

I don't want to upset Ward.

No.

It's related to Star Wars. [Laughter]

'An Angular 2 Force Awakens'.

[Nice].

Somebody's got to put a stop to this. [Laughter]

So, I just found, I should have remembered this a minute earlier. But we actually do have a fun URL. If you go to NativeScript.org/angular then you can find a link to all things NativeScript in Angular. I should have given that earlier.

Awesome.

Oh, you know what I just realized? I have Photoshop. I'm hoping there are good pictures of Ward online so that I can use Photoshop to make a Tumblr blog…

That is Star Ward.

Oh my gosh.

Oh.

Oh wow. That's [inaudible].

That would be so awesome. You totally shouldn't have let that out of the bag. You should have published it and then just see how long it takes for him to notice.

People would be like, “Wow.”

I know a few people who would tweet that like crazy. We'd be all over that.

Alright. Alright, let's go and do some picks.

My pick this week is my daughter turned me onto this Tumblr blog called 'Things Organized Neatly'. So, if you have any stem of OCD in your heart, you will love it. And this weekend we're taking on the challenge of rebuilding the lucky charms image. So, if you go to

ThingsOrganizedNeatly.Tumblr.com you'll see my weekend project.

You're going to… what are you going to do? Take a box of lucky charms and organize them?

Yes. Yes.

Oh my gosh.

What? Wait, what? Seriously?

Yes.

Now, talk about things that really need doing. [Laughter]

What are you going to do after you organize them?

So, here's me doing that. I'd be like I'm eating one. I am getting you one. [Inaudible] [Laughter]

No one said that…

Are you organizing by color? Are you making any design?

Well, I think you're going to have to go to ThingsOrganizedNeatly.Tumblr.com to see.

We are. I know. I know. But the mind [inaudible]…

It's like I came home one day and my wife had organized all my books by color.

Exactly.

Like, what? [Chuckles]

I can't find anything.

I know. I told my daughter I'm not even OCD. Why did you pick this out for me? And she said, “Mom, you secretly would like it. Because you're probably [inaudible].” [Laughter]

I have no OCD but I'm happy to introduce you to my wife.

I have a lot of diseases. That isn't one of them.

Alright, Ward. What are your picks?

Well, I was supposed to be working. And…

Instead I binge read a book called 'House of Cards' and it's not the series. It's the story of the failure of Bear Sterns during the mortgage crisis. And it's really full of interesting insights into hubris. It's really a Greek tragedy over and over again.

[Laughs] You're boring Charles over there.

Yeah, he's yawning already. [Laughter]

I'm tired. This is my third in a portion podcast today.

I'm telling you…

Charles, Charles, quick. Which podcast is it? [Laughter]

If you open that book you won't be able to put it down.

Alright. Joe, what are your picks?

Alright. So, I recently had to do a bunch of work in Angular 1 and I used AngularFire and Firebase. And I want to pick that just because I've been absolutely adoring it and remembering why I did love Angular 1 when I first learned Angular 1. So, I just want to pick the fact that just because it's an older tech, it is still an awesome tech and a great way to build apps. Not that I didn't have a couple of growing pains with it, or a couple of pain points with it. But it was great. And AngularFire really makes it so easy to have a nice backend. I've rebuilt the backend with Node and it was so much more painful than putting it together with Firebase. So, I want to pick that.

I recently took my family to see 'Zootopia'. That was an awesome movie. Great movie. So, that will be my second pick.

Alright. John Papa, what are your picks?

Well, my first pick is something I wish somebody would make. And I've been reading these rumor sites about movies coming out. And there's one movie everybody's wondering who this woman Rey is and who her father is. And there are a lot of these rumor sites but I'm here to tell you now as a breaking story that Rey from 'Star Wars: The Force Awakens', her father, one of the biggest rumors is it's actually Ward Bell.

So, we might see Ward in a future episode as either a troll or a Jawa or something like that. [Laughter]

Or just the good old Jedi Father. No.

Yeah.

I'm [picking] a trailer for Rogue One because it was awesome.

It was an awesome trailer. Yes.

It looks phenomenal.

He's picking [inaudible]…

And I'm also picking my children  because my children are going to play 'Star Wars: The Force Awakens' non-stop while Ward is at my house this coming weekend.

No!

Oh. Oh, man.

And I'm good. That's it.

I have to tell you, my four-year-old loves Star Wars 7. Like, he doesn't 'Star Wars: The Force Awakens'. It's 'Star Wars 7'. And I had some ladies come clean the house while my wife was out of town. Totally surprised her. I think she's still mad at me for spending the money. But anyway, yeah that's how I kept him occupied is I gave him my iPad and he watched 'The Force Awakens' so it's good for all ages.

I've got a few picks here. I had a terrific time at Build Conference this last week. So, I went to Build Conference. Jules was supposed to be there but she decided she was sick.

[Inaudible] so sick, sickest I've been in a long time. I'm so sad.

Yeah. So, we had to settle for Rob. [Chuckles]

No, it was fun. So, JavaScript Jabber we did five or six episodes while we were there. Teamed up with '.NET Rocks!' and it was awesome. We had a great time. And there are a couple of things that I just want to pick that happened there besides the couple of people that I'm going to try and get on this show. One of them is they had this Mars encounters deelio. And it was with the HoloLens. So, it was a virtual reality, augmented reality experience. They teamed up with JPL from NASA. So, you got to walk around the surface of Mars in a semi-fully immersive experience. It was really, really cool.

I also, I got to talk to Anders Hejlsberg who we're going to try and get on the show, some folks over in the Azure platform, and it was a lot of fun. I also want to just pick the guys from '.NET Rocks!', Carl and Richard. They did a lot of work to pull it together. There was also a Microsoft guy, Burak, that pulled a lot of stuff together. So, just way cool stuff. I think a lot of the stuff we talked about there will be interesting to people who listen to this show. So, the next four of five episodes should be on JavaScript Jabber from that conference.

I also went to MicroConf. If you're a small business person I highly recommend you go there. Met a lot of great people and got a lot of information, good information about where to take things from here for the shows and things like that. So anyway I just wanted to shout-out to those things.

And then my last pick is, and this is something that I'm planning on doing over the next few weeks is I found an article that shows you how to build your own Amazon Echo with a Raspberry Pi. Because they open sourced the software on the thing. So, you can actually build skills for your Amazon Echo and I'm just looking forward to that. I think that will be way cool. So yeah, so those are my picks.

TJ, do you have some picks for us?

Yes. So first of all, I am absolutely transfixed with this 'Things Organized Neatly' Tumblr. I'm on page six right now. And…

See, told you. Did you see the lucky charms one?

I have not gotten to the lucky charms ones. But there are some interesting things that people have done, that they have organized.

You may have missed the lucky charms one. It's the third one on…

Oh, I must have missed it. Alright, I will go back.

But my picks, I am a giant fan of the young adults apocalyptic trilogy genre. So, think 'Hunger Games'. It's kind of crazy that that's a genre now. And 'The 5th Wave' is actually a really good book series. I've heard the movie does not get very good reviews but the books are excellent. The first two are out. And I think the third is coming.

The other series is 'Red Rising' which is a series, a similar type series that takes place on Mars.

Quite good. So, if you like those types of books, if you enjoyed 'The Hunger Games' at all, you might find this interesting.

Have you read 'Station Eleven'?

I haven't, no.

I have a friend who's a professor and I was on vacation last week and he recommended that book.

And it starts off great and I hated the ending. So, you should try it and see what you think.

Sure, yeah.

Alright. Well, thank you for coming, TJ.

Yeah, thanks for having me.

Looking forward to getting this one out there. We'll wrap up the show and we'll catch you all next week.