Rewrite NativeScript Properties for NS 8(?)

[NathanaelA]

For anyone who has looked at the Nativescript properties file here: https://github.com/NativeScript/NativeScript/blob/master/packages/core/ui/core/properties/index.ts

These are a colossal pain to even work with. They are a mix of closures captures, direct captures and some class/object properties, making following the code difficult in some cases and also make it impossible to update some values on the classes at runtime.

In addition each property also waste extra memory as frequently they not only assign a this.x = options.x but a const x = options.x and some of them even capture and use the options object, meaning the value(s) passed into the constructor is in memory three times for several of the property types.

In the past capture'd variables were faster than object properties. However, doing some tests recently in Chrome 88 it shows that
https://jsben.ch/rD6WO

Please note that all tests should be done in a Chromium type browser as v8 is the same engine that we use in the standard Android & iOS runtimes.

JSPerf shows that Capture is 7% slower than Properties, and Direct is 10% slower.

Block one is Class A extends Class B extends Class C, with Class A function accessing Class C properties (basically the worst case type scenario for accessing a property in a class).
Block two is a direct capture (not even any extends, so the fastest capture that can ever occur)
Block three is a indirect capture (again no extends, so again the fastest indirect capture that can occur)

The current "Properties" code base uses all three of these method, but almost all properties are used via direct or indirect captures, so based on the above benchmarks (which I've ran multiple times, with multiple benchmark sites) all come out pointing that v8 (which iOS and Android use) are much faster using class properties.

---

Proposal, I would like to volunteer to rewrite this chunk of code, to be more maintainable, modern and hopefully faster and less memory usage. It would not change any other part of the system as the properties would expose the same interface as the existing properties.

---

Any questions, suggestions or issues you see with this?

[farfromrefug]

@NathanaelA i totally agree we need to rewrite this!
A few questions:

• it means it would not work with iOS JSC? I am asking as i am not seeing V8 iOS as ready for production and it does not seem to be happening tomorrow. So i want to make sure it would stay compatible with non v8
• i have not completely understood what part you want to rewrite. Could you detail what you want to "rewrite" (like the Style object, on Property class?)