Consider supporting Proxy

[tychota]

In https://github.com/facebook/hermes/blob/master/doc/Features.md Proxy is listed as Excluded From Support. With

Hermes plans to target ECMAScript 2015 (ES6), with some carefully considered exceptions.

What are those considerations regarding Proxy?

Especially some library in JS environnement like:

• mobx 5
• immer
  rely on proxy support. It is super usefully to add observability upon an object access which helps building reactive apps.

Would it be technically possible to have support as an external / optionnal *. aar so it does bot affect the size of hermes ?

Solves:

• Problem with MobX 5+ : Your environment doesn't support Symbol and Proxy objects. #28

[creativefctr]

I think this is a very important feature! After Redux, MobX is the most used state management solution with React which is getting more popular every day.

[lishine]

Not only that, many state management libs are based on proxy, such as react-easy-state, and many other include Immer, such as easy-peasy.

[tlvenn]

It seems there is a misconception that Immer or Mobx absolutely need proxy to work which is not true.

https://twitter.com/mweststrate/status/1150138659909361665

[itsMapleLeaf]

They're not required, but performance with proxies is significantly faster than with JS getter/setter properties. That, and non-proxy builds have some pitfalls that don't exist in proxy builds.

[crutkas]

For helping prioritizing, does anyone have data that shows popular apps / libraries are performing badly without this? Just like any team, prioritizing features and resources is critical.

@lishine, do you have a list? the more data and targeted we can be, the more we can measure

[lishine]

Performance comparison aside, the bellow state management libs do not use immer, they rely on proxy and symbols, I have used them or considered to use, and there are many more:
react-easy-state
parket
react-recollect

Of course they are not big sharks like mobx, but are useful for their size, speed, simpliness and easiness.

[fbartho]

We too rely on Proxy for a small chunk of our infrastructure. -- Before JSC supported it, we wrote a micro-ponyfill that sort of implemented some of the features we needed. (It's impossible to Polyfill most of the Proxy API because it requires low level engine support). It had so many caveats that we did not publish this as open-source.

It would definitely be ideal if Hermes added support for this API! -- We don't need the full Reflection API / I don't think I even understand what that would entail, but Proxy is super powerful on its own.

[chevonc]

+1. Proxy support would be great to have as well. We decorate our data models with a Proxy caching layer to speed up computations. We're also intending to upgrade keep up-to-date with mobx, but lack of support in hermes would bar us from doing so

[iEchoic]

+1 - MobX aside, proxies are incredibly useful constructs that we want to use directly in our own code and cannot while using Hermes.

[tcodes0]

I'm working on crypto projects and ethereum js uses Proxy. Support for this on hermes would be highly desireable

[mtford90]

Proxies allow for a somewhat cleaner API when inspecting and debugging e.g. with mobx v5. This would be awesome to have.

[fossage]

@crutkas

Regarding performance benchmarks:

From the Immer docs

The ES5 fallback implementation is roughly twice as slow as the proxy implementation, in some cases worse.

Considering the operations are generally very quick anyway, this doesn't seem like the biggest deal in the world. That being said, I think proxy support would be a fantastic addition to Hermes. As proxy support in general becomes more widespread, I think we will see more and more libraries taking advantage of them, and potentially even omitting support for non-proxy environments all together. It would be a real shame to be locked out of certain parts of the ecosystem because one aspect of your JS runtime couldn't support it.

All of that being said, this is a really cool project and thanks for working on it!

*Unfortunately I have yet to find any benchmarks on MobX4(non-proxy version) vs MobX5(proxy version).

[carlosroberto555]

I have used a library that uses mobx5, but when I install on my project with hermes I need to make manual change to mobx4 on yarn.lock, etc
This is complicated, because can on future come more libraries using proxy and with hermes will be impossible to use.

Please consider proxy support.

[d4rky-pl]

To keep the engine’s size small, we have chosen not to support a few language features that do not appear to be commonly used in React Native apps, such as proxies (...)
— Source

I believe this is a very dishonest take, considering the support for proxies was broken for Android since forever so people were coming up with workarounds to avoid using them in the first place

[driley-emoney]

Proxy allows for a whole realm of capabilities, previously impossible in javascript. By blocking it because its "underused" is preventing those capabilities from being explored.

The ability to analyze which properties a function accesses has some great advantages. Currently we use it to know exactly which parts of our state to persist on redux state changes.

We don't use it in any type of situation where it would create a performance problem. Both the claims for not implementing (underuse, performance) are invalid.

[mhorowitz]

I’d like to explain a little more about our thoughts on Proxy. Our concern is that Proxy inserts itself into the JS engine in many places. In an interpreted engine like Hermes, this adds overhead, even if Proxy is never used. For example, when looking up a property on an object, now Hermes needs to check on every call if the object is a Proxy, and branch to a separate code path, even if this branch is never taken. This is not a large cost, but it happens very, very often. Even a little extra cost repeated many times can add latency, even with CPU branch prediction. There are also performance improvements we’d like to investigate which use static analysis of the JS code, but with Proxy, static analysis becomes much harder.

That said, it would appear that our evaluation of the use of Proxy was inadequate. We looked at Facebook RN apps (of which there are many), and FB does not use any of the packages in common use in the community which depend on Proxy. This led us to believe Proxy wasn’t important, but it is now one of our most requested features.

We have begun to investigate how we can implement Proxy without significant impact to performance, and we hope we can build something which meets the needs of the community. But, since we hadn’t originally planned on doing this work, it’s a low priority task, so we can’t give any estimate when Proxy would be available for Hermes. We ask for your patience as we investigate the best way to move forward.

[driley-emoney]

@mhorowitz thanks for providing the explanation. I'm a bit out of my depth with how the VM works, but curios... Is similar branching already happening with computed properties like getters? To me it seems like a similar scenario where you have to execute some code when a property is accessed.

[mhorowitz]

Yes, property accessors also require branching, and we've been careful to minimize those costs. We can overlap the checks in some places, due to the nature of C++ bit comparisons, but not everywhere. Mainly, proxies modify a lot more code paths than accessors do. For example, there's no accessor equivalent to the ownKeys and getOwnPropertyDescriptor traps, and these end up affecting the behavior of a surprising amount of the system.

[sirsavary]

@mhorowitz I'm not a totally versed on VMs but would it not be possible to put Proxy behind some sort of flag? I'm sure some people wouldn't mind opting into the performance hit for improve DX w/ proxies

[mhorowitz]

It would be possible to make it a build flag, but this creates long-term support issues. Flags combine to describe a exponential number of builds. So either everyone need to build the VM from source to set the flags they want, which complicates integration, or we need to create an ever-increasing number of binary releases to support combinations of flags. So this is not a first-choice strategy.

[jamonholmgren]

Could you statically analyze the JS code bundle when you load it to look for Proxy and eliminate any proxy-related code paths if it’s not used in the code base, @mhorowitz? This is one benefit to having all of the JS code known at load time.

[mhorowitz]

This is an interesting idea. In some sense, this is similar to what JITs do when they generate machine code based on observation of the code itself.

My initial impression is that like a JIT, the tradeoff is not ideal for mobile apps. Android is eliminating writable code pages, so we'd need to ship two copies of the engine, or to be able to copy the entire engine with some pieces removed. Either is plausible, but it seems like it would impose nontrivial costs in app size, or in startup I/O. We could move this decision to compile time, and ship only a single engine, based on the JS code at build time, but then technology like code push could add use of Proxy, which could cause issues.

If instead we can structure the implementation to make Proxy very low cost even when present and unused, that seems like the best overall solution.

[ShaMan123]

+1

[mateosilguero]

@schrulnz you could do: npm install [email protected]

[schrulnz]

Sorry, I had a little mistake in my comment. I already did npm install [email protected]. But React Native still uses the v0.5.1 as dependency. Do I have to change something in the RN installation?

[mateosilguero]

No, no extra changes are needed. Did you see "hermes-engine": "0.5.2-rc1", at your package.json ?

[evelant]

@schrulnz To rule out any caching issues you could delete node_modules and package-lock.json (beware removing package lock can cause minor version changes depending on your package.json but usually it isn't an issue) then run npm install again. Then go to your android folder and run ./gradlew clean.

As long as your package.json says "hermes-engine": "0.5.2-rc1", those steps will ensure the correct version gets installed.

[schrulnz]

Thanks for the help. @mateosilguero, yes my package.json says "hermes-engine": "0.5.2-rc1",. But even after the steps of @AndrewMorsillo, my package-lock.json holds "hermes-engine": { "version": "0.5.1",in dependencies > "react-native" > dependencies.

Also in package-lock.json, dependencies > "hermes-engine", it says ""version": "0.5.2-rc1", though. So to me it seems like the npm install works fine, but RN is installing the 0.5.1 version and not using rc1.

[schrulnz]

I solved my issue by using npm-force-resolutions: https://stackoverflow.com/a/62956076/12984119. This overrides nested npm dependency versions.

[Evan-Younan]

@a-eid @Kikketer noted that at https://github.com/facebook/hermes/releases, we explicitly documented the specific RN version that a Hermes release is aimed at, e.g. v0.5.* was for RN 0.63.*, while the 0.6.* and 0.7.* were both for RN's upcoming 0.64.*.

The rule of thumb is just to follow it strictly, since that's the combination we've tested and ensured that they should work. If you encountered instant crash on your apps, it's very likely a version mismatch.

I think the issue is the lack of this documentation on the actual Hermes setup pages and README file. I only ever found out about the compatibility through this thread. Maybe a reference to this versioning should be cited in both?

[byteab]

what about react native firebase. it will not work with proxy anymore

[mhorowitz]

Proxy is now enabled by default starting from RN 0.64:

We have added Proxy support to Hermes, enabling compatibility with popular community projects like react-native-firebase and mobx. If you have been using these packages you can now migrate to Hermes for your project.

-- https://reactnative.dev/blog/2021/03/11/version-0.64#hermes-with-proxy-support

[yzhangdegit]

In order to make it easy to use ES6 Proxy, we've created an npm you can use to opt-in: https://twitter.com/HermesEngine/status/1245136667414913024

1. Upgrade your app to React Native 0.62
2. npm install [email protected]
3. build and install your app

This will only work with RN 0.62. If your using an older version of RN you must upgrade to use Proxy. Using Hermes 0.4.x with RN 0.61.x will most likely crash.

If you use Proxy, or a library which uses Proxy, please let us know your experiences here! Once we have confidence this is stable for the community, we will enable Proxy by default.

If you observe any bugs with Proxy, we'd like to know about that, too. Please open a new issue, instead of commenting here. Thanks!

thanks! it's work. I have another question, enableHermes is working ,but there is no significant improvement in performance? I don't have any ideas.