this is amazing! native script is just superior to react native in so many ways, always wanted to try but now that its paired with vue i may just jump head in!
from what i hear, native script is more native than react native, 100% cross platform from ios and android, and much more performant than React Native.
i can see this becoming a real contender very soon.
I wouldn’t say it’s more native, however, NativeScript gives you access to the entire API space of the target platform in JavaScript versus React Native which doesn’t. What this means is that if something doesn’t exist in NS land, you can open the Android or iOS docs and call the required api from JavaScript like so
var context = ...;
var button = new android.widget.Button(context);
button.setText("My Button");
To achieve the same in RN, you have to drop down into Java/Swift/Obj-C and link back to your JavaScript. Same result, different means.
i never tried native script so i can't tell you for sure, but i hear that it produces code that works 100% on ios and android, whereas with React Native, it is platform dependent so you still need to modify code here and there to make it work. i'm not sure about performance though, i get mixed signals about it.
Apps running inside a JS vm on iOS or Android are not "truly native". Misappropriating an existing term (native app) to include such a design is uninviting; not even necessary.
There are so many ways in which this is inferior to native code. And I say this as someone who works primarily with JavaScript.
To be fair, "native" in this sense is exposing platform native UI components and libraries, which gives apps a native look and feel because, well, they _are_ native. For most apps that's all you'll ever need, and the performance overheard of running JS is negligible. For any performance critical code, you can write them in the platforms native code and interface with them via JavaScript.
Unfortunately though, so many developers do not know how to write in the platforms preferred native language and you end up with components, like most of those listed on awesome-react-native[1], where they're entirely written in JS which:
* sometimes emulate the native look and feel (often poorly), not _are_ the look and feel, and,
* as a result, often perform super poorly compared to their native counterparts, and,
* if emulating the native look and feel, and not implementing their own design/UI (which most do), that look and feel can break between OS upgrades and feel out of place, and,
* often don't distinguish between platforms (i.e. the developer won't bother implementing the look and feel for Android, where the component is entirely compatible).
My experience with React Native was that it doesn't consistently use native UI components, it uses UIViews that people have cobbled together into their own replications of varying quality.
So if you want a big grid of items, you're not using a UICollectionView, you're reimplementing it yourself or finding someone else's attempt at that.
Maybe this is because a UICollectionView doesn't have an identical counterpart on Android so it's easier to just redo it from scratch? But I'd be surprised if the performance of these things is as good as the real native ones, even if they make it out of UIViews.
My other big complaint is that it doesn't help you with UI size classes. iOS apps change their layout depending on (generally) whether you're on an iPad (fullscreen / large split), or iPhone (and iPad small split, which is iPhone sized but much taller). The two weird exceptions being the iPad Pro having two full sized splits, and the Plus sized phones acting sort of iPad-like in landscape view.
Anyone have an example of a React Native app that follows those conventions correctly? Last I checked the Facebook app (which I assume is something of a canonical example) doesn't even support split screen, and iOS 9 came out in 2015.
This was a year or so ago that I was poking around at it, things may have improved since then?
What if the JavaScript is compiled to JVM opcodes?
I guess I don't see your point here.
A Java compiler takes Java code and compiles it to JVM opcodes.
Presumably this package (I haven't looked at the details, so could be wrong here) takes JavaScript code and compiles it to JVM opcodes.
I see no prima facie reason to assume that one would be more "performant" than the other. That's the whole idea behind things like LLVM and CLR, right?
It doesn’t compile it to JVM, it runs a JS engine, and then passes some calls into the native side over an asynchronous bridge, and the native code then builds native views at runtime. It’s a middle ground, and it’s super useful in some cases, and super dumb in others. It’s not a silver bullet, it doesn’t solve all the problems, but it has some good use cases.
> eh, is that really the line? Does it matter what language it's coded in?
Yes, it matters. Levels of indirection matter. Doubting performance or not doesn't change the definition of the term which is admittedly ambiguous.
There are two forms of "native" IMO now. There is "system native" which I define as AOT to processor instructions. VMs, even with JITs, don't count (yup, this includes Android's JVM). Then there is "platform native", which I define as AOT-compiled to platform-suggested instructions. This does include Android JVM bytecodes.
This falls under neither. It may not matter what language something is coded in depending upon your requirements, but we shouldn't keep ascribing even more meaning to the term native.
In my humble opinion, native means exactly that—identical and indistinguishable from a platform’s native code and full capabilities using its expected native language(s) because the byte code is identical. Native UI—the combined term—means using, not emulating, platform-native UI elements and APIs—it actually uses the platform-native byte code. Things that are indistinguishable in appearance do not qualify as native, unless one clearly distinguishes s/he means native look and feel.
When one says truly native, that is an even stronger claim that, in my opinion, directly communicates we are talking about byte code. On iOS, for example, native means Obj-C and Swift. When I read someone has created a framework/library that provides truly native apps using X and Y, my immediate expectation is we are talking about X and Y compiling down to platform-native byte code, with no VM, unless the platform itself is a VM. An example here is Elixir compiling down to truly native BEAM apps.
For the web, JS is truly native. There are a host of other non-JS technologies that compile down to truly native code for the web. I’ve yet to see any JS technologies that compile to truly native platform code for desktop and mobile (except mobile platforms which use web technologies as platform-native code)[0].
[0]: A quick perusal of NativeScript claims it does not use web views. If it actually lets you directly create and use a UITableView, UIButton, UIListView, and the rest, then perhaps it can qualify as native UI. But there’s still a bridge to cross from there to truly native app, and I’m unsure if it actually becomes 100% platform-native code without a JS VM involved the way, for iOS, Obj-C and Swift are.
Yeah, your native vs truly native distinction is just splitting hairs. Unless you're making a game or an otherwise CPU intensive app why does it matter whether you create your UIViews from ObjC or a JS VM?
Because one is native, while the other is not. I don’t think I’m splitting hairs, except in allowing a distinction between native vs native UI. Words have meaning. If a JS VM is being used on a platform for which JS is not a platform-native language and runs in a VM, it’s pretty much clear that’s not native. Calling it native—much less truly native—is making a false claim at worst, or muddying clarity of language and terminology at best. Perhaps creators of JS app technologies should stop claiming to be native, and none of us would ever have to go investigating the latest framework/library to find out if they mean what the rest of us mean when we say native.
This is similar to the long-running argument distinguishing “transpile” and “compile”. It’s a pointless disctintion in most contexts rife with technicalities and ad-hoc definitions. Irrespective of what you believe, I think you can see a substantial difference between say React Native and a Cordova app, right?
> ... I think you can see a substantial difference between say React Native and a Cordova app, right?
Absolutely.
I see a difference between this and discussion about transpiling vs compiling. One of the things I appreciate about transpiling is that it is a different word that does not attempt to take a word with established meaning. I obviously don’t think it’s a pointless distinction—but then I don’t find myself bothered by technicalities when it comes to technical things that need clear meanings.
I think the JS community has brought this problem upon itself by trying to lay claim to the word native when talking about web apps or apps built with web technologies for platforms that don’t rely on web stack as core/native tech. If they’d just choose/create a word that doesn’t already have established meaning on the target platform or technical space, I don’t think there’d be disagreement or confusion.
It’s the same thing when people claim Electron apps are native apps. We all know they aren’t really—they’re web apps wrapped up in a native window, relying on a full browser stack and JS VM to do what they do. I think it’s awesome people are working on things like Electron, because it’d be amazing to have an easy toolchain to create cross-platform native apps that is accessible to everyone. But they aren’t going to be native, and definitely can’t claim to be truly native until someone turns it into platform-native code that doesn’t need a VM.
Ultimately, we wouldn’t need to have this discussion if particular words loaded with extant meaning weren’t being misappropriated by the JS community. At least where mobile/desktop platforms are concerned, native means building with and using UI, threading, performance, libraries, APIs, and a whole host of things directly. I don’t look forward to the day where the JS community co-opts the term to the extent the platform-native tech has to start calling itself by some word other than native.
EDIT: Full disclosure—I like native technologies on various platforms, and don’t particularly find myself interested in building mobile/desktop apps in JS, HTML, and CSS.
Call me ignorant, but isn't Vue.js effectively what backbone and ember were trying to do all those years back? Feels like React sort of changed the paradigm for the better. ::shrug::
Weex is adopted well in the Chinese Community. From what I hear, its used in Alibaba (E Commerce site of China like Amazon) products. Its mature but you won't find well-written docs in English.
That seems like a very ambitious project, is there any company behind this? Otherwise I'm not sure it will work over the long term. Even React Native with Facebook (and Microsoft) behind it and years of development, it still feels like a beta product and many features are still missing. I wish an independent project could do better than that but it's unlikely.
Progress (https://www.progress.com/) is behind NativeScript, and officially supports the two usual NativeScript stacks (plain JavaScript/Typescript & Angular). NativeScript + Vue is a community driven project that seems to be on its way to also being officially supported by Progress.
I personally feel nothing is as close as React Native right now. Whether it be Flutter or NativeScript or Weex. It will still require some time to mature as much as React Native is today.
Looks pretty sweet, I've been wanting a React Native like stack but with Vue as I much prefer working in Vue over React personally. I'll definitely have to try this out.
Maybe they should build some sample apps before telling others to use the framework.