More NativeScript Questions Answered

Over the past few weeks, our team has been incredibly busy speaking at events and talking to developers around the world about NativeScript. We've received a lot of questions from developers about NativeScript and I felt it would be helpful to answer some of the common ones here.

What exactly is your JavaScript virtual machine written in? Specifically, the one you ship in the app package. Are there any differences between yours and V8/WebKit?

No. It's executed through the VMs on each platform (i.e. Android and iOS).

If we have a shell running NativeScript apps, why can we not get it to work on a browser emulator? Or, is this a case of the Telerik Platform just being behind?

The device simulators for the Screen Builder and AppBuilder web clients run within the browser. As such, they are limited to the capabilities of the sandboxed environment that the browser provides. When you use Screen Builder to build apps for NativeScript, we generate an approximation of the native interface through Kendo UI. Our intent is to provide an experience that mimics the native UI as closely as it can be represented on the web. Our goal is to enable you to build native apps using our tools that will take advantage of the native UI controls once running within native simulators or on devices.

If you're looking for to emulate your NativeScript app as a native application in the browser, check out Appetize. It's a little laggy but does a good job:

Great question. NativeScript 1.3 now supports plugins and dependencies via npm. This change frees up our tooling to run the “latest & greatest” of NativeScript. We plan to integrate this capability into AppBuilder by October. The end result means that our tooling will be inline with the NativeScript CLI, which is awesome (if I do say so myself).

How does NativeScript performance compare to other frameworks like Titanium and React Native? Do you have performance benchmarks published anywhere?

We have conducted a significant amount of testing and found that NativeScript performs very well compared to other frameworks. We plan to write much more about performance very soon. In the meantime, Mihail Slavchev has written a little bit about NativeScript performance in the following articles:

Why isn't the Side Drawer listed on the page, User Interface Widgets? When would it be available in the Telerik Platform?

The Side Drawer is part of Telerik UI for NativeScript and not part of the core UI widgets that ship with NativeScript. We have not announced a ship date for the Side Drawer with the Telerik Platform.

Are there any differences between NativeScript debugging on iOS versus Android? Do we have a debugging story with TypeScript?

Yes, there are a few differences. There are a lot of similarities as well. For example, you can debug apps through the CLI using the tns debug command. The runtimes for Android and iOS both provide diagnostic information via the Console and Trace modules. (For more information about tracing in NativeScript, check out Tracing NativeScript Applications.) That stated, debugging your apps through tools does differ in terms of capabilities. Please review the following articles for more information about your available debugging options:

This will provide a listing of available deployment targets, which will include the Android emulator in Visual Studio when it's running. From there, you run your NativeScript application through the following command:

$ tns run android --device <IP Address>:<Port>

You can also achieve the same result via LiveSync with tns livesync --watch.

Is there a performance hit if entire UI visual tree is constructed in code as opposed to in markup?

No. In fact, it's the opposite; there is a slight performance hit when constructing the UI from markup. However, it's negligible and - in most cases - a one-time cost. Either way, we support creating UIs with both code and markup so use whatever makes you happy.

How can we create reusable markup as templates for UI rendering?

The easiest way to do this is through an external fragment that you include in your page. Assume the following XML fragment in a file, main-view-layout.xml:

I can utilize this fragment as a template by including elsewhere (i.e. main-page.xml) as follows:

<Pagexmlns="http://www.nativescript.org/tns.xsd"xmlns:myFragment=".">

<myFragment:main-view-layout/>

</Page>

I like this approach a lot because you can separate your application's markup in reusable parts.

Is Windows 10 or Universal Windows Platform (UMP) support planned for NativeScript?

Yes. We have decided to skip Windows Phone 8/8.1 and focus our efforts on supporting Windows 10. We have not announced if/when this support will be ready. We do (however) have an open issue on GitHub for this that you can follow.

Will styling the UI through Less be an option in the future?

You can use Less now. However, you have to invoke the parser yourself. I would recommend using a tool like grunt for this. Currently, we're looking into supporting transpilers as part of the NativeScript CLI. A guiding principle of this work would be to make this support generic so to include any transpiler. This includes Less/Sass for CSS.

Enterprise

Stay connected with NativeScript

I agree to receive email communications from Progress Software or its Partners, containing information about Progress Software’s products. Consent may be withdrawn at any time.

We see that you have already chosen to receive marketing materials from us. If you wish to change this at any time you may do so by clicking here.

Thank you for your continued interest in Progress. Based on either your previous activity on our websites or our ongoing relationship, we will keep you updated on our products, solutions, services, company news and events. If you decide that you want to be removed from our mailing lists at any time, you can change your contact preferences by clicking here.