Monthly Archives: December 2019

NativeScript 6.3.0 Released

NativeScript 6.30 has a couple cool new things; but better yet it fixes several issues that can will affect your users if you are using 6.2.x lets look at them...

Some of the fixes include instability during android's switching of applications and resuming it. An issue with unloading views on Android. Out of memory situation on Android, and dialog fixes for iOS. In addition to several important build fixes that appear to solve a lot of build HMR related issues. Overall this release is worth upgrading to for just the bug fixes alone.

Core Modules

NativeScript is getting a new CSS parser; unfortunately it is not enabled by default in 6.3; but based on a PR should be enabled by default in 6.4. If you would like to enable this in your app to see how much faster it can parse your css; you do so by editing the packages.json file that ships with the application and adding a new key called "cssParser" and set it to "css-tree". The valid options are "rework" (current parser) and also "nativescript" which was the original css parser.

We had a couple awesome community PR's this month the first by Eduardo Speroni adds requestAnimationFrame as a supported function. And the second by Shailesh Lolam  add dialog sizing (width & height properties) to the modal dialogs on iOS.

And finally to round up our new core module features; Modal dialogs now have all the same CSS properties applied to them to allow better styling. In addition to the normal properties, a new .ns-modal class is applied.

CLI

The CLI team has fixed several outstanding bugs; including several webpack hmr issues. This also includes Node 13 and Android API 29 compatibility.

V8

I'm going to create this new v8 Section, because Android and soon iOS will both be using the same v8 engine. v8 was upgraded to v7.8 which adds:

  • Faster object destructuringconst {x, y} = object; This is now as fast as the normal ES5 const x = object.x, y = object.y;
  • Lazy source positioning; which can save 1 - 2.5% of memory; basically instead of storing all source code lines for when errors occur; it recalculates it when it needs it.
  • Faster RegEx
  • Several Wasm improvements

Android

The Android team kept busy this month;

  • Fixed some Kotlin issues
  • Android Signal 1 & 11 are now captured
  • Fixed a worker issue
  • Upgraded to V8 7.8 (See v8 section)

IOS

  • Upgraded to WebKit 13.2
  • Several metadata fixes
  • Fixed a worker issue
  • Fixed debugger not working issue
  • Fixed discardUncaughtJsExceptions issue

    A lot of changes to the new v8 version of the iOS runtime that is still in alpha testing to eventually replace the JSCore version... It appears the iOS v8 version is shaping up to be an awesome release.

Updating NativeScript

To get updated; you first need to do:
npm i -g nativescript@latest

To update a project; you need to do the following:

Latest Runtimes:
tns platform remove android && tns platform add android@latest
tns platform remove ios && tns platform add ios@latest

Latest Core modules:
npm r tns-core-modules --save
npm i tns-core-modules@latest --save

To install Webpack support:
npm i nativescript-dev-webpack@latest --save-dev

To install latest NativeScript Angular plugin
npm i nativescript-angular@latest --save
You will then need to install the actual angular bits; which as of this post v6 is currently supported.

The addition of t additional analytics/tracking to the CLI reminded me; you can disable it permanently; if you value your privacy by doing:
tns usage-reporting disable && tns error-reporting disable

ProPlugins - end of year update

We started the ProPlugins project pretty close to the launch of NS (NativeScript) 6.0. So it has only been active for about five months now. So how is it doing???

Well, first let cover the reason why we created it. This plays in strongly into how well ProPlugins is doing.

Why ProPlugins?

For most of us plugin developers who have worked in the NativeScript eco-system for a while. We all knew that NS 6.0 had a range of breaking changes; which meant it was the fifth set of breaking changes in less than 4 years for plugins. Each one of the NS major releases, had a range of breaking changes that required certain types of plugins to make fixes. Sometimes the changes were minor, other times the changes actually requires some major rewrites and/or major time debugging why something was no longer working properly. Of course the vast majority of this work was done by the original author; with very little or no help from the rest of the community. I recommend you read all three of my prior blog posts on the plugin costs and the plugin problem. And then why we believe ProPlugins is the solution. With those posts you will have a pretty good idea that the actual costs to an author, the community involvement, and how the open source seems pretty much unsustainable.

In addition to our experience, their are lots of blog posts by many other authors, on how for the most part, the majority of projects that are open source by independent developers has a serious funding and/or burnout issues. We have seen the exact same thing in the NativeScript plugin community way too many times. in fact, the other day I responded to a issue saying that I believe a specific plugin was still maintained as this author has been around for a while -- and then several people pointed me to the issue where the author has mentioned it is no longer maintained. Sadly another excellent plugin author appears to have left the community.

Community Involvement

When we FORKED all these plugins into ProPlugins, the original version was left to see how much the community would be actually willing to maintain them. My stance has been that I didn't believe the community would change any; but I have been 100% committed to allowing the community to prove me wrong and send in any PR's and I would publish the new version fairly quickly.

Sadly, my prior blogs posts on the problem, which tells the sad tale of how many PR's per plugin is received from the community before ProPlugins was created. The communities involvement still has not changed, and as such we have still only seen less than a handful of PR's for all 40 of the plugins we forked into ProPlugins. Meaning the vast majority of all these plugins probably don't work with NativeScript 6.x. This doesn't surprise me, since I had seen this lack of involvement for the last 4 years of plugin development...

The most interesting thing, is that this experiment really could have gone a couple ways. I could have been proven wrong and the community would have finally stepped up and worked on fixing all the plugins for NS 6 support. Or even the worst possible outcome, nobody could have joined, and also nobody did anything to fix any plugins. However, it seems the community has decided that joining ProPlugins as the best option to move forward. It eliminates them from having any additional time commitments, and helps us create sustainable source code.

So how has has ProPlugins done?

We grew to have 40 fully maintained plugins, which have had around 30 PR's for issues introduced in the NS 6.0 upgrade. We have done several PR's for issues people found in the last couple months to several of the plugins. We have also added several new features to multiple plugins. Finally, recently about 10 PR's for different plugins to fix the breaking change that was accidentally introduced in NS 6.2. So adding and maintenance of existing plugins seems to be off to a very successful start.

In addition, this new year we have several new plugins that we have plans to add. Even better, we have more authors lined up for joining the ProPlugins program. So by the end on 2020; we hope we will have around a hundred fully maintained top quality plugins in the program.

Despite the lack of any recent advertising and really my total lack of my focus on it for the last couple months; ProPlugins has each month done considerably better than the prior month. So our subscription revenue has been increasing faster than I had planned.

Since 80% of all revenue goes to the authors, the remainder goes to the actual expenses like paypal fees, advertising, servers, etc. We believe, the ProPlugins experiment has successfully started the process to having sustainable source code in our community, completely from the community. So a big congrats to the community for helping fund this!

We hope you all have a merry Christmas, and a happy New Year. We look forward to even more of you becoming part of the ProPlugins project and helping us fund sustainable open source for the NativeScript community.