RFC: lean core JSC #836
RFC: lean core JSC #836
Conversation
|
Is that 32mb of space saved on app bundles downloaded by end users? |
no, it's only on the developer's building host. |
|
Nice, still awesome to see! Love this. |
|
FYI @Saadnajmi |
proposals/0836-lean-core-jsc.md
Outdated
|
|
||
| ## Proposed Changes and Timeline | ||
|
|
||
| - Version 0.77: Remove the [`jsc-android` npm dependency](https://github.com/facebook/react-native/blob/2d337efc23c662143b3f39a6c994d80fec047054/packages/react-native/package.json#L132) from React Native and instead download the artifact from Maven Central. When using Hermes, downloading the unused npm dependency is unnecessary and removing it saves about 32 MB of uncompressed size. |
There was a problem hiding this comment.
Is this needed in 0.77 for 16KB page support?
There was a problem hiding this comment.
yes, but if there's concern to cherry-pick facebook/react-native#47972 to 0.77. we can postpone the mavenCentral migration to 0.78. on 0.77 we still use jsc-android npm package for a newer version with android 16kb page support.
There was a problem hiding this comment.
I'd rather go with 0.78.
Our take on 16K support is that it's Hermes first. Originally we were not even planning to include JSC for 16K support.
proposals/0836-lean-core-jsc.md
Outdated
|
|
||
| ## Adoption strategy | ||
|
|
||
| We will offer a drop-in replacement with the `react-native-javascriptcore` npm package while maintaining JSC support in the core for two additional React Native releases to ensure a smooth transition. |
There was a problem hiding this comment.
If the boundary is jsi::Runtime, then I think that means there could be frequent updates needed against RN package.
The current structure has a nice benefit of keeping it up to date automatically, since it must build in line with JSI changes. But I think it means the project would need a long term maintainer to continue working. See microsoft/v8-jsi@4438466
Depending on whether there is a natural maintainer, the other option would look like a harder deprecation, which would still allow externally maintained runtimes to develop.
There was a problem hiding this comment.
this is also the same problem for https://github.com/Kudo/react-native-v8. i can try to maintain the in my spare time (also love to have other maintainers from community)
maybe we need to include nightly testing from v8 and react-native-javascriptcore, so that we can catch jsi interface breaking changes and take action earlier.
There was a problem hiding this comment.
We'd be happy to help with maintenance of that RN <-> JSC integration at Callstack
There was a problem hiding this comment.
awesome! love the collaboration with someone from Callstack then.
|
This align with our plans for next year. Not sure whether we can do it in 0.77, because the RC0 is already out and we want to reduce the stabilization time. We might have to shift the timeline by 1 release, but next year we plan to do a release every couple of months, so it shouldn’t delay it that much. @cortinico I know you have thoughts on this! 😄 |
that's fair. we can also do npm |
proposals/0836-lean-core-jsc.md
Outdated
|
|
||
| ## Proposed Changes and Timeline | ||
|
|
||
| - Version 0.77: Remove the [`jsc-android` npm dependency](https://github.com/facebook/react-native/blob/2d337efc23c662143b3f39a6c994d80fec047054/packages/react-native/package.json#L132) from React Native and instead download the artifact from Maven Central. When using Hermes, downloading the unused npm dependency is unnecessary and removing it saves about 32 MB of uncompressed size. |
There was a problem hiding this comment.
I'd rather go with 0.78.
Our take on 16K support is that it's Hermes first. Originally we were not even planning to include JSC for 16K support.
|
I'm very supportive of removing JSC from the default download/build, but I'm concerned about the signal loss of moving all of our testing to out-of-band 3P integration tests. How should we ensure that our JS changes don't break compatibility with JSC, including, say, (Internally I've suggested |
at the beginning we can only run some basic e2e test with nightlies testing. for js regression that may impact to user, we may wait issue report until user find problems. that's more like what community js engine support like v8. if we really care about quality alignment for jsc, then maybe we should still keep jsc in core. a good news on the other hand is, after moving out jsc to community. i plan to upgrade jsc-android to newer WebKit based version. that should support more modern js features. |
writing a proposal to move JSC away from core
View the rendered RFC