Nativescript: Build truly native apps with JavaScript
nativescript.org
nativescript.org
PS - I have no idea what I'm talking about.
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...
Secondly, native infers compiled to executable native code, not interpreted or JIT'd via an intermediary.
https://msdn.microsoft.com/en-us/library/dn584397(v=vs.110)....
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.
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)
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.
Agreed about the lack of native UI. Things like Ionic help, but it is not 100% perfect by any means.
Yes, I called language an interface. And most suck.
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?
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.
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'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.
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/
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.
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.
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 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?
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.
Btw, you may need an addition for Swift, I believe there is at least one cross platform tool for it now.
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).
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.
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.
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:
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.
but then it says (see Roadmap):
> Go-Live license. Developers will be able to use NativeScript framework in production applications.
What does that mean?
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.
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.