Is it actually "native" if it is a JS interpreter passing calls into the runtime? Yes, it is native widgets and UI, but the "brains" of the operation are seemingly outside.

PS - I have no idea what I'm talking about.

I think what makes it "native" or not is how the app is rendered. You can basically take any web application and wrap it into an app, but it displays in a "web view" whereas a "native" app uses the built-in display components of the OS. For example, the little slider gray/green icon instead of radio buttons on iOS. Also, native apps have access to certain device APIs like the camera while non-native apps don't (at least I don't think so).

Cordova, which uses HTML in a WebView paradigm, lets you wrap native API's as plugins, so you can access them from JavaScript. You can access most (all?) native functionality from within JS using either Corfova-supplied or third party plugins. Honestly, Cordova + Ionic/Angular has been a great experience so far. Very few problems and a super quick time to market. I can't imagine iterating as quickly for two platforms at once (three if you care about Windows Mobile).

Yes, but you don't get a native UI with hybrid solutions like Cordova. Also, in order to use native APIs, you have to create special wrappers for them, whereas in NativeScript, it looks like you can call the APIs directly. (How this affects performance, I don't know.)

How does calling API's directly work with different platforms using different names, calling conventions, etc.? I like that with Cordova someone already did the work of normalizing the native calls.

Agreed about the lack of native UI. Things like Ionic help, but it is not 100% perfect by any means.

Haha, I wish more people were as honest as you are!

Native is mostly about widgets and UI -- which is what matters to the user.

Else even Objective-C apps, with the Obj-C messaging system are not native, e.g. they delegate a lot to C-based APIs...

    Else even Objective-C apps, with the Obj-C messaging 
    system are not native, e.g. they delegate a lot to 
    C-based APIs...

For starters, that doesn't make any sense. Note the `C` part of Objective-C.

Secondly, native infers compiled to executable native code, not interpreted or JIT'd via an intermediary.

>Secondly, native infers compiled to executable native code, not interpreted or JIT'd via an intermediary

And the GUI/Widgets part you get to use through JS here is just that (the native implementation from the OS GUI libs), which, as I said, is what users really care about when they ask for native apps.

See also the sibling comment about .NET apps and Windows.

> which, as I said, is what users really care about when they ask for native apps

That's true, but that's not what developers understand "native" to mean. Since most readers here are technical in some fashion, it makes more sense to use the more specific definition of the term (e.g. compiled, not jit'd, interpreted or otherwise managed)

Wouldn't that definition make Dalvik(/Java) applications on Android non-native?

Yes, that is why there is the NDK, aka Native Development Kit.

Java only became native code on Android with the ART bytecode to native compiler.

However, native can also mean, native to the platform. In this case, Java even with Dalvik is native to the Android platform.

I don't think anyone considers .NET apps non-native on Windows.

I'm pretty sure they're considered `managed`, not native. Otherwise, .NET Native wouldn't exist:

https://msdn.microsoft.com/en-us/library/dn584397(v=vs.110)....

Native means ur apps gets compiled to binary during compilation process, and not scripts being interpreted by a vm at runtime.

That's interpreted/JITed vs AOT compiled, not native vs non-native.

If is not 1's and 0's is not native for the CPU so why downplay the intelligent attempt to empower humans with easier scripted interfaces?

Yes, I called language an interface. And most suck.

How does Nativescript compare to Appcelerator Titanium or React Native? I know React Native hasn't been released, but they described their approach at the recent React Conf and was curious if it's similar.

I don't know about React native, but I used Titanium for a while and this looks very similar. The biggest conceptual difference from what I can see is that Nativescript allows you to make calls to any native API method. With Titanium you can only call those native APIs that have been wrapped.

With Titanium, I suppose you could say that the cross-platform wrapper API and the product are one in the same. Nativescript promotes their abstracted cross-platform API as a kinda optional add-on to the platform.

That's just my thoughts after looking at it for 5 minutes.

I just took a look at Titanium and holy moley their documentation was overwhelming. I haven't used a "native" hybrid app framework yet (only have experience with ionic), but NativeScript looks a bit more accessible to me than Titanium does.

I say the documentation is pretty ok once you get familiar with how the API is laid out. And for everything else they have the developer QA section, which is like a self-hosted stack-overflow.

I've been building a couple of simple apps on it the last few months, and it has been a pleasure.

I should be clear here -- I've been using Titanium, not Alloy.

A self hosted QA is pretty awesome. I think another thing that threw me off was how every section I clicked opened up a tab.

I'm still new to the hybrid app world and have only used ionic. I want to eventually try one of these "native" frameworks though.

I agree, Titanium classic is really great to work with once you get up and running. I tried Alloy but quickly realized it slows things down and makes it harder to develop.

So, lesson for me was use titanium classic and NOT Alloy.

Also, I would advise building your own small framework with views (things like title bars etc). Just makes it so much easier to make it look and work exactly how you want on iOS and Android.

They lost me with the switch to Alloy.

Exactly, I started on Alloy and quickly found that there was too much magic in going from templates to js code.

Once I took a step back to Titanium it all felt a lot more sane. Yes it is a little more verbose, but at least I can follow the data flow in code.

Appcelerator is going through some changes as of this week[1] which I hope will improve the documentation and ecosystem around the product.

[1] - http://techcrunch.com/2015/03/04/appcelerator-slashes-staff/

Also, their by far best evangelist, Kevin Whinnery, left for Twilio a year or two ago.

Titanium's Hyperloop/Ti.next tackles this problem, too bad the timeframe for release seems to always be 6 months from whenever you happen to check.

Not everyone is a fan of react.js, this is a nice alternative for people who want to use vanilla js.

Or Cordova/Ionic/PhoneGap?

Those are rendered with a webview. Nativescript is rendered with native components.

How do "native" hybrid apps such as, react native, titanium, etc. access the native components of the phone?

I have been developing a side project using ionic and have had a fairly positive experience so far, but from what I understand ionic/phonegap apps are just wrapped web browsers is that right?

It's pretty much identical at a high level: there is a proxy layer that is much like a message passing system. A component (web view, JS engine, etc.) says, "Take a photo with the camera" and the proxy layer calls the native code needed to take the photo with the camera.

The actual camera data is just abstract data, it doesn't care if it was generated from a JS call or from a native call.

PhoneGap and Cordova are, at the core, just a standard proxy layer and plugin API. The other "pure JS" solutions have their own custom layers.

That's pretty cool, thanks for the insight!

I tried out their little Tasks app on Android that is supposedly build with this. It's very unfinished. Slow too. I was kind of getting excited about this, but so far I'm not impressed.

I haven't tried NativeScript, but I am curious why it would be slow. Slow JavaScript engine on mobile platforms? Emulation library perhaps is not efficient?

I would appreciate some feedback. I just wrote a Firefox addon to work with a rich web app I am working on, and it would be nice to also provide "native" apps. BTW, most of my client code is Clojurescript; has anyone tried NativeScript with Clojurescript?

I have fairly extensive experience with Titanium, and my impression is that the UI can get very laggy if you are not very careful with the way you generate and manipulate the elements on the screen. Going "over the bridge" (parlance for communicating between the JS and native layers via the proxy) is quite expensive.

Agreed. Quite unimpressive. The transition between views was sluggish at best.

Extraordinarily slow, it took me about 30 seconds to load the app initially on the newest Moto X.

I like the idea, but I wonder if it will ever take off. So many "build in your preferred language, publish to some other" platforms have been released, it is hard to keep track.

I will admit that html+css is a relatively good (set of) language(s) to describe a UI, and JS is the way to tie the dynamism together and provide client-side logic. But is it better than just learning the native version for each platform?

I try to keep track of all those platforms, and you're right, it's hard. My findings are summarized at http://www.mobilechameleon.com/ (hosted for free by Weebly, a YC alum).

What a nice site. A small but useful curation presented in a very simple and clean way.

Btw, you may need an addition for Swift, I believe there is at least one cross platform tool for it now.

Good idea. I added a page at http://www.mobilechameleon.com/toolkits-using-swift.html

Holy shit I never realized how many hybrid app frameworks there are. Nice site by the way.

Well, it appears there are only 2 in the most interesting category: Titanium and NativeScript.

My sense is that it's surprising we still don't have a decent way to build native apps in JavaScript. Titanium looked like the answer but I have trouble following where they're going. NativeScript looks promising so far but cannot figure out the tie-in to Telerik.

Because many of us only touch it in the browser?

There is also Tabris.js

Oh, nice; I added it to my site.

I doubt this or other solutions built by a for-profit businesses in a seemingly open fashion will go far. Facebook is a different case and having some hands on experience with current players, believe them coming up with a better engineered solution.

As for the general concerns, i can add that it's not just 'i know JavaScript and don't want to learn anything else', but rather having some common ground while building products/services on the web. It's probably ok for a big company to support say 3 platforms (web, android & ios), but hardly an option for a small startup or a one man band. Now i'd be more than happy to just stick with web, or at least the solutions bringing the others closer to it (that's by the way where Titanium is pretty weak).

There are remarkably few where preferred_language=JavaScript. This, Titanium and perhaps React.

AWT sallies forth once again! :)

No surprise that their screenshot shows a calendar widget. Such things are very easy to abstract. We know from bitter experience in the desktop world that the pain starts in more complex scenarios than a few buttons and complex widgets that have thin interfaces.

In my opinion, with current architecture NativeScript won't be that performant.

They have very thin layer of native runtime, but majority of the UI core modules are kept in JavaScript/TypeScript. UI rendering will require too much of to-and-fro between V8 engine (or JavascriptCore) and NativeScript runtime.

Ideally they should have pushed much of the UI core modules in the runtime itself, along with JavaScript modules that have fewer calls to layout a view. Their current methodology would require too many proxy calls just to set layout properties.

I'm really happy to see NativeScript launch. I spent some time experimenting with it while it was still in beta. It's a rather young project, but I think it has a lot potential. Telerik got a whole lot of things right when they worked out the architecture.

Do they have a showcase where the same app is implemented on both iOS and Android?

I don't think so, but I'll second a request for that! I think it would be good to have on the Showcases page.

Here are some examples that have some UI widgets in common, like list elements/navigation, but they are clearly different apps so it's not blatantly obvious which differences are based only on the platform:

https://www.nativescript.org/showcases

That's how every windowing system should work.

Instead of deploying binaries, just fetch some script and execute it.

I dream of the day an OS will allow a scripting language to do the "easy" stuff, like buttons, interfaces, etc.

Of course you might still need to allow the installation of signed binaries for certain programs that need to make some low level stuff, like databases, 3D games.

I wonder if an OS which is very flexible and easy on the developer can win though.

The code examples don't look very pretty. My money's on React Native.

> NativeScript is licensed under the Apache 2.0 license.

but then it says (see Roadmap):

> Go-Live license. Developers will be able to use NativeScript framework in production applications.

What does that mean?

Really like to see how this compares to React Native

Yes, Facebook Groups for iOS is built in React Native. Unfortunately, it is quite slow.

For my startup, I think we'll use React/RN just to get something "native" on mobile, until we can do it proper with Swift/Java when we have time/devs.

Comparison, FB Groups app and the regular FB app. Latter way better.

Great, I didn't know about React Native and now I know. Great stuff, looks promising.

How to read from SQL Database ?

Cross-platform compatibility is a genuine problem and Nativescript attempts to solve it, just like Titanium, Ionic, and React JS (which is used in production for Facebook Groups).

Write/learn once deploy anywhere is valuable to a lot of people. If you don't like it that's fine because there's no singular best solution and the tradeoffs don't appeal to you. But they at least deserve your respect for trying.

Whoever eventually delivers a viable offering will clean up in the corporate apps market. Companies have lower expectations for internal apps and don't want to hire Java and Swift developers to create each.

Companies who have such low expectations already have alternatives in the form of a WebView with extra bells and whistles, like cordova or any of the numerous JS-based native-but-not-really frameworks and libraries. This is just one more among many, many similar alternatives.

NativeScript: The Framework for developers with low expectations!

Big corporations doing off shore development with low expectations are already use the web view based solutions.

But if your expectations are low enough you can just use an HTML-based framework like Cordova.