NativeScript Under the Hood

On this episode of Eat Sleep Code, guest TJ VanToll talks about the inner-workings of NativeScript. NativeScript is an open source project that allows developers to write native iOS and Android applications using JavaScript, XML and CSS.

Guest @tjvantoll

TJ VanToll is a developer advocate for Telerik, a jQuery team member, and the author of jQuery UI in Action…

TJ has over a decade of web development experience—specializing in performance and the mobile web—and speaks about his research at conferences around the world. TJ is @tjvantoll on Twitter and tjvantoll on GitHub.

Show Notes

Transcript

Ed Charbeneau: Hello, and welcome to Eat Sleep Code, the official Telerik podcast. I'm your host, Ed Charbeneau, and with me today is TJ Van Toll.

TJ Van Toll: Hey, Ed.

EC: And today, we'll be talking about NativeScript. What's inside the black box? TJ is a developer advocate on the DevRel team with Telerik. TJ, you work primarily with the NativeScript team and the engineers to discuss what's going on with NativeScript, and bring NativeScript to the masses.

TT: Yeah, that's more or less right. I've been with Telerik for a bit over two years. And I've been involved with a few different Telerik products. So Kendo UI, the Telerik Platform. And I've been working with the NativeScript team for basically the greater part of this year.

EC: And NativeScript is a way of developing native applications using JavaScript as the primary development language. Correct?

TT: Yeah. I'd like to think of it basically as a way that you can build iOS and Android apps, and Windows Phone, Windows Universal apps, probably some time later this year or early next year. And it's a way of doing it, as you said, with JavaScript, but also some other technologies that developers, and particularly web developers with some languages and technology skill sets that these people may already have. So JavaScript, CSS, optionally typed script. There is a lightweight XML language that's very XAML like for building your actual UIs, NPM for package management. And even when it comes over to the native site, you can use things like CocoaPods for existing iOS frameworks, existing iOS dot framework files, Android frameworks or things like jars. So we try to bring in the most amount of skills that people may already have. And allow people to leverage as many existing tools as you can, all while building iOS and Android apps that a lot of people are looking to do today.

02:22 EC: So what's nice about this is we're building actual native applications from this product. We're not putting this in a web view like, let's say, Apache Cordova or something like that.

02:33 TT: Yes. So that the real single biggest differentiator between NativeScript and something like Cordova and some of these other technologies out there is that you are building a truly native app. And that means that you have a truly native user interface, which means the UI controls are gonna be the same thing that you would have available in iOS app that you built in Xcode or an Android app that you built in Visual Studio. And as such, you're basically gonna have native-like performance because you're using those native controls. Your app is gonna not only look like a native app, but also really perform like a native app as well.

03:12 EC: So I'm glad to have you on the show because I wanted to geek out to you what lies beneath the covers on NativeScript. Because we're talking about taking JavaScript, and turning it into an iOS application, which is generally written in something like Swift or Xcode. And we have Android that's typically Java and XML. So what happens that turns this JavaScript into a native application?

03:43 TT: Yeah. So I'm glad we're talking about this as well because it's pretty cool and the architecture can get pretty fun. And so I think the first thing to know about, basically, how the magic works or how this actually comes together is that NativeScript is actually packaging up a JavaScript virtual machine to actually run your code. Now if you're not familiar with what a JavaScript virtual machine is, it's basically just a piece of software that runs JavaScript. So Chrome has one, IE has one, Edge has one, all of the browsers have a JavaScript VM whose task is basically to take JavaScript code and run it, do what it needs to do.

04:25 TT: So the two that NativeScript uses is part of its development cycle or workflow are JavaScriptCore, which is the same JavaScript VM that appears in Safari in Macs, and that's used in iOS in NativeScript. And V8, which is using Google Chrome. It is also used by the Node JS project as well. V8 ends up getting used in a number of different things. So, really, NativeScript is reusing that JavaScript functionality, but just repurposing it to use it as part of a native app.

Now, what NativeScript actually does with this, knowing that is only half the battle, because then you have to tackle, well, how does NativeScript actually takes something that runs JavaScript to make that actually interact and do nativey the iOS and Android things. And that's where things get a little more complex. The metaphor I like to use to explain this is you can think of how a browser actually uses a JavaScript VM. So take Chrome and V8 as an example because I think it's one that people may be more familiar with. So if you think of how a browser uses a VM, well, JavaScript VM by itself, VM is typically implemented as just a whole bunch of C++ plus code, and the JavaScript VM knows JavaScripty things, so things that are literally in the AtmOScript specifications. So it knows what a var statement is, and what to do with it. It knows what a for loop is, and how to handle a while loop, etc. What a JavaScript VM doesn't know is how to do browsery things.

So it doesn't have any idea what a window object is or a document object or what an input is, a text area, things like that. So the browser and Chrome in our example here has to have some mechanism to tell the JavaScript VM, "Hey, this is what a window is and here are its properties and here are the actions I'd like to take when somebody does something with these." So window.resize, when the browser resizes the window I need to perform some actions and the browser has to have some way of implementing that or some way of communicating with this JavaScript VM back and forth.

And I know JS does something similar using the same V8 JavaScript engine and it needs to implement things that no JS needs to run; things like the require method which isn't a part of JavaScript proper, but Node actually injects that behavior for its own purposes. Node injects a number of other global things and a number of other things to make things happen as well. Well, NativeScript does something similar, the difference is NativeScript injects mobile things, so iOS and Android things. Now because these JavaScript VMs are used by browsers and are used all over the place, they tend to have a bunch of APIs to let you configure how these variables work, what sort of actions you can take when things happen, things like callbacks if you're familiar with how JavaScript works. So they're very configurable to sort of fit these different use cases and these different ways in which they're used. Again, they're just a bunch of C++ code. They have a whole bunch of public APIs, if you do some Googling you can find them, they're extremely configurable. So does that make sense so far, Ed?

07:49 EC: Yeah, so we have something like this in the .NET framework. It's called the common language runtime and then I believe Java as well has a similar type of intermediate layer, a virtual layer that things run through.

08:08 TT: Yeah, I did some time as a Java developer and there's sort of like the JDK or I might be thinking of the incorrect term, but you're right, there's something…

08:19 EC: JRE?

08:20 TT: Yeah JRE, oh man, I've been out of the Java world too long which…

08:24 EC: Java runtime environment?

08:25 TT: Yeah. I'd been out of Java too long which may or may not be a good thing, but yes, there's some sort of common runtime language that exists in JavaScript as well. The next sort of fun part is, okay, so NativeScript has this JavaScript VM, how does it actually do things? Well, what NativeScript does is it actually injects into the JavaScript VM, really the entirety of Android and iOS, so depending on whether you are building an Android app or an iOS app, it'll inject basically every Android and iOS API into that respective VM. So what that means is that on a NativeScript Android app you can, in JavaScript code, type newjava.io.File and NativeScript will actually take that line of code and allocate a Java file object and return it to you so that you can do something with it in JavaScript code.

So the next step in complexity of how that works it something that we at NativeScript call "metadata" and we have these processes that we call "metadata generators" and if you go to GitHub, everything with NativeScript, by the way, is open source so you can go to GitHub.com/NativeScript if you really want to geek out and sort of look how all these things work, but we have metadata generators, both for iOS and Android and what they do is basically they use these APIs, in Java they're called reflection APIs, I'm not sure what they're called in iOS and I know C# has something similar to that concept as well, but basically they say just use these APIs to build up a representation of everything Android and iOS, like what are all the name spaces available in Java? What are all the classes available? What public properties can I set on these things? Etcetera. So that you can build up, basically this complete mapping of the entire ecosystem.

So what these NativeScript repos do as they do that, they build up this representation and it's actually, we came up the mechanism to inject that into the JavaScript VM as bite code, so that it's essentially as efficient as it could possibly be and feed those things into the JavaScript VM so that Java becomes a global variable in a NativeScript Android app and Android becomes a global variable in a NativeScript Android app as well, so that when you're actually in you're NativeScript app at runtime, you can do things like call Java.io.F0ile and things will work. Now the other tricky part of this is, even if you can inject these APIs into the JavaScript VM, basically Java gets injected into V8 in the same way that the browser injects window into V8. The next portion of it is actually reacting to changes, like okay so a line of code actually runs that instantiates a java.io.File, what do you do there? And the answer is, again, in those C++ APIs that the JavaScript VMs have that we talked about earlier. So if you type new java.io.File, essentially JavaScript Core and V8 both have essentially callbacks for that situation. They'll say "Oh, a constructor was called, NativeScript or whatever it is that is invoking this, what would you like to do about that?"

So what NativeScript will do is say, "Oh, java.io.File. Let me consult that metadata that got injected into this app earlier and see what I need to do." And in this case, it'll say, "Oh, I need to actually go inject or instantiate a Java file object and return it to this person." Now, the one tricky aspect of this, especially on Java, is that the NativeScript runtime is written partially in C++ to actually be able to communicate with the JavaScript VM.

And there is one additional step to get over to Java code so your C++ code can actually talk to JavaScript code. There's this thing called the JNI, Java native interface, that's available. It's an android provided tool that basically lets you do just that. You could just basically go back and forth between the C and Java layers so that you can make that communication. And that's what NativeScript is actually going to use to do that instantiation.

13:11 EC: Before we scare too many people off talking about meta programming and basically building expression trees, these things are not something that the NativeScript user has to know. These are things that makes NativeScript work. So a NativeScript developer is going to be on an abstraction above all of this.

13:35 TT: Yes. And I think it's worth saying too that I can only talk about these things at a high level. I think especially because of the crazy number of ecosystems that are involved in this, we're talking about Android, iOS, C++ codes that these JavaScript VMs are written in. And the NativeScript team, the NativeScript team is actually broken into five separate teams and they're dedicated iOS and Android engineers that both handle these respected stacks just because of the complexity involved. I personally can only really speak of this at a high level.

I'm basically conveying the depth of understanding that I personally have because I can't go too much deeper than that just because there's a lot involved to make this happen. But from a user's perspective, in terms of when you're using NativeScript, you don't really have to know that any of this takes place. Your abstraction layer is you're dealing with JavaScript code and you just type newjava.io.File and you get a file back. You don't have to know that under the hood that code is being sent to a JavaScript VM, which is then being sent to NativeScript code that actually interprets that, and uses some bridge to get a Java code. You don't need to know any of that, you're just dealing in JavaScript and you go on your way.

14:58 EC: Yeah. I wanted to make sure we're being clear about that before we get too much further. I just wanted to make sure people's minds are in the right place. You're not gonna have to learn all of these things to use NativeScript, but we wanted to dive deep into what goes on behind the scenes and what gears are turning to make these things happen.

15:17 TT: Yeah. And the one extra thing I would mention too is that your abstraction, even though I'm saying new java.io.File, you actually wouldn't even have to type that because NativeScript then, in addition to these run times that actually make it just architecturally possible to write your abba JavaScript, NativeScript also has a series of modules, they're called the NativeScript core modules, that basically abstract away the common things that you need to do in mobile apps. So one of things would be creating files into APIs, JavaScript APIs, that keep you from having to know the platform specific stuff that you probably do not care to learn in any way, shape or form.

So if you needed to instantiate a file in NativeScript you would just require the file module and just say new file. So just a nice clean JavaScript API, that is. Now, under the hood NativeScript is implementing those API's using that JavaScript methodology. So if you looked in the NativeScript source code you'd find some file system.js or.android.js that would have the new java.io.File syntax but you as a user would just type new file in JavaScript and get your file and not really need to know that any of that is going out under the hood unless you wanted to.

16:44 EC: And we're nerds so we want to.

16:46 TT: Yes. Exactly.

16:48 EC: That's why we're listening to this show. All this stuff is very interesting 'cause we're taking a language that's not normally used for these types of things and turning it into an application that runs right on the hardware of these devices. And another thing we haven't even really gone into it yet, you said there were all of these people on the team that have these just immense knowledges of different parts of these different stacks. We haven't gotten into the user interface part of this, even.

17:25 TT: No, we haven't. So the next part of this would be, so we have the simple example, just new java.io.File, but obviously allocating a file is not the only thing you need to do to build a mobile app, there's a whole lot more to it and a whole lot more to NativeScript. But the interface, the way that user interfaces are actually implemented in NativeScript builds upon this same functionality. These things all tend to dog food each other. So these Native platforms all have API's for building things like buttons or layouts or any of the other number of things that you need to do to build an interface, and so what NativeScript does to implement UI elements is they actually, or the source code for NativeScript, you'll see that it just instantiates these UI components using the exact same methodology.

So take a button for instance, now you as a user, if you want to create a button in a NativeScript app, you would create a new XML file, UIs and NativeScript are defined in XML files, it's very XAML like if you've used XAML before. You go into an XML file, you'd type open bracket button close bracket and you would have a button on the screen. Very boring, but that's the simplest "Hello world" of NativeScript from a UI perspective.

Now under the hood, that XML element, that simple button you typed, is actually being implemented using that same JavaScript syntax that we talked about before for actually creating a new file. So if you looked in the NativeScript core modules, there'd be a UI folder, you'd find a button.android.js and a button.iOS.js and each would contain the native APIs needed to make that button happen. So in the Android file, you'd find some sort of extension of android.widget.button, which is the Android's native button component. You'd find APIs for doing things like setting the text of that button, setting various CSS properties, which we can go into in a minute, setting any of the other number of things, the buttony things that you would need to do in your app and then you would find the same sort of thing available in iOS as well. So the button component that iOS uses is just called a UI button.

But iOS has similar mechanisms, regardless which platform, you're gonna want to do things like set the text of a button, set what happens when you click the button, all of these things and NativeScript is abstracting that behind an API that you don't have to worry necessarily about what platform that your button is running on. The API in this case is in XML, it is just a button, but it dog foods off these same principals where you have this JavaScript file that is actually implementing the thing that is touching, or invoking those native APIs using that same runtime that we've talked about earlier.

20:26 EC: Now, you mentioned CSS, so this is a very foreign thing to native iOS and Android development. So how does CSS become part of this application development?

20:41 TT: Yep, so we can return to our simple examples. So let's say you've started a simple NativeScript app, and NativeScript is primarily built, when you're building a NativeScript app, you're writing XML for your UI, you're writing JavaScript for your application logic, and you're writing CSS. So let's say you had a mypage.XML that contains a simple button, that's the entirety of your app at the moment. You could also say, then create a mypage.css file, you could write some CSS, you would start by selecting the button, so you would just type button, you would type an open curly, close curly, that's just the syntax that CSS uses and then you could define a number of rules to actually style that button. So as a simple example, you could say, background-color: Red, in your CSS file, and then that would then change that UI button on iOS to have a background color of red. And that android.widget.button on Android to have a background color of red as well. So pretty cool.

Now the, since we're sort of, the theme of this show is actually to dive in, the way that works is, what NativeScript is going to do is it's going to, first of all, look for the existence of that CSS file just to see whether that file exists or not and then parse it. NativeScript actually uses in trying to use sort of existing things, we use existing CSS parsers, so the same type CSS parsers that frameworks on the web would use to get out from that source code that you wrote, get out some sort of tree of data that we can actually use from those to apply these CSS rules to the actual controls, and find that, "Oh, we have the user is trying to take a button and trying to change its background color to red."

Now, of course as you said earlier iOS has no concept to CSS, right? Just knowing in NativeScript code, just knowing that the user wants to change this background color to red, you can't directly feed that CSS selector to iOS because it would have no idea what to do with it, and the same thing on Android as well. So NativeScript has to have code to act as a translation layer, it has to say, "Oh, this person is trying to set the background color of this button, well that means in iOS that UI views have a background color property. So I can't feed the iOS CSS but I can find the appropriate controls that match this CSS selector and I can set their background color property to a UI color, a UI color that matches the value of the CSS rule that was applied to me." And take the same approach on Android as well, and I don't remember the Android specific syntax, but the idea is the same, to basically translate the CSS rules from CSS into a format and actual properties that the actual native platform, in this case iOS and Android, can understand.

23:53 EC: Yeah, to get a little more, to be a little more impressed by what this is doing, you can actually write CSS selectors for many different ways of selecting things. So you can still use the hash symbol and select something by ID and at the same time you can actually select things by their actual control type.

24:16 TT: Yep. You can select things by element name, so that would be the button example, the ID which you mentioned. You can also select things by class names. So you can apply class names to UI components exactly as you would on the web, except these are truly native controls and that you can then apply properties to. Now, there is an implication of this, the fact that there needs to be this translation means that not every property that you're used to applying on the web is going to work in a NativeScript context. Now, there's two reasons for that. There are some properties that just it's impossible to make work in an Android and iOS ecosystem. Just remembering that iOS and Android use completely different layout mechanisms than what is used on the web. And in some cases, float being one example that comes to mind. There's really no equivalent of floating in an iOS and Android ecosystem. So if we try to implement that, it would both be prohibitively difficult just from an implementation perspective and even if we did get it to work, it would likely have large performance repercussions.

I know we've said no to certain CSS properties before just because we could not implement it, really, in a way that didn't degrade performance. So the other big ones would then be layouts as well. So if you're used to using things like absolute positioning the web or difference performance constructs, those things aren't available to use from NativeScript's CSS abstraction. Instead, there's actually XML layout elements that you use to layout sort of your elements or your UI components on the screen.

26:02 EC: This is good information if you're looking into using NativeScript too, because knowing what limitations are there helps you build better applications. So knowing that these things exist, but there's certain things that don't quite translate well helps you plan for the road ahead.

26:23 TT: Yeah. And the common things in CSS that you'd want to do, if you think about what would be easy to translate, it's gonna be things like height, width, color, background color, different font families. The common things that you're gonna wanna do are there and they're gonna save you a lot of time over, if you've ever tried to do these things in a native app, you would know just how much of a pain it is to do. In Xcode, if you want to change just simple things like the color, you're in Xcode's GUI and you're playing around with things and it's just a complete nightmare. And just the ease of being able to apply those things via CSS, something that you probably at least have some familiarity with if you've ever dealt with the web is powerful. And the other thing to remember too, is that if you run into one of those limitations, let's say I actually personally ran into this the other day, I wanted to do strikeout text. Which on the web is, I believe, it's text decorations strike-through or strikeout or something like that, I can never remember the exact words, but that's something that NativeScript doesn't support today.

So I actually went ahead and created a GitHub issue to request that actually be implemented. But, in the meantime, NativeScript always has that option because you have all of Android and iOS there, you can always do a quick Google search of saying how do I do strikeout text in iOS and you'll find some Stack Overflow post that'll sort of show you how to do it in native code and you can do that in a NativeScript app. That's one of the real advantages of having all of iOS and all of Android implemented there, is that you can always go off the rails in NativeScript, or you can always go native might be the better way of saying it. Is that when you want to do something that NativeScript doesn't have in abstracted API for, you have the iOS and Android ones there. So even though it might be stepping out of your comfort zone some, you could still get the job done if you need to, if you run into one of those scenarios, where you absolutely need some feature that NativeScript hasn't implemented yet.

28:28 EC: Yeah. And going back to CSS real quick, I think one of the strong points of actually having CSS in something like this is, CSS gets a bad reputation online for web usage. I'm sure most people are familiar with the Family Guy meme where he's trying to adjust the blinds and they just engulf him and then there's the mug where it says CSS is awesome, and it's falling out of the box. In this instance, CSS is being used in its strong suit and those things that people knock it for on the web are generally because of layout issues, which were not really using the CSS for in this instance.

29:11 TT: Yup, correct.

29:13 EC: So we're getting the best of CSS and the things that we were calling limitations are actually stuff we probably don't wanna use anyway because it's flaky on the web.

29:23 TT: Yeah, and as someone… I've been doing web stuff for quite sometime and I always find it funny that the backlash against CSS, like you said, the memes and how it's become the butt of a lot of jokes, and having worked in a few different other ecosystems, CSS to me is far more elegant than any alternative I've ever used for styling any sort of software. I've done stuff in Flash before and I've built Java based UIs and the way of styling those things, is usually it makes CSS look absolutely phenomenal. [chuckle] I've yet to come across an alternative mechanism that makes dialing applications easier, so I'm happy that NativeScript lets you do the basic styling for your app, using it.

30:22 EC: Yeah, I'm happy not to see floats there, though.

30:25 TT: Yeah, yes.

30:28 EC: So when we do all of these things, are there any drawbacks of having this intermediate virtual environment?

30:37 TT: Yeah, so I think the big question that comes up all the time is performance. It's constantly the thing that people want to know. Now, performance is always a tricky question to answer, mostly because it always depends on what you're doing. If you're building a simple line of business app, it's gonna be a lot different than if you're looking to build the next great virtual reality 3D gaming thing that's pushing the limits of the device. But we can give some general guidelines. Now we talked about earlier how NativeScript takes this JavaScript runtime, and it has to do this communication, or what we call marshalling, from your JavaScript code into the native stack. And there is some cost to doing that, that's not necessarily a free translation that's occurring there. But it is fairly fast, it is something that we have performance tests that we run internally to benchmark it to make sure that the performance of that isn't getting crazy.

Now what we know is that instantiating these native objects from JavaScript, there is some cost of going back and forth across the bridge, but that you have to instantiate a large number of these things before the performance becomes a real issue. So what that means, is that for the vast majority of applications, so we're talking line of business apps, or simple apps where you're just driving an application off, say, some sort of restful API in that you're using it to drive an app. It is highly unlikely that you will be able to tell the difference between a NativeScript app and a truly native one, one that you had written in native code. I've yet to see an example of anyone building something where I saw some real noticeable performance delay in NativeScript. It probably won't be there.

However, if you are writing something that is really going to push the limits of the device, and I gave some examples earlier, some sort of higher end games or things that are really doing some sort of intensive processing of some sorts, like maybe you're doing some really hardcore video manipulation or something like that, then in that case, that's something you'd probably want to benchmark and see how NativeScript performs under those scenarios. But NativeScript I think was really driven for ease of use for the common apps that people tend to build, and those are things like, my company has an app, it has an existing API and they want to be on iOS and Android. Those things I think you'll find are not only extremely easy to build with NativeScript, but that you really won't find, in my opinion, unless you're doing something really out of the ordinary, you really won't find much of a performance impact of having this bridge from JavaScript to native code.

33:29 EC: So one thing we haven't touched on here, and a feature that I really love about working in NativeScript, is LiveSync.

33:39 TT: Yes.

33:39 EC: Would you be able to give us a little insight on LiveSync, what it is and how that operates?

33:44 TT: I'm glad you mentioned this, 'cause I forgot to talk about this earlier. So, another question we get is, why would you build an application architecture itself? Some of the benefit is obvious, and especially if you're coming from a web development perspective, being able to write in JavaScript rather than, say, Swift Objective-C, Java is certainly one benefit. But the other big one is that because JavaScript is an interpreted language, you can do some really cool things with it. So NativeScript, the JavaScript code that you write in the NativeScript app, it is interpreted at run time. So because of that architecture we talked about earlier, your JavaScript code isn't being transferred into Objective-C or Swift code. There's no transpolation happening, or compilation, or any sort of craziness.

The JavaScript VM, so JavaScriptCore V8, is actually reading and running your code at run time, and that makes a lot of cool things possible and one of those is LiveSync, which you mentioned. Now what LiveSync does is, the name implies this, is basically reload your app on the fly. So what that means is that when you're actually developing a NativeScript application, so you would do your build. The first time you run a NativeScript app, you do have to do a full build. You have to build in a .ipa executable for iOS, a .apk executable for Android. You would deploy that to either an Android emulator, iOS simulator or an actual physical device. But from that point, what you can do is, once you have the app running, there is no reason you can't hot reload that code on your app. Because really, if you think about it, all you have to do is, say, replace the existing JavaScript XML or CSS file with the new version, and just tell NativeScript to re-evaluate that file, use basically JavaScript's eval function, and you can sort of really instantly test changes that you have made to that file. So…

35:45 EC: So if you're, sorry to interrupt, but if you're a web developer and you're listening, this is live reload for native application development.

35:55 TT: Yep, it basically means, if you change a JavaScript XML or CSS file in NativeScript. The refresh cycle during development just feels a lot like you do when you're developing for a browser, the obvious difference is you're developing for a native app and the difference between say something like a phone gap development cycle or Cordova development cycle is that you're not doing this with code that's running in a that you're not doing this with code that's running in a browser. There no browser involved with NativeScript, you're doing this with completely native UI components and so it's really a best of both worlds scenario because you get the benefits of native, the performance, the UI components, the native UI, those things that you like. But that you also get the best things from the web. You get to use JavaScript, you get to use CSS, and you also get this fast development cycle that people love from the web that a lot of the native platforms… It's kind of a pain to build a native iOS app, a native Android app just because especially once you get into large applications, you have to go through a build cycle every time you change your app and that can get quite annoying.

37:07 EC: Yeah, every time I see LiveSync, it just impresses the hell out of me. That's one of my absolutely favorite features of this whole platform.

37:15 TT: Yep.

37:18 EC: So what is on the horizon for NativeScript? Now that we know what it is, know what's inside of it, although it's a huge stack of many things that we'd have to be an absolute genius to understand all of. What's coming up next? What are our engineers looking into? What's on the NativeScript roadmap?

37:40 TT: Yeah, so one thing we haven't talked about much is TypeScript support in NativeScript. Right now, NativeScript, I haven't mentioned this before, but the NativeScript, both the command line interface, and the NativeScript core module, the actual implementations of things like all those UI components we talked about earlier, but those things are all developed. The NativeScript team writes those all in TypeScript. So we're huge fans of TypeScript here and we also publish the TypeScript, I don't remember if it's declaration or definition files, but basically the files that give you the syntax checking that you need to develop your own NativeScript apps in TypeScript. So what that means is that you can take those files and have all the definitions, have all the static type compiling that you may be used to in a language like C-Sharp, like Java or like a lot of the native languages out there and why that's particularly cool for NativeScript is that we also publish the TypeScript declaration files for our iOS and Android implementations that we inject into the JavaScript VM.

So if you use those files, it means that you can go into your editor and type java.io.File, more specifically you type java.io, type a dot and have your editor be it Visual Studio, be it Visual Studio Code, supply and text. Microsoft has a lot of good implementations of TypeScript now, and get basically the auto complete, auto suggest, whatever you wanna call it for that code which is really pretty cool.

I think it's incredibly valuable in NativeScript apps, more so than a lot of web apps just because of the breadth of APIs that are available. It really gives you the same sort of development feel as if you were working in Xcode or Android studio. I mean say what you will about Xcode in iOS, but Xcode does make a really good editor. It's a really nice experience, it feels like it has some of the best of what Visual Studio offers, And by using TypeScript with NativeScript, you get a lot of those benefits in NativeScript apps. So the reason I'm talking about this for what's on the horizon is we're looking to really directly integrate TypeScript within the NativeScript CLI. If you wanna use TypeScript with NativeScript today, you could do so in an editor that directly supports TypeScript like Visual Studio, something that'll directly compile your TypeScript to JavaScript code. But we wanna bring those same advantages to people using TypeScript really anywhere, so we want that transpolation to be built directly into the CLI. So that's one of the things that we're looking on for the next release.

The other thing we want to bring transpolation support for is Babel and for the people that want to use ES6 code and those sort of the latest and greatest upcoming features from JavaScript directly in NativeScript apps. We want to bring that transpolation support into NativeScript as well. So that's one other thing that's on the horizon. I think the one other big feature that I'll also mention is the support that we upcoming for Angular 2. So one of the questions we get at NativeScript is can I use say library X within NativeScript? 'Cause there's a million JavaScript frameworks out there and the answer is typically yes. You can use most JavaScript modules, you can use most modules you get off NPM.

We have integrated NPM support to NativeScript. But one thing you cannot use is any JavaScript modules, any JavaScript framework that is tied to the DOM. That is tied to the browser because there is no DOM, there is no browser in NativeScript so those modules, those frameworks are just not going to work. And Angular 1 is was one of those frameworks because it is explicitly tied to the DOM. When you make changes to your app, it tries to apply things to things like divs and spans and things that just don't exist in NativeScript.

So Angular 1 is a framework that we just couldn't use. There's other web frameworks that fit that same bill, that just don't work in a native construct but Angular 2, one of the big pushes, they had at Google was to abstract angular away from the DOM. So that Angular could be used in contexts outside of that use case and one of those happens to be NativeScript. So we've been working with them to both make sure that that approach is actually working, that they're actually providing a way for these other frameworks that aren't tied to the DOM to tie into it and also to bring, add to the skill reuse that we offer in NativeScript. We've talked throughout this show how you can take skills that you may already have with JavaScript, CSS, NPM all these other things. But we thought "Well, why not extend that also to Angular as well." So the vision being that you'd be able to write Angular 2 components, that you'd be able to reuse with minimal impact, reuse to write both your web apps and also your native mobile apps as well.

So that's something that is actively going on. We have implementations that you can look at now if you go to GitHub.com/NativeScript. If you do a search for Angular, you'll find early versions of our plug-in. If you're really brave or you really wanna check it out, you can go in. It is functioning, but it's alpha code, so you're gonna get alpha code. You're gonna get code that may work but will likely bring you pain and sorrow if you try to do too much with. But what we're working on is basically both improving the functionality that's offered there, improving the docs, stabilizing that, get something that's ready for people to use and something that will recommend that people use for NativeScript development.

43:24 EC: Yeah, that'll be nice to have implemented where you can actually, like you said, share code on the web and in your application. But besides sharing code, it also gives you the ability to learn one domain-specific language. So you don't have to go relearn something developed native and then do a different type of development and learn a different set of APIs to develop for the web.

43:50 TT: Yeah, that's if you look at one thing today, we didn't talk about NativeScript's Data Binding implementation much, but NativeScript basically provides a XAML like two way Data Binding between Native controls and JavaScript code. But that is one thing, those APIs are things… It's somewhat XAML like, but there's… It's not quite like it and those are APIs that you will have to learn when you get into NativeScript. What Angular 2 gives us is way to lower that barrier like you said. There'd be one other thing that you could reuse that you wouldn't have to learn that's NativeScript specific.

44:28 EC: And speaking of UIs, we have a UI suite on the horizon as well. Telerik we're known for having beautiful UIs and that's one of our main strengths in the market so to speak.

44:44 TT: Yep, and so we… I don't think we've also mentioned but NativeScript… If you use NativeScript through the CLI, it is completely free. You can use it, you can build apps, you can put apps in the app store and you don't have to give us anything. And the NativeScript core modules, which are out on NPM, they'll get pre-installed whenever you create a new NativeScript app. Those are also free and you'll find dozens of UI modules to do all sorts of things in there. So what UI for NativeScript is, is really our premium controls. We're talking not simple things like buttons in here, but we're talking things like charts, and more robust list views, and grids and forms, and all these more powerful things that you might need to build bigger applications, especially if you're building something for a company or you're building something at a larger scale.

And we're calling that UI for NativeScript and we have a preview list of that out now. If you just Google search for UI for NativeScript, you can find it and you can try it out. It's currently a trial version so you can download it. You can let us know what you think. Eventually, and the reason this is on the road map, is eventually, we'll be offering it as sort of a dedicated product that you can go and get.

46:02 EC: So, where do we find out more about NativeScript? If we wanna learn more, get involved, check it out open source.

46:12 TT: Yep, yeah, so there are a couple different ways. NativeScript is on GitHub so if you go to GitHub.com/NativeScript, I've mentioned that a few times, but I'll mention it one more time. You can find all the repos involved with NativeScript. NativeScript is open source which means you're welcome to contribute to NativeScript directly if you're into that sort of thing. You could even contribute the docs are on NativeScript. You could follow along with NativeScript as it's being developed. You can offer tweaks to the docs. That's one way if you want to get involved with the product directly. The best place to keep track of sort of NativeScript news and the latest goings on in the NativeScript world is basically on Twitter. If you search for the @NativeScript handle on twitter.com/NativeScript, follow us. That's where you'll get sort of news as it happens, announcements and such. If you're looking to learn NativeScript. If you're interested and want to get started, the place I'd recommend for that is our new getting started guide. That'll take you probably something around an hour to complete, but it should give you a pretty good idea of how to build NativeScript apps. What's in NativeScript and how to use that to build your next project that you need.

47:32 EC: And I will admit I've done the getting started guide myself and I'll try not to say this with any bias. It's very well done. And TJ, you and Jen Looper, I think, worked on that and did a great job. I think people will enjoy grabbing that and actually being able to build an app in a short period of time with NativeScript.

47:55 TT: Cool, yeah, thanks, yeah, hopefully they will and as anything with NativeScript, the guide itself is also open sourced, it's on the NativeScript docs repo, so you're welcome to let us know if… Give us feedback on it, 'cause we're constantly looking to make these things better.

48:11 EC: And where can we find you, TJ?

48:13 TT: I am TJ Van Toll on most social networks, so I am @TJVanToll on Twitter, I'm TJ Van Toll on GitHub as well.

48:21 EC: And you can also find our blogs and things at developer.telerik.com and blogs.telerik.com. TJ, I appreciate you doing the show, some very cool stuff that you guys are working on with the NativeScript team.

48:34 TT: Yeah, no problem. Thanks for having me.

Subscribe via: RSS | iTunes | SoundCloud | Sitcher | YouTube

Comments