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!

TJ works as a Developer Advocate for Progress, which is a software development company behind KendoUI, NativeScript, and few other tools.

NativeScript is completely free, completely open-source tool that lets you build iOS and Android native apps with Native user interfaces using JavaScript. It also provides built-in support for both TypeScript and Angular, as well. If you’re an Angular developer, it’s a tool that you can use to take Angular and build for Native iOS and Native Android.

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.

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.

Angular is an optional dependency. NativeScript, at its lowest level, it’s just a technology that’s allowing the communication between JavaScript and these Native objects. The reason why the team spends a lot of time working with Angular integrations is that the model that Angular uses happens to be a really good fit for NativeScript. Any JavaScript developer who doesn’t really like using frameworks at all, using these components and syntax that they’re not familiar with could make their learning curve a little bit heavy.

Over the last 6 months or a year, the team’s focus has been performance, tooling, and plug-ins.

In the last release, specifically, NativeScript 3.0 was shipped back in May. That release is really the combination of profiling over the NativeScript source-code based on how fast your apps start up, how you can render your UI, etc. There is a cost to working with NativeScript because we are letting you write your source code in JavaScript. The team’s effort has been in really optimizing how fast you can paint your UI’s, how fast you can transition from one page to the next, the startup time, etc. One of the performance penalties that NativeScript has is because you’re using JavaScript, there is one step that truly Native apps don’t have. Specifically, Angular is not necessarily known for being the world’s smallest JavaScript framework. But Angular is being known for being very tool able. So the team shipped a Webpack plug-in that helps you reduce the footprint of your app, which means faster start-up times when you’re using Angular with NativeScript.

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.

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.

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.

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.

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.

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.

The specific cost when it comes to start-up time is not getting JavaScript from the network. The cost is actually the registration of your JavaScript code with v8 or JavaScript core. It’s the same reason that there’s a cost for that in the browser if you feed Angular into v8. There’s a cost that it will take to be able to parse that thing and run with it.

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.

The team uses v8 on Android to run JavaScript. V8 has this feature called heap snapshots so you can pre-register some of your JavaScript codes directly in the heap memory of v8. Essentially, it’s a trick to shave-off some of those milliseconds when your app starts up.

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.

If you go to nativescript.org, there’s a Get Started button. There are 2 different tutorials you can go through to learn NativeScript. There’s one on Getting Started with NativeScript with straight up JavaScript if you’re the person who doesn’t like dependencies on framework completely.

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

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.

Special Guest: TJ VanToll.