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.
Yes, I called language an interface. And most suck.
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 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?
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.