Nativescript: what I like about you, what I hate about you - tremho/thunderbolt-common GitHub Wiki

Pros and cons of Nativescript

One of the biggest problems I have with Nativescript is its propensity to screw me up.
Lots of time was spent during Sniff work I got stuck in my tracks because Nativescript would simply fail in some inexplicable way. rm -fr node_modules platforms hooks and retry was a mantra.

And they keep updating all the time. Which is good because they have to what with both mobile OS's updating all over the place, plus updates in Android Studio, Xcode, MacOS, and Windows to keep on top of, not to mention their own fast pace feature release schedule of two major drops per year.

But all that updating means more downtime to keep up with.

Philosophy

Nativescript is a technology that formed a framework and seems to have two different camps of thought.

The technology-based thinking is that Nativescript's key feature is its access to the Native APIs of the host platforms. And that is truly very cool, and it's mostly complete, with some issues. Of course, you can go full native too, so it's easy to kick cans down roads.

For example, the File API has the ability to read and write binary files, but it has no mechanism for containing or managing the binary data. You can read a binary file and hold onto that object (you can't really do anything with it, though because it is opaque binary trapped in an. undefined container) and then write this buffer out again to a new file, but you can't do anything with the data, or make your own binary data, etc. The best you can do is make a string and write it out and hope the string encoding doesn't mangle you along the way.

There is no way to represent a byte[] from Android Java in Javascript. An ArrayBuffer would be an excellent choice, but there is no adapter to go to and from this. Actually, there's some utility for coverting from a byte[] to an ArrayBuffer, but not back to a byte[]. The same is true on iOS, but here instead of byte[], the native primitive is NSData.

What I was able to do is to allocate a Java String by converting a JS string of '\0'.repeat(length) and then turning the Java string to a byte[]. I haven't broached the topic of NSData yet.

But solution aside, my point is this is a terrible gap, and it forces you to go native just to use the API for common functions. It would be much better and cleaner to have a built-in adapter for ArrayBuffer and just use that in the top-level APIs that work the same between platforms.

The second mode of thinking is that Nativescript API's allow you to write code that runs the same on both platforms. That bit is only partially true. Of course, there are behavioral differences between the platforms, but in my opinion one should be able to expose or subvert differences according to one's desire via the API, not having to be aware of arcane differences between how an API behaves on one platform vs. the other.

An implementation for a platform feature should go through whatever is necessary to make it look the way this sort of feature works not only on its own native platform, but should mimic the other platform behaviors as well (unless not possible due to fundamental hardware limitations). It's not okay to say 'there's no shadow here because the Mac never uses shadows in these cases'. Instead, draw the offing shadow (you know the Mac can draw a shadow, after all), so it looks the same on windows and Mac. Then, allow an option for shadow, and make the windows imlementation not display a shadow. That way, the code author has the say of whether or not there is a shadow, and that will be respected on both implementations.

Maybe better

With version 8.0.x I'm seeing much better general stability, although there are still a few stupid things in the new release

• Why does all the documentation suck?
• Why does tns still exist, and worse yet, do the wrong thing??

But I do like Nativescript, and since I keep coming back, I guess it's not all that bad.