Thanks for this awesome project! Looking forward to seeing where this goes :)
Features.md notes that let and const support is in progress. Is that still accurate? Does that mean if we use Hermes right now we cannot use let and const at all?
There are other things in progress too like "classes and method definitions" that sound like major limitations, but I'm guessing there are only edge case issues. Some example code of what is and isn't supported might be helpful in Features.md.
In the default React Native pipeline, the Babel transforms are run prior to the Hermes compiler, which should allow you to use modern JS features without needing to know the details of what Hermes itself is able to consume right now.
Any features listed in the "In Progress" section of the document are not officially supported yet, but we have started to add code to support them. This means that they should not be supplied directly as input to Hermes, because Hermes doesn't support fully spec-compliant behavior for them yet. In practice, however, this simply means that JS code which uses "in progress" features should be transformed by Babel into features which are supported by Hermes.
As to the two specific features you're inquiring about:
let/const are currently parsed and emitted as bytecode, but the end behavior is not spec-compliant yet, which is why they are listed as "in progress". Block scoping is not properly handled yet, for example.class. In your actual build pipeline you can lower classes into ES5-style functions via Babel, so this shouldn't be a major limitation in practice.Providing example code of precisely what is and isn't supported at the moment poses some difficulty, as we're in active development on all of these language features right now and the partial list of things we support changes week over week. We will move features from "in progress" to "supported" when the Hermes implementations are compliant and tested, at which point they may be supplied directly as input to Hermes.
If you notice there are features in the "supported" section which are not behaving as you would expect, please open an issue so that we can investigate any potential bugs.
That makes sense, thanks. If I'm understanding correctly, does that mean there is a long term goal to be able to use only Hermes and drop Babel from the build pipeline for the Android side of things?
Totally understood about the example code. After your explanation, that doesn't sound necessary.
Let me rephrase :) Maybe not a goal per-se, but long term one could do that?
Dropping Babel from the RN build pipeline entirely is not a current goal for Hermes. The code that developers write has various non-standard features such as JSX and custom operators which we are not working on implementing in Hermes, and Babel is used to turn these features used by developers into compliant JS which Hermes can understand.
Additionally, the ECMAScript standard is constantly being updated, and using Babel will allow developers to use these features before Hermes fully supports them in a spec-compliant way.
That clears things up, thanks!
Most helpful comment
Dropping Babel from the RN build pipeline entirely is not a current goal for Hermes. The code that developers write has various non-standard features such as JSX and custom operators which we are not working on implementing in Hermes, and Babel is used to turn these features used by developers into compliant JS which Hermes can understand.
Additionally, the ECMAScript standard is constantly being updated, and using Babel will allow developers to use these features before Hermes fully supports them in a spec-compliant way.