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.
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.
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.
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?
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.
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.
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.
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.
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?
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?
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?
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.
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?
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.
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.
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: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.