NativeScript — a general overview and impressions
I would like to shed some light over a tool I’ve discovered a while ago. Ladies and gents, with a great pleasure, I present to you — NativeScript.
What’s the big deal about it?
We’ve had hybrid apps for years. You (the developer) write HTML/CSS garnished with some JS code, lying on top of a framework that deploys all of our resources on a device and voila — an app comes to life. In order for that to be possible, all user interactions passes through a WebView component, which in practice is the built in device browser. A widespread practice is to use Apache Cordova as a bridge between JS code, running in the “browser” and native device drivers.
AppBuilder, Intel XDK and Ionic may seem like a totally different things, but in reality under the hood all of them rely on DOM elements in the WebView to compose the UI and on Cordova for hardware access. That approach surely is productive, but it comes with a couple of nasty side effects. The end product still looks more like a site on a small screen than a mobile app. Ionic comes with a ton of pre-build elements that mimic a native look and feel, but there are still some subtle differences, obvious for a trained eye. The other major issue arises when things start to get non-trivial, for example if we want to stick a database in our app, or render some fancy UI transition. It is likely that we hit a performance boundary, thought there were some major improvements being made in that direction during the last year.
NativeScript approach places it on the other side of the spectrum, closer to React Native or Xamarin (thought C# is the language of choice there). It doesn’t use WebViews, so no DOM manipulations occur. It still uses JS, but in a totally different environment. All of the UI elements are described by XML views, which during the build process transforms into native UI objects. Also NativeScript is free and open-source, backed up by the company Telerik.
The way it works.
Both iOS and Android comes with JS engines (Nitro and V8 respectively) that execute JS code inside their build in browsers. These C++ programs can communicate with external C++ code (so called “hooks” in the case of V8). In practice, by adding functionalities to a JS engine we’re adding things to the JS language itself, which are not a part of the language specification. If you’ve used NodeJS you’re probably already familiar with that concept, because this is exactly the way it works. By using V8 “on steroids” node’s JS is able to work with the file system, intercept network requests, stream binary data etc. In that sense we can look at NativeScript as “NodeJS for mobile devices” that runs inside virtual machine (though that is a bit of oversimplification). Standard JS is packed up with objects that map native Java/Objective-C/Swift objects on the respective device. The end result is JS access to all native components. This includes UI elements (which we typically describe through XML in Android, but that turns into Java code after build). According to its creators, NativeScript code is around 10% slower in comparison with purely native code. Even if we chose to be skeptical about that data it still looks like a bloody good performance. You can find more on the subject here.
Impressions.
Starting with the good ones:
1. Documentation: If you’ve laid eyes on their “getting started” guide, you may have noticed it’s volume. The folks at Telerik made some effort in describing everything we need to know about their invention. That includes not only the api specifics, but some general overview articles as well.
2. Project structure: Files within a NativeScript projects are well organized. There is naming convention which helps CLI tools figuring out how to build them. As a bonus you can use TypeScript to keep your application code well organized and scalable as this is TypeScript’s main selling point.
3. Angular support: As the Angular framework gained traction it practically became the standard way of building NativeScript applications. It is possible of course to use something else, use just TypeScript or even a plain JavaScript. There is a data binding module with syntax similar to the one KnockoutJS uses to bind UI markup to data objects. I would recommend sticking to Angular/TypeScript stack, since most code samples you will find in the web are using it as well.
4. Debugging: Debugger is similar to the one NodeJS uses. It comes with auto-reload option so we don’t have to rebuild the app often. It can also easily be integrated with a text editor like Visual Studio Code.
5. Native libraries support: Since we gain access to all native features, that also includes all external libraries that we choose to build the project with.
Not so good ones:
1. You may have to write a lot of native access code on your own. There are plugins for the most common tasks, but it may take a while to get used to calling native Java/Objective C APIs with a JS syntax. To speed things up you can include whatever npm module you like into the project, as long as it doesn’t require NodeJS specific stuff inside. That shortens the list quite a bit, but there are some commonly used modules that will work.
2. Learning curve: It takes a while to get used to all specifics a developer have to keep in mind. Still if you’re proficient with JS you should be able to reach productive level quickly.
3. Layout debugging: NativeScript uses a subset of CSS to style its XML views, which is cool. As a web developer, I’ve always had troubles remembering Android’s styling/positioning attributes. The bad thing is that I haven’t found a place where I can “inspect” my views and disect my layout. It’s not a big deal to do that by eye, since live reloading works well, but I guess it could be intimidating in a more complex layouts. There is a discussion that addresses that problem, though.
This summarizes my thoughts, based on using the platform for a couple of small scale projects. You can check out these example apps to get a feeling of what else can be done, using NativeScript.
In general, I’m excited to see where the future of hybrid app development is going, especially now when Progressive Web Apps started to appear on stage too.
