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?
The Android runtime for NativeScript is written in C++. Check out On NativeScript for Android for an overview of its architecture. The iOS runtime for NativeScript is written in C++. For more information about NativeScript - including information about both runtimes - make sure to check out the article, NativeScript - A Technical Overview.
What's the NativeScript companion app written in? How is the shell running a truly native app?
The NativeScript companion app for iOS is written in Objective-C. The NativeScript companion app for Android is written in Java. In both cases, the companion app hosts the app package when it's deployed to the device.
Does NativeScript compile my JavaScript code prior to deployment?
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:
Moving forward, how far will the Telerik Platform tooling for NativeScript lag behind the command-line interface (CLI)?
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:
How can I use a native library with a NativeScript app?
You can use a native library through the plugin command of the NativeScript CLI:
$ tns plugin add <Plugin>
It's worth mentioning that CocoaPods is supported in NativeScript. We have an article entitled, Using CocoaPods that walks you through the process of using them by specifying a Podfile to integrate as part of the CLI. For Android, you can integrate JAR libraries to your NativeScript application via the CLI.
Finally, I should mention that we plan to provide an ability for you to add native libraries through our soon-to-be-released verified plugins marketplace for NativeScript. This site enables you to add libraries quickly and easily and will provide supporting documentation and screenshots. For more information, check out Kiril Stanoev's blog post on the NativeScript verified plugins marketplace.
We have CocoaPods and JAR integration for corresponding platforms, but do these work cross-platform in NativeScript?
No. These are technologies to integrate native libraries with Android and iOS. As such, they only integrate with their corresponding platforms.
Is there any guidance on making GenyMotion or the Visual Studio emulator for Android work with NativeScript projects?
The NativeScript CLI supports Genymotion:
$ tns emulate android --geny <GenyName>
Please note that there are prerequisities you need to meet for this to work.
The NativeScript CLI works with the Visual Studio emulator for Android. Once the emulator is running, execute the following command:
$ tns device
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.
When will we have a complete LiveSync story for NativeScript?
Support for LiveSync shipped in NativeScript 1.2. We're looking to improve the experience for future releases. Currently, there are a few improvements are being discussed for the NativeScript 1.4 timeframe.
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:
<StackLayout xmlns="http://schemas.nativescript.org/tns.xsd">
<Label text="Hello, NativeScript!" />
</StackLayout>
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.