[META] Upgrading JSC

[kelset]

The purpose of this issue is to create a "single point of truth" regarding the efforts related to upgrading the JSC used by the react-native repo/project, in order to coordinate and recap all the efforts connected to this subject.

Foreword

The JavaScriptCore (JSC), basically, allows Android developers to use JavaScript natively in their apps - you can read here for more details about how react native uses engines.

Currently, react-native bundles in the Android app android-jsc, which is outdated and relies on old native tooling (ex. NDK v10).

Why

Upgrading the JSC would improve greatly performances for react-native apps running on Android, and allow support for x64 builds on Android apps.

Which links back this to the main "Roadmap of future Android(s)" issue #19297 - quote:

In anticipation of future Android devices that support 64-bit code only, the Play Console will require that new apps and app updates with native libraries provide 64-bit versions in addition to their 32-bit versions. This can be within a single APK or as one of the multiple APKs published.

Related

PRs

Currently there are two approaches possible, keep relying on the android-jsc bundled but changing some other configs:

• [WIP] Android 64-bit [WIP] Android 64-bit #17640

• add arm64 and x86_64 support add x86_64 arm64-v8a support. Fixes #2814 #18754

Which seems to not be the way to go, given that internally FB doesn't use it.

The alternative is to move to the JSC fork maintained by some important players in the core & community:

• Build 64bit binaries for Android Build 64bit binaries for Android #19536

Issues

• React Native for Android is incompatible with 3rd-party 64-bit libraries Support third-party 64-bit libraries on Android #2814

• [...Array(5).keys()] not working in Android [...Array(5).keys()] not working in Android #18426

• React Native apps fail to build since NDK update to r17 (due to removed support for ARMv5/armeabi) React Native apps fail to build since NDK update to r17 (due to removed support for ARMv5/armeabi) #19321

• potentially (as @kmagiera wrote in core), this unfortunately would bring some significant footprint penalty: JSC built with intl enabled takes roughly 5M more than without it. This needs to be multiplied by the number of CPU archs included (e.g. x86, armv7, arm64, x86_64), which leads to an "Hello World" base app to ~40MBs - unless split apk is enabled. But this it potentially "automatically" fixed by Google via their new Android App Bundle feature.

---

Again, this issue is for discussing and keeping everyone updated with decisions around this subject (based on discussions happened with the core team and open issues in the repo). Please avoid going OT.

[newyankeecodeshop]

Great job creating a centralized issue for this @kelset .
The question of whether to include Intl support is a good one. The JavaScriptCore on iOS 10.0+ has Intl support, so it would be good for consistency to have the Android one include it as well. However I can see how the increase in the binary size makes that problematic.

[LegNeato]

I believe you are mistaken...the "FB doesn't use it internally" appears to be referring to the updated SoftwareMansion JSC. That is, FB doesn't want to push an updated JSC to open source that they don't use internally, and the one they use internally is android-jsc. At least, that's how I read it.

Re: newer JavaScriptCore, I would imagine it is basically a non-starter to update JSC past the version shipped by the RN minimum supported iOS version...otherwise one could use JS features on Android that don't work on some subset of iOS devices and cause all sorts of annoying, hard to debug issues.

[LegNeato]

FWIW, I have patches out for both the two issues in Buck blocking RN:

For "React Native for Android is incompatible with 3rd-party 64-bit libraries": facebook/buck#1889
For "React Native apps fail to build since NDK update to r17 ": facebook/buck#1894

[gengjiawen]

I prefer #19536. Also with this I think we can reconfig babel to generate modern js. @rafeca

[gengjiawen]

For app bundle size, x86 and x86_64 should not bundled to the apk when you push the apk to market. Because real phone are using arm cpu.

[hey99xx]

@gengjiawen You can find X86 devices out in the market but they're so much rarer, especially in modern Android versions. It's mostly ignorable, my company only uses it for emulator builds.

[gengjiawen]

Yes, ignorable is the precise desription.

[hramos]

@LegNeato we're not using either JSC at Facebook, therefore there's no reason to force OSS to use android-jsc and we're happy to help unblock folks here.

[LegNeato]

Good to know...but, it would be weird if the JSC of react native was newer than the minimum iOS version's JSC, right? Then you would have Android and modern iOS working, and older iOS devices degrading in quality and compatibility. But perhaps that's ok?

[hey99xx]

we're not using either JSC at Facebook

Wait, what are you guys using as the alternative then?

[hramos]

@hey99xx I can't answer that just yet, but hopefully soon we can share more information. Let's keep this issue scoped to what needs to be done to allow open source to use an arbitrary JSC.

[vovkasm]

@LegNeato

Then you would have Android and modern iOS working, and older iOS devices degrading in quality and compatibility.

It is more or less already the case. Many devs start coding for ios and later builds for android. So short example: we started to use mobx 5, it requires native Proxy support. All worked good until we run our app on ios 9 (iPhone 4s) and bum!... we just discovered that ios 9 JSC too old for Proxy support and this can't be polifilled. For Android we know that we can bundle our own fresh enough JSC. But for ios, we can't find ready to use solution.
So we already have modern iOS working, and broken old devices (that can't run iOS > 9).

(PS. Yes I seen JSCWrapper code and it seems that FB can use custom JSC on iOS. But building JSC itself for iOS seems like hard work for most devs.)

[vovkasm]

Some thoughts about possibility to have one JS engine for build on any platform. If this possible it will be big benefit for manage package process.
Just idea (sorry if it looks like offtopic), currently we have only two JS engines which have enough features and can be built for Android/iOS:

• JSC - has version divergence even on iOS where it is system framework, and building one version for any supported platform looks problematically.
• ChakraCore - also don't ready for iOS in upstream repo, but see https://github.com/janeasystems/nodejs-mobile - they have working build system for iOS and Android.

[kelset]

cc @DanielZlotin

[dulmandakh]

It got easy to build JSC using script from its repo. See https://trac.webkit.org/wiki/JSCOnly and http://constellation.github.io/blog/2016/05/02/how-to-build-javascriptcore-on-your-machine/

[vovkasm]

@dulmandakh Do you really built it for android and ios with this script? )

[dulmandakh]

@vovkasm nope, but from the repo history I thought that the script is actively maintained

[vovkasm]

Ok, seems it contains some condition logic for ios... will try it soon... (I currently evaluate the possibility to build ios version of JSC to allow use of Proxy api in our applications which required by latest mobx versions)

[gengjiawen]

@dulmandakh I have built android-jsc and jsc-android-buildscripts. Both require lots of work for android specific. And you also need to build an icu. Both take very long to build.

[hey99xx]

jsc-android-buildscripts recently updated their readme regarding minSdkVersion being 21 ( react-native-community/jsc-android-buildscripts@fd68310 ).

Will this have an impact in future of RN, should we expect the same in this repo too? Will whatever Facebook use internally, if ever released, come with the increased minSdkVersion?

New apps can easily accept this new requirement, but for existing brownfield apps with only some pages written in RN, I fear this might be a obstacle of updating JSC versions :(

[fotonmoton]

While there is no solution right now maybe it is reasonable to create "React Native's JavaScriptCore: The missing parts"?
It can be repo with known issues and possible solutions to them. Because, I think, developer should be aware ahead of time about this tricky problems (hours or days wasted on figuring out why code runs in debugger but not on a device is not fun).

[kelset]

While there is no solution right now

There are solutions, and also we are planning to have the new JSC in the main repo too (probably by 0.59).

[fotonmoton]

@kelset yeah, but you should search for them yourself and solution are not so trivial (compile your own JSC?) or so trivial you think it already should be solved by RN (global polyfills?). Docs has info only about different js engines, there are no info about known issues and inconsistencies.

we are planning to have the new JSC in the main repo too (probably by 0.59).

It would be great.

[kelset]

Docs has info only about different js engines, there are no info about known issues and inconsistencies.

Would you mind adding that list of "known issues and inconsistencies" as a PR to that page in the docs then? Probably it would help I feel. There is even an open issue over there to cover the purpose of listing the known issues -> facebook/react-native-website#564 (it was meant for components but you can follow the template suggested anyway)

[fotonmoton]

@kelset looks like great idea. I try to find as many issues as I can. Where I can find current version of JSC shipped with RN? Maybe we can use caniuse.com db to list missing parts?

[gengjiawen]

see previous comment in this issue: #19737 (comment).

[kelset]

@fotonmoton awesome - thanks for helping out 😊 Feel free to DM me over on twitter if you need more info/help/anything.

[kelset]

@fotonmoton a couple of issues that probably fits well in the list you are working on:

• Date instance on eve of the beginning of daylight savings returns hour behind (Android) #21559
• toLocaleString has erroneous format on Android #22652
• Android JSC does not support exponentiation operator #19439
• Android version of JavaScriptCore's Array.keys() method returns object without Symbol.iterator method #22573

[hramos]

@DanielZlotin successfully upgraded the JSC in f3e5cce. Based on the current release cycle, it looks like @kelset's estimate will hold out: 0.59 will be the first release with the upgraded JSC.

[hramos]

As of f3e5cce, React Native apps on Android will automatically use the new JavaScriptCore (with x64 support). Closing as the commit is on master and due to be picked up in 0.59 or some other release.

[transitive-bullshit]

Very happy this change is making its way to release.

Are there any basic (or ideally comprehensive) performance breakdowns before & after that the community can view for large perf-related changes like this?

Just saying "it greatly improves performance" is definitely an anti-pattern in perf-related development.

[hey99xx]

Are there any basic (or ideally comprehensive) performance breakdowns

See https://github.com/react-native-community/jsc-android-buildscripts/blob/master/measure/README.md

Also it's not just about performance, it has the modern language features, and 64-bit support.

[transitive-bullshit]

Thanks @hey99xx!

[michaelknoch]

Im looking for a possibility to use my own build of jsc. Is there any way to override the downloadJsc task to use my own version?

we use another version of libc++shared in a ndk module and therefore we rebuilt jsc with this dependency. @hramos

[Kudo]

@michaelknoch
You may try gradle packagingOptions.pickFirst.
There is a solution for me to adopt JSC from jsc-android-buildscripts after RN 0.59.
react-native-community/jsc-android-buildscripts#91