Replies: 3 comments 3 replies
-
|
👋 excited to hear Intl is being prioritized as an area for improvement in Hermes. A big issue for us with Hermes' Intl currently is the lack of support for The timing on this is not particularly ideal given the potential shift to ICU4C, but I've opened #1219 to share the implementation we have internally :)
This is exciting! I'd be curious to understand how much work has been done on this. I think it should be possible to move more of
As an alternative suggestion to explore, I'm wondering if you've considered migrating the implementation to Swift? It seems like Apple has focused on adding new ICU features to their Swift implementations instead of the Objective-C ones. This would continue to rely on an implementation which maps to the platform on iOS, but this seems like it might be possible to support reasonably with Swift's API improvements such as AttributedString and may be preferable to the performance penalty of calling out to JSC on iOS. Apple has been working on C++/Swift interop via Cmake so it should be feasible to call into Swift from Hermes' C++ code.
While working on this space I've noticed that some of the unexpected bugs and issues on iOS, Android, etc. stem from gaps in test262 that are unexpected (e.g. we exclude all tests that use |
Beta Was this translation helpful? Give feedback.
-
|
Apple is worked on a unified internationalization implementation for Swift here based on ICU for reference. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for sharing this, glad to hear that the new Intl approach will eliminate some of the problems you're facing.
We haven't started work on the new Intl implementation, so we would still welcome improvements to the existing implementations.
This is a great observation, and was an eventual goal when we started writing PlatformIntlApple.
It has come up, since there is certainly functionality that is now available in Swift that we cannot use from Obj-C (e.g. #1035). However, it doesn't offer a complete solution to the problem in the way that ICU or JSC would. We would continue to have to try and map JS APIs to what is available from the platform, and create a lot of sharp edges where they are mismatched. This makes the Intl functionality harder for us to develop, and harder for JS developers to use. In the longer term, we could consider keeping the using implementation or calling into Swift for simple/common operations, but we would have to be very careful to ensure that the implementation remains internally consistent. |
Beta Was this translation helpful? Give feedback.
-
|
I'm very excited to read this and will test out new implementations as soon as possible 🙌🏻. Thank you for the update! |
Beta Was this translation helpful? Give feedback.
-
|
This is very exciting news for Intl indeed! Recently becoming frustrated with the lack of support for UnicodePropertyValueExpression in Hermes' regex implementation (see #1027), I started taking a look at implementing this myself. It's pretty clear that the expectation is that you implement this with ICU, the predefined character sets in CoreFoundation are quite a lot more limited than ICU's character properties and property values. Do you think it would make sense to also use the approach of delegating to JSC for these tasks, or is extending And maybe a final, more general question, what do you expect the performance ballpark impact to be for work that is delegated to JSC? |
Beta Was this translation helpful? Give feedback.
-
|
That's an interesting question. I think the guiding principle here will be whether the binary size cost of including it will be prohibitive, as it is with Intl. If the size hit is small, it is preferable to distribute the data with Hermes, since the functionality will work without needing to take a dependency on ICU/JSC.
We don't really know yet. While calling out to JSC certainly adds additional overhead, JSC may also have more aggressive caching of Intl data than our current implementation, which could offset the performance penalty. My expectation is that on balance, there is unlikely to be a meaningful regression for the majority of usage. It is also useful to observe that our current Android implementation calls into Java for every operation. |
Beta Was this translation helpful? Give feedback.
-
Opening this discussion to discuss problems with the Intl implementation, and share our plans for addressing them. We’re aware that the current implementation has missing functionality and bugs on both Android and iOS, and are working towards addressing these while minimizing the cost and disruption to users.
Our current strategy has been to implement Intl on top of the platform APIs available on iOS and Android, with the aim of minimizing the binary size impact. As we’ve expanded the implementation, we’ve found it very difficult to map Intl onto the available APIs, and encountered significant maintenance overhead when building and testing the separate implementations. Our hope is to tackle these shortcomings and provide a better experience for developers with these changes.
On non-Apple platforms, we intend to implement Intl on top of ICU as is done by other engines. This will allow us to provide a complete and compliant implementation that aligns with other engines. On platforms where ICU4C is not available, this will come at significant binary size cost.
While this means that Android apps using Hermes with Intl will incur a large size penalty, the latest versions of Android do provide ICU4C so we expect that penalty to go away once we advance our minimum supported version of Android past API level 31 (unless we have a hard requirement on APIs that are not exposed). We will also continue to support building Hermes without Intl for applications sensitive to size.
On Apple platforms, ICU4C is not readily available. Our current approach using Foundation has run into limitations with the set of features we can support. We are currently planning to instead migrate that code to internally delegate to JavaScriptCore, which allows us to provide Intl without additional binary size cost.
Please share any bugs and limitations with the current implementation that are blocking you from using Hermes. We will prioritize these as we rework Intl.
Beta Was this translation helpful? Give feedback.
All reactions