NativeScript – a Technical Overview

nativescript_overview_header

I am really excited to be part of the engineering team behind Telerik’s new endeavor – NativeScript. It is something so big, challenging and inspiring for me that I can’t wait to share with you a brief overview from a more technical perspective. If you still haven’t read the the announcement, please do so before reading this post, just to ensure you have the overall picture.

So, what is NativeScript?

Well, it is not only a set of libraries but rather a runtime that enables you to call APIs in the Android and iOS (and Windows Universal in the near future) frameworks using JavaScript code. It is built upon several major parts including a JavaScript virtual machine to interpret and execute the JavaScript code as well as what we call “bridge” to translate the calls to the underlying platform-specific APIs. The “bridge” module itself includes a marshaling service that handles data transfer to/from JavaScript to/from native types as well as a set of bindings knowing how to project a certain JavaScript method to its corresponding native equivalent. The JavaScript Virtual Machines are Google’s V8 for Android and WebKit’s JavaScriptCore implementation distributed with iOS 7.0+.

Let’s consider the following code snippet:

var file = new java.io.File(path);

The actions that happen here are:

  • The JavaScript VM evaluates the code.
  • The Bindings will determine the corresponding native method to call.
  • The Marshaling service will convert the JavaScript String to a java.lang.String object.
  • The result of the function call will be a custom JavaScript Object serving as a proxy to the native java.io.File object created on the Android side. When a method is called on this proxy it is delegated to the underlying native object instance.

This mechanism enables you to build full-blown native applications using simple JavaScript code. Additionally, you have all the power, flexibility and extensibility of JavaScript to build your business (platform agnostic) logic – such as data models, data access, view models/controllers, etc. This business logic will be one and the same regardless of the targeted platform.

The following diagrams illustrate the execution flow in greater detail:

nativescript2

nativescript1

You can find more details about NativeScript for Android in this post.

How Do NativeScript Apps Differ from Hybrid Apps?

This is the immediate question that typically follows. The major differences between these two types of apps are the UI Stack and User Input.

Hybrid:

  • User Interfaces are created and styled through HTML and CSS. An instance of the platform-specific browser is embedded within the application and is used to visualize the HTML and CSS.
  • The Cordova (PhoneGap) plugins are used to provide access to some of the native APIs in the underlying platform.
  • User Input is handled by the embedded browser instance and delegated further as JavaScript events to the currently focused DOM element.

NativeScript:

  • User Interfaces are instances of the corresponding native widgets/visuals – e.g. android.widget.Button or UIKit.UIButton.
  • The NativeScript Runtime provides full access to the underlying native APIs such as Camera, Location, File System, etc.
  • User Input is handled by native handlers (delegates) declared in JavaScript – e.g. View.OnClickListener or UIControl.addTarget implementations.

I’m not suggesting one or the other approach is generally better. They serve different scenarios and solve different problems. We have compiled a list with frequently asked questions which can provide some additional information about what problems NativeScript solves.

Performance

The next question I typically receive is about the performance of NativeScript and how it compares to purely native applications implemented in Android or iOS. Well, every additional layer of abstraction comes at a price. The JavaScript code interpretation and data marshaling add their own cost. Our rough measurements show about 10% performance penalty versus the same functionality implemented in native code directly. Still, in most scenarios this 10% is hardly noticeable by the user. Additionally, we’re working on ideas for how the performance can be further optimized and some of these experiments may be included in future versions of the framework.

Modules and Require Support

As a complete Runtime, NativeScript supports JavaScript modules and the implementation follows the CommonJS specification. This feature allows only the JavaScript needed for the current state of the application to be loaded. Later on, as the user interacts with the application, various modules may be loaded if required. For example this very simple snippet shows how to create a stand-alone module, named “about” and representing a new Android Activity:

var activityBody = {
	onCreate: function (bundle) {
    		this.super.onCreate(bundle);
    	var relativeLayout = new android.widget.RelativeLayout(this);
    		this.setContentView(relativeLayout);
	}
};
 
exports.activity = com.tns.NativeScriptActivity.extends(activityBody);

The above module can be required as follows:

var activity = require("about").activity;

Built-in NativeScript Modules (NSM)

nativescript3

Accessing native APIs directly from JavaScript is cool but this means you should have a deep knowledge of the underlying Android and iOS APIs in order to know what to call and when. One of our major goals is to provide set of modules and APIs that provide platform-agnostic access to the underlying target platform. For example let’s consider downloading JSON from the internet – you will need some HTTP-access APIs and these APIs are different on each platform.  Our “http” module provides common APIs that you can use without caring about the native APIs:

var http = require("http");
http.getJSON("http://www.reddit.com/r/aww.json?limit=30")
	.then(function (result) {
    		// result is JSON Object
	});

The implementation that lies behind this function is different for each platform, but it is the module that takes care of the specific implementation. This way you can write code once and execute it on each of the supported platforms.

Here is a list of the currently available modules:

  • Application
    Provides an abstraction over the specific native Application objects and exposes common events for the application lifecycle.
  • Console
    Enables various output functions to the console of the development IDE. There is a console object available in the global context for easier access.
  • File System
    Provides access over the file system of the currently targeted platform.
  • Http
    Provides access to http web requests and exposes shortcut functions like getImage, getJSON, etc.
  • Image Source
    Provides an abstraction over the raw image data objects used by the native frameworks.
  • Local Settings
    Provides an abstraction over the shared preferences per application.
  • Location
    Provides an abstraction over the geo-location access APIs.
  • Timer
    Provides well-known JavaScript functions like setTimeout and setInterval. These function are available in the global context directly.

What comes next?

The currently available version is an early preview meant to validate with you – our users – the vision we have and get feedback on how to further shape it. We have numerous ideas in our heads about various features that will enable high productivity with less development hassle. Some of these ideas are:

  • A complete set of UI Stack modules (much like the Core ones), allowing for one codebase deployed to every platform.
  • XML-based UI declarations through code.
  • A visual designer, providing WYSIWYG experience for building UX.
  • A common styling mechanism.
  • The ability to use third-party native libraries.
  • See the roadmap for the complete list.

If we already have your attention, do not hesitate to request your access to these early bits and to share your feedback with us – we are truly hoping to receive as many of your thoughts as possible to ensure a product you will love.

Here are some resource that will help you get started with NativeScript today:

Getting Started

Documentation

Comments

  • Geoffrey Plitt

    Are there any example apps we can build and play with?

  • Pingback: Is NativeScript the future of cross-platform app development with JavaScript? | Super Dev Resources()

  • Valentin Stoychev

    Hey Geoffrey,
    there are still no examples of applications being built with NativeScript, due to the still very early stage of the framework, but we are working actively on that.
    If you want to get more information about NativeScript please drop me a line (valentin.stoychev@telerik.com).
    Best,
    Valio

  • Pingback: Apple's Biggest Announcement Yet Isn't About Phones Or Watches - Telerik Developer NetworkTelerik Developer Network()

  • Pingback: JavaScript for OS X Automation by Example -Telerik Developer Network()

  • Pingback: JavaScript’s Creep Towards “Write Once, Run Everywhere” | Voxxed()

  • Gavin Engel

    Any thoughts on EmberJs withing the NativeScript ecosystem?–Or perhaps is a heavy js UI framework not needed? Also, does NativeScript make many CSS/UI projects like Kendo, Ionic, Bootstrap Ratchet, etc somewhat unneccessary?

    • Matthew Blott

      My understanding is its use of Native UIs would obviate the need for a heavy JS UI framework.

  • Gavin Engel

    Any thoughts on EmberJs withing the NativeScript ecosystem?–Or perhaps is a heavy js UI framework not needed? Also, does NativeScript make many CSS/UI projects like Kendo, Ionic, Bootstrap Ratchet, etc somewhat unneccessary?

  • Pingback: Getting Started with NativeScript -Telerik Developer Network()

  • AZIZAZOOZ

    I Always say “Show Me”
    Show me what you can do first to convince me, build the App and submitted to the store and let people see that and Experience the UI look and Performance , use the Animation and Data Visualization And let’s see

  • Péter Kulik

    Will it be possible to run dynamically loaded script?
    So if the application download a scriptfile, can it load and run the script without restarting?

  • Katturaja Mookkan

    Is it able to run receiver activity like Is it possible to create BroadcastReceiver in NativeScript?

  • Katturaja Mookkan

    is it able to create android AppWidget using NativeScript?