1

The most fundamental feature of Nativescript is that it converts different platforms' languages and API:s into Javascript (or another given single language e.g. C#), e.g. for iPhone it's the Objective C language and the iOS API:s, and for Android phones it's the Java language and the Android API:s.

Nativescript's "build-time reflection to Javascript proxy" is central here.

Reading through various "Nativescript vs. whatever" pages online, it's clear to me that the authors of those pages not really discuss that exact aspect, so those articles cannot be used to get an overview of that situation at all.

Therefore I want to ask you here:

What projects out there are there that provide that fundamental feature - a language+API binding from different smartphone (and possibly desktop) platforms, to Javascript (or another single language such as C#)?

ALL WebView/HTML rendered UI-based solutions are DISQUALIFIED here. Only native UI component solutions qualify. Do feel free to list the DISQUALIFIED solutions also, for everyone's reference, and mark out carefully that it is disqualified.

Hence I understand that Apache Cordova (https://cordova.apache.org/docs/en/latest/guide/overview/) is DISQUALIFIED.

I prefer Javascript, however let's enumerate all projects independent of which language is used at the unification layer, therefore Xamarin is qualified in this thread.

Also for those respective qualified solutions, are they really as holistic / complete as Nativescript is, in support, or how do they compare?

For the respective solution, do they also provide an runtime that integrates the underlying different UI API:s into one single coherent UI API that spans the multiple platforms? (For Xamarin I understand the answer to this question is NO - different code is needed for the different platforms.)

Also what are their primary difference in approach?

Some names I picked up that could be qualified, are "React Native", "Appcelerator Titanium", and "Electron" (https://electron.atom.io/).

This question is important for any app creator or startup, like me, that will rely on the solution a lot, and also hopefully contribute a lot, so it's a long term choice.

So, for each relevant solution I want: * NAME, URL: Its name, with URL * DISQUALIFIED?: Disqualified or not * AUTO-REFLECTION: Has automatic build-time reflection or not, any details * LANGUAGE: Unifying language (e.g. Javascript) * UNIFIED UI CODE: UI code same between platforms * PLATFORMS: Platforms supported * CODE TRANSFORMATIONS: Any notes about how the app sourcecode is managed, e.g. is it run as Javascript on the device, is any code transformation applied to the Javascript code (e.g. to parse out custom tags which are actually not in themselves valid Javascript), any kind of compilation applied on the Javascript, etc.

Please let me know.

This is extremely valuable for overview.

Thanks again to Telerik and the Nativescript team for making this fantastic tech!!

Mike
  • 53
  • 1
  • Same topic here (maybe the forum has some benefit as location to document the answer on): https://discourse.nativescript.org/t/which-technology-projects-like-nativescript-are-there-in-the-sense-a-native-platform-to-javascript-native-reflection-proxy-binding/2681 – Mike Sep 25 '17 at 15:28

1 Answers1

2

Mobile:

  • Cordova/PhoneGap/Ionic - https://cordova.apache.org/ - Disqualified - Unified UI - JS/HTML/CSS - Basically a wrapped webview with the ability to make native bindings that you can call from it. In once sense you access the native platform via plugins you create. In fact Microsoft has a project called Project Ace https://microsoft.github.io/ace/ which allows you access to the Native API inside your Cordova/Phonegap application. The application code is running inside a webview; and everything is thunked out to the OS and plugins that you build into your app. Despite the "marketing" speak (ionic is really bad about attempting to confuse the market here); Cordova/PhoneGap/Ionic is NOT truly a native application. It might use some native controls, but the engine is running in a webview.

  • Flutter - https://flutter.io/ - Disqualified - Unified UI - Dart - This is another interesting entry in the market; it is fully compiled code on all the platforms, so it is can be more performant than JS based engines. In addition it was written to be a very performant UI (separate thread for UI). To access the native api's on the platforms, you need to create plugins with the interface the compiled dart will be expecting and the iOS or Android API's.

  • Fuse - https://www.fusetools.com/ - Disqualified - Unified UI - JS - This is a interesting project; it actually compiles the markup into compiled code. I believe the JS engine is running on its own thread and the Fuse runtimes handle the GUI thread. To my knowledge all thunking/reflection has to be done via plugins.

  • NativeScript - https://www.nativescript.org - Qualified - Unified UI - JS/XML/CSS - Uses the same markup language for screen layout on both devices, has its own builtin system to marshal calls into the OS on both platforms. No extra plugins needed to access any API resource, everything on iOS and Android is accessible from plain JavaScript. Runs a Javascript engine on the Main thread of the Application, which can cause performance issues if you make the main thread busy. Because of its design it can re-use pretty much all Android AAR/JAR plugins and iOS cocoapod plugins unmodified, bringing a wealth of Native controls that you normally would only get to use if you were using ObjC/Swift/Java. It also is the only one that has zero day access to new API's because reflection is resolved at runtime.

  • React Native - http://www.reactnative.com/ - Disqualified - Unified UI - JS - It is also a JavaScript engine based system, but it has no built in reflection. Pretty much all access to the device API's needs to be ran through compiled plugins that give access to the native api's. One thing to note is that this JS engine runs on its own thread and the main thread is reserved for the GUI. This can make apps be more performant out of the box as anything blocking will occur on a separate thread, but makes GUI related plugins much harder to do.

  • Xamarin - https://www.xamarin.com/ - Qualified - ??? - C# - It has sorta built in reflection. When they release the new versions they basically create a thunking library with the current reflections. So when new versions of the OS comes out, they have to regenerate the C# thunkings before you can use it. Application is compiled on iOS, on Android I believe it is using Mono to run the app. So you cannot do certain things at runtime on iOS, like eval('console.log("hi"); /* even more JS code */') as you can on the JS based engines.

Desktop:

  • Electron - https://electron.atom.io/ - Unqualified - Unified UI - HTML/CSS/JS - This is a desktop based environment that merges node and chrome. So you can access any of the Node api (which is pretty large) and any of the chrome api and create an application. However, anything lower level you will need to create a plugin.

  • NW - https://nwjs.io/ - Unqualified - Unified UI - HTML/CSS/JS - Basically the same notes as Electron.

A couple notes:

  1. All JavaScript based engines DO NOT compile the code; they all run the JavaScript code at runtime.

  2. You can use Cordova/PhoneGap/ionic to share an app between desktop (using electron/nw), web and mobile fairly easily. But it is still a web app on all platforms.

  3. You can also use NativeScript with Angular to create app that shares probably 98% of its code base between a mobile, web, and desktop(electron/nw) application. Basically the only differences in some applications is just the screen layout as you need div/input tags for Web, and StackLayout/TextInput for the Mobile side. But the rest of the code and logic can be generic and access the elements as normal.

Nathanael
  • 5,369
  • 18
  • 23
  • Not sure Flutter should be disqualified. It doesn't use a Webview; it uses the Sky rendering engine. – Tobe Osakwe Oct 05 '17 at 02:11
  • 1
    Unless I misunderstood the question, disqualified is anything that doesn't have built in binding/reflection. To my knowledge there is only two platforms currently that have built in reflection (outside of using pure native java/objc/swift); and that is NativeScript and Xamarin. The rest you have to typically create a bridge in Java/ObjC to the respective language when you want to call any native api functions. However, with that said I believe Flutter has a future if Google continues working on it. – Nathanael Oct 05 '17 at 04:30