AiA 148: What’s New in NativeScript with TJ VanToll
On today’s episode of Adventures in Angular, we have panelists Alyssa Nicoll, Ward Bell, and Charles Max Wood. We have a special guest, TJ VanToll of Progress. If you want to stay current with NativeScript, tune in!
[00:01:55] – Introduction to TJ VanToll
TJ works as a Developer Advocate for Progress, which is a software development company behind KendoUI, NativeScript, and few other tools.
[00:02:20] – NativeScript
NativeScript uses Native UI components so they’re not using web view, the DOM, HTML, etc. For people that are coming from an Angular background, your apps look like Native apps. They’re using the same building blocks that you’d use if you’re building your app straight up in Xcode or Android Studio. You’re still building your apps the same way, the same file and folder structure, routing, etc. But the real learning curve that it takes to build NativeScript apps is that you have to use their user interface components to build your apps.
[00:05:35] – Template syntax
If you’re building a fairly complex Angular app, when you have all custom components, it’s going to look exactly like a NativeScript app. It’s basically using a suite of custom Angular components vs. using divs and spans as you’re building blocks.
[00:08:05] – What’s new in NativeScript
Over the last 6 months or a year, the team’s focus has been performance, tooling, and plug-ins.
The other thing that’s related to tooling with NativeScript is the command line interface. You build NativeScript apps with the command line interface. The team is working on adding some more visual tooling, more like a companion to the CLI. There are problems that visual tooling can solve like how do you build your icons? How do you deal with splash screens? How do you deal with some of these Native configuration files? There is a thing called NativeScript Sidekick that can help you with some of these tasks. There’s an early beta out now.
The team purposely try to keep NativeScript core light, trying to keep our footprint small. TJ encourages developers, on your own team, and the NativeScript community to do that to your plugins because the NativeScript plug-in ecosystem explodes over the last few months. There are somewhere over 500 plug-ins. Their new plug-ins market place is plugins.nativescript.org/ that shipped several months ago. Now, they’re trying to work to add some consistencies to the plug-ins and adding some documentation around as well.
[00:13:25] – NativeScript 3.0 upgrade and compatibility with NativeScript 2.0
It’s like Angular 2.0 to Angular 4.0 in a sense that there are few breaking changes but for most apps, it’s going to be fairly transparent or fairly trivial to update. It had some breaking changes with NativeScript plug-ins and one of the main reasons that they bumped the version number up is part of that performance changes to specifically render your interface faster. They also have to change their layout mechanism and some of the API with the NativeScript visual tree. Those are things that are unlikely to hit your common app because you’re probably just coding using their Angular components, in which case, you don’t necessarily need to know what’s going on under the hood. The team also worked with the plug-in authors of the top 30 or 40 most downloaded plugins out there to make sure that they were absolutely ready to go for the launch date for 3.0.
If you are getting trouble with the upgrade, you can reach out on their forums. They’ve been trying to tackle these issues when they come up.
[00:15:30] – Communication, upgrade, breaking things, and bugs
Progress, as a company, haven’t done project quite like NativeScript before. It’s a project that’s completely open-source and completely free. They want to give people some freedom to of experiment and build their own things. But they try to be as transparent as possible on what we’re trying to do and reach out for feedback.
They have a NativeScript Slack channel, which has a lot of people in there. They’re the first point of contact when making changes. And for the actual upgrade process, they try to actually put a good effort to get plug-ins where people have put on a considerable amount of effort into them.
[00:17:35] – NativeScript 4.0
If you’re a Visual Studio Code user, you can now just directly do this step debugging directly within the debug tab in VS Code for your completely Native iOS and Android apps. The team also launched support for the Chrome developer tools for NativeScript but they’re only available at a very limited capacity right now. Right now, in the Chrome dev tools, the console works and you can see network request but it’s not the full experience that you’d expect if you’re using those tools for web apps.
One of the big pinpoints when it comes to learning NativeScript is learning how to build a visual tree with NativeScript. You can mess with CSS in your web apps, you can play around with layouts, play around with colors, etc. That’s possible to break that to NativeScript as well.
The other big thing is again related to performance. We’ve got a lot of efforts going on at the moment, specifically, around start-up time. I mentioned we shipped a lot of performance-related things for NativeScript 3.0 but most of those were focused on the runtime experience – how fast we can paint your UI, how fast we can paint more complex Native user interfaces. We’re not turning our attention more to just how fast we can start-up your app and what sort of things we can do to optimize that and bring that number down as much as possible. A lot of that involves how can we fight with web configuration files to get exactly what we want, what are the best ways to reduce the number of files we’re using, use whatever we can to reduce that bundle size.
The last that’s related to toolings is some of the visual tooling that we have. They think they can bring some fairly powerful behavior to NativeScript developers. In the past progress, they’ve had some premium tools for working with mobile apps that let you do things like build apps in the cloud. Say, you are a Windows developer and you want to build iOS apps, we have some premium tooling that could do that today. We think we’re going to be able to bring that to the open-source version of NativeScript, sort of make that work with directly within the NativeScript CLI.
[00:21:15] – Store on distribution of apps
With NativeScript, things are going to work exactly the same as if you’re building things from the ground up with Xcode or Android Studio. NativeScript CLI spits out the Native app package – that’s .apk file for Android and .ipa file for iOS. You just head out to the Native stores and actually register your apps and use those stores as the distribution model to get your app out to your users.
There are certain people, especially companies, that don’t need to distribute their apps publicly. Think an app that you need your internal people to have, maybe they’re sales rep, maybe they’re doing an inventory job. In Progress, they sell some of the tools that you can use to distribute your apps locally to users. Because it’s generating those exact same Native binaries, once you have that, you can use any iOS or Android distribution model that you want to use.
[00:22:30] – Start-up performance
One of the big performance advantages that Native apps have is you don’t necessarily have to deal with a network. In terms of media files, a web app might need to worry about your initial load of image assets or video assets. But with Native apps, you have the ability to package that in the file.
[00:25:30] – Lower cost for low-powered devices
TJ has zero concerns about NativeScript start-up performance on a high-end iPhone7. Startup time is like a millisecond. It’s not something that a person’s going to care about on a typical Native app. The bigger cost is on Android. It’s not because Android is necessarily slower. It’s because it has a wider range of performance characteristics from Google Pixel to some crappy Android 4.2 device that is still on the market.
[00:27:10] – Service workers
In NativeScript, there’s no service worker. You’re just using NativeScript API’s, which are abstracting away completely Native iOS or Android API. All of the things that a service worker does, you can accomplish in NativeScript. You can run in the background. You can get a user’s location in the background. You can send push notifications in the background. Anything that an app on your phone can do today that you’ve seen is possible to do on NativeScript apps. One of the reasons to build on NativeScript is your app can send push notifications when it is offline in iOS. It’s something that you can’t do on the web today.
[00:29:05] – Getting started with NativeScript
And then, if you want to learn how to use Angular to build Native apps, there’s the other tutorial on NativeScript that’s on Angular.
Also, community members just launch nativescripting.com, which is a companion to those tutorials but it’s the video-version of them
[00:30:00] – Testing
Unit testing on NativeScript is built directly into the NativeScript CLI. You can use any of the normal unit testing libraries that you might think of using – Mocha, Chai, Jasmine. For CI, there is NativeScript Travis. The team has articles and information on how you can build NativeScript on an automated way.
And because NativeScript is generating Native iOS and Android apps, there are a lot of tools out there that lets you automate starting up and running application if you want a functional test. They start your apps, click the buttons, and make sure those behaviors still work. Internally, the team use a tool called Appian, which lets you automate our iOS and Android apps.
Charles Max Wood